【大咖连载】微服务参考模型（适用性评估以及成熟度参考详情）

微服务参考模型梳理了产品在微服务实施过程中的适用性评估、成熟度参考、度量体系以及能力提升计划，旨在帮助团队尽早识别微服务实施过程中的风险，并有效地推进微服务相关实践的落地。

为什么提出参考模型

对于业务背景、系统复杂度、技术体系、团队规模不尽相同的团队，有效地实施微服务并平滑演进，并不是一件容易的事。微服务的概念看似简单易懂，但实际上却是过去多年“若干最佳实践”的结合，其包括了持续集成、敏捷实践、分布式系统、运维管理、测试管理以及团队文化等方面。

在过去的几年里，笔者参与了多个微服务产品构建。在这个过程中，总会遇到如上所述的各种挑战。因此，笔者基于这些“踩过的坑”，总结出微服务实施参考模型（简称参考模型），希望能为更多实施微服务的团队提供一套可落地的、易实施的微服务实践指导，从而有效地落地微服务。参考模型不是一个强制的规章制度，它是将软件工程方法、分布式系统设计、运维以及团队实践相结合起来的一套范式。

从参考模型中获得的收益

在微服务实施过程中，不同的团队面临的挑战不尽相同，通过使用参考模型，实施微服务的团队可以从中获得如下收益：

— 尽早识别产品微服务演进过程中的风险

微服务的演进过程涉及业务、技术、团队、架构及流程等多个方面。参考模型从业务属性、竞争力、技术实践和团队组织四个方面对现状进行评估，帮助团队尽早识别产品微服务落地过程中的风险。

— 有效制定实施过程中的阶段性目标

参考模型定义了微服务实施过程中的阶段性产出。基于参考模型，能够帮助团队了解当前的状态、待改进点，并有助于团队根据业务形态、技术经验的不同，制定合理的阶段性目标，并持续获得价值。

— 有助于自组织团队培养及积累最佳实践

微服务的实施包含敏捷、全功能团队、持续交付、DevOps等多方面的实践。参考模型从团队文化、技术实践、DevOps以及流程工具等多个方面描述了实施微服务架构的最佳实践组合。通过学习和了解参考模型，有助于培养自组织团队，并积累优秀实践，并为更大范围实施微服务提供可复制的经验。

— 打造团队专属的技术与工具图谱

在微服务的实施过程中，涉及多样化的技术和工具。参考模型帮助团队打造专属能力地图，制定适合的技术与工具栈，并动态衡量团队在技术与工具的能力。

1.2 参考模型的核心内容

微服务参考模型主要由三个部分组成，即适用性评估、成熟度参考以及度量指标，如图1-1所示。

图1.-1 微服务参考模型

适用性评估

微服务架构的落地涉及分布式、DevOps、持续交付、敏捷实践等多维度的内容，对现有系统进行服务化改造需要考虑诸多因素。另外，对于一些复杂的遗留系统，在改造的过程中也会带来额外的成本与风险，如新旧系统的集成、细粒度单元的交付等。所以，如何评估现有产品，判断其是否适合微服务化改造，以及从哪些维度进行改造，是万里长征的第一步。第一部分适用性评估将帮助我们解决这些问题。

成熟度参考

经过基本的风险和问题识别后，接下来需要制定短期和中长期目标，并考虑如何有效落地。第二部分成熟度参考旨在帮助团队制定有效的演进目标，循序渐进地落地。在成熟度参考中，定义了五个成熟度阶段，并从三大方向、八个维度对这五个阶段展开了详细介绍。

度量指标

如何有效体现微服务实施过程中的效果，是每个转型团队都关注的问题。第三部分度量指标旨在帮助团队建立合理的度量体系，及时跟踪微服务实施过程中的数据变化，并获取反馈、持续改进。

1.2.1 适用性评估

为了帮助团队在迈出第一步前，有效识别实施过程中的风险，笔者从业务属性和竞争力两方面整理了微服务落地需要考虑的因素。

业务属性

— 数据一致性

微服务的本质是分布式系统，业务对数据的一致性要求，决定了系统是否可以采用分布式架构进行构建。实施微服务改造前需要重点评估在分布式系统下，CAP定理所带来的数据一致性的影响是否能满足业务场景的需求。

考虑因素：业务数据是否需要满足强一致性，还是最终一致性即可？

— 实时性

