转载

CTO为何要微服务评估

为什么定义参考模型

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

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

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

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

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

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

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

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

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

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

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

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

1). 适用性评估

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

2). 成熟度评估

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

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

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

3). 技能与工具图谱

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

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