事件驱动架构(EDA)

把服务根据业务关系分拆成多个平行的业务，从业务上解耦系统。（这个时候也可以根据服务分拆数据库，这一般看数据库的处理能力，如果数据库不是瓶颈没有必要做更细的分拆）

在这个阶段可以采用事件驱动架构，这种架构部署起来比较简单，从烟囱型架构过度到这种架构还是比较平滑的。支付宝早期的一种做法是，把原来写在一起的臃肿的业务逻辑，分成多个功能专一的业务逻辑，服务之间通过JMS异步消息交换数据。这种架构的关键是消息队列（MQ），比如Apache的ActiveMQ，支付宝的MessageBroker。

面向服务的架构

欲穷千里目，更上一层楼。前三个阶段的设计可以支撑小型团队从无到有从有到优的平滑演进，但是随着系统的继续膨胀，拓展不同的业务之间的数据串联，需要更好的业务划分。

这些年最流行的方式便是SOA（支付宝07年左右已经开始做相关工作，现在内部已经是全面SOA化）。SOA是一个比较虚的概念，实施并不容易。

面向服务的框架把业务重新组织成独立的服务，服务之间高内聚低耦合（类似OO）。一般服务间的通信方式为RPC，在服务多了之后需要做管理平台把各种服务组织起来，利于服务的管理和发现。现在已经有很多SOA方案可以使用：

每一个biz服务都可以在配置中心（ConfigServer）上订阅、发布服务，Biz订阅某个服务之后，可以通过配置中心获取服务的实际地址（类似DNS解析），然后可以和被订阅的服务直接点对点通信。

SOA和EDA并不是相互取代的，而是相符相乘的，两者处理的业务场景很不一样。举一个例子，比如A需要跟B传递一个消息，但是A和B互相不认识，但是他们都知道C，这时候，A可以直接告诉C - “帮我把消息传递给B” 或者是叫C把B的联系方式发过来自己联系。前者是EDA后者是SOA。

平台化架构

从事件驱动架构到SOA做的事情都是一样的，业务分拆，模块化开发。平台化架构在SOA的基础上，从更高的抽象层面把各种服务分拆成“云”。并对SOA和EDA架构的一些缺点予以改进。比如SOA中的RPC调用，在跨机房的情况下性能是非常低的，解决方案是合并部署/单元化部署。

合并部署 把相关的服务部署在整合在一起，把远程调用转换成本地调用 单元化部署和异地部署 把服务打包成一个单元，部署在一个区域（物理区域），每个区域部署相同的节点，提高系统的可用性。

其他问题

数据库分片 单机数据库容易达到磁盘上限，那么就需要有分库系统，提供统一透明的接口，底层实现自动的分库存储。

一致性事务 在业务分拆的过程中，如果各个子系统还使用同一个台数据库，那么很容易出现数据库瓶颈问题，而且不利于数据库的管理，每个服务应该使用自己的数据库。这样会带来新的问题，如果一个操作会同时写入两个数据库，那么如何保证这个两个写入的一致性？在单机数据源的情况下，一般都会使用遵循ACID原则的单机事物，但是在大型分布式系统中，这种方式已经失效，比如J2EE的2PC两阶段提交会拉低整个系统的系能，现在主流的处理方式是使用遵循BASE原则的一致性事物，从业务规则上来达到数据的最终一致。