1. 电路保险丝

1.1. 保险丝通过自身率先失效，控制整体的系统失效方式

1.2. 当遇到电阻时，电流产生的热量与电流强度的平方和电阻的乘积（I^2R）成正比

1.3. 在房子着火前先行熔断，切断电路并避免火灾

1.4. 民用保险丝早已被淘汰

2. 断路器

2.1. 断路器可以避免房屋起火

2.1.1. 由于短路或其他原因导致电流过大时，断路器能允许一个子系统（电路）发生系统失效，从而保护整个系统（房屋）

2.2. 出现问题，停止调用

2.3. 断路器会阻止而不是重新执行操作

2.3.1. 即用一个组件将那些有风险的操作纳入其中，在系统异常时，该组件能防止调用

2.4. 断路器能有效防止集成点、层叠失效、系统容量失衡和响应缓慢等危及稳定性的反模式出现，它能与超时模式紧密协作，跟踪调用超时失败

2.4.1. 断路器是一种系统在流量压力之下实现自动功能降级的方法

2.5. 断路器会将系统失效记录下来

2.5.1. 一旦系统失效次数（或更复杂情况下的系统失效频率）超过阈值，断路器就会跳闸并“断开电路

2.6. 当断路器处于断开状态时，必须对调用访问做出处理

2.6.1. 最简单的方式是让调用立即返回失败结果

2.7. 经过超时设定的时间后，断路器决定尝试执行重复操作，因此进入半断开状态

2.7.1. 如果这次尝试失败，断路器将返回到断开状态，直到另一个超时时间结束

3. 断路器的状态

3.1. 开放、跟踪并报告断路器状态变化情况

3.2. 应该始终用日志记录断路器状态的变化，并开放断路器当前的状态，以供查询和监控

3.3. 断路器也有助于收集有关调用量和响应时间的信息

3.4. 一个简单累加次数的计数器并不能说明问题

3.4.1. 5个小时之内观察到的5次均匀分布的失败与最近30秒之内发生的5次失败，这两个现象之间存在巨大的差异

3.4.2. 相比失败的总数，我们通常对失败的密度更感兴趣

3.5. 在单个进程的范围内构建断路器

3.5.1. 一个进程只会令其内部的各个线程了解其断路器状态，但不会向多个其他进程共享其断路器状态

4. 舱壁

4.1. 船舶的舱壁是一些隔板，一旦将其密封起来，就能将船分隔成若干独立的水密隔舱

4.1.1. 船体即使被洞穿一次也不会沉没

4.2. 舱壁这种设计强调了控制损害范围的原则

4.3. 通过使用隔板对系统进行分区，就可以将系统失效控制在其中某个分区内，而不会令其摧毁整个系统

4.4. 确定一些自然边界，这些边界能够以具备技术可行性和经济收益性的方法对系统加以分隔，具体分隔边界可以根据调用方、功能或系统拓扑来划定

4.5. 当灾难发生时，舱壁模式将系统进行分隔，确保部分系统功能可用

4.6. 物理冗余是实现舱壁最常见的形式

4.6.1. 在一台服务器上运行两个应用程序实例，如果其中一个崩溃，那么另一个仍将继续运行

4.6.2. 物理机冗余设计比虚拟机冗余设计更加稳健

4.7. 当访问请求量到达系统最大容量时，就可以为系统的关键服务分配几个独立的服务器农场，预留其中的某些农场供关键应用程序使用，其他农场用于非关键应用程序

4.8. 在云环境中，应该在服务的不同分区中运行实例

4.8.1. 每个分区的规模都很大，彼此隔离性很强

4.8.2. 当使用函数即服务时，基本上每个函数调用都会在自己的隔间中运行

4.9. 当系统容量规模较小时，进程绑定就是通过舱壁进行分隔的一个例子

4.9.1. 这种做法能够减少进程在CPU内核之间迁移时对缓存的冲击，所以进程绑定通常被认为是一种性能调优手段

4.9.2. 如果该进程被绑定到一个CPU内核上，则它只能在该内核上使用所有可用的CPU处理周期

4.9.3. 可以对应用程序内的线程池进行分隔，对服务器的CPU进行分隔，或对集群中的服务器进行分隔

4.10. 即使在出现系统失效时，舱壁也能有效地维持整个或部分服务的正常运行

4.10.1. SOA内的每个服务都存在单点失效问题

4.10.2. 对于单一服务失效就能拖垮整个企业应用系统的SOA，这点特别有用

4.11. 当使用共享服务模型时，尤其要考虑使用舱壁模式

4.11.1. SOA或微服务架构的系统失效，可能会非常迅速地蔓延开来

526互联

