微服務實施的 5 個階段模型

最新 05-30

本文作者：汪照輝王作敬中國銀河證券股份有限公司信息技術部IT研發中心

原題：《微服務實施階段模型》

昨天同學群里一個美女同學說單位要採用微服務，向大家諮詢如何實施微服務，引起大家熱烈的討論。她們打算要做三期，但苦於缺乏必要的理論和實踐，擔心廠商忽悠她。

目前的確是這個狀況。微服務是什麼，適合什麼樣的場景，前面我們也討論過了（可參考文後所附系列文章）。今天我們就微服務實施階段模型進行簡單的介紹，以及在沒有技術能力把控微服務項目的時候，考慮引入微服務項目監理來協助企業微服務建設，作為採用微服務實施時的參考。

實施微服務首先要理解微服務，通常我們會拿SOA ESB和微服務比較，SOA ESB重在集成，微服務意在重構。採用微服務往往是需要重構單體應用的時候，為了後面單體系統轉向服務化，實現系統融合，從數據層實現真正的數據清洗、去冗、一致性、標準化、完整性等數據治理能力，最終實現為企業應用提供唯一數據來源；在服務層方便的實現業務微服務，構建企業服務中台；基於服務中台可以敏捷的對企業業務需求作出響應，快速應對企業業務應用變化的需求。

目前很多公司對微服務的理解不深，更不知道怎麼實現，特別如果還要建立基礎設施容器雲平台或部署到容器雲平台，更是一籌莫展。找廠商來實施微服務，又擔心被廠商忽悠，怕最終做的不倫不類，真是兩難啊。

對於微服務實施，基於我們SOA ESB的實施經驗，我們定義為如下5個階段，可行性評估級、採用級、應用級、企業級、生態級。這也可以作為評估微服務實施情況的模型。後面我們會從多個維度來介紹如何評估微服務實施階段及微服務成熟度。

隨著微服務的持續應用和改進，逐步向更高階段發展，收益也會越發明顯的體現出來。微服務實施初期投入可能比單體應用要大，特別沒有做數據清洗、通用數據模型的企業，需要的資金和人力投入會更大，這也可能是影響初期微服務實施成功和成效的原因。下面我們對每個階段做簡單的介紹。

考慮採用微服務首先要做一些準備工作，比如行業內交流調研學習、邀請廠商交流、做PoC驗證測試等，要確認採用微服務是可行的，能解決企業目前IT系統面臨的問題，為企業帶來的收益。所以我們定義初始微服務級別為可行性評估級。這是微服務交流學習驗證的階段，為採用微服務和實施微服務打下牢固基礎。

我們不能為了微服務而去採用微服務，因為微服務很熱門，其他人用了，我們也要用。這樣的想法是做不好的。任何技術都只是一種手段，你熟悉它、理解它，才能熟能生巧，為你所用，否則很可能成為累贅。所以要儘可能的去學習、去熟悉、去思考、去理解微服務。

當然最快的學習是交流，避免封閉起來，閉門造車。以開放的心態多交流，和同行、和廠商不斷的交流和探討，對同一個問題可以傾聽不同人的意見、想法，逐步能夠融會貫通。在交流過程中對廠商能力的認識也會逐步地加深，也是為PoC測試和後期的項目預作準備。

深入的理解少不了動手去實踐。無論說得多麼天花亂墜，實際做的過程中才能看到、才能體會到差別。不去實踐很多事可能是想不到的。微服務數據梳理、建模、編程、通信、治理、運營等涉及的基礎設施、數據、架構、方法、組織人員、業務等都有不少難點，不要期望一蹴而就、一次成功，總是要在不斷嘗試、不斷失敗、不斷改進的過程中走向成熟和完善。所以正式開始項目之前需要重視PoC測試。儘可能的多測試一些場景，儘可能多熟悉一些細節，測試的時間長短可以不用規定死，多測幾遍也沒關係，有疑問的地方問清楚，和不同廠商溝通，明白思維的差別。一個人的思維總是有局限性，所以要多聽聽不同人的想法。最終決定是否有必要採用微服務。

