從Netflix的Hystrix框架理解服務熔斷和服務降級
伴隨著微服務架構被宣傳得如火如荼，一些概念也被推到了我們面前，其實大多數概念以前就有，但很少被提的這麼頻繁。想起有人總結的一句話，微服務架構的特點就是：“一解釋就懂，一問就不知，一討論就吵架”。
圖片 來自網路，如果涉及版權請與我們聯絡。
其實對老外的總結能力一直特別崇拜，Kevin Kelly、Martin Fowler、Werner Vogels……，都是著名的“演講家”。正好這段時間看了些微服務、容器的相關資料，也在我們新一代產品中進行了部分實踐，回過頭來，再來談談對一些概念的理解。
今天先來說說“服務熔斷”和“服務降級”。為什麼要說這個呢，因為我很長時間裡都把這兩個概念同質化了，不知道這兩個詞大家怎麼理解，一個意思or有所不同？現在的我是這麼來看的：
-
在股票市場，熔斷這個詞大家都不陌生，是指當股指波幅達到某個點後，交易所為控制風險採取的暫停交易措施。相應的，服務熔斷一般是指軟體系統中，由於某些原因使得服務出現了過載現象，為防止造成整個系統故障，從而採用的一種保護措施，所以很多地方把熔斷亦稱為過載保護。
-
大家都見過女生旅行吧，大號的旅行箱是必備物，平常走走近處綽綽有餘，但一旦出個遠門，再大的箱子都白搭了，怎麼辦呢？常見的情景就是把物品拿出來分分堆，比了又比，最後一些非必需品的就忍痛放下了，等到下次箱子夠用了，再帶上用一用。而服務降級，就是這麼回事，整體資源快不夠了，忍痛將某些服務先關掉，待渡過難關，再開啟回來。
圖片 來自網路，如果涉及版權請與我們聯絡
所以從上述分析來看，兩者其實從有些角度看是有一定的類似性的：
-
目的很一致，都是從可用性可靠性著想，為防止系統的整體緩慢甚至崩潰，採用的技術手段；
-
最終表現類似，對於兩者來說，最終讓使用者體驗到的是某些功能暫時不可達或不可用；
-
粒度一般都是服務級別，當然，業界也有不少更細粒度的做法，比如做到資料持久層（允許查詢，不允許增刪改）；
-
自治性要求很高，熔斷模式一般都是服務基於策略的自動觸發，降級雖說可人工干預，但在微服務架構下，完全靠人顯然不可能，開關預置、配置中心都是必要手段；
而兩者的區別也是明顯的：
-
觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；
-
管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）
-
實現方式不太一樣，這個區別後面會單獨來說；
當然這只是我個人對兩者的理解，外面把兩者歸為完全一致的也不在少數，或者把熔斷機制理解為應對降級目標的一種實現也說的過去，可能“一討論就吵架”也正是這個原因吧！
概念算是說完了，避免空談，我再總結下對常用的實現方法的理解。對於這兩個概念，號稱支援的框架可不少，Hystrix當屬其中的佼佼者。
先說說最裸的熔斷器的設計思路，下面這張圖大家應該不陌生（我只是參考著又畫了畫），簡明扼要的給出了好的熔斷器實現的三個狀態機：
-
Closed：熔斷器關閉狀態，呼叫失敗次數積累，到了閾值（或一定比例）則啟動熔斷機制；
-
Open：熔斷器開啟狀態，此時對下游的呼叫都內部直接返回錯誤，不走網路，但設計了一個時鐘選項，預設的時鐘達到了一定時間（這個時間一般設定成平均故障處理時間，也就是MTTR），到了這個時間，進入半熔斷狀態
-
Half-Open：半熔斷狀態，允許定量的服務請求，如果呼叫都成功（或一定比例）則認為恢復了，關閉熔斷器，否則認為還沒好，又回到熔斷器開啟狀態；
那Hystrix，作為Netflix開源框架中的最受喜愛元件之一，是怎麼處理依賴隔離，實現熔斷機制的呢，他的處理遠比我上面說個實現機制複雜的多，一起來看看核心程式碼吧，我只保留了程式碼片段的關鍵部分：
（注：程式碼圖片）
HystrixCommand是重重之重，在Hystrix的整個機制中，涉及到依賴邊界的地方，都是通過這個Command模式進行呼叫的，顯然，這個Command負責了核心的服務熔斷和降級的處理，子類要實現的方法主要有兩個：
-
run方法：實現依賴的邏輯，或者說是實現微服務之間的呼叫；
-
getFallBack方法：實現服務降級處理邏輯，只做熔斷處理的則可不實現；
使用時，可參考如下方式：
（注：程式碼圖片）
細心的同學肯定發現Command機制裡大量使用了Observable相關的API，這個是什麼呢？原來其隸屬於RxJava，這個框架就不多介紹了 --- 響應式開發，也是Netflix的作品之一，具體大家可參考這系列部落格，我覺得作者寫的很通俗：
接著呢，大家一定會問，那之前說的熔斷閾值設定等，都在哪塊做的呢？再來看看另一塊核心程式碼：
（注：程式碼圖片）
這個類作為策略類，返回相關的屬性配置，大家可重新實現。而在具體的策略中，主要包括以下幾種策略屬性配置：
-
circuitBreakerEnabled：是否允許熔斷，預設允許；
-
circuitBreakerRequestVolumeThreshold：熔斷器是否開啟的閥值，也就是說單位時間超過了閥值請求數，熔斷器才開；
-
circuitBreakerSleepWindowInMilliseconds：熔斷器預設工作時間，超過此時間會進入半開狀態，即允許流量做嘗試；
-
circuitBreakerErrorThresholdPercentage：錯誤比例觸發熔斷；
-
......
屬性很多，這裡就不一一說明了，大家可參考HystrixCommandProperties類裡的詳細定義。還有一點要著重說明的，在熔斷器的設計裡，隔離採用了執行緒的方式（據說還有訊號的方式，這兩個區別我還沒搞太明白），處理依賴併發和阻塞擴充套件，示意圖如下：
如上圖，好處也很明顯，對於每個依賴都有獨立可控的執行緒池，當然高併發時，CPU切換較多，有一定的影響。
囉嗦了一堆，最後總結一下，我認為服務熔斷和服務降級兩者是有區別的，同時通過對Hystrix的簡單學習，瞭解了其實現機制，會逐步引入到我們的產品研發中。當然還有好多概念：服務限流、分流，請求與依賴分離等，後面有時間一一與大家分享。