作者 | 漫話編程
本文經授權轉載自漫話編程（ID：mhcoding）
最近比較忙，白天上班，晚上還得面試，都沒有時間關注新聞。某天晚上剛剛結束一個電話面試，正準備寫面試評價，女朋友拿著手機走過來，滿臉疑惑的問我：
在《如何給女朋友解釋為什麼雙十一無法修改收貨地址》中我們介紹過關於QPS、RT、併發用戶數以及最大線程數等知識。我們知道，如果一個軟件系統的併發請求數目超過了系統的最佳線程數，那麼就會導致激烈的資源競爭，隨著資源的匱乏甚至枯竭，整個系統也就面臨著災難。
所以，很多軟件系統為了保證即使在出現併發用戶數>最佳線程數時，也不至於導致整個萬網站崩潰，都會採用一些技術手段來避免發生系統性災難。這些技術中比較典型的就是限流、降級和熔斷。
這次就來講講什麼是服務熔斷，以及如何在微服務架構中做服務熔斷。
為什麼需要熔斷？
現在很多網站的背後都是一個龐大的《分佈式》系統，多個系統之間的交互大多數都是採用《RPC》的方式，但是因為是遠程調用，所以被調用者的服務的可用情況其實是不可控的。
而越是龐大的系統，上下游的調用鏈就會越長，而如果在一個很長的調用鏈中，某一個服務由於某種原因導致響應時間很長，或者完全無響應，那麼就可能把整個分佈式系統都拖垮。
以上調用鏈，如果其中某一個服務由於自身原因導致響應很慢，那麼就可能導致上游的服務影響也很慢，這樣循環往復，就會導致整個系統全線崩潰，這就是服務雪崩。
其實，在分佈式系統中，為了保證整體服務可用性和一致性，很多系統都會引入重試機制，在有些情況下，重試其實是可以解決問題的，比如網絡問題等，都可以通過重試來解決。
但是，有些情況下，重試並不能解決問題，返而會加劇問題的嚴重性，比如下游系統因為請求量太大，導致CPU已經被打滿，說著數據庫連接池被佔滿，這時候上游系統調不通就會不斷進行重試，這種重試請求，對於下游系統來說，無疑是雪上加霜，給下游系統造成二次傷害。
而分佈式系統，大多數的服務雪崩也都是因為不斷重試導致的，這種重試有可能是框架級別的自動重試、有可能是代碼級別的重試邏輯、還有可能是用戶的主動重試。
有些重試是無法避免的，而且如果因為防止雪崩，就不設計重試機制，也是一種因噎廢食。
熔斷器模式
熔斷器模式（Circuit Breaker Pattern），是一個現代軟件開發的設計模式。用以偵測錯誤，並避免不斷地觸發相同的錯誤（如維護時服務不可用、暫時性的系統問題或是未知的系統錯誤）。
假設有個應用程序每秒會與數據庫溝通數百次，此時數據庫突然發生了錯誤，程序員並不會希望在錯誤時還不斷地訪問數據庫。因此會想辦法直接處理這個錯誤，並進入正常的結束程序。簡單來說，
熔斷器會偵測錯誤並且“預防”應用程序不斷地重試調用一個近乎毫無回應的服務（除非該服務已經安全到可重試連線了）。
熔斷器模式是方誌微服務系統雪崩的一種重要手段。
一個比較完善的熔斷器，一般包含三種狀態：
- 關閉
- 熔斷器在默認情況下下是呈現關閉的狀態，而熔斷器本身帶有計數功能，每當錯誤發生一次，計數器也就會進行“累加”的動作，到了一定的錯誤發生次數斷路器就會被“開啟”，這個時候亦會在內部啟用一個計時器，一旦時間到了就會切換成半開啟的狀態。
- 開啟
- 在開啟的狀態下任何請求都會“直接”被拒絕並且拋出異常訊息。
- 半開啟
- 在此狀態下斷路器會允許部分的請求，如果這些請求都能成功通過，那麼就意味著錯誤已經不存在，則會被切換回關閉狀態並重置計數。倘若請求中有“任一”的錯誤發生，則會回覆到“開啟”狀態，並且重新計時，給予系統一段休息時間。
上圖是熔斷器的三種狀態的轉換情況。
如果在微服務系統的調用過程中，引入熔斷器，那麼整個系統將天然具備以下能力：
- 快速失敗：當因為調用遠程服務失敗次數過多，熔斷器開啟時，上游服務對於下游服務的調用就會快速失敗，這樣可以避免上游服務被拖垮。
- 無縫恢復：因為熔斷器可以定期檢查下游系統是否恢復，一旦恢復就可以重新回到關閉狀態，所有請求便可以正常請求到下游服務。使得系統不需要認為干預。
熔斷工具
熔斷器為了實現快速失敗和無縫恢復，就需要進行服務調用次數統計、服務調用切斷等操作，如果想要自己實現一個熔斷器其實也是可以的。
但是，市面上有一些框架已經幫我們做了這些事情。如Hystrix和Sentinel、resilience4j等。
Hystrix
Hystrix（https://github.com/Netflix/Hystrix ）是Netflix開源的一款容錯系統，能幫助使用者碼出具備強大的容錯能力和魯棒性的程序。提供降級，熔斷等功能。
但是，在2018年底，Hystrix在其GitHub主頁宣佈，不再開放新功能，推薦開發者使用其他仍然活躍的開源項目。
Hystrix雖然不再開發新功能 ，但對用戶的影響應該不會太大，一是因為開發者可以繼續使用Hystrix的最新版本1.5.18
resilience4j
Hystrix停更之後，Netflix官方推薦使用resilience4j（https://github.com/resilience4j/resilience4j ），它是一個輕量、易用、可組裝的高可用框架，支持熔斷、高頻控制、隔離、限流、限時、重試等多種高可用機制。
與Hystrix相比，它有以下一些主要的區別：
- Hystrix調用必須被封裝到HystrixCommand裡，而resilience4j以裝飾器的方式提供對函數式接口、lambda表達式等的嵌套裝飾，因此你可以用簡潔的方式組合多種高可用機制
- Hystrix的頻次統計採用滑動窗口的方式，而resilience4j採用環狀緩衝區的方式
- 關於熔斷器在半開狀態時的狀態轉換，Hystrix僅使用一次執行判定是否進行狀態轉換，而resilience4j則採用可配置的執行次數與閾值，來決定是否進行狀態轉換，這種方式提高了熔斷機制的穩定性
- 關於隔離機制，Hystrix提供基於線程池和信號量的隔離，而resilience4j只提供基於信號量的隔離
Sentinel
Sentinel（https://github.com/alibaba/Sentinel ）是阿里中間件團隊開源的，面向分佈式服務架構的輕量級高可用流量控制組件，主要以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度來幫助用戶保護服務的穩定性。
Hystrix 的關注點在於以隔離和熔斷為主的容錯機制，超時或被熔斷的調用將會快速失敗，並可以提供 fallback 機制。
而 Sentinel 的側重點在於：
- 多樣化的流量控制
- 熔斷降級
- 系統負載保護
- 實時監控和控制檯
下圖是Sentinel的GitHub主頁中關於Sentinel和Hystrix的對比：
擴展知識
熔斷機制：
指的是在股票市場的交易時間中，當價格波動的幅度達到某一個限定的目標（熔斷點）時，對其暫停交易一段時間的機制。此機制如同保險絲在電流過大時候熔斷比較相似，故而得名。
熔斷機制推出的目的是為了防範系統性風險，給市場更多的冷靜時間，避免恐慌情緒蔓延導致市場波動，從而防止大規模股價下跌現象的發生。然而熔斷機制也因切斷了資金的流通性，同樣會造成市場情緒加大，並令市場風險在熔斷期結束後繼續擴大。
美國熔斷機制：
美國指數熔斷機制的基準指數為標普500，單項跌幅閾值為7%、13%、20%。當指數較前一天收盤點位下跌7%、13%時，全美證券市場交易將暫停15分鐘，當指數較前一天收盤點位下跌20%時，當天交易停止。2010年美股又開始實行個股熔斷機制。
熔斷機制最早由美國的紐約股票交易所在1987年提出，以避免發生類似“黑色星期一”的股災。此時的熔斷機制僅針對大盤指數進行熔斷。1997年10月27日，道瓊斯工業指數暴跌7.18%，收於7161.15點，這是熔斷機制在1988年引入之後第一次被觸發。
美股第二次觸發熔斷機制是在美東時間2020年3月9日，受2019冠狀病毒病疫情和油價崩盤影響，3月9日上午9點34分，標普500指數開盤後跌7%觸發第一層熔斷機制，暫停交易15分鐘。3天后，3月12日，標普500指數開盤後短時間內跌幅超過7%再次觸發第一層熔斷機制。
中國大陸熔斷機制：
中華人民共和國自2016年起開始在上海證券交易所、深圳證券交易所和中國金融期貨交易所同時試行熔斷機制。其熔斷的基準指數是滬深300指數，設置5%、7%兩檔指數熔斷閾值，漲跌皆熔斷。
作者簡介：漫話編程，是一個通過漫畫+音頻的形式講解枯燥的編程知識的公眾號。致力於讓編程變得更有樂趣。
閱讀更多 CSDN程序人生 的文章
