前面主要讲了单体和垂直应用架构，这一节主要讲分布式、SOA和微服务架构。 演变历程：
分布式架构
抽出业务无关的公共模块
比如上图，一个电商系统的订单管理可能要用到用户服务、商品服务、订单服务。
而后台系统也可能用到用户服务，商品服务等，把这些服务抽出来，这些服务可以叫做组件，系统与组件之间的链接方式可以通过网络
优点：业务无关的独立服务
缺点：组件或者服务的bug可导致多个系统瘫痪，甚至全栈瘫痪；不同服务之间可存在冗余；
调用关系复杂
SOA面向服务的架构
开始引入服务、服务注册的概念
服务：所有的业务功能都是一项服务，服务就意味着要对外提供开放的能力，当其他系统需要使用这项功能时，无须定制化开发
ESB：Enterprise Service Bus，企业服务总线，ESB将企业中各个不同的服务连接在一起
服务注册：将所有的服务接口（很多时候是hession协议的接口）,注册到一个中心的分布式服务集群上（你可以考虑成apache的zookeeper服务实现的效果）。各个业务系统直接访问分布式服务查找需要调用的接口位置，进而调用。
微服务架构
微服务是一种经过良好架构设计的分布式架构方案，微服务架构特征:
1.单一职责:微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
2.面向服务:微服务对外暴露业务接口
3.自治:团队独立、技术独立、数据独立、部署独立
4.隔离性强:服务调用做好隔离、容错、降级，避免出现级联问题
根据功能细粒度拆分，使用轻量级的RPC框架进行通信，独立部署
微服务架构更强调服务的彻底拆分，是将系统根据功能细粒度拆分为一个个小的可以独立部署的微服务，服务间通过轻量级的RPC框架进行通信。每个服务可以使用不同的语言、使用不同的数据库。
【优点】
- 服务彻底拆分，各服务独立打包、独立部署和独立升级。
- 微服务之间可以采用轻量级RPC框架进行通信。
【缺点】
- 分布式系统开发的技术成本高（容错、分布式事务等）
- 多服务运维难度增大
