从混乱的单体应用到微服务架构

混沌阶段

• 所有功能在一个项目里面

• 项目里面根据功能划分为若干Service实现业务

• Service通过DAO访问数据库

• 业务逻辑没有清晰地表现出来，和数据库访问、前端接口耦合在一起

如果你的项目在这个阶段，你需要做的是：

• 拆分出业务逻辑、业务实体，将业务逻辑、业务实体和数据库访问、对外接口等隔离开。

• 运用DDD编程思维，拆分出业务领域。

• 完成后，你将达到第二阶段

混沌初开

• 业务领域被拆分出来，形成若干独立的业务领域

• 具体到前端功能，可能由多个业务领域组合。比如用户注册，可能涉及到的用户、短信两个业务领域的组合。这个组合在ServiceFacade里面完成

• ServiceFacade，对外提供服务接口，通过组合N个业务领域，完成最终业务

每个Domain的结构如下：

拨云见日

接下来，随着项目的业务开始增长，你发现单个服务不能满足要求，他变得太大了，你需要拆分成多块，分给不同团队开发：

• 把不同的业务模块，拆分成多个项目。比如后台管理员、后台业务员、商品搜索、订单服务等

• 不同服务之间，通过共享Domain 、Domain的外部实现，来把业务领域引入到自己的项目里面。

• 每个服务本质上是通过Domain，来直接操作数据库。

• 这个时期虽然分为若干应用，但业务层面保持了DRY原则，大家都直接访问数据库。

到了这个阶段，绝大部分产品就没有问题了，如果业务量不进一步增长，就可以满足业务需求。不过是随着业务复杂度上升，拆分了更多服务和领域对象。但如果随着业务量迅速上升，原来的单一数据库逐渐不能满足需求，我们就需要进化到微服务了。

由于之前对业务和业务领域已经拆分干净，所以进化到微服务也比较容易（但仍然有很多工作）。

微服务