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)，可以參考技能圖譜，里面提供了視頻以及分享材料。

對于演進過程中遇到的疑惑，可以參考我們提供的案例，獲得相關的參考。