該不該將單體架構遷移到微服務？

譯者 | 陳峻

目前，業界最常見的軟體範例有：單體（Monolith）和微服務架構兩種型別。兩者的邏輯結構如下圖所示。

通常：

微服務架構是將應用程式表示為微小的、鬆散耦合的服務集合。由於整體的複雜性被轉移到了服務的協調級別上，因此每個服務都代表了一種業務功能，可以更加容易地去定位相關程式碼。

而單體架構是將幾個離散的功能組成一個單元，作為一個整體進行測試、部署和擴充套件。由於所有元件都是相互依賴的，因此通常不能夠單獨執行。這就意味著某個模組中的錯誤，可能會減慢、甚至破壞整個應用程式。

1。微服務架構的優點

一直以來，我們都沿用且諳熟單體架構，下面，我們先主要來討論微服務架構的各項優點：

易於擴充套件

應用元件相互獨立

有清晰的邊界，並能透過HTTP實現通訊

可以使用不同的程式語言和資料儲存

開發過程可被分到多個團隊

可被獨立部署

易於更新和維護

使用較小的程式碼庫

2。微服務架構的缺點

難以監控

具有更為複雜的服務部署

服務之間的通訊需要額外安全加固

效能會有所降低

鑑於分散式系統的遠端呼叫較慢，因此經常存在著程式設計難度大和失敗的風險

增加了運營的複雜性

3。何時選擇微服務

2001年，面對各種應用請求的增加，編碼問題突顯、開發的延遲、以及服務間的相互依賴性等問題，Amazon逐漸意識到需要從頭開始重構其系統，因此它將其單一的應用程式分解成小型的、獨立的特定於服務（service-specific）的應用程式，開創了微服務的架構。該架構實現了由一種服務接受訂單，另一種服務生成待購買的推薦商品列表，而第三種服務負責提供簡單的身份驗證服務等模式。正如Martin Fowler早在2015年，針對如何構建實用的軟體，所給出的建議那樣：“幾乎所有成功的微服務案例都是從拆分一個巨型的單體架構開始的。”當然，僅僅根據現代化趨勢來選擇微服務，不一定是正確的。通常，我們認為如下的應用和程式碼設計需求，更適合企業選擇轉向微服務：

繁重的系統負載，需要與不同的支付系統進行互動。

使用者需求不斷增長和規模持續擴大，現有應用系統常出現中斷。

單體應用變得不夠靈活且無法升級。

為了在競爭激烈的業務環境中取得成功，需要加快應用的開發和釋出時間，並可在後續著手進行功能的更新與升級。

需要實施人工智慧之類高階的商業智慧方案，以獲得更深入、更具競爭力的業務資料、報告和分析。

目前的基礎設施無法提供所需的橫向可擴充套件性，無法處理大資料的處理負載。

Amazon在2008年完成的被稱為“死亡之星”的微服務基礎設施

4。遷移至微服務所面臨的挑戰

企業在從單體架構向微服務架構的遷移過程中，往往會遇到各種技術和組織方面的挑戰，因此我們有必要了解與之相伴的各類風險：

麻煩且耗時。由於從單體應用整體遷移到微服務是非常耗費時間和精力的，因此企業往往選擇以“小步快跑”的方式進行分步遷移。如果需要在遷移的過程中引入新的服務特性，那麼開發團隊還要投入更多的精力。

成本較高。無論是從開發與編寫程式碼的角度，還是從支援、運維、以及更改的角度，遷移到微服務的成本都比較高。企業需要在構建基礎設施、開發文件、以及重構應用等方面進行大量的投資。

由於微服務是一個分散式系統，因此開發團隊需要選擇，並實現基於訊息傳遞或RPC的程序間通訊機制。

移動程式碼庫。為了順利地將資料從現有的單體架構提取至配合微服務的資料庫和程式碼庫，我們有可能需要重構其實現的過程，並透過完備的測試覆蓋率，以避免引入新的bug。

組織的轉變。為了實現遷移，企業需要將現有的大型專案團隊，拆分成能夠自主開展工作的小型團隊。同時，企業仍需要保持組織架構的一致型。

團隊應對其服務負責。在完成遷移後，各個團隊將擁有自己的程式碼庫，一旦出現服務交付的失敗，他們將不再可以歸咎他人，而需要從自身找原因，動手解決，負責到底。

此外，在系統不宕機的情況下進行遷移，並保證使用者持續有權訪問應用程式。這本身就有一定的風險。

