背景
随着新功能的增加，代码库越来越大，当我们部署新功能时，需要将整个系统完整同步到生产环境，如果某同事的问题代码被发布到生产环境，可能会导致整个系统瘫痪，很难快速定位问题，这也是单块系统最大的弊端。
为了解决该问题，人们便想方设法的模块化、清晰化自己的项目，将整个系统拆分为若干个小而单一的功能，以服务的方式提供给上层业务部门，每类服务有专人负责，通过单独部署某个服务来避免发布无关的代码导致的系统瘫痪。这就是微服务。
那如何拆分服务呢？
如何拆分服务
我们先从几个原则说起。
单一职责原则
了解过面向对象的人应该都听说过“单一职责原则”，即每一个类都拥有一个职责。比如一个搬砖类，它既可以盖房子，也可以用来拍人，这时搬砖就拥有了两个职责，所以我们应该把类拆分为两个。微服务也是一个道理，我们应该做到一个服务是用来做一件事情的。我们怎么样才能做到该原则呢？
松耦合
在工作中，当我们修改了一个服务就不需要再去修改其他的服务，那么我们就做到了松耦合。
一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息。这也意味着，应该限制两个服务之间不同调用形式的数量，因为除了潜在的性能问题之外，过度的通信可能会导致紧耦合。
高内聚
当我们想要修改某个行为的时候，最理想的方式就是修改某一个服务然后尽快上线，如果需要部署多个服务的时候会增大风险性。所以要遵守高内聚与松耦合才能尽可能的实现单一职责原则。
我们现在了解了高内聚、松耦合，那应该把什么聚在一起，什么隔离开来呢？换句话说，服务之间的边界该怎么划分呢？
DDD
DDD中文叫做领域驱动设计，《领域驱动设计》一书中使用细胞作为比喻：
细胞之所以会存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜。
那我们怎么按领域来划分服务呢？对，我们可以按业务进行拆分，比如财务、订单、仓库等等。这样我们的团队也可以拆分开来分别负责不同的服务，这样不仅项目清晰了，就连公司内部的组织结构权责分配也变得清晰了。
刚才从横向来看我们可以按业务领域拆分，纵向的呢？我们可以按层次进行拆分，比如最底层的数据层、基础设施层以及与业务无关的推送、邮件、短信等等。我们还可以按安全性、性能等需要特别关照的以及通用的功能进行抽离沉淀。
原来掌握了领域驱动设计不仅遵守了高内聚、松耦合还符合了单一职责原则，那还不赶紧拆起来？！
避免过早拆分
过早的划分服务，可能发展一段时间之后，服务的边界会和之前有所不同，导致很多跨服务的修改，代价越来越高，最终又变成了单块系统。所以一开始我们应该按照较粗的粒度进行划分，而是否拆分为更小的服务，应该由团队组织结构决定，如果团队对拆分后服务的维护成本更大了，那就应该放弃拆分更小的粒度。
总结
我们看到了领域驱动设计对微服务的划分是非常有利的，但是领域驱动设计的水很深，还需要慢慢参透才能拆分出更加合理的服务。
|
