背景

现在微服务比较流程，那么对于微服务的拆分方法也比较让人困惑。本文从不同的角度切入后以系统的、全面的、统一的方式为各位介绍服务拆分的问题。

问题定义

服务划分具体的问题在哪里？
- 服务划分是对于具体技术的选择？
  是选择使用纵向切割的方式，还是使用横向切割的方式将业务切割开。这个切割方式是不是有效，直接对于业务切割是否能够满足其他方面的要求。都是需要考虑的。
- 还是在实现过程中遇到的服务聚合的问题？
  很多人对于OO的理解都没有深入就开始抽象服务，这些人对于SOLID的追求，还是对于KISS，DRY的追求？在追逐这些的同时反模式的考量在哪里？
- 还是在架构层面管理可用、可靠？
  架构层面的要求不止是可用、可靠。还有对于安全，对于可扩展性的要求。对于服务划分这个任务是否需要满足？
- 还是在于对业务模型的确认？
  对于业务模型的验证是需要越快越好的。我们是否可以在服务拆分的过程中就将业务模型验证了？
- 还是在于业务团队之间的合作是否有效？
  团队之间是否会产生相互推诿的问题，是否是因为工作责任未定义明确。根据康威定律这是在所难免的，出现这样的问题要不修改组织结构，要不修改技术架构。
- 新业务加入的是否怎样拆分？
  对于新业务加入是使用流程的方式加入？还是使用业务聚合的方式加入？还是使用其他的方式加入？在我们整体的服务拆分策略里都是需要考虑的。
- 还是在于企业的发展规划？
  企业需要发展，企业需要降低成本，企业需要加快发展速度，企业需要吸引更多的客户。
问题需要全面、统一的看待

从上面可以看到服务拆分并不是一个问题，而是一个复杂的领域。这个领域内需要通盘考虑的问题比较多，所以就会涉及到不同层面的划分方法。并且这里还会涉及到静态划分规则和动态划分规则的问题。所以，这里先将问题分类，在针对问题做解决域的考虑。
- 静态划分解决方案
  - 公司战略层面
  - 业务管理层面
  - 技术架构层面
  - 具体实现层面
- 动态划分解决方案
  微服务在演进过程中会遇到的问题，以及解决他们的办法。

问题解决

在一个业务是否应该放在某一个特定的服务上

几条大原则：
- 解决问题的三种办法：抽象，分解，知识。
- 全局、系统的考虑问题。
  站在全局的层面思考与解决问题。
- 服务中心一定是不断发展的。
  随着业务的不断发展，服务中心会不断的演进。技术架构设计不是一劳永逸的。
- 服务中心中的服务形态多样性。
  成为业务的服务，成为工具的服务，成为数据的服务等。
- 服务中心可以演变为服务群。
  一个服务可以逐渐的演变为一个独立的业务形态，独立的业务群。
静态划分解决方案
- 公司战略层面
  每一个服务都是一种能力或多种能力的提供，可以赋能给更前端的应用系统。使用大中台的概念控制公司的战略层面的划分规则。使用这样的结构固化企业的核心业务，使其真正的成为企业的核心。并为创新提供可能。并使用最技术的层面去解决与竞品之间竞争的问题。
  
  公司的战略划分
- 业务管理层面
  企业的业务是经过多个层次，逐渐的进行流转的。所以，一个业务可以看成是一个业务流。对于这个业务流中所涉及到的服务为我们服务体系中的服务。而不是某一个业务流就是我们中台，前台，后台中的服务。下图中是阿里体系中的业务流程。这些业务流程设计到纵向的内容就可以拆分成一个个独立的服务。
  
  业务流程

业务的组织形式辐射的形式发散出去。使用业务模型的方法去建立业务层面的服务拆分。针对业务域中的角色，功能进行拆分。在业务规划层面使用ToGaf的架构设计方法AMD去完成企业数字化的设计。

业务划分

技术架构层面

很多人认为微服务拆分就是技术的事情。其实在这个过程中上下游的工作形式，工作方法都与技术服务的拆分工作密切相关。在技术层面使用微服务的4个设计原则和19个解决方案+DDD+架构模式+技术考量等等组合成为技术架构层面的拆分规则。

四个设计原则

服务划分策略

具体实现层面
在具体的实现层面需要考虑的就是服务是否可以达到数据一致性原则，CAP原则，BASE原则。
动态划分解决方案

演进的过程与决策的过程。服务中心是需要业务不断的滋养才可以形成。但是需要定义规则进行相关的设计与实现。在动态划分的方面是需要有决策组织进行帮助决策的。例如在一个新的业务线加入到平台中时，需要有决策组去决策是否可以把新业务线加入到平台中。