CTO为何要微服务评估

为什么定义参考模型

之前我的工作，大部分时间都是聚焦在某个产品/团队，为他们提供微服务/DevOps的实施及指导。进入公司后，同时参与了多个产品团队的改造研讨。其中最大的不同在于：

在面对一个团队的时候，范围聚焦，可以集中梳理问题并全方位跟进；

但是，当同时面对多个团队时，尤其是业务背景、技术积累、团队规模、复杂度不尽相同的团队，如何快速有效的推进？

因此，如何能最大化地为多团队提供支撑，帮助他们有效实施微服务并持续获得收益，成为挑战。

微服务的概念看似浅显易懂，但实际上却涉及敏捷实践、架构演进、领域建模、持续交付、DevOps等多个维度的方法论与实践。在整个演进过程中，持续交付、DevOps、演进式架构成为有效实施微服务的必备能力。

于是，根据之前的经验和总结，通过对微服务实施过程中不同维度的思考，梳理了《微服务实施参考模型》，旨在帮助微服务实施的团队获取如下关键内容:

(1) 全方位诊断当前系统是否适合微服务化。

(2) 清楚了解服务化实施的当前状态以及遇到的瓶颈。

(3) 制定切实可行的阶段性目标(这一点非常重要，微服务带来的各种好处不言而喻。但是如何有效的按阶段推进，如何梳理最佳实践并进行大规模复制，其实是有不少坑要趟的)。

(4) 帮助团队梳理中长期的目标并在更大范围内复制(产品线、部门级别) 。

微服务实施参考模型包括什么

微服务实施参考模型主要包括如下四部分内容：

1). 适用性评估

真实世界里，不存在"One size fits all"的解决方案。虽然微服务有诸多迷人的优势，但它的弊端和挑战也是我们在决策时必须要考虑的风险。对于遗留系统的改造场景，至少要考虑"新业务"、"现有业务"、"数据的独立与依赖性"、"双模IT集成"等内容。所以，如何评估现有的产品或者业务，是否适合大规模的微服务化改造，从哪些维度能够帮助我们思考并鉴别风险，是×××长征的第一步。

2). 成熟度评估

经过上面的评估，已经确定了微服务对产品的适用度。那接下来，团队的当前状态如何，能多大程度的投入？过去是否有积累的敏捷或者持续交付实践，接下来的实施面临哪些挑战？第一步从哪些角度入手？

这些是很多团队面临的困惑。

通过定义三大关键、五个等级及八个维度，成熟度参考能帮助团队了解当前微服务的状态，明确短期目标并定义中长期目标，同时为团队提供清晰的路标。

3). 技能与工具图谱

清楚了短期目标、中长期目标，接下来的部分就是如何落地。在微服务落地的过程中，会涉及到很多工具、技能以及相关的实践。因此，该部分旨在提供落地过程中的语言、框架、工具以及实践指导。

另外，为了完善服务落地时能力提升的活动，我们也提供了对于服务演进过程中需要工具的视频或者素材，帮助团队快速上手并获得相关能力。同时，更深层次的目标，其实也是希望团队能在熟悉这个流程后，根据自身实践，打造适合团队自己的技能图谱。

取得的效果

目前《微服务实施参考模型》在多个团队取得了良好的效果。

基于《微服务实施参考模型》，在业务支撑工具团队的新版本，对微服务实施过程中定义26+项实践改进，包括服务演进、数据拆分、监告警、基于契约的集成验证、可视化任务管理等，团队在3个月内将单服务上线周期从35天降低到14天。同时，在提交频率、平均提交行数、CI构建时间和单元测试覆盖率上有显著的提升。

在某云服务团队中，通过《微服务实施参考模型》定义的成熟度阶段参考与阶段实施，团队定义了10多项改进实践，在服务自启动、持续集成、服务间测试联调、敏捷实践和测试环境搭建上有显著的效率提升。

复用借鉴方式

对于还未开始实施微服务的团队，可以基于《微服实施参考模型》的适用度评估部分，对现有系统进行多维度的检查，尽早识别微服务过程中的风险；根据评估后的结果，团队内也可以探讨并决定多大范围的实施微服务；

对于已经开始实施微服务的团队，可以基于《实施参考-成熟度模型》进行成熟度的检查，在架构与技术、组织与文化以及流程与工具三大类、全功能团队、敏捷实践、服务拆分与设计、运维与监控、服务测试、持续集成等多个维度，分析短板，并基于成熟度的不同阶段，制定循序渐进的改进目标。

对于微服务过程中遇到的工具和平台问题，譬如看板(DevLean)、服务间契约测试(Pact)、基础设施的自动搭建(Infrastructure as code)，可以参考技能图谱，里面提供了视频以及分享材料。

对于演进过程中遇到的疑惑，可以参考我们提供的案例，获得相关的参考。