單元化架構，分散式系統的新王！

0 關鍵收穫

• 單元化架構透過減少故障的爆炸半徑來增加系統彈性
• 單元化架構是那些任何停機時間都被認為是不可接受的，或者可以顯著影響終端使用者的系統的一個好選擇
• 單元化架構透過強制使用固定大小的單元作為部署單元，並傾向於擴充套件而不是擴充套件的方法，增強了微服務的可伸縮性模型
• 單元化架構透過將各種元件（可能是微服務）打包並部署為單元，而不是在應用程式服務的粒度級別上，使它們在更廣泛的系統上下文中的位置更清晰
• 單元化架構透過在單元周圍應用額外的安全層來幫助提高分散式系統安全性

本文是[單元化架構：如何構建可擴充套件和彈性系統]系列的一部分。在這個系列中，我們展示了一個發現之旅，並提供了對單元化架構的許多關鍵方面的全面概述和深入分析，以及將這種方法應用於現有和新架構的實用建議。

業務架構是一個存續了20多年的概念，至今也未有官方的定義，說明業務架構一個涵蓋具有廣泛包容性的概念，在不同場景和語境下它可能包含至少如下的含義：

1. 實現業務需求的技術架構
2. 在基礎架構/中臺架構之上的包含具體業務功能的架構層
3. 更宏觀的，支援企業戰略實現的能力佈局，也可以稱為業務架構

存在即合理，本專場不求對概念做清晰的闡釋，意在為大家展示此概念下的各種可能行，展示不同業務下不同環境下技術人員如何利用或成熟的，早期的或者創新的技術來解決業務問題，提升業務效率。當然，我們更傾向於選擇具有創新意義的話題，譬如：

• Cell-based架構：最近出現的一種架構模式，微服務架構大家都非常熟悉了，在這個架構中採用的是“所有人都可以互相通訊”的原則。在單元化架構中增加了路由策略，服務會優先呼叫同一單元（Cel）中的其他服務，Cell可以是可用區域也可以是任何其他的自定義的訪問範圍。Cell-based架構可以顯著節省成本，減少了延遲提高效能。同時也可以提高可用性，因為故障的爆炸半徑被縮小為一個單元，其他單元完全不受影響，可以正常執行。

  Roblox、Slack 和 DoorDash 只是實施單元化架構並取得顯著改進的公司的幾個例子。我們相信這是一個創新趨勢，許多公司將開始採用，因為他們希望調整分散式系統的規模、控制成本並提高系統彈性。

• 資料驅動架構：一定程度上在基於業務資料做架構決策，從資料中識別出可廣泛應用的明確的趨勢是非常具有挑戰性的。所以在資料驅動架構下，複雜的資料分析平臺不再是系統的附加功能，而是升級為了業務架構的的核心部分之一。

軟體開發面臨主要挑戰之一是擴充套件性。無論你在創業公司還是大型企業，評估如何交付一個新產品或功能時，系統應該如何可靠地處理不斷增加的負載的問題不可避免地出現。

構建和運營現代分散式系統的挑戰隨著規模和複雜性的增加而增加。基礎設施資源，無論是在雲中還是在本地，都可能經歷難以排查的意外故障，架構元件需要處理這些故障以提供所需的可用性。

1 單體、微服務和彈性挑戰

幾年前，微服務及其相關的架構變得流行，因為它們幫助解決了單體應用程式（monorepos）面臨的一些擴充套件挑戰。

正如Susan Fowler在幾年前接受InfoQ採訪時提到的，這些應用程式可能不支援足夠的併發或分割槽，因此會達到導致效能和穩定性問題的可擴充套件性限制。隨這些單體應用程式的增長，它們在本地環境中的工作變得更加具有挑戰性。應用程式部署變得越來越複雜，導致團隊的開發速度會急劇下降。

微服務透過使團隊能夠獨立工作、部署和擴充套件服務來緩解這些問題。然而，像大多數事物一樣，沒有什麼是無缺陷的，微服務也有挑戰。其中一個是，微服務架構非常細粒度，以至於達到了單個服務的水平。因此，開發團隊將缺乏對他們擁有的各個微服務在更廣泛的系統上下文中的使用位置的知識。瞭解其他團隊擁有的哪些微服務將更感興趣也將更具挑戰性。

