譯者 | 劉汪洋

審校 | 重樓

當單體架構成為項目增長的瓶頸時，遷移到微服務架構就成了必然的選擇。

微服務雖然具有明顯的優點，但由于其內在復雜性和缺乏一種通用的遷移方案，實施過程中可能會遇到不少挑戰。本文旨在分享解決方案架構師在單體架構向微服務遷移過程中的專業經驗，并闡述如何在確保項目安全性和可靠性的前提下，成功完成遷移。

單體架構到微服務：遷移路線圖

下面，我們將從涉及的五個主要步驟入手，深入探討如何讓單體架構向微服務的遷移過程更為順利。

第一步：技術與商業需求分析

成功地從單體架構遷移到微服務的第一步是從商業角度證實這一轉型的必要性。每個項目都有其特定的技術優勢和局限性，因此，這一轉型將對整個產品架構產生深遠影響。這個新架構需要能夠適應未來的業務增長。因此，建議與商業分析師和技術專家聯手，準確地評估當前系統的需求，并制定一個高效的開發路線圖。

盡管微服務多年來一直是業界熱點，但并不是所有項目都適合采用微服務。事實上，完全符合微服務理念的項目是相當罕見的。盡管微服務已經成為一種行業趨勢，但至今還沒有一個完美的微服務實施案例。但這不應成為企業進行轉型的障礙。關鍵在于合理地設定期望，并仔細評估預期的技術方案是否能夠實現既定目標。

應用現代化策略中，將現有應用遷移到微服務是一種常見的做法。然而，從零開始就使用微服務構建應用并不總是最佳選擇。相反，應首先考慮采用單體架構，或者至少在其中實現核心業務邏輯。這樣，后續的服務拆分會更為簡單。過度追求微服務之間的隔離可能會導致不必要的復雜性。

對于大型團隊參與的項目，微服務無疑是一個合適的選擇。它們不僅在系統架構層面提供了可擴展性，還能在團隊協作方面帶來便利。這種架構的一個顯著優勢是能夠整合多種不同的技術棧。

在正式遷移到微服務之前，進行全面的技術審計是非常關鍵的。這一審計應明確當前項目所依賴的技術棧，并評估這些技術是否可能成為未來發展的制約因素。如果有這種可能，應考慮是否需要采用其他更適合微服務的技術選項。與具有特定技術專長的專家進行咨詢，可以獲取有價值的建議，從而確保架構轉型過程的平穩和高效。

第二步：識別適合遷移到微服務的系統組件

接下來，我們需要確定哪些系統組件適合遷移到微服務，以及這些微服務將如何進行模塊間的交互。簡而言之，這一步驟涉及到對產品總體架構的設計，以及確定哪些服務應當優先進行拆分。

微服務在處理某些特定功能時表現尤為出色，如實時通信、數據處理流程、后端任務處理，或與外部服務的接口。這些功能雖然可能需要訪問單體架構中的數據，但在技術實現上是相對獨立的。

第三步：單體架構到微服務的拆分策略

拆分單體架構到微服務有兩種主要方法。

第一種方法是從單體架構中逐步剝離特定功能，同時逐漸減少其與其他組件的依賴性。一旦完全解耦并設計了新的 API，這些功能便可以作為獨立的微服務發布。這種方法通常需要對原有的單體架構進行較大幅度的修改。

第二種方法則是復制所需的功能，并在保留單體架構中原有功能的同時，將其開發為一個新的微服務。一旦新的微服務經過全面測試并確認功能完備，便可以從單體架構中移除原有功能。

第四步：數據管理策略

微服務架構的一個核心原則是，每個微服務應擁有其專屬的數據庫。然而，由于數據庫對象間可能存在交集和依賴關系，拆分單體數據庫通常是一項具有挑戰性的任務。

不同的微服務可以采用不同的數據庫、編程語言和數據存儲方案。某些數據庫可能比其他數據庫更為復雜，這使得將所有數據集中到一個統一數據庫中變得不現實。因此，針對特定類型的數據，通常會使用專用的存儲系統。

在微服務的數據管理方面，可以根據涉及的數據模式進行相應的操作分類。

獨享數據庫模式（Database-per-Service）

在微服務架構中，每個服務獨立數據庫模式強調了模塊自主性和數據封裝的重要性。該模式通過為每個微服務配置專屬數據庫，確保了數據一致性和隔離性，從而降低了服務間的數據競爭風險。

然而，這種做法也使得數據集成和跨服務查詢變得更為復雜，因此需要高效的通信協議和明確的接口定義。同時，數據庫模式的變更需要謹慎處理，以防意外導致服務中斷。但憑借合適的策略，該模式能顯著提升微服務生態系統的可擴展性和容錯能力。

