微服务架构拆分

微服务介绍

英文:https://martinfowler.com/articles/microservices.html
中文:http://blog.cuicc.com/blog/2015/07/22/microservices

微服务拆分时机

如下场景是否需要进行微服务拆分？

• 代码维护困难，几百人同时开发一个模块，提交代码频繁出现大量冲
  突；
• 模块耦合严重，互相依赖，小功能修改也必须累计到大版本才能上
  线，上线还需要总监协调各个团队开会确定；
• 横向扩展流程复杂，主要业务和次要业务耦合。 例如下单和支付业务
  需要扩容，而注册业务不需要扩容
  
  何时进行微服务的拆分：
• 业务规模：业务模式得到市场的验证，需要进一步加快脚步快速占领市场，这时业务的规模变得越来越大，按产品生命周期来划分（导入期、成长期、成熟期、衰退期）这时一般在成长期阶段。如果是导入期，尽量采用单体架构。
• 团队规模：一般是团队达到百人的时候，主要还是要结合业务复杂度
• 技术储备：领域驱动设计、注册中心、配置中心、日志系统、持续交付、监控系统、分布式定时任务、CAP 理论、分布式调用链、API 网关等等。
• 人才储备：精通微服务落地经验的架构师及相应开发人员。
• 研发效率：研发效率大幅下降。

微服务拆分的一些通用原则

单一服务内部功能高内聚低耦合：

每个服务只完成自己职责内的任务，对于不是自己职责的功能交给其它服务来完成

• 闭包原则（CCP）：微服务的闭包原则就是当我们需要改变一个微服务的时候，所有依赖都在这个微服务的组件内，不需要修改其他微服务

• 服务自治、接口隔离原则：尽量消除对其他服务的强依赖，这样可以降低沟通成本，提升服务稳定性。服务通过标准的接口隔离，隐藏内部实现细节。这使得服务可以独立开发、测试、部署、运行，以服务为单位持续交付。

• 持续演进原则：在服务拆分的初期，你其实很难确定服务究竟要拆成什么样。应逐步划分，持续演进，避免服务数量的爆炸性增长。

• 拆分的过程尽量避免影响产品的日常功能迭代：也就是说要一边做产品功能迭代，一边完成服务化拆分。比如优先剥离比较独立的边界服务（如短信服务等），从非核心的服务出发减少拆分对现有业务的影响，也给团队一个练习、试错的机会。同时当两个服务存在依赖关系时优先拆分被依赖的服务。

• 服务接口的定义要具备可扩展性：比如微服务的接口因为升级把之前的三个参数改成了四个，上线后导致调用方大量报错，推荐做法服务接口的参数类型最好是封装类，这样如果增加参数就不必变更接口的签名

• 避免环形依赖与双向依赖：尽量不要有服务之间的环形依赖或双向依赖，原因是存在这种情况说明我们的功能边界没有化分清楚或者有通用的功能没有下沉下来。
  

• 阶段性合并：随着你对业务领域理解的逐渐深入或者业务本身逻辑发生了比较大的变化，亦或者之前的拆分没有考虑的很清楚，导致拆分后的服务边界变得越来越混乱，这时就要重新梳理领域边界，不断纠正拆分的合理性。

• 自动化驱动：部署和运维的成本会随着服务的增多呈指数级增长，每个服务都需要部署、监控、日志分析等运维工作，成本会显著提升。因此，在服务划分之前，应该首先构建自动化的工具及环境。开发人员应该以自动化为驱动力，简化
  服务在创建、开发、测试、部署、运维上的重复性工作，通过工具实现更可靠的操作，避免微服务数量增多带来的开发、管理复杂度问题。

• 功能维度拆分策略
  大的原则是基于业务复杂度拆分服务： 业务复杂度足够高，应该基于领域驱动拆分服务。业务复杂度较低，选择基于数据驱动拆分服务

  • 基于数据驱动拆分服务： 自下而上的架构设计方法，通过分析需求，确定整体数据结构，根据表之间的关系拆
    分服务。
    拆分步骤： 需求分析，抽象数据结构，划分服务，确定调用关系和业务流程验证。
  • 基于领域驱动拆分服务： 自上而下的架构设计方法，通过和领域专家建立统一的语言，不断交流，确定关键业务场景，逐步确定边界上下文。领域驱动更强调业务实现效果，认为自下而上的设计可能会导致技术人员不能更好地理解业务方向，进而偏离业务目标。
    拆分步骤：通过模型和领域专家建立统一语言，业务分析，寻找聚合，确定服务调用关系，业务流程验证和持续优化。

• 还有一种常见拆分场景，从已有单体架构中逐步拆分服务。
  拆分步骤： 前后端分离，提取公共基础服务（如单点登录），不断从老系统抽取服务，垂直划分优先，适当水平
  切分
  以上几种拆分方式不是多选一，而是可以根据实际情况自由排列组合。同时拆分不仅仅是架构上的调整，也意味着要在组织结构上做出相应的适应性优化，以确保拆分后的服务由相对独立的团队负责维护。