sentinal：
除了流量控制以外，對調用鍊路中不穩定的資源進行熔斷降級也是保障高可用的重要措施之一。一個服務常常會調用别的子產品，可能是另外的一個遠端服務、資料庫，或者第三方 API 等。例如，支付的時候，可能需要遠端調用銀聯提供的 API；查詢某個商品的價格，可能需要進行資料庫查詢。然而，這個被依賴服務的穩定性是不能保證的。如果依賴的服務出現了不穩定的情況，請求的響應時間變長，那麼調用服務的方法的響應時間也會變長，線程會産生堆積，最終可能耗盡業務自身的線程池，服務本身也變得不可用。
現代微服務架構都是分布式的，由非常多的服務組成。不同服務之間互相調用，組成複雜的調用鍊路。以上的問題在鍊路調用中會産生放大的效果。複雜鍊路上的某一環不穩定，就可能會層層級聯，最終導緻整個鍊路都不可用。是以我們需要對不穩定的弱依賴服務調用進行熔斷降級，暫時切斷不穩定調用，避免局部不穩定因素導緻整體的雪崩。熔斷降級作為保護自身的手段，通常在用戶端（調用端）進行配置。
Sentinel 提供以下幾種熔斷政策：
慢調用比例 (<code>SLOW_REQUEST_RATIO</code>)：選擇以慢調用比例作為門檻值，需要設定允許的慢調用 RT（即最大的響應時間），請求的響應時間大于該值則統計為慢調用。當機關統計時長（<code>statIntervalMs</code>）内請求數目大于設定的最小請求數目，并且慢調用的比例大于門檻值，則接下來的熔斷時長内請求會自動被熔斷。經過熔斷時長後熔斷器會進入探測恢複狀态（HALF-OPEN 狀态），若接下來的一個請求響應時間小于設定的慢調用 RT 則結束熔斷，若大于設定的慢調用 RT 則會再次被熔斷。
異常比例 (<code>ERROR_RATIO</code>)：當機關統計時長（<code>statIntervalMs</code>）内請求數目大于設定的最小請求數目，并且異常的比例大于門檻值，則接下來的熔斷時長内請求會自動被熔斷。經過熔斷時長後熔斷器會進入探測恢複狀态（HALF-OPEN 狀态），若接下來的一個請求成功完成（沒有錯誤）則結束熔斷，否則會再次被熔斷。異常比率的門檻值範圍是 <code>[0.0, 1.0]</code>，代表 0% - 100%。
異常數 (<code>ERROR_COUNT</code>)：當機關統計時長内的異常數目超過門檻值之後會自動進行熔斷。經過熔斷時長後熔斷器會進入探測恢複狀态（HALF-OPEN 狀态），若接下來的一個請求成功完成（沒有錯誤）則結束熔斷，否則會再次被熔斷。
注意異常降級僅針對業務異常，對 Sentinel 限流降級本身的異常（<code>BlockException</code>）不生效。為了統計異常比例或異常數，需要通過 <code>Tracer.trace(ex)</code> 記錄業務異常。示例：
開源整合子產品，如 Sentinel Dubbo Adapter, Sentinel Web Servlet Filter 或 <code>@SentinelResource</code> 注解會自動統計業務異常，無需手動調用。
熔斷降級規則（DegradeRule）包含下面幾個重要的屬性：
Field
說明
預設值
resource
資源名，即規則的作用對象
grade
熔斷政策，支援慢調用比例/異常比例/異常數政策
慢調用比例
count
慢調用比例模式下為慢調用臨界 RT（超出該值計為慢調用）；異常比例/異常數模式下為對應的門檻值
timeWindow
熔斷時長，機關為 s
minRequestAmount
熔斷觸發的最小請求數，請求數小于該值時即使異常比率超出門檻值也不會熔斷（1.7.0 引入）
5
statIntervalMs
統計時長（機關為 ms），如 60*1000 代表分鐘級（1.8.0 引入）
1000 ms
slowRatioThreshold
慢調用比例門檻值，僅慢調用比例模式有效（1.8.0 引入）
Sentinel 支援注冊自定義的事件監聽器監聽熔斷器狀态變換事件（state change event）。示例：
慢調用比例熔斷示例：SlowRatioCircuitBreakerDemo
hystrix:
圖中流程的說明:
将遠端服務調用邏輯封裝進一個HystrixCommand。
對于每次服務調用可以使用同步或異步機制，對應執行execute()或queue()。
判斷熔斷器(circuit-breaker)是否打開或者半打開狀态，如果打開跳到步驟8，進行回退政策，如果關閉進入步驟4。
判斷線程池/隊列/信号量（使用了艙壁隔離模式）是否跑滿，如果跑滿進入回退步驟8，否則繼續後續步驟5。
run方法中執行了實際的服務調用。
a. 服務調用發生逾時時，進入步驟8。
判斷run方法中的代碼是否執行成功。
a. 執行成功傳回結果。
b. 執行中出現錯誤則進入步驟8。
所有的運作狀态(成功，失敗，拒絕，逾時)上報給熔斷器，用于統計進而影響熔斷器狀态。
進入getFallback()回退邏輯。
a. 沒有實作getFallback()回退邏輯的調用将直接抛出異常。
b. 回退邏輯調用成功直接傳回。
c. 回退邏輯調用失敗抛出異常。
傳回執行成功結果。
注意：熔斷是否開啟熔斷器主要由依賴調用的錯誤比率決定的，依賴調用的錯誤比率=請求失敗數/請求總數。Hystrix中斷路器打開的預設請求錯誤比率為50%（這裡暫時稱為請求錯誤率），還有一個參數，用于設定在一個滾動視窗中，打開斷路器的最少請求數（這裡暫時稱為滾動視窗最小請求數），這裡舉個具體的例子：如果滾動視窗最小請求數為預設20，在一個視窗内（預設10秒，統計滾動視窗的時間可以設定），收到19個請求，即使這19個請求都失敗了，此時請求錯誤率高達95%，但是斷路器也不會打開。對于被熔斷的請求，并不是永久被切斷，而是被暫停一段時間（預設是5000ms）之後，允許部分請求通過，若請求都是健康的（ResponseTime<250ms）則對請求健康恢複（取消熔斷），如果不是健康的，則繼續熔斷。（這裡很容易出現一種錯覺：多個請求失敗但是沒有觸發熔斷。這是因為在一個滾動視窗内的失敗請求數沒有達到打開斷路器的最少請求數）
最近我整理了整套《JAVA核心知識點總結》,說實話 ,作為一名Java程式員,不論你需不需要面試都應該好好看下這份資料。拿到手總是不虧的~我的不少粉絲也是以拿到騰訊位元組快手等公司的Offer
進【Java進階之路群】，找管理者擷取哦-！