Spring Cloud構建微服務架構：服務容錯保護（Hystrix依賴隔離）

依賴隔離

「艙壁模式」對於熟悉Docker的讀者必定不陌生，Docker經過「艙壁模式」實現進程的隔離，使得容器與容器之間不會互相影響。而Hystrix則使用該模式實現線程池的隔離，它會爲每個Hystrix命令建立一個獨立的線程池，這樣就算某個在Hystrix命令包裝下的依賴服務出現延遲太高的狀況，也只是對該依賴服務的調用產生影響，而不會拖慢其餘的服務。

經過對依賴服務的線程池隔離實現，能夠帶來以下優點：

• 應用自身獲得徹底的保護，不會受不可控的依賴服務影響。即使給依賴服務分配的線程池被填滿，也不會影響應用自身的額其他部分。
• 能夠有效的下降接入新服務的風險。若是新服務接入後運行不穩定或存在問題，徹底不會影響到應用其餘的請求。
• 當依賴的服務從失效恢復正常後，它的線程池會被清理而且可以立刻恢復健康的服務，相比之下容器級別的清理恢復速度要慢得多。
• 當依賴的服務出現配置錯誤的時候，線程池會快速的反應出此問題（經過失敗次數、延遲、超時、拒絕等指標的增長狀況）。同時，咱們能夠在不影響應用功能的狀況下經過實時的動態屬性刷新（後續會經過Spring Cloud Config與Spring Cloud Bus的聯合使用來介紹）來處理它。
• 當依賴的服務因實現機制調整等緣由形成其性能出現很大變化的時候，此時線程池的監控指標信息會反映出這樣的變化。同時，咱們也能夠經過實時動態刷新自身應用對依賴服務的閾值進行調整以適應依賴方的改變。
• 除了上面經過線程池隔離服務發揮的優勢以外，每一個專有線程池都提供了內置的併發實現，能夠利用它爲同步的依賴服務構建異步的訪問。

總之，經過對依賴服務實現線程池隔離，讓咱們的應用更加健壯，不會由於個別依賴服務出現問題而引發非相關服務的異常。同時，也使得咱們的應用變得更加靈活，能夠在不中止服務的狀況下，配合動態配置刷新實現性能配置上的調整。

雖然線程池隔離的方案帶了如此多的好處，可是不少使用者可能會擔憂爲每個依賴服務都分配一個線程池是否會過多地增長系統的負載和開銷。對於這一點，使用者不用過於擔憂，由於這些顧慮也是大部分工程師們會考慮到的，Netflix在設計Hystrix的時候，認爲線程池上的開銷相對於隔離所帶來的好處是沒法比擬的。同時，Netflix也針對線程池的開銷作了相關的測試，以證實和打消Hystrix實現對性能影響的顧慮。

下圖是Netflix Hystrix官方提供的一個Hystrix命令的性能監控，該命令以每秒60個請求的速度（QPS）向一個單服務實例進行訪問，該服務實例每秒運行的線程數峯值爲350個。

從圖中的統計咱們能夠看到，使用線程池隔離與不使用線程池隔離的耗時差別以下表所示：

比較狀況	未使用線程池隔離	使用了線程池隔離	耗時差距
中位數	2ms	2ms	2ms
90百分位	5ms	8ms	3ms
99百分位	28ms	37ms	9ms

在99%的狀況下，使用線程池隔離的延遲有9ms，對於大多數需求來講這樣的消耗是微乎其微的，更況且爲系統在穩定性和靈活性上所帶來的巨大提高。雖然對於大部分的請求咱們能夠忽略線程池的額外開銷，而對於小部分延遲自己就很是小的請求（可能只須要1ms），那麼9ms的延遲開銷仍是很是昂貴的。實際上Hystrix也爲此設計了另外的一個解決方案：信號量。

Hystrix中除了使用線程池以外，還可使用信號量來控制單個依賴服務的併發度，信號量的開銷要遠比線程池的開銷小得多，可是它不能設置超時和實現異步訪問。因此，只有在依賴服務是足夠可靠的狀況下才使用信號量。在HystrixCommand和HystrixObservableCommand中2處支持信號量的使用：

• 命令執行：若是隔離策略參數execution.isolation.strategy設置爲SEMAPHORE，Hystrix會使用信號量替代線程池來控制依賴服務的併發控制。
• 降級邏輯：當Hystrix嘗試降級邏輯時候，它會在調用線程中使用信號量。

信號量的默認值爲10，咱們也能夠經過動態刷新配置的方式來控制併發線程的數量。對於信號量大小的估算方法與線程池併發度的估算相似。僅訪問內存數據的請求通常耗時在1ms之內，性能能夠達到5000rps，這樣級別的請求咱們能夠將信號量設置爲1或者2，咱們能夠按此標準並根據實際請求耗時來設置信號量。

如何使用

說了那麼多依賴隔離的好處，那麼咱們如何使用Hystrix來實現依賴隔離呢？其實，咱們在上一篇定義服務降級的時候，已經自動的實現了依賴隔離。

在上一篇的示例中，咱們使用了@HystrixCommand來將某個函數包裝成了Hystrix命令，這裏除了定義服務降級以外，Hystrix框架就會自動的爲這個函數實現調用的隔離。因此，依賴隔離、服務降級在使用時候都是一體化實現的，這樣利用Hystrix來實現服務容錯保護在編程模型上就很是方便的，而且考慮更爲全面。除了依賴隔離、服務降級以外，還有一個重要元素：斷路器。咱們將在下一篇作詳細的介紹，這三個重要利器構成了Hystrix實現服務容錯保護的強力組合拳。Spring Cloud大型企業分佈式微服務雲架構源碼請加企鵝求求：一七九一七四三三八零