斷路器
斷路器模式源於Martin Fowler的Circuit Breaker一文。“斷路器”本身是一種開關裝置，用於在電路上保護線路過載，當線路中有電器發生短路時，“斷路器”能夠及時的切斷故障電路，防止發生過載、發熱、甚至起火等嚴重後果。
在分散式架構中，斷路器模式的作用也是類似的，當某個服務單元發生故障（類似用電器發生短路）之後，通過斷路器的故障監控（類似熔斷保險絲），直接切斷原來的主邏輯呼叫。但是，在Hystrix中的斷路器除了切斷主邏輯的功能之外，還有更復雜的邏輯，下面我們來看看它更為深層次的處理邏輯。
以在《Spring Cloud構建微服務架構：服務容錯保護（Hystrix服務降級）》一文中實現的服務降級例子為示例，我們來說說斷路器的工作原理。當我們把服務提供者eureka-client中加入了模擬的時間延遲之後，在服務消費端的服務降級邏輯因為hystrix命令呼叫依賴服務超時，觸發了降級邏輯，但是即使這樣，受限於Hystrix超時時間的問題，我們的呼叫依然很有可能產生堆積。
這個時候斷路器就會發揮作用，那麼斷路器是在什麼情況下開始起作用呢？這裡涉及到斷路器的三個重要引數：快照時間窗、請求總數下限、錯誤百分比下限。這個引數的作用分別是：
快照時間窗：斷路器確定是否開啟需要統計一些請求和錯誤資料，而統計的時間範圍就是快照時間窗，預設為最近的10秒。
請求總數下限：在快照時間窗內，必須滿足請求總數下限才有資格根據熔斷。預設為20，意味著在10秒內，如果該hystrix命令的呼叫此時不足20次，即時所有的請求都超時或其他原因失敗，斷路器都不會開啟。
錯誤百分比下限：當請求總數在快照時間窗內超過了下限，比如發生了30次呼叫，如果在這30次呼叫中，有16次發生了超時異常，也就是超過50%的錯誤百分比，在預設設定50%下限情況下，這時候就會將斷路器開啟。
那麼當斷路器開啟之後會發生什麼呢？我們先來說說斷路器未開啟之前，對於之前那個示例的情況就是每個請求都會在當hystrix超時之後返回fallback，每個請求時間延遲就是近似hystrix的超時時間，如果設定為5秒，那麼每個請求就都要延遲5秒才會返回。當熔斷器在10秒內發現請求總數超過20，並且錯誤百分比超過50%，這個時候熔斷器開啟。開啟之後，再有請求呼叫的時候，將不會呼叫主邏輯，而是直接呼叫降級邏輯，這個時候就不會等待5秒之後才返回fallback。通過斷路器，實現了自動地發現錯誤並將降級邏輯切換為主邏輯，減少響應延遲的效果。
在斷路器開啟之後，處理邏輯並沒有結束，我們的降級邏輯已經被成了主邏輯，那麼原來的主邏輯要如何恢復呢？對於這一問題，hystrix也為我們實現了自動恢復功能。當斷路器開啟，對主邏輯進行熔斷之後，hystrix會啟動一個休眠時間窗，在這個時間窗內，降級邏輯是臨時的成為主邏輯，當休眠時間窗到期，斷路器將進入半開狀態，釋放一次請求到原來的主邏輯上，如果此次請求正常返回，那麼斷路器將繼續閉合，主邏輯恢復，如果這次請求依然有問題，斷路器繼續進入開啟狀態，休眠時間窗重新計時。
通過上面的一系列機制，hystrix的斷路器實現了對依賴資源故障的埠、對降級策略的自動切換以及對主邏輯的自動恢復機制。這使得我們的微服務在依賴外部服務或資源的時候得到了非常好的保護，同時對於一些具備降級邏輯的業務需求可以實現自動化的切換與恢復，相比於設定開關由監控和運維來進行切換的傳統實現方式顯得更為智慧和高效。
從現在開始，我這邊會將近期研發的springcloud微服務雲架構的搭建過程和精髓記錄下來，幫助更多有興趣研發spring cloud框架的朋友，希望可以幫助更多的好學者。大家來一起探討spring cloud架構的搭建過程及如何運用於企業專案。
原始碼來源：minglisoft.cn/honghu/tech…