點擊下方“JavaEdge”，選擇“設(shè)為星標”

第一時間關(guān)注技術(shù)干貨！

免責聲明~ 任何文章不要過度深思！ 萬事萬物都經(jīng)不起審視，因為世上沒有同樣的成長環(huán)境，也沒有同樣的認知水平，更「沒有適用于所有人的解決方案」； 不要急著評判文章列出的觀點，只需代入其中，適度審視一番自己即可，能「跳脫出來從外人的角度看看現(xiàn)在的自己處在什么樣的階段」才不為俗人。 怎么想、怎么做，全在乎自己「不斷實踐中尋找適合自己的大道」

0 前言

• 單元化架構(gòu)通過減少故障影響范圍來增強系統(tǒng)的彈性。

• 單元化架構(gòu)是對于那些無法接受停機或可能對最終用戶產(chǎn)生負面影響的系統(tǒng)的良好選擇。

• 單元化架構(gòu)可能很復雜，有一些最佳實踐可以遵循，以提高成功的機會。

• 在推出單元化架構(gòu)或?qū)F(xiàn)有的云原生/微服務架構(gòu)改造/轉(zhuǎn)變?yōu)閱卧軜?gòu)時，有一些實際步驟需要考慮。

• 單元不是微服務的替代品，而是一種幫助在大規(guī)模情況下管理微服務的方法。許多適用于微服務的最佳實踐、問題和實際步驟也適用于單元。

一切都在不斷失敗，而單元化架構(gòu)可以是接受這些失敗、隔離它們并保持整個系統(tǒng)可靠運行的好方法。然而，這種架構(gòu)在設(shè)計和實施上可能很復雜。本文探討了組織可以用來成功的一些最佳實踐、問題和采用指南。

1 單元化架構(gòu)的最佳實踐

組織在采用單元化架構(gòu)以提高系統(tǒng)的可管理性和彈性時，應考慮幾個最佳實踐。

1.1 考慮用例

單元化架構(gòu)可能更復雜、成本更高。并不是每個系統(tǒng)都需要像S3那樣的規(guī)模和可靠性；考慮用例，以及是否值得額外投資。對于需要：

1. 高可用性。

2. 大規(guī)模擴展，以避免級聯(lián)故障。

3. 非常低的RTO（恢復時間目標）。

4. 系統(tǒng)如此復雜，以至于自動化測試覆蓋不足以覆蓋所有測試用例。

還要考慮系統(tǒng)的大小。對于一些組織來說，每個單元代表一個完整的堆棧：每個服務都部署在每個單元中，單元之間不相互通信（DoorDash, Slack）。對于其他組織來說，每個單元都有自己的有界業(yè)務上下文，系統(tǒng)由多個相互通信的單元層組成（WSO2, Uber的DOMA）。后者可能更靈活，但無疑更復雜。

1.2 明確單元所有權(quán)

如果多個單元層相互通信，理想情況下，每個單元應該由一個單一的團隊擁有，該團隊有權(quán)構(gòu)建和交付單元的功能到生產(chǎn)環(huán)境。

考慮使單元的邊界“團隊大小”，以便于建立所有權(quán)，并幫助團隊根據(jù)業(yè)務需求發(fā)展系統(tǒng)。技術(shù)如領(lǐng)域驅(qū)動設(shè)計和事件風暴可以幫助找到這些邊界。

1.3 隔離單元

單元應盡可能相互隔離，以最小化可靠性和安全問題的爆炸半徑。這在現(xiàn)實世界中并不總是可能的，但共享資源應該謹慎進行，因為它可以顯著降低使用單元的好處。

在AWS上，確保隔離的一個好方法是每個單元使用一個單獨的賬戶。許多賬戶可能會帶來管理問題，但它們默認提供了很好的爆炸半徑保護，因為您必須顯式允許跨賬戶訪問數(shù)據(jù)和資源。

重要的是要考慮單個單元是否應該位于單個可用性區(qū)域，或者將其服務復制到多個可用性區(qū)域以利用可用性區(qū)域提供的物理隔離。這里有一個權(quán)衡。

