斷路器模式
艙壁隔離模式
容錯理念
- 凡是依賴都可能會失敗
- 凡是資源都有限制
- CPU/Memory/Threads/Queue
- 網絡并不可靠，延遲是應用穩定性殺手
1 資源隔離
讓你的系統裡，某一塊東西，在故障的情況下，不會耗盡系統所有的資源，比如線程資源
項目中的一個case，有一塊東西，是要用多線程做一些事情，小夥伴做項目的時候，沒有太留神，資源隔離，那塊代碼，在遇到一些故障的情況下，每個線程在跑的時候，因為那個bug，直接就死循環了，導緻那塊東西啟動了大量的線程，每個線程都死循環
最終導緻系統資源耗盡，崩潰，不工作，不可用，廢掉了
資源隔離，那一塊代碼，最多最多就是用掉10個線程，不能再多了，就廢掉了，限定好的一些資源
2 限流
對打入服務的請求流量進行控制，使服務能夠承擔不超過自己能力的流量壓力。
高并發的流量湧入進來，比如說突然間一秒鐘100萬QPS，廢掉了，10萬QPS進入系統，其他90萬QPS被拒絕了
3 熔斷
A服務調用B服務的某個功能，由于網絡不穩定問題，或者B服務卡機，導緻功能時
間超長。如果這樣的次數太多。我們就可以直接将B斷路(A不再請求B接口)，凡是
調用B的直接傳回降級資料，不必等待B的超長執行。這樣B的故障問題，就不會級聯影
響到A。
依賴服務，出了一些故障，每次請求都報錯，熔斷它，後續的請求過來直接不接收了，拒絕通路，10分鐘之後再嘗試去看看接口是否恢複。
4 降級
整個網站處于流量高峰期，伺服器壓力劇增，根據目前業務情況及流量，對一些服務和頁面進行有政策的降級[停止服務，所有的調用直接傳回降級資料]。以此緩解伺服器資源的的壓力，以保證核心業務的正常運作，同時也保持了客戶和大部分客戶的得到正确的響應。
MySQL挂了，系統發現了，自動降級，從記憶體裡存的少量資料中，去提取一些資料出來。
和熔斷的異同
相同點
- 為了保證叢集大部分服務的可用性和可靠性，防止崩潰，犧牲小我
- 使用者最終都是體驗到某個功能不可用
不同點
- 熔斷是被調用方故障，觸發的系統主動規則
- 降級是基于全局考慮，停止一些正常服務，釋放資源
5 運維監控
監控+報警+優化，各種異常的情況，有問題就及時報警，優化一些系統的配置和參數，或者代碼
如果你的各種依賴的服務有了故障，那麼很可能會導緻你的系統不可用
hystrix對系統進行各種高可用性的系統加強，來應對各種不可用的情況
最佳實踐
網關集中埋點,覆寫大部分場景
盡量架構集中埋點,用戶端為主
配置對接Apollo ,根據實際使用調整閥值
信号量vs線程池場景
信号量:網關，緩存
線程池場景:服務間調用用戶端，資料庫通路，第三方通路
線程池大小經驗值
30rps x0.2sec= 6 + breathing room = 10 threads
Thread-pool Queue size:5 ~ 10
部署
Hystrix Dashboard大盤(無線/H5/第3三方網關)
共享Hystrix Dashboard/Turbine伺服器
熔斷告警
Spring Cloud Hystrix标注
————————————————
版權聲明：本文為CSDN部落客「JavaEdge.」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/qq_33589510/article/details/95803214