線上防雪崩利器——熔斷器設計原理與實現
前言
這是一篇根據工作中遇到的問題總結出的最佳實踐。
上周六，我負責的業務在淩晨00-04點的支付全部失敗了。
結果一查，MD，晚上銀行維護，下遊支付系統沒有掛維護公告，在此期間一直請求維護中的銀行，當然所有返回就是失敗了，有種欲哭無淚的感覺，鍋讓業務來背。
為了杜絕在此出現這種大面積批量的支付失敗情況發生，保障系統的健壯性。我需要個在集中性異常的時候可以終止請求，當服務恢復，恢復請求。
我想了一些方式，最後，覺得熔斷器比較適合幹這種事情。
狀態模式
我們已一個開關為例
在每一種狀態下，context不必關心每一種狀態下的行為。交給每一種狀態自己處理。
熔斷器基本原理
熔斷器是當依賴的服務已經出現故障時，為了保證自身服務的正常運行不再訪問依賴的服務，防止雪崩效應
熔斷器本身就是一個狀態機。
關閉狀態：熔斷器的初始化狀態，該狀態下允許請求通過。當失敗超過閥值，轉入打開狀態，
打開狀態：熔斷狀態，該狀態下不允許請求通過，當進入該狀態經過一段時間，進入半開狀態。
半開狀態：在半開狀態期間，允許部分請求通過，在半開期間，觀察失敗狀態是否超過閥值。如果沒有超過進入關閉狀態，如果超過了進入關閉狀態。如此往復。
之前，查了一些資料，網上所有的資料幾乎都是針對Hystrix的。這個只是針對分布式系統的接口請求，並不能運用於我們的系統中，因此這種情況下，根據原理自己實現了一個基本的分布式熔斷器，數值與計數器存放在redis中，因為redis的操作客戶端不一樣，我就以本地熔斷器為例，講解熔斷器實現。
希望我的文章能對於理解熔斷器，以及需要熔斷器的人有所幫助。
簡單的本地熔斷器實現
一個基本的本地熔斷器。
image.png
對外暴露接口
熔斷器對外暴露接口
熔斷器狀態對外暴露接口
三種狀態
關閉狀態實現：
打開狀態
半開狀態
熔斷器
抽象熔斷器
本地熔斷器
測試例子
結果
線上防雪崩利器——熔斷器設計原理與實現