服務治理利器Hystrix-理論篇

引言    

如今的大中型應用，不少都在朝着服務化、分佈式的方向發展。這有多方面的考慮，好比說，方便治理、便於擴展、服務隔離等等。不過在帶來如此多利好的同時，不可避免的也會帶來麻煩，好比系統架構複雜、服務依賴關係繁雜。總體來講，仍是利大於弊，而咱們須要思考的，就是怎麼在獲得這些利的同時，解決弊端。從本篇開始，將會用兩到三篇來探討這方面的心得。

 正文

    這類應用，每每會依賴幾個甚至幾十個服務，而服務發生故障又是不可避免的事情，即便你說本身的服務達到了四個9的高標準，那麼借用網上的一個算式，若是應用A依賴了30個服務，那麼出錯的概率也是99.99%^30=99.70%每一年大約有24個小時是不穩定的。一億次請求*0.3%=30w次失敗。有沒有細思極恐的趕腳？

 

    不少時候，咱們還不得不面臨，只有一個服務延遲或者掛掉，結果整個應用都受到影響。在高QPS的場景下，很快整個服務器上的資源就會被耗盡。來個圖感覺下（注：圖片來自於網絡）：

    服務I出問題，站在其餘服務的角度看，這就是坑隊友了啊。若是再有級聯的依賴，簡直就是噩夢。

        

    那麼怎麼辦呢？繼續提高每一個服務的可用率？固然，這是咱們永遠的追求，如星辰大海通常，沒有止境。但也正是所以認識到，想達到100%的可用率，幾乎不可能，只要有那麼點缺憾的存在，那麼，一旦量級起來了，刺耳的報警短信之音仍是會在夜深人靜的時候響起。

    

    既然這條路走不通，或者說只能部分走通，那麼還有沒有其餘路呢？固然有，辦法總比問題多。

 

    最經常使用的就是降級策略。所謂降級，無非就是願意承擔必定限度的成本，保證總體可用。舉幾個例子來講：

 

• 犧牲一小部分流量（其實深究起來就是用戶的請求），來保證服務總體不被壓垮。

• 再也不強求一小部分服務的返回值，保證絕大多數服務可用。

• 固然還有緩存，犧牲數據的時效性，保證可用性。

    

    方向性的指導原則有了，不會南轅北轍了，那麼剩下的就是具體實踐了，正所謂工欲善其事必先利其器。本篇，將重點研究業界流行的一件神兵利器：Hystrix。

 

    Hystrix是經過什麼手段來實現的服務降級呢？在小端看來，最核心的就是如下三點，其餘的都是錦上添花的東西：

1. 配置線程池，來控制併發量

2. 配置超時時間，加快返回速度

3. 配置熔斷器，直接拒絕請求（舍小我保你們）   

    

   下面，詳細說明：

 

隔離：

        爲每個服務，注意，是每個，都維護一個獨立的線程池（或者信號量），當線程池滿時，使用相應策略處理，好比拒絕服務，好比排隊（要看配置的是哪一種線程池了）。這樣，就控制了併發量。不會由於忽然而至的請求驟增，壓垮服務。這樣就實現了服務間相互隔離，彼此不受影響的效果。以下圖（圖片來自網絡）：

 

命令模式：

        這個真沒什麼高深的，就是咱們的業務邏輯類，要繼承HystrixCommand或者HystrixObservableCommand，重寫他們的run()或construct()方法。在該方法裏，實現對外部服務的調用。而在使用時，就像下命令同樣，對業務邏輯類實例化的對象，下達「命令」（即調用提供的統一的execute、queue等方法），而不需關心內部的具體調用邏輯，便可自動執行咱們重寫的run()或者construct()。

 

超時：

        設置超時時間，那麼在每一個請求執行過程當中，一旦發生響應超時，便可有所動做，對的，就是轉而去執行getFallBack()方法，快速返回結果，釋放系統資源。固然，執行失敗的，也是如此處置。

 

熔斷器：

        這個詞看起來高大上，知道這個詞，是前幾年A股裏的那次事件。在這裏思路其實差很少，就是我要統計一個時間窗口內，服務的成功、失敗、超時等的數據，而後依據配置的策略，好比失敗率達到80%時，切斷服務一段時間，這時，任何請求，都拒絕服務！拒絕服務！拒絕服務！直接執行getFallBack()邏輯。比較牛的設計是，提供了自動恢復能力。能夠配置一個時間閾值，在拒絕服務超過這個時長後，接受一個請求，嘗試調用服務。若是成功，則服務恢復，若是失敗，則繼續進入熔斷狀態。

 下篇預告

基本原理性的東西，先寫這麼多，下篇繼續從使用層面分析。

若是對你有幫助，能夠關注個人公衆號，第一時間看到更多原創內容：

搜索：小端有話說

掃碼：