你想像的斷路器

生活中的circuit breaker常見配電箱與機械設備之中，當電路的電流負載過高的時候會自動斷路，避免因為過高的電流造成電路或是設備的損害。當斷路器經常跳電的時候就會需要專業人員去檢查電路與設備是否老舊或出現問題。

微服務的斷路器

微服務也有軟體上的circuit breaker設計，內建類似錯誤處理機制，避免單一服務崩潰，造成整體服務連鎖崩壞，同時可以利用retry機制自動處理暫時性的故障，例如短時間的網路不穩，速度過慢，但對於長時間或是無法自行回復的故障持續的retry是沒有意義的，只會佔據有限的系統資源，所以也需要有機制可以立即回應這個服務無法使用，讓API gateway或是上層的服務可以連線到其他正常運作的服務。

在斷路器(circuit breaker)概念中會有三種狀態的切換
-全開路(open): 服務處於無法正常運作的狀態，所有request都會立即丟出exception或是調用預先設定的fallback方法
-全閉路(closed): 服務處於可以運作的狀態，同時封裝一些容錯的機制例如retry跟判斷服務是否故障的邏輯(Threshold閥值: 像是retry次數)在這個狀態之中
-半開路(half-open): 服務處於可以小部份正常運作的狀態，主要的目的是監測服務是否從暫時的故障或問題中復原

(https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker)
中間的狀態切換流程大概如下:
closed-->retry的錯誤次數到達判斷服務故障的threshold-->
open-->收到request會回應exception或是調用fallback的指定method，同時啟動等待暫時性故障排除的計時器-->計時器時間到-->
half-open-->
服務開始處理小量的request，並以處理request的連續成功次數作為判斷故障恢復的閥值，萬一到達成功閥值前又出現故障-->
open-->再次啟動一個等待暫時性故障排除的計時器-->計時器時間到-->
half-open-->服務開始處理小量的request，成功到達故障恢復的閥值-->
closed-->服務正常運作

其他一些實作變化像是在斷路器裡面也可以整合log來做服務的監測應用cache來做fallback，
另外在.Net裡面實作circuit breaker會是多執行緒，thread-safe也會是自行實作時候需要重點考慮的部分。

整合斷路器設計於微服務增加強健度，同時也增加了微服務本身的獨立性，集合自我錯誤監測與處理於一身。
這篇稍微介紹一下斷路器原理，後面實作時計畫使用Netflix的Hystrix。