SAGA 模式

SAGA 模式是解決微服務事務中跨分布式系統數據一致性問題的關鍵策略。與依賴傳統數據庫事務不同，SAGA 模式將事務操作拆分為一系列可獨立執行且可回滾的步驟。如果某個步驟執行失敗，將觸發相應的補償事務以保證整體數據一致性。

這種分布式處理方式雖然增強了系統的彈性和可擴展性，但也要求精細的任務編排和錯誤處理機制，以有效地應對可能出現的失敗情況。

API 組合模式（API Composition）

API 組合模式是微服務架構中用于解決多服務數據檢索問題的基礎策略。在一個由多個微服務組成、每個服務管理各自數據片段的環境中，直接在客戶端進行數據查詢往往會變得復雜和低效。

為解決這一問題，API 組合模式引入了一個中介層，通常稱為 API 組合器或聚合器。該中介負責將來自不同微服務的數據整合為一個統一的響應結果，從而為客戶端提供了一個集中的數據訪問入口，簡化了查詢過程并優化了數據傳輸效率。然而，開發人員需要確保這個組合器高效運行，避免成為系統的性能瓶頸或單點故障。

命令查詢職責分離模式（CQRS）

在微服務架構中，數據管理通常是分散的，特別是當一個服務需要同時負責數據的更新和查詢時，這會增加系統復雜性。

CQRS 通過分離命令操作（即數據寫入）和查詢操作（即數據讀取）來解決這個問題。按照這種設計，微服務可以根據其主要職責進行優化：某些服務主要負責數據讀取，而其他服務則專注于數據寫入。這樣，每個服務都能根據自己的工作負載進行獨立擴展。

雖然 CQRS 在微服務架構中有多個優勢，但它也增加了額外的復雜性，尤其是在保證服務間數據一致性的方面。因此，在決定是否采用 CQRS 時，需要仔細評估系統的具體需求。

事件源模式（Event Sourcing）

事件源模式強調將應用狀態的所有變化以事件的形式進行捕獲和存儲。與僅保存數據的當前狀態不同，該模式保存一系列狀態轉換的事件，從而允許系統通過回放這些事件來重構狀態。

在微服務環境下，這種方法讓每個服務都能維護自己的歷史狀態，從而增強了服務之間的自主性和解耦。由于這些事件成為了數據的唯一真實來源，它們可以用于多種用途，從數據分析到審計追蹤。

雖然這種模式很強大，但還需要考慮事件版本控制和數據存儲的可擴展性。

共享數據庫反模式（Shared Database Anti-pattern）

當多個微服務或系統組件直接與一個公共數據庫交互，而不是通過 API 或消息傳遞機制，就會出現所謂的“共享數據庫反模式”。這種直接的數據庫訪問方式不僅削弱了各個服務的自主性，還可能導致數據完整性問題。

采用這種設計的系統可能會面臨安全風險，因為有可能無意中暴露敏感數據。此外，這樣的設計也會增加系統演進的復雜性，因為即使是微小的數據庫更改也可能需要多個服務進行協調和調整。

下一步

無論你選擇哪種數據管理策略，都應避免陷入“分布式單體”這一陷阱。如果各個服務之間沒有做到完全的隔離，這通常會引發更多問題。從結構和數據庫角度看，這樣的設計仍然具有單體的特性。盡管表面上看似已經進行了拆分，但實際上各服務之間仍然存在大量的耦合，從而導致微服務的多數優勢被削弱。

接下來，您需要構建 API 接口，這些接口將負責微服務與單體應用以及其他微服務之間的通信。API 將從被調用的服務獲取必要的數據。

步驟 4：優化服務間通信

在設計服務間的通信策略時，需要考慮交互模式。通常，服務間的交互可以分為兩類：

• 每個客戶端請求由單一服務處理（一對一交互）
• 多個服務共同參與處理一個請求（一對多交互）

同時，還需要考慮交互的同步或異步特性：

• 同步交互：在這種模式下，客戶端發送請求后會等待服務端的即時響應，期間可能會被阻塞。這是一種直接的、同步的交互方式。
• 異步交互：與同步交互不同，異步模式下客戶端在發送請求后不會被阻塞。服務端的響應可能不會立即到達。這通常通過消息代理來實現：一個獨立的軟件組件負責維護數據通道。一個服務在該通道上發布消息，而需要這些消息的服務則訂閱它。這樣，各服務可以在合適的時機異步地處理這些數據。

從業務邏輯的角度來看，如果某個任務可以異步完成，那么最好采用異步方式。這不僅提高了系統的穩定性，還有助于實現負載均衡。

步驟 5：測試與部署