读发布！设计与部署稳定的分布式系统（第2版）笔记13_断路器与舱壁

1. 电路保险丝

1.1. 保险丝通过自身率先失效，控制整体的系统失效方式

1.2. 当遇到电阻时，电流产生的热量与电流强度的平方和电阻的乘积（I^2R）成正比

1.3. 在房子着火前先行熔断，切断电路并避免火灾

1.4. 民用保险丝早已被淘汰

2. 断路器

2.1. 断路器可以避免房屋起火

2.1.1. 由于短路或其他原因导致电流过大时，断路器能允许一个子系统（电路）发生系统失效，从而保护整个系统（房屋）

2.2. 出现问题，停止调用

2.3. 断路器会阻止而不是重新执行操作

2.3.1. 即用一个组件将那些有风险的操作纳入其中，在系统异常时，该组件能防止调用

2.4. 断路器能有效防止集成点、层叠失效、系统容量失衡和响应缓慢等危及稳定性的反模式出现，它能与超时模式紧密协作，跟踪调用超时失败

2.4.1. 断路器是一种系统在流量压力之下实现自动功能降级的方法

2.5. 断路器会将系统失效记录下来

2.5.1. 一旦系统失效次数（或更复杂情况下的系统失效频率）超过阈值，断路器就会跳闸并“断开电路

2.6. 当断路器处于断开状态时，必须对调用访问做出处理

2.6.1. 最简单的方式是让调用立即返回失败结果

2.7. 经过超时设定的时间后，断路器决定尝试执行重复操作，因此进入半断开状态

2.7.1. 如果这次尝试失败，断路器将返回到断开状态，直到另一个超时时间结束

3. 断路器的状态

3.1. 开放、跟踪并报告断路器状态变化情况

3.2. 应该始终用日志记录断路器状态的变化，并开放断路器当前的状态，以供查询和监控

3.3. 断路器也有助于收集有关调用量和响应时间的信息

3.4. 一个简单累加次数的计数器并不能说明问题

3.4.1. 5个小时之内观察到的5次均匀分布的失败与最近30秒之内发生的5次失败，这两个现象之间存在巨大的差异

3.4.2. 相比失败的总数，我们通常对失败的密度更感兴趣

3.5. 在单个进程的范围内构建断路器

3.5.1. 一个进程只会令其内部的各个线程了解其断路器状态，但不会向多个其他进程共享其断路器状态

4. 舱壁

4.1. 船舶的舱壁是一些隔板，一旦将其密封起来，就能将船分隔成若干独立的水密隔舱

4.1.1. 船体即使被洞穿一次也不会沉没

4.2. 舱壁这种设计强调了控制损害范围的原则

4.3. 通过使用隔板对系统进行分区，就可以将系统失效控制在其中某个分区内，而不会令其摧毁整个系统

4.4. 确定一些自然边界，这些边界能够以具备技术可行性和经济收益性的方法对系统加以分隔，具体分隔边界可以根据调用方、功能或系统拓扑来划定

4.5. 当灾难发生时，舱壁模式将系统进行分隔，确保部分系统功能可用

4.6. 物理冗余是实现舱壁最常见的形式

4.6.1. 在一台服务器上运行两个应用程序实例，如果其中一个崩溃，那么另一个仍将继续运行

4.6.2. 物理机冗余设计比虚拟机冗余设计更加稳健

4.7. 当访问请求量到达系统最大容量时，就可以为系统的关键服务分配几个独立的服务器农场，预留其中的某些农场供关键应用程序使用，其他农场用于非关键应用程序

4.8. 在云环境中，应该在服务的不同分区中运行实例

4.8.1. 每个分区的规模都很大，彼此隔离性很强

4.8.2. 当使用函数即服务时，基本上每个函数调用都会在自己的隔间中运行

4.9. 当系统容量规模较小时，进程绑定就是通过舱壁进行分隔的一个例子

4.9.1. 这种做法能够减少进程在CPU内核之间迁移时对缓存的冲击，所以进程绑定通常被认为是一种性能调优手段

4.9.2. 如果该进程被绑定到一个CPU内核上，则它只能在该内核上使用所有可用的CPU处理周期

4.9.3. 可以对应用程序内的线程池进行分隔，对服务器的CPU进行分隔，或对集群中的服务器进行分隔

4.10. 即使在出现系统失效时，舱壁也能有效地维持整个或部分服务的正常运行

4.10.1. SOA内的每个服务都存在单点失效问题

4.10.2. 对于单一服务失效就能拖垮整个企业应用系统的SOA，这点特别有用

4.11. 当使用共享服务模型时，尤其要考虑使用舱壁模式

4.11.1. SOA或微服务架构的系统失效，可能会非常迅速地蔓延开来