# 微服務架構設計 - 客戶彈性模式 Client-Side Resiliency Pattern
# 前言
Client-Side Resiliency Pattern 目的在 Client Side Service 避免存取過程中，被呼叫方的異常導致一系列的崩潰， Client-Side Resiliency Pattern 可以讓 Client 自主快速失敗並且不會耗盡自身資源，其中達成的方式會組合
- Client-Side Load Balancing Pattern
- Circuit Breaker Pattern
- Fallback Pattern
- Bulkhead Pattern
# 先來講講未使用 Client-Side Resiliency Pattern
以下是我們用來當範例的系統架構
- Client A/B Use Book Service
- Book Service call Author Service
- Author Service call Inventory Service
- Inventory Service need NAS
- Client C Use Inventory Service
有天 NAS 系統正在調整中，一開始系統工作正常後來發現對特定硬碟子系統的讀取變慢了
因為 Author Service Developer 不知道呼叫 Inventory Service 的效能會被慢，因此一開始 Inventory 與 Author Service 的資料庫的寫入是放在一個 Transaction 當中，當 Inventory 變慢這時放在 Inventory 相同執行續池的 Author 及相關被依賴服務的執行續池開始飽和，且一直累積連線數量直到數量耗盡，是因為每一筆對 Inventory 的交易都沒有完成而導致保持連線的狀態。
接者依賴 Author 的 Book Service 也開始受到影響展開一連串的異常。
那麼這時候我們就可以運用斷路器類似保險絲的概念來避免這樣的連鎖效應發生。
# 使用 Resilience Pattern
- 樂觀成功
- 斷路器維護一個計時器，如果在計時結束前完成呼叫及完成
- 部分降級
- 當超出預期時間，斷路器會中斷與服務的連接，並且返回錯誤
- 快速回退
- 如果 Book 已經知道有問題，不需等待超時即可選擇完全失敗或 fallback 處理找替代方案，這樣斷路器已經斷開讓 Author Service 有空間與時間處理，有效防止因服務降級導致的一系列崩潰
- 在降級的情境之下，斷路器還是會偶爾的放行一些 Request 如果成功多人，斷路器又會開放連線，斷路器模式的好處就是能夠在呼叫遠端服務時
- 快速失敗
- 優雅斯拜
- 無縫復原
# 參考資料
- 書籍 - 微服務開發指南｜使用 Spring Cloud 與 Docker
