作為軟件開發人員，我們的生活是快節奏的，我們采用的是敏捷軟件開發方法，迭代式的開發我們軟件功能，開發完成提交測試，通過了QA的測試后被部署到生產環境，然后可怕的事情在生產環境里發生了，生產環境的壓力超過了我們的設計值，也就是說過載了，這種情況經常發生在調用遠程服務，因為沒有做過載保護，導致請求的資源阻塞在服務器上等待從而耗盡系統或者服務器資源，很多時候剛開始的時候只是系統出現了局部的，小規模的故障，然而由于種種原因，故障的范圍越來越大，最終導致了全局性的后果，墨菲定律在軟件里面特別靈驗。俗話說就是"任何會出錯的，一定會出錯"，我們如何來解決這個問題呢，這就有一個設計模式叫做熔斷器，可以用來解決過載保護問題。
我們在日常生活中有一種經常會碰到的現象，如果家里用電負載過大，比如開了很多家用電器，就會"自動跳閘"，此時電路就會斷開。在以前更古老的一種方式是"保險絲"，當負載過大，或者電路發生故障或異常時，電流會不斷升高，為防止升高的電流有可能損壞電路中的某些重要器件或貴重器件，燒毀電路甚至造成火災。保險絲會在電流異常升高到一定的高度和熱度的時候，自身熔斷切斷電流，從而起到保護電路安全運行的作用。這個自動跳閘的裝置就是電路熔斷器，通常是用電磁鐵切斷電路而不是燃燒掉，熔斷器可以重復使用。我們在軟件中模仿電路熔斷器的組件模式就是CircuitBreaker。
在大型的分布式系統中，通常需要調用或操作遠程的服務或者資源，這些遠程的服務或者資源由于調用者不可以控的原因比如網絡連接緩慢，資源被占用或者暫時不可用等原因，導致對這些遠程資源的調用失敗。這些錯誤通常在稍后的一段時間內可以恢復正常。但是，在某些情況下，由于一些無法預知的原因導致結果很難預料，遠程的方法或者資源可能需要很長的一段時間才能修復。這種錯誤嚴重到系統的部分失去響應甚至導致整個服務的完全不可用。在這種情況下，采用不斷地重試可能解決不了問題，相反，應用程序在這個時候應該立即返回并且報告錯誤。
通常，如果一個服務器非常繁忙，那么系統中的部分失敗可能會導致 "連鎖失效"（cascading failure）。比如，某個操作可能會調用云端的服務，這個service會設置一個超時的時間，如果響應時間超過了該時間就會拋出一個異常。但是這種策略會導致并發的請求調用同樣的操作會阻塞，一直等到超時時間的到期。這種對請求的阻塞可能會占用寶貴的系統資源，如內存，線程，數據庫連接等等，最后這些資源就會消耗殆盡，使得其他系統不相關的部分所使用的資源也耗盡從而拖累整個系統。在這種情況下，操作立即返回錯誤而不是等待超時的發生可能是一種更好的選擇。只有當調用服務有可能成功時我們再去嘗試。
熔斷器設計模式
馬丁大叔總結的熔斷器模式http://martinfowler.com/bliki/CircuitBreaker.html ，熔斷器模式可以防止應用程序不斷地嘗試執行可能會失敗的操作，使得應用程序繼續執行而不用等待修正錯誤，或者浪費CPU時間去等到長時間的超時產生。熔斷器模式也可以使應用程序能夠診斷錯誤是否已經修正，如果已經修正，應用程序會再次嘗試調用操作。
熔斷器模式就像是那些容易導致錯誤的操作的一種代理。這種代理能夠記錄最近調用發生錯誤的次數，然后決定使用允許操作繼續，或者立即返回錯誤。
熔斷器可以使用狀態機來實現，內部模擬以下幾種狀態。
- 閉合（closed）狀態： 對應用程序的請求能夠直接引起方法的調用。代理類維護了最近調用失敗的次數，如果某次調用失敗，則使失敗次數加1。如果最近失敗次數超過了在給定時間內允許失敗的閾值，則代理類切換到斷開(Open)狀態。此時代理開啟了一個超時時鐘，當該時鐘超過了該時間，則切換到半斷開（Half-Open）狀態。該超時時間的設定是給了系統一次機會來修正導致調用失敗的錯誤。
- 斷開(Open)狀態：在該狀態下，對應用程序的請求會立即返回錯誤響應。
- 半斷開（Half-Open）狀態：允許對應用程序的一定數量的請求可以去調用服務。如果這些請求對服務的調用成功，那么可以認為之前導致調用失敗的錯誤已經修正，此時熔斷器切換到閉合狀態(并且將錯誤計數器重置)；如果這一定數量的請求有調用失敗的情況，則認為導致之前調用失敗的問題仍然存在，熔斷器切回到斷開方式，然后開始重置計時器來給系統一定的時間來修正錯誤。半斷開狀態能夠有效防止正在恢復中的服務被突然而來的大量請求再次拖垮。
各個狀態之間的轉換如下圖：
在Close狀態下，錯誤計數器是基于時間的。在特定的時間間隔內會自動重置。這能夠防止由于某次的偶然錯誤導致熔斷器進入斷開狀態。觸發熔斷器進入斷開狀態的失敗閾值只有在特定的時間間隔內，錯誤次數達到指定錯誤次數的閾值才會產生。在Half-Open狀態中使用的連續成功次數計數器記錄調用的成功次數。當連續調用成功次數達到某個指定值時，切換到閉合狀態，如果某次調用失敗，立即切換到斷開狀態，連續成功調用次數計時器在下次進入半斷開狀態時歸零。
實現熔斷器模式使得系統更加穩定和有彈性，在系統從錯誤中恢復的時候提供穩定性，并且減少了錯誤對系統性能的影響。它通過快速的拒絕那些試圖有可能調用會導致錯誤的服務，而不會去等待操作超時或者永遠不會不返回結果來提高系統的響應事件。如果熔斷器設計模式在每次狀態切換的時候會發出一個事件，這種信息可以用來監控服務的運行狀態，能夠通知管理員在熔斷器切換到斷開狀態時進行處理。
可以對熔斷器模式進行定制以適應一些可能會導致遠程服務失敗的特定場景。比如，可以在熔斷器中對超時時間使用不斷增長的策略。在熔斷器開始進入斷開狀態的時候，可以設置超時時間為幾秒鐘，然后如果錯誤沒有被解決，然后將該超時時間設置為幾分鐘，依次類推。在一些情況下，在斷開狀態下我們可以返回一些錯誤的默認值，而不是拋出異常。
上述內容來自在MSDN的一篇文章Circuit Breaker Pattern。文章中列出了要考慮的因素：
在實現熔斷器模式的時候，以下這些因素可能需要考慮：
- 異常處理：調用受熔斷器保護的服務的時候，我們必須要處理當服務不可用時的異常情況。這些異常處理通常需要視具體的業務情況而定。比如，如果應用程序只是暫時的功能降級，可能需要切換到其它的可替換的服務上來執行相同的任務或者獲取相同的數據，或者給用戶報告錯誤然后提示他們稍后重試。
- 異常的類型：請求失敗的原因可能有很多種。一些原因可能會比其它原因更嚴重。比如，請求會失敗可能是由于遠程的服務崩潰，這可能需要花費數分鐘來恢復；也可能是由于服務器暫時負載過重導致超時。熔斷器應該能夠檢查錯誤的類型，從而根據具體的錯誤情況來調整策略。比如，可能需要很多次超時異常才可以斷定需要切換到斷開狀態，而只需要幾次錯誤提示就可以判斷服務不可用而快速切換到斷開狀態。
- 日志：熔斷器應該能夠記錄所有失敗的請求，以及一些可能會嘗試成功的請求，使得的管理員能夠監控使用熔斷器保護的服務的執行情況。
- 測試服務是否可用：在斷開狀態下，熔斷器可以采用定期的ping遠程的服務或者資源，來判斷是否服務是否恢復，而不是使用計時器來自動切換到半斷開狀態。這種ping操作可以模擬之前那些失敗的請求，或者可以使用通過調用遠程服務提供的檢查服務是否可用的方法來判斷。
- 手動重置：在系統中對于失敗操作的恢復時間是很難確定的，提供一個手動重置功能能夠使得管理員可以手動的強制將熔斷器切換到閉合狀態。同樣的，如果受熔斷器保護的服務暫時不可用的話，管理員能夠強制的將熔斷器設置為斷開狀態。
- 并發問題：相同的熔斷器有可能被大量并發請求同時訪問。熔斷器的實現不應該阻塞并發的請求或者增加每次請求調用的負擔。
- 資源的差異性：使用單個熔斷器時，一個資源如果有分布在多個地方就需要小心。比如，一個數據可能存儲在多個磁盤分區上(shard)，某個分區可以正常訪問，而另一個可能存在暫時性的問題。在這種情況下，不同的錯誤響應如果混為一談，那么應用程序訪問的這些存在問題的分區的失敗的可能性就會高，而那些被認為是正常的分區，就有可能被阻塞。
- 加快熔斷器的熔斷操作:有時候，服務返回的錯誤信息足夠讓熔斷器立即執行熔斷操作并且保持一段時間。比如，如果從一個分布式資源返回的響應提示負載超重，那么可以斷定出不建議立即重試，而是應該等待幾分鐘后再重試。（HTTP協議定義了"HTTP 503 Service Unavailable"來表示請求的服務當前不可用，他可以包含其他信息比如，超時等）
- 重復失敗請求：當熔斷器在斷開狀態的時候，熔斷器可以記錄每一次請求的細節，而不是僅僅返回失敗信息，這樣當遠程服務恢復的時候，可以將這些失敗的請求再重新請求一次。
熔斷器使用場景
應該使用該模式來：
- 防止應用程序直接調用那些很可能會調用失敗的遠程服務或共享資源。
不適合的場景
- 對于應用程序中的直接訪問本地私有資源，比如內存中的數據結構，如果使用熔斷器模式只會增加系統額外開銷。
- 不適合作為應用程序中業務邏輯的異常處理替代品
有很多類庫都實現了熔斷器設計模式，這里我們介紹一個叫做Polly的項目。它是一個非常整潔的包，為我們提供很多種熔斷器。它涵蓋了大多數的異常處理像重試，重試并等待的策略，Polly使用起來也非常簡單，下面是Polly的使用方法：
// Break the circuit after the specified number of exceptions
// and keep circuit broken for the specified duration
var policy = Policy
.Handle<DivideByZeroException>()
.CircuitBreaker(2, TimeSpan.FromMinutes(1));
var result = poilcy.Execute(() => DoSomething());
如果DoSomething() 引發了DivideByZeroException 2次熔斷器斷開一分鐘。使用起來非常的簡單吧，更詳細的請參看文章 《Circuit Breaking With Polly》http://blog.jaywayco.co.uk/circuit-breaking-with-polly/ ，微軟已經在一些核心組件里考慮了重試，有一個例子就是EF 6可以非常方便的實現重試策略，具體可以參看文章《Entity Framework Connection Resiliency and Polly》http://blog.jaywayco.co.uk/entity-framework-connection-resiliency/ 。
在應用系統中，我們通常會去調用遠程的服務或者資源(這些服務或資源通常是來自第三方)，對這些遠程服務或者資源的調用通常會導致失敗，或者掛起沒有響應，直到超時的產生。在一些極端情況下，大量的請求會阻塞在對這些異常的遠程服務的調用上，會導致一些關鍵性的系統資源耗盡，從而導致級聯的失敗，從而拖垮整個系統。熔斷器模式在內部采用狀態機的形式，使得對這些可能會導致請求失敗的遠程服務進行了包裝，當遠程服務發生異常時，可以立即對進來的請求返回錯誤響應，并告知系統管理員，將錯誤控制在局部范圍內，從而提高系統的穩定性和可靠性。
文章列表
留言列表
