推進微服務落地的 7 個步驟

如果以上 5 點都讓你膝蓋中箭。那麼根據我個人的經驗，綜合解決微服務實施難點的第一步就是：

步驟1：以終為始，先構建一個獨立的敏捷微服務團隊

我們對微服務的期待就是：可以獨立開發，獨立部署，獨立發布，並且去中心化管理。那麼，我們就先構造一隻「可以獨立開發，獨立部署，並且去中心化管理」的團隊。

這個團隊為了達到這個目標，會採取各種方法(例如：DevOps，全功能團隊)解決阻礙」獨立開發，獨立部署，獨立發布 和 去中心化的問題。而根據康威定理，系統的架構會慢慢向去中心化方向發展。

一定要意識到，這個過程會打破大型系統自上而下的既有流程並採用更有生產力的方式構建新的組織結構。你索要做的就是要充分信任團隊，把它看做是一個微型的技術管理創新。不要用老的方式控制團隊的運作，這會打擊團隊的士氣。

管理建議：

讓微服務團隊完全脫離之前的工作，專心於微服務的工作中。如果分心同時做幾件事，每件事都不會做到最好。

給微服務團隊一些特權，為了滿足「全功能微服務團隊的」訴求，特事特辦。

如果團隊在執行的過程出現了依賴從而阻礙了進度。則需要把依賴標明出來。代碼中的依賴容易看見，但組織中的流程依賴很難發現。

為了避免團隊對外部的「依賴慣性」，讓團隊自己想辦法在內部解決依賴。

組織流程的改變也是很重要的微服務架構產物，而不僅僅是微服務代碼或基礎設施。

技術建議：

為微服務建立一個全新的代碼庫，而不要從原先的代碼庫上克隆或者複製，避免和原團隊的開發依賴。

建設一個獨立的持續交付流水線，最好是通過「流水線即代碼技術」(例如 Jenkinsfile)來自動生成流水線。

步驟2：構建微服務的「電梯演講」

成立了微服務團隊之後，接下來就是要選擇第一個實現的微服務。但是這個微服務應該多大，邊界在哪是個問題。這不需要進行嚴格的設計和反覆的論證，只要發現當前的痛點或者想要完成一個假設就足夠上路了。讓整個過程變輕，而不是變重。

我的建議是通過「微服務電梯演講」的方式來定義微服務。格式可以是：

(XX微服務)用來

在(出現痛點的場景)的情況下

解決了(解決現有的某個問題)

從而(達到什麼樣的效果)

提升了(微服務的價值)

例如：

(訂單查詢微服務)用來

在(訂單查詢數量快速)的情況下

解決了(訪問數量迅速升高導致整體應用性能下降的問題)

從而(分離了訂單查詢請求)

提升了(提升了其他功能的性能)

當構造了微服務的電梯演講，團隊就可以以此為原則啟動了。當碰到和現有系統衝突的問題，替換幾個詞比較有幫助你做決策。(語言一定程度上也是具有魔力的)

把「拆分」換成「移除」。例如：「從現有系統中拆分出訂單查詢功能」 轉變為 」從現有系統中移除訂單查詢功能「。思維方式就從一個團隊負責兩個系統變成了兩個團隊負責兩個系統。

把「集成」換成「調用」。例如：」用戶註冊和用戶登錄需要集成」轉變為「用戶登錄服務需要調用用戶註冊服務的信息」。思維方式就把兩個系統的關係更精確了，從而明確了微服務之間的關係和溝通方式。

管理建議：

把微服務的電梯演講列印出來掛到牆上，讓團隊成員銘記於心。這會強化組織對微服務的邊界認識。

隨著團隊的反思和學習，電梯演講有可能會變更，但一定要讓團隊形成共識好和一致的意見。

不要期望一次就能劃分正確。劃分是一個持續權衡取捨的過程。

技術建議：

明確了微服務的職責和邊界之後再去看代碼，否則會被代碼的複雜度影響。

領域驅動設計(DDD)可以幫助你更好的劃分微服務。領域驅動設計很好的遵循了「關注點分離」(Separation of concerns，SOC)的原則，提出了更成熟、清晰的分層架構。

不會領域驅動設計(DDD)也沒有關係。簡單的使用「關注點分離原則」也可以幫你達到這一點。例如：從介面中分離出流量較大的介面獨立部署，把讀資料庫和寫資料庫的 API 分開獨立部署，把靜態和動態訪問分離……等等。

步驟3：以最小的代價發布出第一個微服務

要注意兩個關鍵點：一個是「最小的代價」，另一個是「發布」(Release)。

正如前文所述，微服務架構本身就覺了微服務一定是低成本低風險的漸進式演進。而最大的浪費在於：

1. 級別/職責分工明確的組織溝通結構。

2. 「長時間，慢反饋」的行動習慣。

3. 先進且學習成本較高的技術棧。

