序言
感覺hystrix很精彩,文檔講的也很好，這篇總結到哪里是哪里吧
寫Hystrix之前，我們先簡單的說說熔斷器，和限流，這樣你看完之后，就可以很容易理解Hystrix
熔斷器
熔斷器模式源於Martin Fowler的Circuit Breaker一文。“熔斷器”本身是一種開關裝置，用於在電路上保護線路過載，當線路中有電器發生短路時，“熔斷器”能夠及時的切斷故障電路，防止發生過載、發熱、甚至起火等嚴重后果。
熔斷器設計中有三種狀態，生生世世，循環往復。
- closed（關閉狀態，流量可以正常進入）
- open（即熔斷狀態，一旦錯誤達到閾值，熔斷器將打開，拒絕所有流量）
- half-open(半開狀態，open狀態持續一段時間后將自動進入該狀態，重新接收流量，一旦請求失敗，重新進入open狀態，但如果成功數量達到閾值，將進入closed狀態)
整體流程見下圖：
CLOSED關閉狀態：允許流量通過。
OPEN打開狀態：不允許流量通過，即處於降級狀態，走降級邏輯。
HALF_OPEN半開狀態：允許某些流量通過，並關注這些流量的結果，如果出現超時、異常等情況，將進入OPEN狀態，如果成功，那么將進入CLOSED狀態。
在分布式架構中，熔斷器模式的作用也是類似的，當某個服務單元發生故障（類似用電器發生短路）之后，通過斷路器的故障監控（類似熔斷保險絲），向調用方返回一個錯誤響應，而不是長時間的等待。這樣就不會使得線程因調用故障服務被長時間占用不釋放，避免了故障在分布式系統中的蔓延。
限流
在開發高並發系統時，有很多手段保護系統，比如緩存、降級和限流。緩存的目的是提升系統訪問速度和增大系統處理能力，可謂是抗高並發的銀彈。而降級是當服務出問題或者影響到核心流程的性能，需要暫時屏蔽掉，待高峰過去或者問題解決后再打開的場景。而有些場景並不能用緩存和降級來解決，比如稀缺資源（秒殺、搶購）、寫服務（如評論、下單）、頻繁的復雜查詢（評論的最后幾頁）等。因此，需要有一種手段來限制這些場景下的並發/請求量，這種手段就是限流。
限流的目的是通過對並發訪問/請求進行限速或者一個時間窗口內的請求進行限速來保護系統，一旦達到限速速率則可以拒絕服務（定向到錯誤頁或告知資源沒有了）、排隊或等待（比如秒殺、評論、下單）、降級（返回兜底數據或者默認數據，如商品詳情頁庫存默認有貨）。在壓測時，我們能找出每個系統的處理峰值，然后通過設定峰值閾值，當系統過載時，通過拒絕過載的請求來保障系統可用。另外，也可以根據系統的吞吐量、響應時間、可用率來動態調整限流閾值。
一般開發高並發系統場景的限流有：限制總並發數（比如數據庫連接池、線程池）、限制瞬時並發數（如Nginx的limit_conn模塊，用來限制瞬間並發連接數）、限制時間窗口內的平均速率（如Guava的RateLimiter、Nginx的limit_req模塊，用來限制每秒的平均速率），以及限制遠程接口調用速率、限制MQ的消費速率等。另外還可以根據網絡連接數、網絡流量、CPU或內存負載等來限流。
限流算法
常見的限流算法有：令牌桶、漏桶。計數器也可以用來進行粗暴限流實現。
令牌桶算法
令牌桶算法，是一個存放固定容量令牌的桶，按照固定速率往桶里添加令牌。令牌桶算法的描述如下：
- 假設限制2r/s，則按照500毫秒的固定速率往桶內添加令牌。
- 桶中最多存放b個令牌，當桶滿時，新添加的令牌會被丟棄或拒絕。
- 當一個n個字節大小的數據包到達，將從桶中刪除n個令牌，接着數據包被發送到網絡上。
- 如果桶中的令牌不足n個，則不會刪除令牌，且該數據包被限流（要么丟棄，要么在緩沖區等待）。
漏桶算法
漏桶作為計量工具時，可以用於流量整形和流量控制，漏桶算法的描述如下：
- 一個固定容量的漏桶，按照常量固定速率流出水滴。
- 如果桶是空的，則不需流出水滴。
- 可以以任意速率流入水滴到漏桶。
- 如果流入水滴超過了桶的容量，則流入的水滴溢出了（被丟棄），而漏桶容量是不變的。
常見的限流方式有：限制總並發數（數據庫連接池、線程池）、限制瞬時並發數（如Nginx的limit_conn模塊）、限制時間窗口的平均速率（如Guava的RateLimiter、Nginx的limit_req模塊）、限制遠程接口的調用速率、限制MQ的消費速率等。從應用的層面上來講，又可以分為：接入層限流、應用層限流和分布式限流等。
Hystrix是什么
這一節方便閱讀，我都抄下來來，具體看文檔Hystrix：https://github.com/Netflix/Hystrix/wiki
在分布式環境中，許多服務依賴項中的一些不可避免地會失敗。Hystrix是一個庫，可通過添加延遲容錯和容錯邏輯來幫助您控制這些分布式服務之間的交互。Hystrix通過隔離服務之間的訪問點，阻止它們之間的級聯故障以及提供后備選項來實現這一目標，所有這些都可以提高系統的整體彈性。
Hystrix旨在執行以下操作：
- 通過第三方客戶端庫訪問（通常通過網絡）依賴關系，以防止和控制延遲和故障。
- 在復雜的分布式系統中停止級聯故障。
- 快速失敗並迅速恢復。
- 在可能的情況下，后退並優雅地降級。
- 實現近實時監控，警報和操作控制。
復雜分布式體系結構中的應用程序有許多依賴項，每個依賴項在某些時候都不可避免地會失敗。如果主機應用程序沒有與這些外部故障隔離，那么它有可能被他們拖垮。
例如，對於一個依賴於30個服務的應用程序，每個服務都有99.99%的正常運行時間，你可以期望如下：
99.9930 = 99.7% 可用
也就是說一億個請求的0.03% = 3000000 會失敗
如果一切正常，那么每個月有2個小時服務是不可用的
現實通常是更糟糕
當一切正常時，請求看起來是這樣的：
當其中有一個系統有延遲時，它可能阻塞整個用戶請求：
在高流量的情況下，一個后端依賴項的延遲可能導致所有服務器上的所有資源在數秒內飽和（PS：意味着后續再有請求將無法立即提供服務）
當您使用Hystrix來包裝每個底層依賴項時，上圖中顯示的體系結構將更改為類似於下圖。每個依賴項彼此隔離，在發生延遲時可以飽和的資源受到限制，並且在回退邏輯中涵蓋，該邏輯決定了在依賴項中發生任何類型的故障時要做出的響應：
Feign調用使用Hystrix示例
首先，前幾節的環境，都有啊，沒有或需要的去看我前幾篇文章吧
pom.xml
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency>
feign調用接口
@FeignClient(name = "trade-promotion", fallback = PromotionClientFallback.class) public interface PromotionClient { @RequestMapping(value = "/Promotion/delete", method = RequestMethod.GET) String releasePromotion(@RequestParam int orderID); }
fallback類
@Component public class PromotionClientFallback implements PromotionClient { @Override public String releasePromotion(@RequestParam int orderID) { return "hello ,fallback !"; } }
調用
@RestController @RequestMapping(value = "/promotion", method = RequestMethod.GET) public class PromotionController { @Autowired PromotionClient promotionClient; @RequestMapping(value = "/delete") public String delete(@RequestParam int orderID) { return promotionClient.releasePromotion(orderID); } }
配置文件
#hystrix
feign.hystrix.enabled=true
好啦,可以啦.說下,就是如果遠程調用接口異常,會執行Fallback返回 "hello ,fallback !";
如果你想知道為什么失敗,失敗的原因
@Component public class PromotionClientFallbackFactory implements FallbackFactory<PromotionClient> { @Override public PromotionClient create(Throwable cause) { return new PromotionClient() { @Override public String releasePromotion(int orderID) { return "fallback:orderid=" + orderID + "，message:" + cause.getMessage(); } }; } }
@FeignClient(name = "trade-promotion", fallbackFactory = PromotionClientFallbackFactory.class) public interface PromotionClient { @RequestMapping(value = "/Promotion/delete", method = RequestMethod.GET) String releasePromotion(@RequestParam int orderID); }
這樣也可以
@HystrixCommand(fallbackMethod = "error") public String search(@RequestParam int id) { try { Thread.sleep(10000); return id + ""; } catch (Exception ex) { return ex.getMessage(); } } public String error(int id) { return "error"+id; }
好啦,這樣就ok啦.
Hystrix配置
#hystrix
feign.hystrix.enabled=true
#是否開啟fallback功能，默認為true
hystrix.command.default.fallback.enabled=true
#開啟hystrix請求超時機制 也可以設置成永久不超時
hystrix.command.default.execution.timeout.enabled=true
#設置調用者執行的超時時間（單位毫秒），默認：1000
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000
#此屬性設置從調用線程允許HystrixCommand.getFallback（）方法允許的最大並發請求數
#如果達到最大的並發量，則接下來的請求會被拒絕並且拋出異常.
#默認為10
hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests = 500
#當HystrixCommand.run()使用SEMAPHORE的隔離策略時，設置最大的並發量
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests = 1000
#是否開啟斷路器功能，默認為true
hystrix.command.default.circuitBreaker.enabled=true
#該屬性設置滾動窗口中將使斷路器跳閘的最小請求數量
#如果此屬性值為20，則在窗口時間內（如10s內），如果只收到19個請求且都失敗了，則斷路器也不會開啟。
#默認值：20
hystrix.command.default.circuitBreaker.requestVolumeThreshold=200
#斷路器跳閘后，在此值的時間的內，hystrix會拒絕新的請求，只有過了這個時間斷路器才會打開閘門
#默認值：5000
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=60000
#設置失敗百分比的閾值。如果失敗比率超過這個值，則斷路器跳閘並且進入fallback邏輯
#默認值：50 ，即50%
hystrix.command.default.circuitBreaker=50
#如果設置true，則強制使斷路器進行關閉狀態，此時會允許執行所有請求，無論是否失敗的次數達到circuitBreaker.errorThresholdPercentage值
#默認值：false
hystrix.command.default.circuitBreaker.forceOpe=false
#如果設置true，則強制使斷路器進行關閉狀態，此時會允許執行所有請求，無論是否失敗的次數達到circuitBreaker.errorThresholdPercentage值
#默認值：false
hystrix.command.default.circuitBreaker.forceClosed=false
#設置線程池的core size,這是最大的並發執行數量。默認10
hystrix.threadpool.default.coreSize=500
#最大隊列長度。設置BlockingQueue的最大長度。默認-1。
#如果設置成-1，就會使用SynchronizeQueue。
#如果其他正整數就會使用LinkedBlockingQueue。
hystrix.threadpool.default.maxQueueSize=1000
#設置拒絕請求的臨界值。只有maxQueueSize為-1時才有效。
#設置設個值的原因是maxQueueSize值運行時不能改變，我們可以通過修改這個變量動態修改允許排隊的長度。默認5
hystrix.threadpool.default.queueSizeRejectionThreshold=1000
#設置統計滾動窗口的時間長度，默認值：10000
hystrix.command.default.metrics.rollingStats.timeInMilliseconds=10000
#設置統計滾動窗口的桶數量，
#注意：以下配置必須成立，否則會拋出異常。
#metrics.rollingStats.timeInMilliseconds % metrics.rollingStats.numBuckets == 0
#如：10000/10、10000/20是正確的配置,但是10000/7錯誤的
#在高並發的環境里，每個桶的時間長度建議大於100ms
#默認值：10
hystrix.command.default.metrics.rollingStats.numBuckets=10
#設置執行延遲是否被跟蹤，並且被計算在失敗百分比中。如果設置為false,則所有的統計數據返回-1
#默認值： true
hystrix.command.default.metrics.rollingPercentile.enabled=true
#此屬性設置統計滾動百分比窗口的持續時間，默認值：60000
hystrix.command.default.metrics.rollingPercentile.timeInMilliseconds=60000
#設置統計滾動百分比窗口的桶數量
#注意：以下配置必須成立，否則會拋出異常。
#metrics.rollingPercentile.timeInMilliseconds % metrics.rollingPercentile.numBuckets == 0
#如： 60000/6、60000/60是正確的配置,但是10000/7錯誤的
#在高並發的環境里，每個桶的時間長度建議大於1000ms
#默認值：6
hystrix.command.default.metrics.rollingPercentile.numBuckets=6
#此屬性設置每個桶保存的執行時間的最大值。如果桶數量是100，統計窗口為10s，如果這10s里有500次執行，只有最后100次執行會被統計到bucket里去
#默認值：100
hystrix.command.default.metrics.rollingPercentile.bucketSize=100
#采樣時間間隔
hystrix.command.default.metrics.healthSnapshot.intervalInMilliseconds=500
總結
多看官放文檔,推薦看下hystrix是如何工作的,很精彩.去吧,再次方便你,學不好就怪自己太忙,沒時間看文檔吧: https://github.com/Netflix/Hystrix/wiki
有時間再把hystrix的監控寫下,今天就這啦,88