年初在開發者對話（一月）的活動主題 Health Check（健康檢查） 延伸討論到熔斷（Circuit Breaker）機制，這次就來跟大家稍微聊一下這個功能。
我們在設計系統的時候大多不會馬上考慮到這個問題，然而當系統遭遇到「超出負荷」的情況時，使用熔斷處理就會是一個很不錯的方法。
熔斷的作用
熔斷這個詞基本上就是「保險絲熔斷」的意思，我們可以很直覺的將這個概念套用到網路服務中的「熔斷」概念，也就是所謂的「超出負荷停止服務」的機制。會延伸到這個問題，是因為有人認為當服務不正常時 Health Check 也該正常回應這樣的想法，然而如果 Health Check 還能回應正常，不就無法反應當下這個服務「超出負荷」的狀況了嗎？
也就是說，如果將 Health Check 視為「自我檢查」那麼熔斷就是其他人去檢查的機制，或者說一種「保險措施」
如何保護
我們以 Circuitbox 這個 Ruby Gem 為例子來看，當我們呼叫其他服務在一定時間內失敗超過一定次數時，會「暫停呼叫」並且在一段時間後重新測試。
這跟保險絲的原理也是類似的，我們假設每個服務都有他的「極限」存在，當我們失敗多次後表示呼叫的服務可能是超過極限的狀態。因此我們「暫停」或者「中斷」呼叫，直到後面的服務恢復到正常的狀態，有了這樣的機制，我們就可以避免在超出負荷的狀態下還繼續「增加負擔」
提升存活率
簡單來說，這是一種提升存活率的手段之一。即使我們什麼都不做，網站死掉連不上也是一種「熔斷」然而這個熔斷可能是「非常嚴重」的狀態。
除此之外，即使我們自己的系統是正常的。有沒有可能合作的廠商系統正處於高度負載的狀態？如果再繼續呼叫，那麼我們可能就會成為壓倒駱駝的最後一根稻草。
透過恰當的熔斷機制，我們至少可以確保所有服務至少能夠維持在「存活」的狀態下，至少會比整個中斷後的成本要低，就像電腦當機後恢復跟重開機，後者有可能是「重要檔案沒有存檔」的狀態，問題可能嚴重很多。
封面圖片使用 Unsplash 上 PhotSigmun 的作品，有想聽的主題可以透過匿名問卷告訴我，想了解專業的技術主題可以到弦而時習之找找靈感。