1.3.1 單個AZ

在單個AZ設(shè)計中，每個單元在單個可用性區(qū)域中運行：

優(yōu)點：可以檢測到AZ故障，并采取行動處理它，例如將所有請求路由到其他區(qū)域。

缺點：

1. 恢復可能會因為需要將單元內(nèi)容復制到另一個AZ而變得復雜，這可能會破壞單元設(shè)計的隔離屬性

2. 根據(jù)路由器設(shè)計，客戶端可能需要知道特定區(qū)域的端點。

在多AZ設(shè)計中，每個單元跨越兩個或更多可用性區(qū)域運行：

多AZ的優(yōu)勢在于使用區(qū)域云資源（如Amazon DynamoDB）使單元在單個區(qū)域失敗時更具彈性。

缺點：

1. 當服務僅在一個AZ中遇到問題時，可能會發(fā)生灰色故障，這使得排除給定單元的特定AZ變得困難

2. 此外，可能還會有額外的跨AZ數(shù)據(jù)傳輸成本。DoorDash 使用監(jiān)控和具有AZ感知路由的服務網(wǎng)格來優(yōu)化成本，盡可能在同一個AZ內(nèi)保持流量

如果單個AZ設(shè)計中的AZ變得不可用，會發(fā)生什么？受影響的用戶請求將被路由到哪里？

一個答案是根本不處理故障轉(zhuǎn)移：單元旨在隔離故障。必須修復故障，受影響的單元才能重新使用。

另一個選擇是使用災難恢復策略將單元數(shù)據(jù)復制到另一個AZ中的另一個單元，并開始將請求路由到新單元。這里的風險是復制可能會降低單元的隔離。復制過程將取決于數(shù)據(jù)需求和底層數(shù)據(jù)存儲（區(qū)域云服務可以幫助這里：見利用高可用云服務）。

1.4 自動化部署

就像微服務一樣，要大規(guī)模運行單元，您需要能夠在幾小時內(nèi)甚至最好是幾分鐘內(nèi)部署它們——而不是幾天?？焖俨渴鹦枰獦藴驶⒆詣踊姆绞絹砉芾韱卧?，這一點至關(guān)重要，取決于對工具、監(jiān)控和流程的投資。

標準化并不意味著每個團隊都需要使用相同的語言、數(shù)據(jù)庫或技術(shù)。然而，應該存在一個被良好理解和標準化的方式來打包和部署應用程序到新的或現(xiàn)有的單元。理想情況下，配置/部署管道應該允許團隊：

1. 創(chuàng)建新的單元。

2. 監(jiān)控它們的健康狀況。

3. 向它們部署更新的代碼。

4. 監(jiān)控部署狀態(tài)。

5. 節(jié)流和擴展單元。

部署管道應該減少平臺用戶的復雜性和認知負荷——這到底是什么樣子將取決于組織的大小和技術(shù)棧。

單元上方的路由器可以說是系統(tǒng)中最關(guān)鍵的部分：沒有它，其他什么都不工作，它可能成為單點故障。設(shè)計它盡可能簡單是很重要的，因此有幾件事需要考慮：

1. 技術(shù)：DNS、API網(wǎng)關(guān)、自定義服務。每個都有其自身的優(yōu)缺點（例如，管理DNS的生命周期）。

2. 利用高可用服務。例如，如果路由器需要存儲客戶單元，使用S3或DynamoDB，它們具有非常高的SLA，而不是單個MySQL實例。

3. 分離控制和數(shù)據(jù)平面。例如，客戶單元可以存儲在S3中，路由器可以在桶中查找數(shù)據(jù)。單獨的控制平面管理桶的內(nèi)容，控制平面可以失敗而不影響路由。

4. 考慮認證應該在哪里發(fā)生。例如，應該是：

   1. 在路由器中，這簡化了下游服務，但如果失敗會增加一個大的爆炸半徑。

   2. 在單元中，這可能會增加每個單元的復雜性和重復性。

5. 路由器必須知道單元的位置和健康狀況，以便將請求從失敗或正在排出的單元路由出去。

