高可用的微服務架構設計-資源隔離、限流、熔斷、降級、監控

斷路器模式

艙壁隔離模式

容錯理念

凡是依賴都可能會失敗

凡是資源都有限制

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標注

微服務 架構設計

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。