發博詞
此博文内容全部來自網上資料及消化後的補充。
基礎知識
如何緩解伺服器雪崩
一般情況對于服務依賴的保護主要有3中解決方案，熔斷模式和隔離模式都屬于出錯後的容錯處理機制，而限流模式則可以稱為預防模式：
（1）熔斷模式：這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災。放到我們的系統中，如果某個目标服務調用慢或者有大量逾時，此時，熔斷該服務的調用，對于後續調用請求，不在繼續調用目标服務，直接傳回，快速釋放資源。如果目标服務情況好轉則恢複調用。
（2）隔離模式：這種模式就像對系統請求按類型劃分成一個個小島的一樣，當某個小島被火少光了，不會影響到其他的小島。例如可以對不同類型的請求使用線程池來資源隔離，每種類型的請求互不影響，如果一種類型的請求線程資源耗盡，則對後續的該類型請求直接傳回，不再調用後續資源。這種模式使用場景非常多，例如将一個服務拆開，對于重要的服務使用單獨伺服器來部署，再或者公司最近推廣的多中心。
（3）限流模式：限流模式主要是提前對各個類型的請求設定最高的QPS門檻值，若高于設定的門檻值則對該請求直接傳回，不再調用後續資源。這種模式不能解決服務依賴的問題，隻能解決系統整體資源配置設定問題，因為沒有被限流的請求依然有可能造成雪崩效應。
熔斷設計
在熔斷的設計主要參考了hystrix的做法。其中最重要的是三個子產品：熔斷請求判斷算法、熔斷恢複機制、熔斷報警
（1）熔斷請求判斷機制算法：使用無鎖循環隊列計數，每個熔斷器預設維護10個bucket，每1秒一個bucket，每個blucket記錄請求的成功、失敗、逾時、拒絕的狀态，預設錯誤超過50%且10秒内超過20個請求進行中斷攔截。
（2）熔斷恢複：對于被熔斷的請求，每隔5s允許部分請求通過，若請求都是健康的（RT<250ms）則對請求健康恢複。
（3）熔斷報警：對于熔斷的請求打日志，異常請求超過某些設定則報警
Hystrix的熔斷器有三種類型的狀态：open、half-open以及closed：
##隔離設計- 線程隔離和信号量隔離
（1）線程池隔離模式：使用一個線程池來存儲目前的請求，線程池對請求作處理，設定任務傳回處理逾時時間，堆積的請求堆積入線程池隊列。這種方式需要為每個依賴的服務申請線程池，有一定的資源消耗，好處是可以應對突發流量（流量洪峰來臨時，處理不完可将資料存儲到線程池隊裡慢慢處理）
（2）信号量隔離模式：使用一個原子計數器（或信号量）來記錄目前有多少個線程在運作，請求來先判斷計數器的數值，若超過設定的最大線程個數則丢棄改類型的新請求，若不超過則執行計數操作請求來計數器+1，請求傳回計數器-1。這種方式是嚴格的控制線程且立即傳回模式，無法應對突發流量（流量洪峰來臨時，處理的線程超過數量，其他的請求會直接傳回，不繼續去請求依賴的服務）
(1):線程隔離
把執行依賴代碼的線程與請求線程(如:jetty線程)分離，請求線程可以自由控制離開的時間(異步過程)。
通過線程池大小可以控制并發量，當線程池飽和時可以提前拒絕服務,防止依賴問題擴散。
線上建議線程池不要設定過大，否則大量堵塞線程有可能會拖慢伺服器。
(2):線程隔離的優缺點
線程隔離的優點:
[1]:使用線程可以完全隔離第三方代碼,請求線程可以快速放回。
[2]:當一個失敗的依賴再次變成可用時，線程池将清理，并立即恢複可用，而不是一個長時間的恢複。
[3]:可以完全模拟異步調用，友善異步程式設計。
線程隔離的缺點:
[1]:線程池的主要缺點是它增加了cpu，因為每個指令的執行涉及到排隊(預設使用SynchronousQueue避免排隊)，排程和上下文切換。
[2]:對使用ThreadLocal等依賴線程狀态的代碼增加複雜性，需要手動傳遞和清理線程狀态。
NOTE: Netflix公司内部認為線程隔離開銷足夠小，不會造成重大的成本或性能的影響。
Netflix 内部API 每天100億的HystrixCommand依賴請求使用線程隔，每個應用大約40多個線程池，每個線程池大約5-20個線程。
(3):信号隔離
信号隔離也可以用于限制并發通路，防止阻塞擴散, 與線程隔離最大不同在于執行依賴代碼的線程依然是請求線程（該線程需要通過信号申請）,
如果用戶端是可信的且可以快速傳回，可以使用信号隔離替換線程隔離,降低開銷.
信号量的大小可以動态調整, 線程池大小不可以.
逾時機制設計
逾時分兩種，一種是請求的等待逾時，一種是請求運作逾時。
等待逾時：在任務入隊列時設定任務入隊列時間，并判斷隊頭的任務入隊列時間是否大于逾時時間，超過則丢棄任務。
運作逾時：直接可使用線程池提供的get方法
參考：
服務隔離神器-HystrixHystrix線程隔離技術解析-線程池Hystrix線程隔離技術解析-信号量微服務熔斷與隔離
Hystrix請求緩存和COLLAPSER
在Hystrix中有個Request的概念，有一些操作需要在request中進行。Collapser可以合并多個請求一起調用，Collapser可以用來一起調用一批請求，在第一個調用get時會對積壓的command一起調用。
參考：
Hystrx權威指南–Hystrix請求緩存和COLLAPSER
Hystrix執行流程
降級邏輯。以下四種情況将觸發getFallback調用：
- 熔斷器開啟攔截調用
- 線程池/隊列/信号量是否跑滿
- run()方法抛出非HystrixBadRequestException異常。
-
run()方法調用逾時
沒有實作getFallback的Command将直接抛出異常，fallback降級邏輯調用成功直接傳回，降級邏輯調用失敗抛出異常.
Hystrx權威指南–Hystrix執行流程
Hystrix DashBoard
- 圓圈的顔色和大小分别代表健康和通路量
- 折線圖表示兩分鐘内的請求速率，用來展示通路量的相對變化
- Hosts：叢集中報告資訊的節點個數
- Median
- Mean
- 90th、99th和99.5th分别代表90%的通路量的延遲時間、99%的通路量的延遲時間和99.5%的通路量的延遲時間
- 6種顔色的數字，新版的有7種，綠色代表通路成功，深藍色代表短路，淺藍色代表Bad Request，橘黃色代表請求線程逾時，紫色代表線程池Rejects，紅色代表失敗，灰色代表失敗的百分比，事實上，Hystrix對一次請求的狀态辨別多達18種，詳情請看HystrixEventType；
- Circuit的狀态 Open、Closed
- Host：54.0/s 請求速率