如果多個單元層相互通信，它應該通過明確定義的API進行，這有助于封裝單元的邏輯，并允許單元內(nèi)的服務在不過分破壞API契約的情況下發(fā)展。根據(jù)復雜性需求，這個API可能由單元中的服務直接暴露，或者由單元邊緣的網(wǎng)關(guān)暴露。

避免單元之間的頻繁通信。限制單元之間的依賴將幫助它們保持故障隔離并避免級聯(lián)故障。

您可能需要使用內(nèi)部層來協(xié)調(diào)單元之間的流量，例如服務網(wǎng)格、API網(wǎng)關(guān)或自定義路由器。同樣，必須小心確保所使用的任何東西都不是單點故障。異步消息傳遞也可能有所幫助，只要消息傳遞層是可靠的。

1.7 利用高可用云服務

如上文路由部分所述，許多云服務已經(jīng)為高可用性而構(gòu)建（通常使用像EBS和Azure AD這樣的單元）。這些服務可以簡化您的選擇并避免重新發(fā)明輪子。

考慮云服務的SLA，無論它們是全球的、區(qū)域的還是區(qū)域的，以及如果給定的云服務失敗，將如何影響系統(tǒng)的性能。

2 基于單元架構(gòu)的潛在問題2.1 獲取組織支持

單元化架構(gòu)可能很復雜，運行成本更高，因此像許多技術(shù)項目一樣，它需要組織的支持才能成功。

對于管理層來說，專注于業(yè)務影響可能是有幫助的，例如增加速度（團隊可以更自信地部署新代碼）和提高可用性（滿意的客戶和更好的聲譽）。

它還需要架構(gòu)、DevOps和開發(fā)團隊的支持和投資，以構(gòu)建和運行具有足夠隔離、監(jiān)控和自動化的單元，因此請確保盡早讓他們參與以幫助指導過程。

2.2 避免單元間共享

在單元之間共享資源，如數(shù)據(jù)庫，可能看起來是減少復雜性和成本的好方法，但它降低了單元之間的隔離，并使得一個單元中的故障更有可能影響其他單元。

關(guān)鍵問題是：如果這個共享資源失敗，會有多少單元受到影響？如果答案是很多，那么存在問題，并且沒有完全實現(xiàn)基于單元架構(gòu)的好處。

共享數(shù)據(jù)庫可以作為遷移到單元的旅程中的一個有用的步驟，但不應無限期共享；還應有一個拆分數(shù)據(jù)庫的計劃。

2.3 避免創(chuàng)建過于復雜的路由器

路由器可能是單點故障，并且隨著復雜性的增加，遇到某種故障的風險會增加。向路由器添加功能以簡化單元服務可能很誘人，但每個決策都必須權(quán)衡對系統(tǒng)整體可靠性的影響。執(zhí)行一些故障模式分析以識別和減少路由器中的故障點。

例如，如果路由器需要從數(shù)據(jù)庫中查找單元映射，那么在啟動路由器時將數(shù)據(jù)庫存儲在內(nèi)存中可能比依賴每個請求的數(shù)據(jù)訪問更快、更可靠。

2.4 錯過單元間的復制和遷移

可能很誘人，認為單元遷移是一個高級功能，并在項目開始時跳過它，但它對架構(gòu)的成功至關(guān)重要。如果單元失敗或變得過載（例如，兩個大客戶最終位于同一個單元），一些客戶需要遷移到另一個單元。實際的樣子將取決于路由和數(shù)據(jù)分區(qū)，但總體思路是：

1. 確定要遷移到的單元（要么是具有容量的現(xiàn)有單元，要么是新創(chuàng)建的一個）。

2. 從舊單元的數(shù)據(jù)庫復制任何所需數(shù)據(jù)到目標單元。

3. 更新路由器配置，使目標單元對相關(guān)客戶生效。

還需要與路由層集成，以確保在正確的時間將請求路由到正確的單元。

