1. 快速失敗而非緩慢響應

1.1. 如果響應緩慢比沒有響應更糟，那麼最壞的情況肯定是緩慢的失敗響應

1.2. 如果系統能夠預先確定某次調用會失敗，那麼最好快速失敗

2. 快速失敗模式通過避免響應緩慢來提高整個系統的穩定性

2.1. 當系統由於部分失效而面臨壓力時，快速失敗模式還有助於保持系統容量

2.2. 與超時模式配合使用，快速失敗模式有助於避免層疊失效

3. 預留資源並儘早驗證集成點有效

3.1. 確保在開始之前就能完成事務

3.1.1. 關鍵資源不可用，比如所需調用的斷路器已跳閘，那麼就不要再浪費精力去調用

3.2. 在事務的開始階段和中間階段，關鍵資源可用狀態發生變化的可能性極小

3.3. 應用程式或服務可以從傳入的請求或消息中，大致瞭解需要哪些資料庫連接和外部集成點，然後可以快速檢查所需的連接，並查看集成點周圍的斷路器狀態

4. 使用輸入驗證

4.1. 即使在預留資源之前，也要進行基本的用戶輸入驗證

4.2. 找到未輸入的必需參數才是關鍵

5. 任其崩潰並替換

5.1. 有時，為了實現系統級穩定性，放棄組件級穩定性就是所能做的最好的事情

5.1.1. 通過組件崩潰保護系統

5.1.2. 通過組件級不穩定性構建系統級穩定性

5.1.3. 這可能是將系統恢復到已知良好狀態的最佳方式

5.1.4. 隔離組件以實現獨立崩潰

5.2. 在Erlang語言中，這被稱為“任其崩潰並替換”的哲學

5.2.1. 任其崩潰並替換的方法認為錯誤恢復難以完成且不可信賴，所以我們的目標應該是儘快回到剛完成啟動時的乾凈狀態

5.3. 程式所能擁有的最乾凈的狀態，就是在剛剛完成啟動的那一刻

5.4. 前提

5.4.1. 有限的粒度

5.4.1.1. 必須為崩潰定義邊界

5.4.1.2. 發生崩潰的組件應該是獨立的，系統的其餘部分必須能夠自我防護，避免受到層疊失效的影響

5.4.1.3. 在微服務架構中，服務的整個實例可能是正確的崩潰粒度

5.4.1.4. 在Erlang和Elixir中，崩潰的自然邊界就是actor

5.4.2. 快速替換

5.4.2.1. actor這樣的進程內組件，重啟時間以微秒為單位

5.4.2.2. 在容器中運行Go二進位文件

5.4.2.2.1. 啟動一個新容器及其內部一個進程的時間以毫秒為單位計算，此時就可以通過讓整個容器崩潰實現快速替換

5.4.2.3. NodeJS服務在AWS中一個長時間運行的虛擬機上運行

5.4.2.3.1. 啟動NodeJS進程需要花幾毫秒，但啟動一臺新的虛擬機則需要幾分鐘

5.4.2.3.2. 只需要讓NodeJS進程崩潰，就可以實現快速替換

5.4.2.4. 不要讓單體系統崩潰

5.4.2.4.1. 運行時負載較大或啟動時間較長的大型進程，不適合運用“任其崩潰並替換”策略

5.4.2.4.2. 將許多特性耦合到單個進程中的應用程式，也不推薦運用該策略

5.4.2.4.3. 在數據中心的幾台虛擬機上，運行著一個老舊的前端安裝API的JavaEE應用程式

5.4.2.4.3.1. 啟動時間以分鐘為單位計算，此時，“任其崩潰並替換”並不是正確的策略

5.4.3. 監管

5.4.3.1. 監管器不是服務的消費者

5.4.3.2. 管理工人與要求服務是兩碼事

5.4.3.3. 如果把兩者混淆，就會損害系統

5.4.4. 重新歸隊

5.4.4.1. 在一個actor或實例先崩潰然後由監管器重新將其啟動之後，系統必須要恢復對新啟動的服務提供方的調用

5.4.4.2. 如果實例被直接調用，則調用方的斷路器應該自動將該實例重新歸隊

5.4.4.3. 如果實例是負載均衡池中的一部分，那麼必須能夠將實例加回池中，接受工作