因此，「最小的代價」包含了以下三個方面：

1. 最精簡的獨立敏捷全功能團隊。

2. 最快的時間。

3. 代價最小的技術棧。

此外，很多微服務的「愛好者」由於害怕失敗，因此將微服務技術始終放在「實驗室」里。要勇於面對失敗，在生產環境中面對真實的問題，但要採取一些規避風險的措施。

管理建議：

盡量讓現有微服務團隊自己學習解決問題，成為全功能團隊。如無必要，絕不增添新的人手。

「扯破嗓子不如甩開膀子」，先動起來，在前進中解決問題。

先考慮最後如何發布，根據發布流程倒推。

技術建議：

根據當前技術採用的情況選擇代價較小的技術棧。

採用動態特性開關(Feature Toggle)，在發布後可以在生產環境動態的控制微服務的啟用，降低失敗風險。

如果採用了特性開關，一定要設立刪除特性開關和對應舊代碼的時間，一般不超過兩個月。否則後面大量的特性開關會帶來管理成本的提升和代碼的凌亂。

由於團隊比較小，功能比較單一，不建議採用分支來構建微服務，而應該採用單主幹方式開發。

步驟4：取得快速勝利(Quick wins)，演示(Showcase)驅動開發

剛開始進行微服務改造的時候一定會是一個試錯的過程。如果目標定得太大，會讓團隊倍感壓力，從而士氣低落。而制定每日的短期目標，贏得快速勝利則會不斷激勵團隊的士氣。通過設定當天結束的產出來確定今天需要做什麼是一個非常有效的辦法。

每日演示(Daily Showcase)就是一種推進產出的做法。每天向團隊分享今天的工作內容，使小組能夠共同學習。並且以當天或者明天的 showcase 作為目標。每個人showcase 的內容一般不超過20分鐘，一天的 showcase 時間不超過一小時。可以早上 showcase，也可以下班後 showcase。

常見的快速勝利目標如下：

構造第一條微服務流水線。

上線第一個微服務 HelloWorld

構造出第一個微服務自動化測試。

而 以下的目標不適合作為快速勝利的目標：

構造出微服務 DevOps 平台。

完成整個產品的微服務架構拆分。

構造微服務自動化運維體系。

管理建議：

要防止團隊畫大餅，完成好每日和每周的工作目標即可。微服務開發本身就沒有很長周期。

強迫團隊有所產出，這樣才能用關鍵產出驅動開發。產出不一定是代碼或者基礎設施，一篇總結，或者學習的文章分享，甚至是踩過的坑和遇到的問題都可以展示，目的是要打造自治學習的團隊。

貴在堅持，不要計劃太遠。超過一個月，就要對目標是不是範圍過大進行反思。

以天為單位拆分任務，超過一天的必須要拆分。無法在一天完成的工作需要拆分出階段性產出。

如果能結對，並且能夠每天交換結對，showcase 不必要。

可視化所有任務，用敏捷看板來管理任務是了解現狀的最好方式。

技術建議：

除了讓第一個 HelloWord 微服務儘快發布到生產環境，其它的不要想太多。

完成了 HelloWord 的發布，然後要考慮如何對發布流程進行改進。而不是上線業務。

步驟5：代碼未動，DevOps 先行

微服務解耦的本質是把代碼內部的複雜性通過一些工具轉化外部複雜性。把代碼內部的複雜性分散到各個微服務中以降低整體複雜性和架構風險。在這個過程中會大量採用了 DevOps 技術和工具。也可以說，微服務是 DevOps 文化和技術在走到極致的必然結果。

以 J2EE 的應用為例，以前Web Server App Server MiddleWare Database 的傳統架構被代碼更少，更多的基礎設施工具所取代。因為基礎設施相對於代碼來說更加穩定，更加利於擴展。

我把微服務的技術架構問題比作「搭台唱戲」：首先需要建立好微服務交付和運行的平台，然後讓微服務上台「唱戲」。

這個平台一開始不需要很完善，只需要滿足生產上線的必要要求即可。而在很多企業里，這個部分是由 Ops 團隊在交付流程的末尾把關的。因此，把最後一道關卡的確認工作放到最前面考慮可以減少後期的返工以及不必要的浪費。

以前，軟體的開發和測試過程是分開的。然而，隨著 DevOps 運動的興起和各種自動化運維工具的興起，這之間的必要性不如從前，只要有足夠的自動化測試做質量保證，就可以很快的將微服務快速部署和發布到生產環境上。

最開始的時候，哪怕是發布一個 Hello World 程序，都表明微服務的持續交付和運行的平台已經搭建好，微服務交付流程已經打通，這一點是重中之重。

從技術交付產物來說，DevOps 主要交付兩點：

持續交付流水線。

微服務運行平台。

為了保證微服務交付的高效，需要把這二者通過自動化的方式有機的結合起來，而不是各為其主。讓開發和運維的矛盾變成「自動化的開發運維矛盾」