復制可能由單元故障觸發(fā)，或者復制單元以便另一個單元始終準備就緒。這復制到底是什么樣子將取決于單元的數(shù)據(jù)模式、恢復點目標（RPO）和恢復點目標（RTO）需求：數(shù)據(jù)庫級復制、消息傳遞和S3都是選項。見AWS上的災難恢復工作負載白皮書以獲取更多關(guān)于恢復策略的討論。

2.5 避免云資源限制

如果系統(tǒng)每個單元消耗大量云資源，可能會遇到云提供商施加的軟限制或硬限制。軟限制可以請求增加，但硬限制可能由服務或硬件限制施加，并且是固定的。

在AWS上，許多限制可以通過每個單元使用單獨的賬戶來避免。

2.6 平衡邏輯和數(shù)據(jù)的復制

在保持單元盡可能隔離與避免服務之間邏輯和數(shù)據(jù)復制之間存在權(quán)衡。與微服務一樣，存在“不要重復自己”（DRY）原則的相同權(quán)衡。

隨著系統(tǒng)的發(fā)展，通過在不同單元的服務之間復制代碼來避免緊密耦合和促進隔離可能更好，甚至在有意義的情況下復制數(shù)據(jù)。這個問題沒有通用的對錯答案：應該根據(jù)具體情況進行評估。進行故障模式分析可以幫助識別單元之間的依賴關(guān)系何時可能成為問題，以及何時應該被移除，可能通過復制來實現(xiàn)。

3 采用指南

你已經(jīng)決定單元化架構(gòu)是一個不錯的選擇——現(xiàn)在怎么辦？

3.1 遷移

引用Martin Fowler的話：如果你進行大爆炸式重寫，唯一確定的事情就是大爆炸。

將現(xiàn)有的微服務架構(gòu)遷移為單元化架構(gòu)可能會很棘手。常見的第一步是將第一個單元定義為現(xiàn)有系統(tǒng)，并在頂部放置一個路由器，然后像進行單體到微服務遷移一樣剝離服務到新的單元。

組織可用許多單體到微服務策略。如：

1. 使用領(lǐng)域驅(qū)動設(shè)計（DDD）定義有界上下文，幫助決定什么放入新的單元。

2. 首先將服務邏輯遷移到單獨的單元，然后在后續(xù)階段將共享數(shù)據(jù)分割到單元特定的數(shù)據(jù)庫。

3. 考慮在決定首先分割到單元的業(yè)務領(lǐng)域時，哪些業(yè)務領(lǐng)域會從更大的彈性中受益。

4. 確保有足夠的自動化和可觀察性來管理新的、更復雜的系統(tǒng)。

在單元化架構(gòu)中，部署單元是部署的單位。新應用程序版本應該首先部署到單個單元，以測試它們?nèi)绾闻c系統(tǒng)的其余部分交互，同時最小化廣泛故障的風險。使用像金絲雀或藍/綠部署這樣的技術(shù)進行增量更改，并在繼續(xù)推出之前驗證系統(tǒng)仍然按預期運行（通常在波中）。

如果新版本有問題，應該回滾更改，并暫停部署，直到進一步調(diào)查可以確定問題。

“烘焙時間”的概念也很重要，以確保新單元有足夠的時間來服務真實流量，以便監(jiān)控可以檢測問題。確切的時間將根據(jù)系統(tǒng)類型、風險承受能力和復雜性而有所不同。

3.3 可觀察性

除了正確監(jiān)控微服務之外，還應該增加單元監(jiān)控和儀表板，以查看聚合和單元級別的視圖：

1. 單元的數(shù)量。

2. 單元的健康狀況。

3. 部署波的狀態(tài)。

4. 任何對單元重要的SLO指標。

這些都可以從標準云指標中派生出來，但可能需要額外的標記標準來獲得單元級別的視圖。

由于單元化架構(gòu)可能會增加云使用量，因此跟蹤資源使用情況和每個單元的成本至關(guān)重要。目標是允許團隊提出問題，如“我的單元成本是多少？”、“我如何更有效地使用資源？”以及“單元大小是否優(yōu)化？”。

3.4 擴展

