CTO为何要微服务评估

  • 为什么定义参考模型

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

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

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

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

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

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

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

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

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

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

 

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

微服务实施参考模型主要包括如下四部分内容:
1). 适用性评估

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

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

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

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

3). 技能与工具图谱

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

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

 

  • 取得的效果

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

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

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

 

复用借鉴方式

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

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

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

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

  5. 更多参考:https://www.huaweicloud.com/product/cse.html

你可能感兴趣的:(技术剖析)