SpringCloud：
谈到 SOA 和微服务的区别, 那咱们先谈谈架构的演变
1. 集中式架构
项目功能简单, 一个项目只需一个应用, 将所有功能部署在一起, 这样的架构好处是减
少了部署节点和成本.
缺点: 代码耦合，开发维护困难, 无法水平扩展, 单点容错率低，并发能力差
2. 垂直拆分架构
当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我
们根据业务功能对系统进行拆分：
优点：
系统拆分实现了流量分担，解决了并发问题
可以针对不同模块进行优化, 方便水平扩展，负载均衡，容错率提高
缺点：
系统间相互独立，会有很多重复开发工作，影响开发效率
3. 分布式服务
当垂直应用越来越多, 随着项目业务功能越来越复杂, 并非垂直应用这一条线进行数据
调用, 应用和应用之间也会互相调用, 也就是完成某一个功能,需要多个应用互相调用, 这就
是将功能拆完来完成的分布式架构.
优点: 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率
缺点: 系统间耦合度变高，调用关系错综复杂，难以维护.
4. 服务治理架构 SOA
SOA ：面向服务的架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调
度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资
源调度和治理中心(SOA)是关键, 而最初的服务治理基石是 Dubbo 服务治理
以前分布式服务的问题？
服务越来越多，需要管理每个服务的地址, 调用关系错综复杂，难以理清依赖关系
服务过多，服务状态难以管理，无法根据服务情况动态管理
SOA 服务治理架构的优点:
服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
动态监控服务状态监控报告，人为控制服务状态
SOA 服务治理架构的缺点：
服务间依然会有依赖关系，一旦某个环节出错会影响较大(容错机制)
服务关系复杂，运维、测试部署困难，不符合开发-运维一站式维护的思想.
5. 微服务
前面说的 SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行
拆分。因此两者非常容易混淆，但其实缺有一些差别：
微服务的特点：
单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责.
微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服
务虽小，但“五脏俱全”。
面向服务：面向服务是说每个服务都要对外暴露 Rest 风格服务接口 API。并不关心
服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供
Rest 的接口即可。
自治：自治是说服务间互相独立，互不干扰
团队独立：每个服务都是一个独立的开发团队，人数不能过多。
技术独立：因为是面向服务，提供 Rest 接口，使用什么技术没有别人干涉
前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、
移动段开发不同接口
数据库分离：每个服务都使用自己的数据源
部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持
续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，
易维护. 基于 docker 容器是开发.
目前微服务微服务架构主流的是 SpringBoot+Dubbo 和 SpringBoot+SpringCloud
的架构模式.
综上, 无论是 SOA 还是微服务, 都需要进行服务调度, 目前主流的服务调度室 RPC 和
HTTP 两种协议, 而 Dubbo 基于 RPC 的远程调度机构, SpringCloud 是基于 Rest 风格(基
于 http 协议实现的)的 Spring 全家桶微服务服务治理框架. 说到这里也可以继续说下
Dubbo 和 SpringCloud 的区别.