微服務當然有微服務的價值，但好的不一定是適合的。不僅僅考慮好的技術架構、還要考慮投入、現有人員的技術水平和能力、後期運維支持能力、服務改造的影響和風險等等，在決定採用微服務之前，這些都要進行評估的，在可以駕馭微服務架構的情況框下，才是可行的。

微服務方案具有可行性，那麼就可以選擇一個項目開始微服務建設。初始建議以非核心項目為起點，選擇相對獨立的一塊業務來採用並實施微服務。萬事開頭難，微服務雖沒有什麼特別的技術，但細枝末節也紛繁複雜。採用微服務首先要考慮支撐微服務的基礎設施平台。PoC測試中這些可能不是重點，但在實際的項目中，必須考慮標準化和規範化。微服務架構和容器雲平台、DevOps方法論像是相輔相成的孿生兄弟，容器雲支撐微服務的部署運營，DevOps協助微服務敏捷開發、持續集成和持續部署、持續反饋和持續改進流程。微服務的思想也可用於容器雲平台的建設、DevOps流程的設計。容器雲平台提供標準化的鏡像輸出、完善的基礎設施環境、應用為中心的微服務管理、安全的訪問控制機制、多層次的資源隔離、以及統一的容器雲平台基礎組件和中間件服務，比如日誌、監控、告警等服務。日誌、監控、告警等也是基礎組件微服務。

在這個階段很難具備微服務需要的這些基礎設施平台和組件。要建設這些基礎設施平台和組件也是不小的項目和工作量，所以初期可以採用臨時的方案，松耦合架構，可以在後期逐步的完善和替換，比如日誌，在建設的過程建立集中日誌中心，公司所有業務的日誌都可以採集到集中日誌中心進行統一管理，數據集中，就可以方便的進行查詢、統計、分析等。

微服務不一定非要部署到容器雲，如果有微服務管理平台，微服務架構設計合理，可以方便的實現伸縮部署，部署在虛擬機上也許更合適。但這可能需要比使用容器雲平台付出更多的努力來構建微服務管理平台。

這個階段可能是一個最痛苦的階段。就象人到中年，上有老、下有小，不得不承擔頂天立地的壓力。這個階段可能多個微服務項目並行推進，微服務基礎設施平台和基礎組件也可能在建設和完善之中。問題可能總是層出不窮。隨著微服務數量、節點數的增加，一些理論上正常的事情可能也變的不正常。新舊系統並行，一方面開發運營著微服務，另一方面不得不集成很多單體系統，數據可能需要雙向流動，既要進行數據清洗、去冗，保持數據完整性和一致性，又要數據同步到不同的單體應用系統中以保證這些系統的運行。所以依然需要採用採用ESB Adapter集成的方式，先集成這些單體系統，然後逐步地進行功能分解，最後完成替換，也就是重構了此單體系統。

業務梳理，是實現微服務的基礎。所有相同的業務功能梳理並提取出來，成為獨立自治的微服務，為業務應用提供服務支持。比如客戶維護操作、賬戶微服務操作、資金維護操作、訂單維護操作等，都可以提取為獨立的微服務。這些微服務又是客戶交易平台的基礎服務。還有單體系統中公共的功能提取出來形成公共微服務組件，就象我們說的日誌、監控、認證、許可權等都是公用的組件，提取出來作為基礎公用微服務組件，這樣微服務平台只需要實現一套日誌微服務、監控微服務等組件，所有的業務應用共用這些基礎的公共組件，不用每個應用都重複建設。這也是服務化實現服務共享的方式。所有這些微服務共同構成了企業服務中台能力，是實現企業業務需求變化快速相應的基礎。

