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

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/556065.html

標籤：架構設計

上一篇：跨架構平臺在云計算中的應用

下一篇：返回列表

讀發布！設計與部署穩定的分布式系統（第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或微服務架構的系統失效，可能會非常迅速地蔓延開來