線程隔離和信號量隔離
Hystrix 裏面核心的一項功能，其實就是所謂的資源隔離，要解決的最最核心的問題，就是將多個依賴服務的調用分別隔離到各自的資源池內。避免說對某一個依賴服務的調用，因爲依賴服務的接口調用的延遲或者失敗，導致服務所有的線程資源全部耗費在這個服務的接口調用上。一旦說某個服務的線程資源全部耗盡的話，就可能導致服務崩潰，甚至說這種故障會不斷蔓延。
資源隔離主要分爲如下兩種方式
- 線程池
- 信號量
信號量機制
信號量的資源隔離只是起到一個開關的作用，比如，服務 A 的信號量大小爲 10，那麼就是說它同時只允許有 10 個 tomcat線程來訪問服務 A，其它的請求都會被拒絕，從而達到資源隔離和限流保護的作用。
線程池機制
線程池隔離技術，並不是說去控制類似 tomcat 這種 web 容器的線程。更加嚴格的意義上來說，Hystrix 的線程池隔離技術，控制的是 tomcat 線程的執行。Hystrix 線程池滿後，會確保說，tomcat 的線程不會因爲依賴服務的接口調用延遲或故障而被 hang 住，tomcat 其它的線程不會卡死，可以快速返回，然後支撐其它的事情。
信號量機制與線程池機制的區別
線程池隔離技術，是用 Hystrix 自己的線程去執行調用；而信號量隔離技術，是直接讓 tomcat 線程去調用依賴服務。信號量隔離，只是一道關卡，信號量有多少，就允許多少個 tomcat 線程通過它，然後去執行。
適用場景
- 線程池技術，適合絕大多數場景，比如說我們對依賴服務的網絡請求的調用和訪問、需要對調用的 timeout 進行控制（捕捉 timeout 超時異常）。
適用於請求併發量大，並且耗時長（一般是計算量大或者讀數據庫）：採用線程池隔離，這樣的話，可以保證大量的容器線程可用，不會由於服務原因，一直處於阻塞或者等待狀態，快速失敗返回。 - 信號量技術，適合說你的訪問不是對外部依賴的訪問，而是對內部的一些比較複雜的業務邏輯的訪問，並且系統內部的代碼，其實不涉及任何的網絡請求，那麼只要做信號量的普通限流就可以了，因爲不需要去捕獲 timeout 類似的問題。適用於請求併發量大，並且耗時短（一般是計算量小，或讀緩存）：採用信號量隔離：因爲這類服務的返回往往非常快，不會佔用容器線程太長時間，並且減少了線程切換的一些開銷，提高了緩存服務的效率。
Hystrix請求命令 HystrixCommand、HystrixObservableCommand
- HystrixCommand用在依賴服務返回單個操作結果的時候。又兩種執行方式
-execute():同步執行。從依賴的服務返回一個單一的結果對象，或是在發生錯誤的時候拋出異常。
-queue();異步執行。直接返回一個Future對象，其中包含了服務執行結束時要返回的單一結果對象。
- HystrixObservableCommand 用在依賴服務返回多個操作結果的時候。它也實現了兩種執行方式
-observe():返回Obervable對象，他代表了操作的多個結果，他是一個HotObservable
-toObservable():同樣返回Observable對象，也代表了操作多個結果，但它返回的是一個Cold Observable。
Soul中配置失敗降級URL
soul中Hystrix的CallBackUri()需要寫在soul-boostrap項目中，因爲集成網關之後，http請求的本體項目是沒有集成Hystrix的，所以網關只能進入自己的uri中，當然我們如果需要獲取本體項目的一些信息或者數據，那麼我們可以在boostrap中通過某種方式向本體服務拿到數據或請求再返回。
可以類比的是，其他的限流插件可能CallBackUri()都必須寫在soul-boostrap中了
疑問
HystrixObservableCommand,HystrixCommand與隔離機制之間的對應關係的具體原因？
參考博客https://www.imooc.com/article/296565 , https://www.cnblogs.com/pretttyboy/p/13519823.html ,https://cloud.tencent.com/developer/article/1600695 ,https://www.cnblogs.com/happyflyingpig/p/8079308.html
歡迎搜索關注本人與朋友共同開發的微信面經小程序【大廠面試助手】和公衆號【微瞰技術】，以及總結的分類面試題https://github.com/zhendiao/JavaInterview
