Soul網關Hystrix插件相關知識點掃盲

線程隔離和信號量隔離

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