微服务的拆分一直是历史性的难题，行业内更是没有具体的拆分标准，拆分的好坏更多取决于拆分者的经验，并经过反复迭代，逐步优化、调整，以达到比较合适的划分。
本文包括微服务的拆分时机、拆分原则、拆分方法，用于指导微服务的拆分工作，希望能够对大家有所启示。
1.拆分时机
微服务拆分绝非是一个大跃进的过程，拆分时机不对，很容易把一个应用拆分的七零八落，最终大大增加运维成本，却不会带来明显收益。
微服务拆分的过程，是基于某个痛点出发，是业务真正遇到快速迭代和高并发等问题，如果不拆分，将对于业务的发展带来影响，只有这个时候，微服务的拆分才是有确定收益的，增加的运维成本才是值得的。
1.1 有快速迭代的需求
互联网时代，业务快速变化，应用的交付需要快速响应式交付。通过微服务架构，采用快速迭代的方式进行架构演进，将系统拆分成多个独立的微服务，微服务之间彼此独立，通过服务接口交互。当某个微服务遇到问题时发版修复，不会导致整个系统不可用，从而支撑业务的快速试错。
1.2 提交代码频繁出现大量冲突
单体应用开发通常是几十人开发一个系统，代码管理时经常会遇到代码提交冲突。微服务架构通过快速迭代可实现开发独立，将系统拆分成不同的微服务，每个微服务对外提供接口，其他依赖服务不用关注具体的实现细节，只需保证接口正确即可。每几个人维护一个服务模块，降低代码冲突的概率，出现冲突时也可快速解决。
1.3 小功能要积累到大版本才能上线
传统模式单次上线的需求通常较多、风险较大，小功能的错误可能会导致大功能无法上线。因此每次上线都会带来较大的工作量。
微服务架构对于快速迭代可带来独立上线的效果。微服务拆分后，在服务接口稳定的情况下，不同的微服务可独立上线。上线的次数增多，单次上线的需求量变小，可随时回滚，风险变小，时间变短，影响面小，从而加快迭代速度。
1.4 解决高并发横向扩展问题
互联网时代，业务应用的高并发要求越来越高，单体应用虽然可以通过部署多份承载一定的并发量，但是会造成资源非常浪费。有的业务需要扩容，例如下单和支付，有的业务不需要扩容，例如注册。如果一起扩容，消耗的资源可能是拆分后的几倍。因此，对于并发量大的系统，选择微服务拆分是很有必要的。
2.拆分原则
- 单一职责原则： 每个微服务只需关心自己的业务规则，确保职责单一，避免职责交叉，耦合度过高将会造成代码修改重合，不利于后期维护。
- 服务自治原则： 每个微服务的开发，必须拥有开发、测试、运维、部署等整个过程，并且拥有自己独立的数据库等，可以完全把其当作一个单独的项目来做，而不牵扯到其他无关业务。
- 轻量级通信原则： 微服务间需通过轻量级通信机制进行交互。首先是体量较轻，其次是需要支持跨平台、跨语言的通信协议，再次是需要具备操作性强、易于测试等能力，如：REST通信协议。
- 接口明确原则： 明确接口要实现的内容，避免接口依赖，如A接口的改动会导致B接口的改动。
- 持续演进原则： 单体架构向微服务架构拆分过程中，无法做到一蹴而就，刚开始不建议拆分太小，过度拆分将会带来架构复杂度的急剧升高，开发、测试、运维等环节很难快速适应，将会导致故障率大幅增加，可用性降低，非必要情况，应逐步拆分细化，持续演进，避免微服务数量的瞬间爆炸性增长。
3.拆分方法
微服务的拆分应遵循上述拆分时机、拆分原则，并选择合适的拆分方法，逐步拆分。在实际拆分过程中，除了要遵循拆分原则，还要从实际业务领域出发，并结合考虑非业务的因素，比如需求变更的频率、高性能、安全性、团队规模以及技术异构等因素。这些非业务因素对于最终落地也会起到决定性的作用，因此在微服务拆分时需要重点关注。
3.1 业务领域拆分
基于领域模型，围绕业务界限上下文边界，将同类业务划归为一个微服务，按单一职责原则、功能完整性进行微服务的拆分。
3.2 需求变化频率
需要识别业务需求的变动频率，考虑业务变化频率与相关度，将业务需求变动较高和功能相对稳定的业务进一步分离拆分。
因为需求的经常性变动必然会导致代码的频繁修改和版本发布，这种拆分可以有效降低频繁发布版本的业务对不需要经常发布版本的业务的影响。
3.3 服务性能要求
需要识别性能压力较大的业务。因为对性能指标要求高的业务在资源需求上会比其他业务的高，这样可能会拖累其他业务，也会造成资源无谓的浪费。为了降低对系统整体性能和资源要求的影响，我们将对性能方面有较高要求的业务与对性能要求不高的业务进一步拆分。
3.4 组织架构和团队规模
除非有意识地优化组织架构，否则微服务的拆分应尽量避免对组织架构和团队的调整，避免由于功能的重新划分，而增加大量且不必要的团队之间的沟通成本。
在进行微服务拆分和组建项目团队时，应尽量将沟通边界控制在团队内。
3.5 安全边界
对于有特殊安全要求的业务，应独立出来，避免因不同的安全要求，而带来不必要的成本，或带来泄密的风险。
3.6 技术异构
虽然都是在同一个业务领域内，但由于各种条件的限制，在技术实现时可能会存在较大的差异（存在技术异构的问题）。
大部分都是采用Java语言实现，但由于业务场景或者技术条件的限制，有的可能需要采用Go语言实现，甚至有的采用大数据技术架构。
对应这些存在技术异构的业务功能，可以考虑按照技术栈的边界进一步拆分。
你认为微服务怎么拆分更合理呢？欢迎一起讨论、交流！
感谢您的阅读，也欢迎您发表关于这篇文章的任何建议，关注我，技术不迷茫！
