Hystrix依賴隔離
“艙壁模式”對於熟悉Docker的讀者一定不陌生，Docker通過“艙壁模式”實現進程的隔離，使得容器與容器之間不會互相影響。而Hystrix則使用該模式實現線程池的隔離，它會為每一個Hystrix命令創建一個獨立的線程池，這樣就算某個在Hystrix命令包裝下的依賴服務出現延遲過高的情況，也只是對該依賴服務的調用產生影響，而不會拖慢其他的服務。
通過對依賴服務的線程池隔離實現，可以帶來如下優勢：
應用自身得到完全的保護，不會受不可控的依賴服務影響。即便給依賴服務分配的線程池被填滿，也不會影響應用自身的額其余部分。
可以有效的降低接入新服務的風險。如果新服務接入後運行不穩定或存在問題，完全不會影響到應用其他的請求。
當依賴的服務出現配置錯誤的時候，線程池會快速的反應出此問題（通過失敗次數、延遲、超時、拒絕等指標的增加情況）。同時，我們可以在不影響應用功能的情況下通過實時的動態屬性刷新（後續會通過Spring Cloud Config與Spring Cloud Bus的聯合使用來介紹）來處理它。
當依賴的服務因實現機制調整等原因造成其性能出現很大變化的時候，此時線程池的監控指標信息會反映出這樣的變化。同時，我們也可以通過實時動態刷新自身應用對依賴服務的閾值進行調整以適應依賴方的改變。
除了上面通過線程池隔離服務發揮的優點之外，每個專有線程池都提供了內置的並發實現，可以利用它為同步的依賴服務構建異步的訪問。
雖然線程池隔離的方案帶了如此多的好處，但是很多使用者可能會擔心為每一個依賴服務都分配一個線程池是否會過多地增加系統的負載和開銷。對於這一點，使用者不用過於擔心，因為這些顧慮也是大部分工程師們會考慮到的，Netflix在設計Hystrix的時候，認為線程池上的開銷相對於隔離所帶來的好處是無法比擬的。同時，Netflix也針對線程池的開銷做了相關的測試，以證明和打消Hystrix實現對性能影響的顧慮。
在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實現服務容錯保護的強力組合拳。
從現在開始，我這邊會將近期研發的springcloud微服務雲架構的搭建過程和精髓記錄下來，幫助更多有興趣研發spring cloud框架的朋友，希望可以幫助更多的好學者。大家來一起探討spring cloud架構的搭建過程及如何運用於企業項目。
Hystrix依賴隔離