業務梳理說起來容易做起來難，千頭萬緒，紛繁雜亂。不同的部門不同的團隊不同的人員各有自己的考慮，可能用到同樣的數據，可能面對的是同一個客戶，卻是數據彼此隔離，格式、編碼、存儲方式等各不相同。如果沒有公司級的強有力支持，業務梳理很難推進。我們也說過，做業務梳理的目的是理順業務流程，實現數據治理，為企業提供唯一標準數據來源。這些數據沒有冗餘、沒有錯誤、沒有不一致、沒有不完整。這樣去實施微服務才更有價值。不過有困難解決困難，不能不去嘗試。可以基於採用級微服務實施的經驗，選擇相對核心的系統來分解實現微服務，比如客戶關係系統（CRM）。這一個系統可能涉及客戶、賬戶、資金、訂單、積分、消息等很多個微服務，基於這些微服務來構建新的客戶服務應用、客戶交易應用、客戶積分管理應用、客戶消息管理應用等。一個客戶可能有多個賬戶，如果想實現一賬通應用，就可以基於這些服務快速構建。其他單體系統的數據和功能逐步的合併到這些微服務，也就逐步建立起了企業的服務中台。

歷經千辛萬苦能走到這一步不容易。到達這一階段企業的主要微服務都已構建，基礎設施平台和基礎組件都已逐漸成熟，建立起了企業自身的服務中台體系，企業不再有獨立的單體系統，數據也都已經完成融合併得到良好治理，企業的數據通過唯一的數據源提供。這一階段的主要任務是業務應用的快速響應和構建，以及微服務和基礎組件服務的持續改進。

這一階段壓力會小很多，投入也很少了，主要是平台和微服務的運維以及新業務應用的開發運營。真正做到以業務為核心，快速的響應和部署。大部分業務應用通過服務編排都可以實現。企業的收益率明顯的成倍提升。

一些企業也可能不需要到達此階段。但大部分企業在萬物互連的時代難免需要跟其他企業交互。比如我們跟京東合作，在我們的業務中引入他們的京東剛蹦，建立業務生態體系，相互依存。社會就是一個關係網路，企業也不可能獨自生存，所以要考慮和其他企業的合作。IT系統和服務提供了便利的手段和工具，提供實時的聯繫和響應。這時企業的服務中台就會承擔起主角，安全、認證、許可權、連接、轉換、過濾、分發、處理、響應中台能力等支撐起不同合作夥伴的業務互連需求。

這個階段安全將會格外重要。不只是協議、數據、存儲等安全，這也許會促進區塊鏈等技術的發展。

微服務實施並不容易，在企業自身沒有相應的技術實力能夠把控微服務實施的話，可以考慮引入獨立的第三方軟體工程監理，保證軟體交付質量，同時可以提供諮詢、培訓、架構設計、服務設計等方面的支持，具體實施可以外包或者由企業選擇一家廠商來做。微服務項目監理對微服務實施工期、效果和質量負責，通常有一個人就夠了，監控整個項目的方向、架構、計劃、進度、質量等。微服務項目監理和實施最好不要由同一家廠商來做，由獨立的第三方來承擔。雖然可能多付出一些成本，但能保證整個項目的順利進行，直到成功。就象為項目實施買了份保險，在出現意外的情況下由監理公司承擔賠付責任。

目前雖然微服務很熱，但國內實施微服務真正做的好的項目幾乎沒有，也可能是目前很多項目還未達到應用級和企業級等階段的緣故。但總的來說微服務高端人才缺乏是一個不爭的事實。大部分技術人員僅僅是編程，難以承擔起微服務設計的角色。更因為微服務分解和設計需要熟悉業務，熟悉數據，不同的業務場景、數據存儲、數據量、請求負載、技術選型等可能需要採用不同的設計。即便同一個微服務，在不同的階段也可能需要不同的設計，持續的改進。所以採用微服務必須有專業的人才來支持。避免廠商技術人員能力，眼界、境界的限制，避免最終雖然叫微服務，卻是不倫不類，依然有諸多瓶頸，難以發揮微服務的優勢。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！