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或微服務架構的系統失效，可能會非常迅速地蔓延開來