在微服務測試方面，與傳統單體應用有明顯的不同。在單體應用架構中，整個程序可以作為一個緊密耦合的單元進行全面測試。然而，在微服務架構中，應用由多個服務組成，這些服務可能無法同時進行測試，從而增加了端到端測試的復雜性。這一點要求我們采用不同的測試策略。

針對微服務，我們通常會進行以下幾種類型的測試：

• 單元測試：專門針對單一服務的功能性進行測試。
• 集成測試：確保不同服務之間能夠順暢地協同工作。
• 性能測試：評估整個系統的響應速度和穩定性。
• 組件測試：對單個服務的各個組件進行測試。
• 契約測試：驗證用戶與服務間的交互是否符合預定規范。
• 端到端測試：全面檢查應用程序的性能和功能。

這些測試類型旨在確保微服務不僅單獨，而且在整體上都能滿足業務需求。然而，測試微服務也面臨一系列挑戰。

例如，一個微服務中出現的錯誤可能會引發一連串的問題，這大大增加了根因分析的復雜性。由于微服務間通常通過多種方式和協議進行通信，這就需要具備專門的技術知識和能力。加上需要測試多個接口點，并且自動化測試在這里尤為重要，因此熟練掌握腳本編寫和自動化測試工具變得尤為關鍵。

微服務開發：挑戰與最佳方案

微服務開發面臨一系列特有的挑戰，因此需要一套全面的方法論來應對。對這些問題的早期認識和解決，是微服務成功部署的關鍵。

數據一致性

在微服務架構中，確保各個服務之間事務的準確性和數據的一致性是一大挑戰。雖然沒有一種“萬能”的解決方案，但有一些普遍適用的管理數據的原則。

在需要強一致性的業務場景中，某個服務可以作為特定數據實體的主要數據源。其他服務可以通過 API 接口來訪問這個主數據源。某些服務可能會維護部分數據副本或版本，但這些都應與主數據源保持一致。

以電子商務系統為例，可能存在一個專門處理客戶訂單的服務和一個負責推薦的服務。推薦服務雖然能感知訂單服務的活動，但在如客戶退款等特殊情況下，訂單服務仍然是完整交易記錄的權威來源。

因此，經驗豐富的開發者需要先了解具體業務場景的需求。然后，他們可以靈活選擇最適合的數據一致性保證方法。

團隊組織與協作

在微服務的開發過程中，不同的團隊可能有各自的管理風格和開發方法論。因此，建立一個明確的團隊間溝通和協作機制是至關重要的，尤其是當工作需要在內部團隊和外包團隊之間協作時。

一個高度正規的組織結構可能讓各團隊能有效地開發自己的服務。然而，如果忽視與其他團隊服務的集成，可能會出現數據格式不一致等問題。因此，項目中需要有一個“協調者”角色，負責統籌各個團隊的工作。

從更高的層面來看，康威定律告訴我們，軟件系統的架構往往會反映其開發團隊的組織結構。因此，如果目標是構建一個由多個自治服務組成的系統，那么首先應該組織多個小型、自治的開發團隊，并確保他們能夠有效地進行溝通和協作。

DevOps 的角色與挑戰

在微服務架構中，DevOps 扮演著至關重要的角色，因為這種架構本身具有更高的復雜性。在這樣的環境下，需要精細地協調各個微服務的部署，以確保它們能夠無縫地互相協作。這尤其重要，因為微服務之間通常是緊密相連的，并且可能會有向后不兼容的變更。因此，提前解決所有依賴關系并采用靈活的工具，如 Kubernetes 和 Docker，非常關鍵。DevOps 工程師在這方面起到了至關重要的支持作用。

此外，微服務架構也使得故障排查更加具有挑戰性。與單體架構相比，在微服務環境中，準確地定位問題的根源更加困難。這是因為一個服務可能會接收數據并傳遞給另一個服務，這樣就增加了確定問題所在環節的復雜性和耗時。為了解決這一問題，必須集成集中式的日志聚合工具、部署編排系統和分布式追蹤系統。這樣做能讓整個系統更容易管理。

總結與建議

當企業決定向微服務架構遷移時，需要全面考慮多個方面。這包括確定哪些系統組件適合遷移到微服務、如何管理數據、如何構建高效的基礎設施，以及如何組織和協調團隊的工作。在這一過程中，與經驗豐富的工程師和解決方案架構師的緊密合作是實現目標的關鍵。

譯者介紹

劉汪洋，51CTO社區編輯，昵稱：明明如月，一個擁有 5 年開發經驗的某大廠高級 Java 工程師，擁有多個主流技術博客平臺博客專家稱號。

原文標題：How to Migrate from Monolith to Microservices: Challenges and Best Practices，作者：MobiDev