微服务拆分

拆分时机

• 代码维护困难，进行代码合并时总会出现大量冲突
• 模块耦合严重，小功能的修改需要累计到大版本才能上线且上线时需要协调多个团队
• 横向扩展流程复杂，主要业务和次要业务耦合。在主要业务需要扩容时，次要业务也因为和主要业务耦合的原因进行了扩容
• 业务规模扩大，业务复杂度变高时需要根据具体情况进行微服务的拆分
• 团队规模扩大到一定程度时。
• 研发效率大幅度下降
• 技术储备，技术团队具有微服务的相关知识，才能能够进行微服务拆分

拆分原则

• 单一服务内部功能高内聚：每个服务仅完成自己职责，其他部分的功能交给其他服务来实现
• 闭包原则：修改微服务时，不涉及其他微服务
• 服务自治、接口隔离：尽量降低对其他服务的依赖性，通过标准的接口隔离，隐藏内部的实现细节，使服务可以独立的开发、测试、部署运行
• 持续演进原则：逐步划分，持续演进，在服务需要拆分时就要拆分，避免服务规模过大一次性拆分所导致的服务数量爆炸性增长
• 尽量避免影响日常的功能迭代：优先剥离比较独立的边界服务，优先拆分被依赖的服务
• 服务接口的定义要具备可扩展性：防止服务接口的修改上线引起调用该接口的其他服务大量报错问题，可以考虑接口定义时的向老版本兼容，将接口多个参数封装成类(不会因为参数数量的更改引起服务报错)
• 避免环形依赖或双向依赖：可能是服务的通用部分没有下沉出来，功能边界没有划分清楚
• 阶段性合并：不断梳理领域边界，不断矫正才分的合理性，与持续演进原则相同
• 自动化驱动：应首先构建自动化工具和环境，避免开发、测试、部署、运维上的重复性工作，减少微服务数量增多带来的开发和管理复杂度问题

拆分策略

功能维度拆分策略

主要是基于业务复杂度拆分。当业务复杂度高时，可以基于领域驱动拆分服务；当业务复杂度低时，可以基于数据驱动拆分服务。

• 基于数据驱动拆分服务：自下而上的架构设计方法，根据表之间的关系拆分服务。拆分步骤：需求分析、抽象数据结构、划分服务、确定调用关系和业务流程验证。
• 基于领域驱动拆分服务：自上而下的架构设计方法，确定关键业务场景，确定边界上下文。拆分步骤：建立模型，业务分析，寻找聚合，确定调用关系，业务流程验证和持续优化

非功能维度拆分策略

• 扩展性：将成熟的、通用的服务功能拆分出来作为公用的服务，将不成熟的具有特质化且需要根据业务需求不断变化的部分拆分出来满足个性化的扩展需要
• 复用性：将公共服务拆分出来，供其他服务使用。例如组织架构服务，鉴权服务等
• 高性能：将性能要求高且服务压力大的模块拆分出来，避免影响其他服务功能，也方便扩展。基于读写分离来拆分服务(一个服务负责数据的读取访问，一个服务负责数据的修改增加删除)，对于要求数据强一致性的功能，尽量放在一个服务中。
• 安全性：把对信息安全要求高的服务拆分出来，进行区别部署
• 异构性：将不同语言实现的服务拆分出来

拆分风险

• 技术储备：团队是否具有足够的经验，具有微服务的相关知识以及技术栈
• 不断纠正：业务不断演进，服务拆分方案仅仅是现对于现状相对合适，因此服务的划分要随着变化而不断的演进和纠正
• 考虑人员和资源与服务数量是否匹配