【小宅按】 對於任何企業，MSA的實施都不能一蹴而就。企業在實施MSA的過程中應該避免教條主義、理想化、低估必需的投資、邊學習新流程邊變更架構、擔憂失敗等風險與陷阱。企業可以在MSA實施指導框架的指引下，進一步建立MSA的戰略目標、原則、實踐、工具平臺視圖，以更好地指導MSA落地。

隨著領域驅動設計（DDD，Domain Driven Design）、持續交付、雲計算、小型自治團隊、大型集羣系統等實踐的發展與流行，微服務架構（MSA，Microservices Architecture）也應運而生。在數字化轉型時代，許多組織為了提升業務敏捷性（Business Agility），發現MSA或許是幫助自己更快地交付軟體的強大武器，因為MSA有望在靈活的變更交付、技術靈活性、更精準的彈性等方面帶來益處。

然而企業卻很快發現，單純將MSA視為靈活的架構模式，往往難以保障MSA的成功實施。因而，若要成功實施MSA，除了改變軟體交付物的結構化方式，企業必須在以下方面進行改變：

    • 應用開發、交付與運維的組織方式
    • 維持流動性同時確保質量與彈性的流程
    • 微服務相關模式與實踐所必需的新工具與平臺

那麼，企業到底應該如何實施MSA才能提升成功率呢？有沒有一種指導性框架為MSA實施保駕護航呢？在探討此問題之前，也許明確一下MSA的適用場景更為緊要。在《人月神話》中，Fred Brooks曾指出「軟體沒有銀彈」。此論斷對於MSA仍然適用。企業不應該將MSA視為軟體交付的銀彈。從嚴格意義上來講，MSA的優勢在於幫助企業解決軟體領域的複雜問題（Complex Problem）。一般來講，複雜問題具有以下幾個特徵：（1）沒有足夠的數據進行決策；（2）必須進行探索；（3）需要浮現式設計與實踐；（4）面向行動的方法。關於複雜問題的詳細闡述，可以參考Cynephin框架（mindtools.com/pages/art）。當然，在企業面對複雜問題或者系統時，如果同時需要頻繁部署來快速響應市場需求、需要高可用以及快速彈性神作，MSA將成為優先選項。

基於MSA的適用場景，並結合諸多企業實施MSA的實踐，形成了如下圖所示的實施指導框架，稱之為「3PSD」。

圖 MSA實施指導框架3PSD

從上圖中，可以自然而然地看出流程（Process）、人員（People）、平臺（Platform）、服務（Service）、數據（Data）之間相互影響：

    • 從流程來講：流程需要平臺自動化、流程驅動自治團隊、流程優化驅動服務的範疇界定；
    • 從人員來講：人員文化支持流程優化，人員技能影響平臺選擇；
    • 從平臺來講：平臺能力支持流程執行、人員角色、約束服務，平臺持久化與移動數據；
    • 從服務來講：服務的定義驅動平臺需求、人員組織、數據組織；
    • 從數據來講：數據的組織驅動服務的範疇界定，數據需求驅動平臺需求。

因此，對於實施MSA的軟體系統來講，流程、人員、平臺、服務、數據很難一步到位，採用迭代方式成為一種必然選擇。當然，MSA的實施難以有明顯的最終狀態，因為隨著迭代深入，實施框架中的5個方面發生變化的概率非常大。

在實施MSA之前，企業組織確定了適應的場景後，應該開展準備工作，評估組織的就緒程度。簡單來講，企業可以從以下幾方面進行評估：

1. 真正敏捷；敏捷開發流程與實踐；

2. 自動化程度：構建、測試、部署等；

3. 工程師文化：規劃交付，並準備好試驗與演進；

4. 踐行DevOps；持續交付等；

5. 產品思維；

經過評估認為實施MSA已就緒後，企業應該確認商業幹係人需要快速、可靠、靈活的功能交付與變更帶來的價值。這樣，企業就可以按照指導框架在流程、人員、平臺、服務、數據等方面開展相關工作。

1 優化流程