在單元化架構(gòu)中，擴展單元是擴展的單位：根據(jù)負載水平可以水平部署更多。確切的擴展標準將取決于工作負載，但可能包括請求數(shù)量、資源使用情況、客戶大小等。擴展可以進行到什么程度將取決于單元的隔離程度——任何共享資源都將限制可擴展性。

架構(gòu)還應該小心知道單元的限制，并避免發(fā)送超出其資源處理能力的流量，例如通過路由器或單元本身進行負載卸載。

3.5 單元大小

決定每個單元的大小是一個關(guān)鍵的權(quán)衡。許多較小的單元意味著較小的爆炸半徑，因為每個單元處理的用戶請求較少。小單元也更容易測試和管理（例如，更快的部署時間）。

另一方面，較大的單元可能更好地利用可用容量，更容易將大客戶放入單個單元，并使整個系統(tǒng)更容易管理，因為單元較少。

考慮：

1. 爆炸半徑。

2. 性能。一個單元可以容納多少流量，以及它如何影響其性能？

3. 預留空間，以防現(xiàn)有單元需要開始處理來自失敗單元的流量。

4. 平衡分配的資源，以確保單元不會因處理預期負載而功能不足，但也不會功能過強，成本過高。

較小單元的優(yōu)點是：

1. 它們有較小的爆炸半徑，因此任何故障都會影響較小比例的用戶。

2. 它們不太可能達到任何云提供商的配額限制。

3. 降低測試新部署的風險，因為針對較小的用戶集合更容易。

4. 每個單元的用戶較少意味著遷移和故障轉(zhuǎn)移可以更快。

較大單元的優(yōu)點是：

1. 它們更容易操作和復制，因為它們較少。

2. 它們更有效地利用容量。

3. 減少必須將大用戶分割到多個單元的風險。

正確的選擇將嚴重依賴于正在構(gòu)建的確切系統(tǒng)。許多組織從較大的單元開始，隨著信心和工具的改進而轉(zhuǎn)向較小的單元。

3.6 數(shù)據(jù)分區(qū)

與單元大小密切相關(guān)的是分區(qū)數(shù)據(jù)和決定客戶流量應該路由到哪個單元。許多因素可以通知分區(qū)方法，包括業(yè)務需求、數(shù)據(jù)屬性的基數(shù)和單元的最大大小。

分區(qū)鍵可以是客戶ID，如果請求可以分割成不同的客戶。每個單元被分配一定比例的客戶，以便同一個客戶始終由同一個單元服務。如果某些客戶比其他客戶大，則需要確保沒有單個客戶比單元的最大大小大。

其他選項是地理區(qū)域、市場類型、輪詢或基于負載。

無論采用哪種方法，覆蓋路由器并手動將客戶放置在特定單元中進行測試和隔離某些工作負載也可能是有益的。

3.7 映射

使用客戶ID意味著路由器將需要將客戶映射到單元。存儲映射數(shù)據(jù)的最簡單方法可能是一個表格，該表格將每個客戶映射到單元：

其顯著優(yōu)點是它非常容易實現(xiàn)，并簡化了在單元之間遷移客戶：只需更新數(shù)據(jù)庫中的映射。

這種方法的缺點是它需要一個數(shù)據(jù)庫，這可能是單點故障，并引起性能問題。

其他方法是一致性哈希和將一系列鍵映射到單元。然而，它們都不夠靈活，因為它們有熱單元的風險，使遷移更具挑戰(zhàn)性。

3.8 衡量成功

理想情況下，組織應該考慮采用單元化架構(gòu)來實現(xiàn)特定的業(yè)務目標，例如通過提高技術(shù)平臺的穩(wěn)定性來提高客戶滿意度。

通過遷移，應該可以衡量朝著這些目標取得的進展。通常，目標是在面對故障時的彈性，其中一些定量措施是有用的：

1. 健康指標，包括錯誤率或正常運行時間（例如，當EBS遷移到單元時，錯誤率大幅下降）。

2. MTTR（平均修復時間）。

