筆者在工作中，主要維護所在bg的營銷活動的列表，活動的列表像商詳頁或團詳頁一樣需要聚合大量服務提供的數據，而且作為後兩者的入口，活動列表出不得任何閃失，否則結局必是災難性的。每一次的大促活動能否平安度過，取決于平日準備時對這些下遊服務更好地把控。熔斷降級作為最基本和有效的手段，保證了服務的柔性可用，提高系統整體的可用性與穩定性。接下來就談談熔斷和降級。

先簡單一句話概括，降級就是在調用的下遊服務A出現問題（常見超時），提供PLAN-B，返回的效果可能沒有服務A好，但是聊勝于無。而熔斷器的存在就是要保障何時走到降級方法，何時恢複，以什麼樣的策略恢複。

接下來，我想舉個例子，詳細說明熔斷降級的作用和必要性。

就用我們公司最有意思的神秘民間組織，美團外賣舉例。

如上圖，我們公司在該地區一共有4個外賣小哥，編号0-3；該地有6家流行餐廳，幾乎是用戶必點。編号從A-F。故事開始前，我們做如下假定：

（1）外賣火爆，幾乎外賣小哥每次在外都能接到不止一單，且是不同的餐廳；

（2）外賣小哥都是耿直的人，不取完本次接單的幾家餐廳，不輕易送餐。

一切看起來很和諧，直到有一天，餐廳A出事了，主廚的大叔失戀了，出餐的速度大降。每個要去餐廳A取餐的小哥都要花費更長的時間在A等餐。而且餐廳A越流行，出餐速度越慢，排隊等待的小哥就會越多。在上圖中，最後4個外賣小哥，有3個都排隊在等A餐廳的飯食。這有兩點直接影響：

（1）不光是A，其他餐廳單子也還沒有配送，用戶吃不到A的飯，就連其他用戶點的B、C、D的飯也不能配送，差評，卸載，美團一生黑；

（2）3/4的外賣小哥處于低效率地排隊等待，而不是送餐，降低了整個公司在該地區的配送效率，老王坐不住了。

然而，正如江湖傳言，美團外賣是個神秘的組織，有一天，一個機智的小哥，橫空出世，改變了整個行業的布局。

小哥在餐廳A親自操刀，很快就做完後，送餐了。用戶收到熱乎乎的飯菜，吃起來沒有以前的好吃，但也覺察不出任何異樣，不會投訴；整個地區的小哥又重新流通起來，恢複到大叔失戀前的配送效率。

後來，在公司的内部總結中。發現不光是A餐廳的大叔會失戀，C餐廳D餐廳的大叔們也偶爾失戀，影響出餐速度。後來公司和這些餐廳們商量，為更好的規範化出餐流程，各餐廳新添加二叔，二叔廚藝一般，請二叔各餐廳花費成本不高，所以紛紛表示贊同。

在實踐的過程中，小哥和大叔二叔們約定，如果在規定時間和次數，大叔不能按時出餐，那麼二叔替代大叔，接相同的單，用同樣的鍋；大叔的出餐速度會被定期檢查，是否恢複了正常水平，恢複了之後，單子慢慢還由大叔下廚。

現在，我們來對應下關系。

美團外賣大本營——容器，常見的如tomcat，jetty的線程池

外賣小哥——線程

餐廳——服務接口

二叔——降級方法

大叔到二叔的切換——熔斷

恢複大叔下廚——熔斷降級的恢複策略。

熔斷保證了下遊服務在出錯率達到阈值時，上遊調用切換到降級方法，提供有損服務，避免服務的級聯失敗，影響整個系統的穩定性。熔斷的時機，取決于業務的實際場景和流量大小，不要過高，也不要過低；恢複的策略，其核心是恢複的速率，不要過快也不要過慢。一句廢話，看需求。

在公司，我們有自己的故障演練分析防護的平台，由于沒開源，不便過多閑話。在開源社區，也有很多相應的産品，比較推薦的，也是目前使用較為廣泛的是NetFlix的Hystrix，Hystrix是個完善的容錯庫，實現了熔斷降級、線程隔離、限流等多種功能，開箱即用，有需要的朋友速速入手吧。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!