可見，由於需要一定的資源投入，微服務架構可能並不總是對初創型或中型企業有利。

5。從審查和分析開始遷移

正如前文所提到的，從一個單體架構遷移到微服務架構不但繁瑣耗時，而且存在著風險。那麼，我們怎麼能夠在遷移之前就認定微服務一定適合本企業呢？《微服務遷移模式》一書的作者——Sam Newman，建議開發人員在動手之前考慮如下三個方面的問題：

您希望達到什麼目的？

您考慮過使用微服務的折中方案嗎？

您怎麼判斷遷移的有效性？

下面，我們根據Sam Newman的建議，提出一套分析方法：

6。設定目標

定義遷移對於業務和終端使用者的好處，明確企業想透過微服務獲得什麼。例如：是為了快速開發的整體程序，還是需要減少服務的相互依賴、亦或增加正常執行時間、以及增強可擴充套件性。

同時，我們需要事先預測系統在完成遷移後的負載和使用者數。

7。盤點業務與功能現狀

企業的應用架構師需要能夠找到關聯的程式碼物件，並將它們與系統中的業務功能相匹配。

在現有的單體架構中，可能許多函式由於在其使用域中尚未被明確地定義，或者是業務流程的邏輯較為混亂，因此往往無法被直接遷移或替換。例如：某個元件持續與其他多個元件相關聯，那麼就很難被拆分為多個普通的微服務。

分析當前的功能，並考慮對其進行最佳化。例如，透過剔除大量不必要的資訊，來最佳化資料庫的查詢，或者可以直接更換新的硬體，以及透過開發新的功能，來引入微服務。

8。團隊的能力和折中方案

評估團隊的DevOps成熟度水平，包括：是否瞭解DevOps的核心實踐，是否具備基本的自動化文化？運營團隊是否支援指令碼式部署？是否擁有程式碼即基礎設施？是否已有程式碼評審的標準？團隊只有具備了這些成熟的開發和運維實踐能力，才能發揮微服務架構的優勢。

由於依賴性在服務之間建立了連線，模糊了元件的邊界，並導致它們必須組合成單個的模組功能，因此團隊只能嘗試著從應用的垂直或水平方向進行擴充套件。

根據專案的特點，僅分離並遷移諸如：電子郵件的傳送、通知的推送或電話的呼叫等部分受限的功能。當然，如果您只想從儀表盤系統內剝離出來，從已連線的資料庫中收集與分析資料，進而單獨形成微服務的話，那麼應全面考慮相互之間的關聯性。

9。選擇可擴充套件平臺

為了保證在構建和遷移至微服務時，使用者的體驗不會受到影響，開發團隊應邀請使用者一起進行業務需求分析，構建詳細的業務邏輯和資料流。有時，您可能需要一個專有的平臺來擴充套件微服務的資源，並能夠支援自動化的調整。在此方面，您可以使用由雲服務提供商託管的無伺服器型別的基礎設施，例如：Google Cloud、Microsoft Azure和Amazon Web Services等。

10。考慮建立跨職能團隊

在遷移的過程中，企業需要團結包括開發人員、質量保證（QA）人員、操作運維人員、以及企業所有者等角色，以微服務為驅動，來建立可以從事設計、構建、部署和維護的服務型團隊，並儘量簡化不必要的審批流程。傑夫·貝索斯曾說：“我們試圖建立一支規模不超過兩個比薩餅的隊伍。”他稱之為“雙披薩團隊規則”。

下面，我將向您介紹從單體架構遷移到微服務架構的一些值得注意的參考經驗。

11。定義邊界

正確的邊界往往是有效的微服務架構的基礎。相反，如果邊界定義錯誤，則可能導致在新的微服務中，各項功能被頻繁更改，特別是那些提供呼叫的微服務介面，很可能會在隨後的整合測試中持續“浮動”。而且，由於不同微服務出自不同的團隊，因此它們會牽扯到團隊之間的各種反覆協商與較量。

一個典型的域分離的例子源於軟體公司Istio。由於前期定義不足，在遷移到微服務後不久，Istio團隊便從使用者處得到了各種反饋。他們很快地意識到，微服務並非像他們最初想象的那麼實用。其主要原因是：所有控制面的服務都是被一股腦部署和使用的，並且共享著相同的管理和安全域。因此，為了大幅降低Istio的操作複雜性，以更少的精力滿足業務需求，並能夠更容易地開發出服務產品，他們決定從微服務架構迴歸至單體架構，並按照相關的技術標準來構建單體架構，識別架構中的業務域邊界，並使用公共的API作為介面，來予以實施。