開發與運維流程通常是MSA交付中最為關鍵並且最容易被忽略的部分。MSA需要非常高水平的開發與運維流程的成熟度與自動化。目前來看，DevOps的原則、文化與實踐對於MSA的成功至關重要。企業組織應該從以下方面優化流程：

    • 持續集成/持續交付：利用流水線實現微服務並行獨立部署
    • 流程自動化：構建、測試、部署、環境等環境自動化能力
    • DevOps反饋環：在交付流程中增強反饋，隨時掌握服務狀態、健康度，行為等
    • 發布方式與計劃：每個獨立的微服務可以獨立、按需發布，來滿足快速的需要；
    • 優化測試與QA流程：採用TDD/BDD、集成測試等測試左移（Shift-left testing）與金絲雀測試、A/B測試、在線巡檢等測試右移（Shift-right testing）相結合
    • 解決自治與分佈服務引發的治理訴求：服務的SLA定義，服務下線等等；

2 提升人員與技能

通過MSA實現敏捷性非常依賴小型的自治團隊。此團隊應該與業務服務領域對齊，而不是技術領域。此組織結構與敏捷開發中的特性團隊或者組件團隊類似。關於組織結構，可以參考「DevOps組織如何選取拓撲結構以提升協作效能」。對於人員與技能，建議在以下在以下方面進行提升：

    • 平衡自治與責任
    • 敏捷與DevOps文化相關的原則
    • 面向服務的工程師文化
    • 現代開發範式與概念：例如DDD、事件驅動架構、浮現式架構等；
    • 更廣泛的技術技能：例如T-shaped；
    • 擁有質量意識：例如單元測試、測試自動化等；

3 構建技術平臺

對於實施MAS的企業來講，不單單需要敏捷與DevOps流程、良好組織與技能豐富的人員，更需要技術平臺來管理日益增加的複雜性。

圖 MSA技術平臺全景

如上圖所示，MSA平臺不應被過度簡化為容器化，MSA平臺包含了外部網關、Service Mesh、遙測與監控、CI/CD自動化等部件。關於MSA平臺的選擇可以分為2類：一類為雲服務提供商平臺，一類為部署在自行管理基礎設施上的雲原生應用平臺。對於第一類平臺，企業可以選擇華為雲相關服務，例如DevCloud（）提供了端到端DevOps平臺能力，可以有效支持CI/CD自動化；ServiceStage提供面向企業的雲原生應用管理服務。

4 定義服務

在MSA中，模塊化的主要單元是服務本身，主要包括：（1）功能集合與訪問功能的介面；（2）實現的邊界與部署單元。企業可以應用DDD與限定上下文來劃定微服務，並在靈活性、複雜性與性能之間進行許可權，使微服務滿足以下特徵：

    • 松耦合
    • 高內聚
    • 採用公開標準暴露介面
    • 實現單一職能
    • 擁有管理的數據
    • 獨立部署
    • 獨立伸縮
    • 將發布的API與微服務實現解耦

5 解耦數據

為了提高敏捷度以及服務間的獨立性，企業必須對服務的數據進行解耦。數據解耦可以參考以下原則進行：

    • 數據必須被一個也只能被一個微服務管理（創建、更新與刪除）
    • 數據只能通過管理此數據的微服務提供的介面訪問
    • 嚴格禁止不同服務擁有的數據之間的資料庫強制型關係（例如引用完整性）
    • 需要平衡數據解耦帶來複雜性與敏捷性
    • 可以通過API契約進行數據關係建模

對於任何企業，MSA的實施都不能一蹴而就。企業在實施MSA的過程中應該避免教條主義、理想化、低估必需的投資、邊學習新流程邊變更架構、擔憂失敗等風險與陷阱。企業可以在MSA實施指導框架的指引下，進一步建立MSA的戰略目標、原則、實踐、工具平臺視圖，以更好地指導MSA落地。

圖 MSA戰略目標-原則-實踐-平臺工具視圖

更多精彩內容，請滑至頂部點擊右上角關注小宅哦~

來源：華為雲社區 作者：倫語春秋


推薦閱讀：
相關文章