# REL10-BP04 采用隔板架构来限制影响范围
<a name="rel_fault_isolation_use_bulkhead"></a>

实施隔板架构（也称为基于 cell 的架构），将工作负载中故障的影响限制到有限数量的组件上。

 **期望结果：**基于 cell 的架构使用工作负载的多个独立实例，每个实例称为一个 cell。每个 cell 是独立的，不与其他 cell 分享状态，并处理整个工作负载请求的一个子集。这样减少了故障（例如，错误的软件更新）对单个 cell 及其正在处理的请求的潜在影响。如果工作负载使用 10 个 cell 来提供 100 个请求，则在发生故障时，总请求中有 90% 不受故障的影响。 

 **常见反模式：** 
+  让 cell 无限制地发展。 
+  同时将代码更新或部署应用到所有 cell。 
+  在不同 cell 之间分享状态或组件（路由器层除外）。 
+  向路由器层添加复杂的业务或路由逻辑。 
+  没有尽量减少 cell 间的相互作用。 

 **建立此最佳实践的好处：**借助基于 cell 的架构，许多常见类型的故障控制在 cell 本身，从而实现了额外的故障隔离。在出现难以控制的故障类型（例如不成功的代码部署，或者是出错或触发特定故障模式的请求，也称为*“毒药”请求*）时，这些故障边界可以提供弹性。 

## 实施指导
<a name="implementation-guidance"></a>

 在船舶上，隔板确保船体裂口控制在船体的一个区段内。在复杂的系统中，通常会复制此模式以实现故障隔离。故障隔离边界可将一个工作负载内的故障影响限制于有限数量的组件。边界以外的组件不会受到故障的影响。使用多个故障隔离边界，您可以限制作用于您的工作负载的影响。在 AWS 中，客户可以使用多个可用区和区域来实现故障隔离，但故障隔离的概念可以也可以扩展到工作负载的架构。 

 整个工作负载是分区的 cell，按分区键进行划分。这个键需要与服务的*粒度*，或者与使用最小的跨 cell 交互来细分服务工作负载的自然方式保持一致。分区键的示例包括客户 ID、资源 ID 或可以在大多数 API 调用中轻松访问的任何其他参数。cell 路由层根据分区键将请求分发到单个 cell，并向客户端提供单个端点。 

![图中显示基于 Cell 的架构](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/framework/images/cell-based-architecture.png)


 **实施步骤** 

 在设计基于 cell 的架构时，需要考虑几个设计注意事项： 

1.  **分区键**：选择分区键时应特别考虑。
   +  它应与服务的粒度，或者与使用最小的跨 cell 交互来细分服务工作负载的自然方式保持一致。示例包括 `客户 ID` 或 `资源 ID`。 
   +  在所有请求中都必须提供分区键，要么直接提供，要么通过很容易由其他参数确定地推断出来的方式提供。 

1.  **持久 cell 映射**：上游服务在其资源的生命周期内应只与单个 cell 交互。
   +  根据工作负载，可能需要使用 cell 迁移策略将数据从一个 cell 迁移到另一个 cell。可能需要进行 cell 迁移的一种情况是：工作负载中的一个特定用户或资源变得太大，要求它具有专用的 cell。 
   +  Cell 之间不应该共享状态或组件。 
   +  因此，应该避免或尽量减少跨 cell 的交互，因为这些交互会在 cell 之间产生依赖关系，从而削弱故障隔离的改进。 

1.  **路由器层**：路由器层是 cell 之间的一个共享组件，因此无法遵循与 cell 相同的分隔策略。
   +  建议路由器层使用分区映射算法以一种计算效率高的方式将请求分发到各个 cell，例如结合加密哈希函数和模块化算法，将分区键映射到 cell。 
   +  为避免产生多 cell 影响，路由层必须尽可能保持简单和可横向扩展，这就需要在此层中避免出现复杂的业务逻辑。这还有一个额外的好处，即始终可以轻松地理解其预期行为，从而实现彻底的可测试性。正如 Colm MacCárthaigh 在[可靠性、持续工作和安然无忧](https://aws.amazon.com/builders-library/reliability-and-constant-work/)中所说，简单的设计和持续工作模式可产生可靠的系统并降低抗脆弱性。 

1.  **Cell 大小**：Cell 应具有最大大小，不得发展到超过这个大小。
   +  应通过执行彻底的测试来确定最大大小，直至达到临界点并建立安全的运营边际。有关如何实施测试实践的更多详细信息，请参阅 [REL07-BP04 对工作负载进行负载测试](rel_adapt_to_changes_load_tested_adapt.md) 
   +  总体工作负载增长时应增加额外的 cell，使得工作负载能够随着需求的增加而扩展。 

1.  **多可用区或多区域策略**：应该利用多层弹性来防止出现不同的故障域。
   +  要实现弹性，您应使用构建防御层的方法。其中一层使用多可用区，通过构建高度可用的架构，防止出现较小规模、更常见的中断。另一个防御层用于防御很少发生的事件，例如大范围的自然灾害和区域级别的中断。这个第二层涉及到设计应用程序的架构来跨越多个 AWS 区域。为工作负载实施多区域策略，有助于防御影响到某个国家/地区中较大地理面积的大范围自然灾害，或者区域范围的技术故障。请注意，实施多区域架构会有很高的复杂性，对于大部分工作负载通常来说都是不必要的。有关更多详细信息，请参阅 [REL10-BP02 为您的多位置部署选择合适的位置](rel_fault_isolation_select_location.md)。 

1.  **代码部署**：交错的代码部署策略应该优于同时将代码更改部署到所有 cell。
   +  这将有助于最大限度地减少由于部署不当或人为错误而导致多个 cell 可能出现故障。有关更多详细信息，请参阅[自动执行安全、不需要人工介入的部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)。 

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

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

 **相关最佳实践：** 
+  [REL07-BP04 对工作负载进行负载测试](rel_adapt_to_changes_load_tested_adapt.md) 
+  [REL10-BP02 为您的多位置部署选择合适的位置](rel_fault_isolation_select_location.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 Builders' Library 简介（DOP328）](https://youtu.be/sKRdemSirDM?t=1373) 
+ [2021 AWS 峰会（澳大利亚和新西兰） - 故障在所难免：针对弹性而设计](https://www.youtube.com/watch?v=wUzSeSfu1XA)

 **相关示例：** 
+  [Well-Architected 实验室 - 使用随机分片进行故障隔离](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)