3. 性能指標，包括p75、p95和p99的請求處理時間，以查看額外的層是否對延遲產(chǎn)生不利影響。如果客戶現(xiàn)在由比之前系統(tǒng)更小的單元服務，性能可能會提高！

4. 資源使用情況，以確保成本沒有失控，如果必要，可以優(yōu)化。

這些都意味著良好的可觀察性，以衡量性能、可靠性和成本。

4 結(jié)論

單元化架構(gòu)可能令人生畏且復雜，但許多好的做法對微服務開發(fā)人員來說很熟悉。任何在這個規(guī)模上的架構(gòu)都應該包括部署自動化、可觀察性、擴展和故障恢復；單元化架構(gòu)也不例外。這些在設(shè)計單元大小時、單元隔離、數(shù)據(jù)所有權(quán)和從故障中恢復的策略時必須考慮。

也許需要做出的關(guān)鍵決策是關(guān)于數(shù)據(jù)分區(qū)的，以及密切相關(guān)的，如何分配和映射請求流量到單元。更簡單的方法可能更容易實現(xiàn)，但它們通常缺乏運行單元所需的靈活性。

公共云提供商提供許多高可用性服務，可以利用這些服務來提高可靠性，同時簡化設(shè)計。AWS在單元化架構(gòu)方面在線上占有最多的份額，有關(guān)他們?nèi)绾螌⑦@種模式應用于自己的系統(tǒng)以及使用AWS服務實現(xiàn)的建議的討論。

組織必須確保單元化架構(gòu)適合他們，并且遷移不會造成比解決的問題更多的問題。將現(xiàn)有系統(tǒng)遷移到單元化架構(gòu)可以分步驟進行，以最小化干擾，并驗證更改按預期工作，然后再繼續(xù)。

構(gòu)建現(xiàn)代、可靠和可理解的分布式系統(tǒng)的挑戰(zhàn)持續(xù)增長，單元化架構(gòu)是接受、隔離和面對故障保持可靠的有價值方式。

關(guān)注我，緊跟本系列專欄文章，咱們下篇再續(xù)！

★ 作者簡介：魔都架構(gòu)師，多家大廠后端一線研發(fā)經(jīng)驗，在分布式系統(tǒng)設(shè)計、數(shù)據(jù)平臺架構(gòu)和AI應用開發(fā)等領(lǐng)域都有豐富實踐經(jīng)驗。 各大技術(shù)社區(qū)頭部專家博主。具有豐富的引領(lǐng)團隊經(jīng)驗，深厚業(yè)務架構(gòu)和解決方案的積累。 負責： 中央/分銷預訂系統(tǒng)性能優(yōu)化 活動&券等營銷中臺建設(shè) 交易平臺及數(shù)據(jù)中臺等架構(gòu)和開發(fā)設(shè)計 車聯(lián)網(wǎng)核心平臺-物聯(lián)網(wǎng)連接平臺、大數(shù)據(jù)平臺架構(gòu)設(shè)計及優(yōu)化 LLM Agent應用開發(fā) 區(qū)塊鏈應用開發(fā) 大數(shù)據(jù)開發(fā)挖掘經(jīng)驗 推薦系統(tǒng)項目 目前主攻市級軟件項目設(shè)計、構(gòu)建服務全社會的應用系統(tǒng)。 ”

參考：

• 編程嚴選網(wǎng)

編程嚴選網(wǎng)：http://www.javaedge.cn/ 專注分享軟件開發(fā)全生態(tài)相關(guān)技術(shù)文章、視頻教程資源、熱點資訊等，全站資源免費學習，快來看看吧~ 【編程嚴選】星球

歡迎長按圖片加好友，我會第一時間和你分享軟件行業(yè)趨勢，面試資源，學習方法等等。

添加好友備注【技術(shù)群交流】拉你進技術(shù)交流群

關(guān)注公眾號后，在后臺私信：

• 更多教程資源應有盡有，歡迎關(guān)注并加技術(shù)交流群，慢慢獲取

• 為避免大量資源被收藏白嫖而浪費各自精力，以上資源領(lǐng)取分別需要收取1元門檻費！