隨著時間的推移，這些挑戰在微服務架構變得更加複雜時變得更加突出。此外，隨著雲基礎設施的廣泛採用，許多公司現在管理著從計算到儲存再到網路和支援服務的大量雲資源。這些資源中的任何一個都可能經歷失敗，可能導致服務的輕微或顯著降級，儘管使用了冗餘和故障轉移機制，但如果沒有采取特殊措施，一些故障模式不能完全被遏制。

2 基於單元架構的復興

與故障隔離相關的挑戰並不新鮮，也不特定於微服務或雲。隨著軟體系統變得分散式以適應不斷增加的負載需求，由於其分散式特性，必須考慮許多新的故障模式。

單元化架構首次出現在SOA時代，作為在大型分散式系統中管理故障並防止它們影響整個系統可用性的嘗試。這些公司如Tumblr、Flickr、Salesforce或Facebook的初始實現 旨在使用自包含的單元作為並行化的單元來管理基礎設施和應用程式資源，並隔離故障，將故障的爆炸半徑限制在只有一部分客戶或使用者群體（一個分片）。

單元化架構，首先，是艙壁模式的一種實現，這是軟體工程從造船業採納的一個概念。艙壁 是船體結構中的水密垂直隔板，以防船體破損時水淹沒整個船。

艙壁正在保護船隻免受洪水蔓延：

多年來，艙壁模式一直被宣傳為現代架構的關鍵彈性模式之一，特別是微服務。然而，由於額外的複雜性，採用率一直很低，因此大多數公司選擇將工作重點放在其他地方。

一些高調的公司最近選擇重新審視單元化架構方法，以滿足其基於微服務的、雲託管平臺的高可用性要求：

• Slack已經將其大部分關鍵面向使用者服務遷移到使用基於單元的方法 ，因為在AWS可用區域網路故障後經歷了部分停機
• Doordash 實現了基於其Envoy基礎服務網格的區域感知路由 ，轉移到基於AZ的單元架構，並減少了跨AZ資料傳輸成本
• 反過來，Roblox 正在將其基礎設施重新組織為單元以提高效率和彈性 ，因為它繼續擴充套件

這些公司的共同點是，它們在雲或私有資料中心的大型基礎設施上執行微服務架構，並且由於基礎設施或應用程式故障的無限爆炸半徑，經歷了嚴重的停機。作為回應，它們採用了單元化架構，以防止故障導致廣泛停機。

亞馬遜網路服務（AWS）一直是基於單元架構的長期採用者和倡導者，並在2018年的年度re:Invent會議上 和2022年再次 介紹了它。該公司還於2023年9月釋出了關於基於單元架構的白皮書。

3 基於單元架構的構建塊

在高層次上，單元化架構由以下元素組成：

• 單元 - 自包含的基礎設施/應用程式棧，提供故障邊界；負責處理應用程式工作負載
• 控制平面 - 負責提供資源、部署應用程式服務、確定路由對映、提供平臺可觀察性、移動/遷移資料等。
• 資料平面 - 負責根據資料放置和單元健康（由控制平面確定）適當路由流量

為提供容錯好處，單元化架構旨在支援單元級別的隔離和控制平面與資料平面之間的低耦合。重要的是要確保資料平面可以在沒有控制平面的情況下執行，並且不應直接依賴於控制平面的健康狀況。

4 單元作為一等架構構造

採用單元化架構提供了有趣的好處組合。單元首先在基礎設施級別提供故障邊界，指定的單元例項用於服務特定部分的流量，將故障隔離到使用者或客戶群體的一個子集。然而，它們也提供了將相關應用程式服務分組到特定於域的叢集中的機會，幫助與架構和組織結構對齊，促進高內聚和低耦合，並減少工程團隊的認知負擔。

對於小型系統或當開始單元化架構採用工作時，完全有可能有一個單元包含所有應用程式服務。對於具有許多應用程式服務的大型系統，可以使用多個單元根據域邊界組織架構。這種方法可以幫助更大的組織採用產品思維，並使系統架構與產品域和子域對齊。這對於由數十或數百個團隊構建和運營大型產品組合的大型微服務系統尤其重要。

單元化架構結合了域和故障隔離邊界：

