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. 如果實體是負載均衡池中的一部分，那么必須能夠將實體加回池中，接受作業
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/556256.html
標籤：架構設計
上一篇：Bean生命周期的擴展點：Bean Post Processor
下一篇：返回列表