我是獸獸，從事雲計算的健身萌妹紙，不定期更新5G&IoT內容，更多好貨可關注公號：5G物聯網世界。

除了超時和回退之外，斷路也是一種有用的微服務模式。當整個系統或其中的給定服務處於壓力之下時，這一切都是關於快速失敗和提供一種自動處理功能的方法。想象一個斷路器。當一切正常時，斷路器關閉，車流正常;然而，當事情發生故障時，斷路器打開，交通被分流。現在想象一下在您的微服務體系結構中實現的概念。

這是關於微服務模式的系列文章的第三部分。第1部分討論了事件處理如何通過使用消息隊列來解耦微服務。第2部分探索了幫助您處理服務集群轉移的服務發現工具。在深入研究斷路微服務模式(本系列最後一篇文章(目前)的主題)之前，讓我們先研究幾個模式，它們將幫助我們更好地理解斷路模式。

微服務模式:超時

在與其他服務或數據存儲進行通信時，超時是一種非常有用的模式。其思想是為服務的響應時間設置一個限制。如果在允許的時間內沒有收到響應，則可以求助於編寫的用於處理此故障的業務邏輯，例如重試或將故障消息發送回上游服務。超時可能是檢測下游服務故障的唯一方法。然而，服務沒有回覆並不意味著服務沒有接收和處理消息，或者它不存在。超時的關鍵特性是快速失敗，並將此失敗通知調用者。

這是一種很好的做法，原因有很多，不僅僅是從儘早返回客戶端和不讓他們無限期等待的角度來看。從負載和容量的角度來看，這也很有幫助。超時在大型分佈式系統中是一個有效的衛生因素，在大型分佈式系統中，一個服務的許多小實例通常是集群的，以實現高吞吐量和冗餘。如果這些實例中的一個發生故障，而您連接到它，這可能會阻塞整個功能性服務。正確的方法是等待給定時間的響應;如果在此期間沒有響應，則取消調用並嘗試列表中的下一個服務。對於應該將超時設置為多長時間這個問題，沒有簡單的答案。我們還需要考慮網絡請求中可能出現的不同類型的超時。您可能會有以下超時:

• 連接超時——打開到服務器的網絡連接所需的時間。
• 請求超時——服務器處理請求所需的時間。

請求超時幾乎總是這兩種超時中持續時間最長的。我建議在服務的配置中定義超時。雖然您最初可能將其設置為任意值，比如10秒，但是您可以在系統在生產環境中運行之後以及在您有足夠的事務時間數據集要查看之後修改它。

微服務模式:回退

通常，一旦連接失敗，您不希望立即重試，以避免請求充斥網絡或服務器。為了實現這一點，有必要在重試策略中實現回退方法。在第一次失敗後重試之前，backoff算法將等待一段設置的時間。這將隨著後續故障的增加而增加，直到設置的最大持續時間。

在客戶端調用的API中使用這種策略可能不可取，因為它違背了快速失敗的要求。但是，如果我們有一個只處理消息隊列的worker進程，那麼這可能正是為系統添加一點保護的正確策略。

微服務模式:斷路

我們已經瞭解了一些模式，如超時和回退，它們有助於保護系統在停機時避免級聯故障。然而，現在是時候引入另一種模式來補充這兩種模式了。斷路就是快速地失敗。這是一種在系統處於壓力下自動降級功能的方法。

讓我們考慮一個前端web應用程序的示例，該應用程序依賴於下游服務來為用戶可用的服務提供建議。由於此調用與主頁加載同步，所以web服務器在成功返回建議之前不會返回數據。現在您已經為失敗進行了設計，併為這個調用引入了5秒的超時。然而，由於推薦系統存在問題，一個通常需要20毫秒的調用現在需要5000毫秒才能失敗。

每個查看服務的用戶等待的時間都比平常長5秒;您的應用程序處理請求和釋放資源的速度沒有正常情況下快，並且它的容量顯著降低。此外，由於處理單個頁面請求所需的時間較長，到主網站的併發連接數量也有所增加。這就給前端增加了負載，而前端的速度開始變慢。如果推薦服務沒有開始響應，那麼整個站點將面臨停機。

有一個簡單的解決方案:停止嘗試調用推薦服務，讓網站恢復正常運行速度，並稍微降低服務頁面的功能。這有三個影響:

1. 將瀏覽體驗還原給站點上的其他用戶。
2. 稍微降低一個領域的經驗。
3. 直接影響系統的業務，這就是為什麼在實現電路中斷模式之前必須與涉眾進行對話的原因。

假設推薦增加了1%的轉化率;但是，緩慢的頁面加載會減少90%。降級1%而不是90%不是更好嗎?這個例子很簡單，但是如果下游服務是一個庫存檢查系統呢?如果有可能你沒有庫存來完成訂單，你應該接受嗎?

斷路是如何工作的?

在正常運行情況下，就像你的電開關盒裡的斷路器一樣，斷路器是關閉的，車流正常。然而，一旦超過預定的錯誤閾值，斷路器就進入打開狀態，所有請求立即失敗，甚至沒有嘗試。一段時間後，進一步的請求將被允許，電路進入半開放狀態。在這種狀態下，無論錯誤閾值是多少，失敗都會立即返回到open狀態。一旦一些請求被處理沒有任何錯誤，電路再次返回到關閉狀態，只有當失敗的數量超過錯誤閾值，電路才會再次打開。

錯誤行為不是軟件工程可以自己回答的問題;所有業務涉眾都需要參與這個決策。在計劃系統設計時，將失敗作為非功能性需求的一部分進行討論。提前決定當下游服務失敗時要做什麼。