從容錯的角度來看，一個單元（或單元例項）是一個完整的、獨立的基礎設施棧，包括它執行和為指定部分的流量服務所需的所有資源和應用程式服務例項（由單元分割槽策略確定）。至關重要的是儘可能隔離單元以保持故障包含。理想情況下，單元應該獨立於其他單元，並且不共享任何狀態或具有共享依賴項，如資料庫。任何單元間通訊應該保持在最低限度；理想情況下，應該避免同步API呼叫。相反，應該使用非同步、訊息驅動的資料同步。如果無法避免API互動，它們必須透過單元路由器進行，以便不會破壞基於單元架構的故障隔離屬性。

關於單元部署選項的許多考慮因素包括選擇單個或多DC（資料中心）部署，並確定最優的單元大小。一些組織採用了單個DC部署的單元化架構，其中所有基礎設施和應用程式資源的單元例項都位於同一個資料中心或可用區域。這種方法最小化了多DC部署的灰色故障影響，並簡化了健康監測（單元要麼健康，要麼不健康）。另一方面，如果使用得當，多DC部署可以在DC級故障的情況下提供彈性，但健康監測變得更加具有挑戰性。

單元大小也可以在管理故障影響和管理基礎設施成本方面發揮重要作用。使用較小的單元可以減少影響範圍（受影響的使用者/客戶較少），提高資源利用率（由於較高的單元佔用水平，閒置資源較少），並限制重新路由流量段到其他單元所需的工作。然而，如果單元大小太小，可能會在服務非常大的客戶/客戶時帶來挑戰，因此單元應該足夠大，以迎合基於分割槽鍵的最大流量段。

另一方面，單元越大，在資源方面就越大的經濟規模，這意味著更好的容量利用。管理較少的單元數量可能對運營團隊來說更容易。此外，對於較大的單元大小，需要小心考慮基礎設施限制，例如雲提供商平臺的區域和帳戶級別限制。

5 控制平面管理單元化架構

採用單元化架構需要大量的努力來開發超出支援常規微服務架構所需的管理功能。除了提供和部署基礎設施和應用程式服務之外，單元化架構還需要額外的功能，專門用於管理和監控單元、在可用單元中劃分和放置流量以及遷移資料。

基於單元架構的主要考慮是如何在單元之間劃分流量，應分別針對每個域使用面向單元的方法來確定。制定最佳分割槽方案的第一步是選擇分割槽鍵。在大多數情況下，這可能最終是一個使用者或客戶識別符號，但選擇應針對每種情況單獨進行，考慮流量段的粒度，以避免大於所選單元容量的段。

單元分割槽可以使用不同的對映方法：

實現單元分割槽對映的方法有很多，它們各自的優缺點。這些方法從完整對映（儲存所有對映記錄）到使用一致性雜湊演算法，提供相當穩定的專案分配給桶，並在新增和刪除桶時最小化混亂。無論選擇哪種對映方法，提供覆蓋能力都是有幫助的，以允許對某些分割槽鍵進行特殊處理，並協助測試活動。

其次是當新使用者/客戶加入或新單元被提供時的單元放置策略。該策略應考慮每個單元的大小和可用容量以及可能發揮作用的任何雲提供商配額/限制。當單元容量閾值達到，並且需要一個新的單元來容納到達平臺的流量時，控制平面負責提供新的單元並更新確定資料平面路由應用程式流量的單元對映配置。

與上述相關的是資料遷移能力，這對於單元放置（如果需要重新洗牌分割槽）或在事件（如果單元變得不健康並需要被排空）中非常重要。從技術角度來看，資料遷移本質上是非常具有挑戰性的，因此這種能力是提供單元化架構最困難的方面之一。相反，在不同單元中的資料儲存之間遷移或同步底層資料開闢了關於資料冗餘和故障轉移的新可能性，進一步提高了採用單元化架構所提供的彈性。

6 資料平面路由應用程式流量

儘管控制平面負責管理架構，但資料平面可靠地移動流量資料。在單元化架構的背景下，這意味著將流量路由到適當的單元，如分割槽對映記錄所確定的。需要強調的是，路由層需要儘可能簡單和水平可擴充套件，並且應避免複雜的業務邏輯，因為資料平面是單點故障。

