微服务拆分原则

拆分原则

• 单一职责原则

  每个微服务只需关心自己的业务规则，确保职责单一，避免职责交叉，耦合度过高将会造成代码修改重合，不利于后期维护。

• 服务自治原则

  每个微服务的开发，必须拥有开发、测试、运维、部署等整个过程，并且拥有自己独立的数据库等，可以完全把其当作一个单独的项目来做，而不牵扯到其他无关业务。

• 轻量级通信原则

  微服务间需通过轻量级通信机制进行交互。首先是体量较轻，其次是需要支持跨平台、跨语言的通信协议，再次是需要具备操作性强、易于测试等能力，如：REST通信协议。

• 接口明确原则

  明确接口要实现的内容，避免接口依赖，如A接口的改动会导致B接口的改动。

• 持续演进原则

  单体架构向微服务架构拆分过程中，无法做到一蹴而就，刚开始不建议拆分太小，过度拆分将会带来架构复杂度的急剧升高，开发、测试、运维等环节很难快速适应，将会导致故障率大幅增加，可用性降低，非必要情况，应逐步拆分细化，持续演进，避免微服务数量的瞬间爆炸性增长。

拆分方法

• 业务领域拆分

  基于领域模型，围绕业务界限上下文边界，将同类业务划归为一个微服务，按单一职责原则、功能完整性进行微服务的拆分。

• 需求变化频率

  需要识别业务需求的变动频率，考虑业务变化频率与相关度，将业务需求变动较高和功能相对稳定的业务进一步分离拆分。

  因为需求的经常性变动必然会导致代码的频繁修改和版本发布，这种拆分可以有效降低频繁发布版本的业务对不需要经常发布版本的业务的影响。

• 服务性能要求

  需要识别性能压力较大的业务。因为对性能指标要求高的业务在资源需求上会比其他业务的高，这样可能会拖累其他业务，也会造成资源无谓的浪费。为了降低对系统整体性能和资源要求的影响，我们将对性能方面有较高要求的业务与对性能要求不高的业务进一步拆分。

• 组织架构和团队规模

  除非有意识地优化组织架构，否则微服务的拆分应尽量避免对组织架构和团队的调整，避免由于功能的重新划分，而增加大量且不必要的团队之间的沟通成本。

  在进行微服务拆分和组建项目团队时，应尽量将沟通边界控制在团队内。

• 安全边界

  对于有特殊安全要求的业务，应独立出来，避免因不同的安全要求，而带来不必要的成本，或带来泄密的风险。

• 技术异构

  虽然都是在同一个业务领域内，但由于各种条件的限制，在技术实现时可能会存在较大的差异（存在技术异构的问题）。

  对应这些存在技术异构的业务功能，可以考虑按照技术栈的边界进一步拆分。