此外，DevOps 指的不光是一系列技術，更是一種工作方式。從團隊工作方式來說，DevOps 要做到：

要讓 Dev 和 Ops 共同參與決策，設計，實現和維護。

團隊完全獨立自主，打破對現有流程的依賴。

不斷的追求改進，讓團隊行程改進的團隊文化。

管理建議：

給團隊繼續前進最大的動力就是新程序快速投入生產。

如果你的組織是 Dev 和 Ops 分離的組織，先諮詢一下 Ops 工程師的意見。最好是能夠給微服務團隊裡面配備一名 Ops 工程師。

如果不具備實施 DevOps 的條件，微服務架構就要從運維側，而不是開發側開始進行。

技術建議：

微服務的平台一開始可以很簡單，可以以後慢慢增強和擴展。但是一定要部署到生產環境里使用。

如果想使用現成的微服務平台可以參考 Spring Cloud。

微服務運行平台可以通過反向代理和生產環境並行運行。

採用灰度發布技術在生產環境中逐步提升微服務的使用佔比。

基礎設施即代碼是 DevOps 核心實踐，可以幫助開發人員迅速在本機構建生產環境相似的開發環境，減少環境的不一致性。可以採用 Docker，Ansible，Vagrant 等工具來完成。

基礎設施對微服務應該是透明的。微服務不應該也沒必要知道運行環境的細節。只要能夠正常啟動並執行業務就完成了它的任務。因此，基礎設施代碼要和微服務業務代碼分開，且微服務不應該告訴平台自己如何部署。

服務註冊和發現是微服務架構的核心部分。consul 和 Eureka 是這方面的佼佼者。

部署(Deploy)和發布(Release)要分開。

步驟6：除了提交代碼和發布，微服務平台一切都應當自動化

在完成了微服務的基礎設施和交付流程之後，就可以開始實現微服務的業務了。這時候需要依據電梯演講劃分出來的微服務進行業務邏輯的開發。在以 DevOps 的方式工作一段時間之後，團隊應該養成了一些自動化的習慣，如果沒有，就應該檢查一下自己的自動化程度。最佳的自動糊理想的狀態就是除了代碼提交和發布。在這之間的每一個流程和環節都應當由自動化的手段來完成。

當然，也有不能自動化的部分。根據我的經驗，不能自動化的原因主要來自於流程管理的制度要求，而非技術困難。這往往是組織沒有依據微服務進行流程變革導致的。這時候需要檢討不能自動化的部分是不是有存在的必要。

另一方面，雖然自動化可以大量縮短微服務交付時間，提升微服務交付效率。但是自動化的同時需要考慮到安全因素和風險，不能顧此失彼。對於生產來說，可用性和安全性是最重要的部分。

關鍵的自動化：

自動化功能性測試(UI/集成/單元/回歸)

自動化構建

自動化部署

自動化性能測試

自動化安全掃描

管理建議：

鼓勵團隊成員自發的進行自動化的改進，這會給未來微服務批量開發帶來很多裨益。

不要一開始就追求全面的自動化，自動化需要花費一定時間。根據團隊的進度視情況適度進行。

技術建議：

採用 TDD 的方式開發不光可以提升質量，也完成了測試的自動化。

注意自動化的安全隱患。機密信息需要獨立管理。

關鍵步驟需要準備自動手動兩種方式，必要時可以干預自動過程。

採用 git 的 hook 技術，在代碼 push 之前就可以完成測試和靜態檢查，提升 CI 的成功率。

步驟7：總結並複製成功經驗，建立起微服務交付的節奏

當完成了第一個微服務，不要著急開始進行下一個微服務的開發。而是需要進行一次關於可複製經驗的總結，識別微服務開發中的經驗教訓並總結成可複製的經驗和產出。

以下是一些需要總結出來的關鍵產出：

微服務開發到發布的端到端流程規範。

微服務開發的技術質量規範。

團隊合作中的堅持的最佳實踐。

常見技術問題總結。

有了以上的關鍵產出，就可以對微服務開發團隊進行擴張。這時候有了微服務開發的老司機，帶著剛加入的同事一起開發，風險會相對低很多。

管理建議：

剛開始的時候可以每周進行一個回顧會議，團隊需要快速的反饋和調整。

不要急於擴張團隊，要在成功經驗穩定並形成模式之後再快速擴充。

避免微服務良好的開發氛圍被稀釋，剛開始的時候擴充團隊可以慢一點。新老成員的配比不要超過1:1。

雖然微服務平台趨於穩定，但在微服務沒有上規模之前，不要讓團隊里缺少 Ops 成員。

注意知識的傳遞和人員的培養。

技術建議：

不要急於在微服務應用規模不大的時候形成微服務模板，否則會限制未來微服務的開發和擴展。

在微服務不成規模的時候不要放鬆對微服務平台的改進。

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