路由層實現可以採用從DNS和API閘道器到部署在通用計算或基於容器的執行平臺上的定製應用程式服務的解決方案。無論哪種情況，分割槽對映資料必須能夠從可靠的資料儲存中讀取，可能是一個高可用的分散式資料庫或blob儲存服務。路由層可以支援同步API呼叫（HTTP或GRPC）和非同步訊息，儘管後者可能更難以實現。

單元路由器作為主要資料平面元件

考慮到它在單元之間流量流動中的關鍵作用，資料平面可以實施安全策略，以確保只有經過授權的API請求才能由單元內的服務提供。因此，可以實施一系列安全機制來保護免受未經授權的訪問，包括OAuth或JWT、用於認證的相互TLS以及用於授權的RBAC或ABAC。

7 使用基於單元架構的好處

採用基於單元架構的主要好處是透過故障隔離提高彈性。單元提供故障隔離邊界，並減少部署失敗、客戶端濫用產品/平臺、運營商錯誤或資料腐敗等問題的影響。

使用單元還可以幫助系統的可擴充套件性。理想情況下，單元應該限制在大小上，以減少故障的爆炸半徑，這也使單元成為擴充套件平臺的一個很好的單元。隨著時間的推移，工作負載增加，可以提供更多的單元來迎合新的流量（新客戶/使用者）。限制單元大小減少了來自任何非線性擴充套件因素或意外的爭用點（效能瓶頸）的驚喜風險。

同樣，單元可以用於部署範圍。而不是在任何地方都推出服務的新版本，組織可以在將其更改推廣到更廣泛的使用者/客戶群體之前，使用限定在單元（因此是使用者/客戶子集）的金絲雀部署。

大小受限的單元非常適合量化系統的效能，因為測試單個單元的效能並根據擴充套件整個單元而不是擴充套件單元內元件來建立系統的可擴充套件性特徵更容易。

單元提供了將屬於同一子域或有界上下文的服務分組的額外好處，這可以幫助組織將團隊和部門邊界與產品域邊界對齊。這對於大型組織尤其相關，這些組織中有數十或數百個團隊構建和運營大型產品組合。

最後一個潛在的好處可能是從減少跨AZ流量中節省成本，但這應該與執行資料平面內的路由層相關的任何額外運營成本進行權衡。

8 採用基於單元架構的考慮

雖然單元化架構在分散式系統的背景下提供了許多優勢，但實施這種方法需要額外的努力並引入挑戰，因此可能不是每個組織，如仍在尋找產品市場契合度的初創公司，都適合投資。像微服務架構一樣，單元化架構需要在底層平臺上進行重大投資，以便這種架構能夠加速團隊的速度，而不是阻礙它。

考慮到大多數具有非平凡基礎設施足跡的公司可能會面臨過去促使其他人採用基於單元架構的挑戰，仍然值得評估基於單元的方法是否值得追求。

首先，任何因聲譽、財務或合同要求而無法承受廣泛停機的公司都應該強烈考慮採用單元化架構，即使不是全部，至少對於關鍵的面向使用者服務也是如此。

此外，任何需要或希望低恢復點目標（RPO）或恢復時間目標（RTO）的系統也應該考慮基於單元的方法。最後，需要在租戶級別提供嚴格的基礎設施級隔離的多租戶產品也可以從單元化架構中受益，以提供完全專用的租戶能力。

任何情況下，應該考慮採用基於單元架構的總成本，並與預期的好處進行權衡，以確定預期的投資回報。

9 總結

本系列文章，我們展示了一個發現之旅，並提供了對單元化架構的許多關鍵方面的全面概述和深入分析，以及將這種方法應用於現有和新架構的實用建議。

關注我，緊跟本系列專欄文章，咱們下篇再續！

作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。

各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。

負責：

• 中央/分銷預訂系統效能最佳化
• 活動&券等營銷中臺建設
• 交易平臺及資料中臺等架構和開發設計
• 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
• LLM Agent應用開發
• 區塊鏈應用開發
• 大資料開發挖掘經驗
• 推薦系統專案

目前主攻市級軟體專案設計、構建服務全社會的應用系統。

參考：

• 程式設計嚴選網

本文由部落格一文多發平臺 OpenWrite 釋出！