服务拆分与架构演进

　　“领域驱动设计和服务自演进能力是内功。”

　　前言

　　提到，微服务帮助企业提升其响应力，而企业需要从DevOps、服务构建、团队和文化四点入手，应对微服务带来的复杂度和各种挑战，从而真正获益。如果说运维能力是微服务的加油站，服务则是其核心。

　　企业想要实施微服务架构，经常问到的第一个问题是，怎么拆？如何从单体到服务化的结构？第二个问题是拆完后业务变了增加了怎么办？另外，我们想要改变的系统往往已经成功上线，并有着活跃的用户。那么对其拆分还需要考虑现有的系统运行，如何以安全最快最低成本的方式拆分也是在这个过程中需要回答的问题。

　　本文会针对以上问题，介绍我们团队在服务拆分和演进过程中的实践和经验总结。

　　我们项目架构的演化历程

　　该项目始于2009年，到现在已有7年的时间。在这7年中覆盖的业务线不断扩大，从工单、差旅、计费、文件、报表、增值业务等；业务流程从部分节点到用户端的全线延伸；7年间打造多个产品，架构经历了多次调整，从单体架构、RPC、服务化、规模化到微服务。

　　主要架构变迁如下图所示：

　　在这7年架构演进路上，我们遇到的主要挑战如下：

如何拆？即如何正确理解业务，将单体结构拆分为服务化架构？

拆完后业务变了增加了怎么办？即在业务需求不断发展变化的前提下，如何持续快速地演进？

如何安全地持续地拆？即如何在不影响当下系统运行状态的前提下，持续安全地演进？

如何保证拆对了？

拆完了怎么保证不被破坏？

　　就如庖丁解牛一样，拆分需要摸清内部的构造脉络，在筋骨缝隙处下刀。那么微服务架构中，我们认为服务是业务能力的代表，需要围绕业务进行组织。拆分的关键在于正确理解业务，识别单体内部的业务领域及其边界，并按边界进行拆分。

　　1. 识别业务领域及边界。

　　首先需要将客户、体验设计师、业务分析师、技术人员集结在一起对业务需求进行沟通，随后对其进行领域划分，确定限界上下文(Boundary Context)，也称战略建模。

　　以下我们经常使用的方法和参考的红蓝宝书：

| Scenarios，用于梳理业务流程，由粗粒度到细粒度逐一场景分析。

，用于提取核心概念、关键数据项和业务约束。

领域驱动设计-战略设计，用于划分领域及边界、进行技术验证。

，用于提取领域中的业务事件，便于正确建模。

　　一个业务领域或子域是一个企业中的业务范围以及在其中进行的活动，核心子域指业务成功的主要促成因素，是企业的核心竞争力；通用子域不是核心，但被整个业务系统所使用；支撑子域不是核心，不被整个系统使用，该能力可从外部购买。一个业务领域和子域可以包括多个业务能力，一个业务能力对应一个服务。领域的边界即限界上下文，也是服务的边界，开奖，它封装了一系列的领域模型。

　　一个业务流程代表了企业的一个业务领域，业务流程所涉及的数据或角色或是通用子域，或是支撑子域，由其在企业的核心竞争力的角色所决定。比如企业有统一身份认证，决策不同部门负责不同的流程任务，那么身份认证子域并不产生业务价值，不是业务成功的促成因素，但是所有流程的入口，因而为通用子域，可为单独服务；而部门负责的业务则为核心子域。

　　举个例子

　　工单业务流程：

　　某企业为服务人员提供工单服务的业务流程简化如下。首先搜索服务人员，选取服务人员购买的服务，基于目标国家的工单流程，向服务人员收取资料，对其进行审计，最后发送结果。

　　识别的领域：