分布式系统相比单体应用而言，会带来额外的网络开销。对于业务上要求低时延的系统，需要重点评估在分布式架构下，网络带来的延迟能否满足业务需求。

考虑因素：通信过程带来的开销是否能满足业务需求？业务处理允许时延为秒级、毫秒级还是微秒级？

— 可用性

通过集群的方式可以提升服务的可用性，但前提是需要考虑服务是否容易水平扩展。通常无状态的服务容易扩展到多个实例，而有状态的服务则成本较高。

考虑因素：系统原有服务是主备模式还是单实例模式？服务的实例有无状态？在业务流量增加的情况下，能否通过水平扩展满足可用性的要求？

竞争力

— 交付周期

对于产品团队而言，快速的交付有利于缩短获取用户反馈的周期，有利于团队实现敏捷开发及降低发布的风险。

考虑因素：响应业务需求的快速变化以及交付周期的缩短是提高核心竞争力的重要因素吗？业务领域的需求变化频率是什么单位级别，是季度、月、周或者天？所处的行业，对产品交付周期有什么样的限制和诉求？

— 可伸缩性

微服务的架构具有良好的可伸缩性，可以按照业务需要进行水平伸缩。

考虑因素：对于系统而言，按需的弹性伸缩能力，是提高其核心竞争力的重要因素吗？水平伸缩的场景是可以预测的吗？是否需要自动化的弹性伸缩机制？

1.2.2 成熟度参考

任何优秀架构的演进都是增量式过程，不可能一蹴而就，笔者定义了微服务的实施成熟度参考，旨在帮助团队循序渐进地实施微服务，并且不断衡量进展，制定有效的演进目标。

微服务的实施是一个涉及组织、架构、工程等多方面的演进过程，综合笔者过去在多个团队的实践经验，这里将微服务实施的过程划分为五个阶段，并基于团队与文化、架构与技术、工程与实践三个方向，细分出八个维度。通过在每个维度上对不同阶段进行详细解读，将维度与阶段的横纵向连接，读者可以清晰地定位团队在各个维度所处的位置，并制定具体的改进方向，帮助读者解开“不知身在何处，不知向何处去”的困惑。

参考维度定义

笔者基于团队与文化、架构与技术、工程与实践三大方向，将微服务实践的过程细分为全功能团队、敏捷实践、服务设计与实现、服务支撑组件、运维管理、测试管理、交付流水线、部署管理八个维度。

各个维度所描述的具体含义如下表所示。

参考阶段定义

基于如上定义的维度，笔者将每个维度分为五个演进阶段。如图1-2所示。

图1-2 参考阶段定义

其中，每个阶段表示了微服务落地过程中的关键特征。通过定义不同特征，帮助读者有效识别实施过程中离下一阶段的差距，制定演进的计划和时间点。

— Stage 0：初始阶段（Initial）

微服务交付的过程多借助手动执行，流程通常是混乱和无序的，缺乏稳定的环境，产品的交付经常超出成本或赶不上进度。

— Stage 1：已管理阶段（Managed）

微服务实施过程得到管理，服务交付的过程有计划、执行、跟踪和管控，部分过程自动化，服务状态可视化。

— Stage 2：已定义阶段（Defined）

定义和建立了团队级的标准过程，用标准、规范、工具和方法等描述了服务的交付过程，并在整个组织范围内得到认可，在微服务生命周期上实现了过程自动化。

— Stage 3：量化管理阶段（Quantitatively Managed）

定义了过程度量指标，能够评价微服务交付过程执行的效率和质量，而且交付过程是可以度量、控制和预测的，构建了可视化的度量收集方法并能持续跟踪。

— Stage 4：持续优化阶段（Optimizing）

形成了成熟的自治团队，能够自行分析和解决在微服务实施过程执行中的相关问题，可以有效识别和控制交付过程中的风险，建立了适合自身的持续优化和创新过程，并能够在组织内有效复制。

参考模型详情

基于如上所示的三个方向、五个阶段以及八个维度，梳理出如下表所示的参考模型详情，涵盖微服务实施过程中需要考虑的架构、工程、组织各维度等因素。表格中所列出的特征是笔者认为在该维度下重要的特征，但实际场景并不仅限于此，读者可以基于这些特征进行扩展。

双模IT源自Gartner2014年提出的双模IT概念，表示遗留系统和新系统同时存在并提供服务的状态。