12。選擇單體架構中可以被遷移的功能

在遷移之前，一個由工程師和作用域專家組成的團隊，可以通過了解現有的實現方式、依賴關係、以及內部事件等途徑，來確定哪些功能組可以作為微服務，提供最大的產品價值；而哪些剩下的功能，則可以酌情保留在單體架構中。

13。微服務的獨立資料儲存

每個微服務都需要有一個數據儲存庫，這在某種程度上給分離資料的管理增加了難度。由於單個儲存系統很容易因為失去同步，而出現不一致性，因此您需要使用能夠執行主資料管理（master data management，MDM）的工具。例如，它可以透過檢查每個訂閱者ID的資料庫，及時發現其中是否存在相同的ID。據此，就算某個服務停止了工作，它也能夠確保使用者資料的安全性。當然，最理想的狀況是將資料同時儲存在微服務和單體表中。

14。保留微服務的程式碼

通常，我們與其在效能良好的微服務中新增、重寫一段程式碼，不如為新的或更改後的程式碼建立或部署一個新的微服務。據此，我們不但可以簡化新程式碼的測試，而且能夠減少現有服務在微服務中出錯的可能性。

15。微服務的單獨構建

透過對每個微服務採取單獨的構建，我們可以在儲存庫中，以適當的修訂級別獲取元件檔案。

16。在容器中部署微服務

為了儘量簡化，我們最好使用同一種工具，在容器中部署微服務。例如，Docker便是被廣為推薦的一種容器標準。

17。典型的成功遷移案例

Netflix（奈飛）

為了能夠全天候地運營，Netflix需要一種架構來最佳化交付速度，並擴充套件到下一個資料量級。因此，Netflix決定擺脫資料中心裡由關係型資料庫所帶來的，在垂直向擴充套件時的單點故障，使用NoSQL資料庫對資料模型進行非規範化處理。同時，該公司採用了由雲服務提供的高度可靠的、可橫向擴充套件的分散式系統，並透過選擇AWS作為雲服務提供商，獲得了大規模且廣泛的服務和功能。此外，微服務架構也方便Netflix將系統分成獨立的服務，其中包括：儲存所有觀看節目的服務，負責每月信用卡支付的服務，以及分析觀看歷史以提供類似電影節目的服務。該公司的全部遷移過程耗時整整七年。

Netflix微服務基礎設施的邏輯圖

Wix.com

由於Wix。com的應用程式是彼此連線的，因此係統一旦在某個部分出現問題，都會導致整個系統的崩潰。對此，Wix。com開創了新的整合和端到端測試模式，運用JSON/RPC協議，在SpringMVC的基礎上，構建了一套微服務框架。透過遷移，它們解決了處理微服務之間的通訊、故障與除錯等的技術債。

Cloud Elements

Cloud Elements使用諸如Minikube和Docker之類的工具，管理本地和遠端執行的服務。由於所有的微服務都在Node。js中，因此他們使用諸如Ava等基於npm的單元測試包，實現了程式碼測試的全覆蓋，以應對業務的指數增長，並根據新增的需求不斷迭代其微服務。

Best Buy（百思買）

過去，相互依賴的架構造成了Best Buy在業務部署上的難題。長時間的宕機給其線上業務的維持帶來了不小的挑戰。開發團隊往往需要把新的功能逐個打包，再累計釋出。如今，他們透過諸如：Chef和Jenkins等工具，實現了持續整合與部署，並且將資料庫遷移到了Riak（一個分散式NoSQL鍵值資料儲存）上。

18。小結

綜上所述，我們是否應該跟上軟體架構的趨勢，放棄單體架構，投入微服務的懷抱，目前尚無絕對的定論。我的觀點是：如果目標專案既沒有高負載，又無頻繁地與外部服務互動的需求，那麼我們便可以選擇或維持單體架構；而如果系統必須在大量的負載和服務請求下工作，那麼微服務架構會是更好的選擇。

我們再來看企業的組織結構層面。如果貴公司只有一個開發團隊，那麼建議您集中精力構建和維護單體架構；但是如果您有幾個IT團隊，可以同時開發同一個產品的話，微服務會比較合適一些。

客觀而言，微服務架構有利有弊，它只是構建軟體的另一種方式。是否應該選擇完全取決於應用程式的業務需求。當然，您也可以從一個簡單的單體架構開始，隨著服務需求的增長，慢慢將應用元件獨立出來，並遷移到微服務中。這可能是更為穩妥的應用實踐。