# REL10-BP03 使用隔板架構限制影響範圍
<a name="rel_fault_isolation_use_bulkhead"></a>

實作隔板架構 (也稱為小組型架構) 將工作負載內的失敗效應限制為有限數量的元件。

 **預期成果：**小組型架構使用工作負載的多個獨立執行個體，其中每個執行個體稱為小組。每個小組都是獨立的，不會與其他小組共用狀態，並且處理整體工作負載請求的子集。這會對個別小組和它處理的請求降低失敗的潛在影響，例如不良的軟體更新。如果工作負載使用 10 個小組為 100 個請求提供服務，發生失敗時，整體請求中 90% 不會受到失敗影響。

 **常見的反模式：**
+  允許小組成長，沒有界限。
+  將程式碼更新或部署同時套用到所有小組。
+  在小組之間共用狀態或元件 (路由器層例外)。
+  將複雜商業或路由邏輯新增至路由器層。
+  不將跨小組互動降至最低。

 **建立此最佳實務的優勢：**使用小組型架構時，小組本身包含許多常見的故障類型，從而提供額外的故障隔離。這些故障界限可針對難以控制的失敗類型提供復原能力，例如失敗的程式碼部署或已損毀或叫用特定失敗模式 (也稱為*毒藥請求) 的請求*。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 在船上，隔板可確保船體破口包含在船體的其中一個區段內。在複雜的系統中，通常會複寫這個模式以實現故障隔離。故障隔離界限會在工作負載內將失敗影響限制為有限數量的元件。界限外部的元件不會受到故障影響。您可以使用多個錯誤隔離界限來限制對工作負載的影響。在 AWS 上，客戶可以使用多個可用區域或區域來提供故障隔離，但是故障隔離的概念也可以延伸為您的工作負載的架構。

 整體工作負載是依分割區索引鍵的分割區小組。此索引鍵需要與服務的*精細度*保持一致，否則服務的工作負載會自然地透過最小的跨小組互動進行細分。分割區索引鍵的範例為客戶 ID、資源 ID 或可在大部分 API 呼叫中輕易存取的其他任何參數。小組路由層會根據分割區索引鍵將請求分散到個別小組，並且對用戶端呈現單一端點。

![\[圖表顯示小組型架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/cell-based-architecture.png)


 **實作步驟** 

 設計小組型架構時，要考慮數個設計考量：

1.  **分割區索引鍵**：選擇分割區索引鍵時，應特別考慮。
   +  應該與服務的精細度保持一致，否則服務的工作負載會自然地透過最小跨小組互動進行細分。例如 `customer ID` 或 `resource ID`。
   +  分割區索引鍵必須在所有請求中都可供使用，無論是直接或由其他參數確定性地推斷。

1.  **持久性小組映射**：上游服務應該僅在其資源的生命週期內與單個小組進行互動。
   +  依據工作負載而定，可能需要小組遷移策略，以便從其中一個小組將資料遷移到另一個小組。可能需要小組遷移的可能情境是，如果您的工作負載中特定使用者或資源變得太大並且要求它具備專有小組。
   +  小組不應該在小組之間共用狀態或元件。
   +  因此，應該避免跨小組互動或保持在最低程度，因為這些互動會建立小組之間的相依性，因而消滅故障隔離改善。

1.  **路由器層**：路由器層是儲存格之間的共用元件，因此無法遵循與儲存格相同的區隔策略。
   +  建議路由器層以有效率運算的方式使用分割區對應演算法將請求分發到個別小組，例如結合加密雜湊函數和模組化算術以將分割區索引鍵對應至小組。
   +  若要避免多小組影響，路由層必須保持簡單並且盡可能水平擴展，如此才能避免此層級內的複雜商業邏輯。這樣有增加的優點，隨時都容易了解其預期行為，以獲得徹底的可測試性。正如 Colm MacCárthaigh 在[可靠性、持續工作以及一杯好咖啡](https://aws.amazon.com/builders-library/reliability-and-constant-work/)中所述，簡單的設計和持續的工作模式會產生可靠的系統並降低抗脆弱性。

1.  **儲存格大小**：儲存格應具有最大的大小，且不允許超過它。
   +  最大大小應該藉由執行徹底測試來識別，直到觸及中斷點並且建立安全的操作邊距。如需如何實作測試實務的詳細資訊，請參閱 [REL07-BP04 Load 測試您的工作負載](rel_adapt_to_changes_load_tested_adapt.md) 
   +  整體工作負載應該透過新增額外小組來成長，讓工作負載隨著需求的增加而擴展。

1.  **多可用區域或多區域策略**：應利用多層彈性來防範不同的故障網域。
   +  對於彈性，您應該使用建置防禦層的方法。一層透過使用多個 AZ 建置高度可用的架構來防範更小、更常見的中斷。另一防禦層旨在防範發生罕見事件，例如廣泛的自然災害和區域級中斷。這第二層涉及架構您的應用程式以跨越多個 AWS 區域。針對您的工作負載實作多區域策略有助於其防範影響國家一大片地理區域的廣泛自然災害，或整個區域範圍的技術失敗。請注意，實作多區域架構可能相當複雜，並且通常對於大多數工作負載而言不是必要的。如需詳細資訊，請參閱[REL10-BP01 將工作負載部署至多個位置](rel_fault_isolation_multiaz_region_system.md)。

1.  **程式碼部署**：交錯的程式碼部署策略應優先於同時將程式碼變更部署到所有單元格。
   +  這樣可協助將多個小組由於不良部署或人為錯誤的潛在失敗降至最低。如需詳細資訊，請參閱[安全且無需人為干預的自動化部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [REL07-BP04 Load 測試您的工作負載](rel_adapt_to_changes_load_tested_adapt.md) 
+  [REL10-BP01 將工作負載部署至多個位置](rel_fault_isolation_multiaz_region_system.md) 

 **相關文件：**
+  [可靠性、持續工作以及一杯好咖啡](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+ [AWS 和分隔](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [使用隨機切換分區隔離工作負載](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+  [自動化安全、無人為介入的部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

 **相關影片：**
+ [AWS re:Invent 2018：閉環與開放思維：如何取得大小型系統的控制權](https://www.youtube.com/watch?v=O8xLxNje30M)
+  [AWS re:Invent 2018：AWS 如何最大程度地減小故障的影響範圍 (ARC338)](https://youtu.be/swQbA4zub20) 
+  [隨機切換分區：AWS re:Invent 2019：Amazon 建置者資料中心簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1373) 
+ [AWS Summit ANZ 2021 - 故障總在情理之中、意料之外 (Everything fails, all the time)：專為彈性而設計](https://www.youtube.com/watch?v=wUzSeSfu1XA)