本篇文章將介紹go chassis如何通過熔斷機制，隔離上游服務，保護下游服務。
Go chassis如何保證上游錯誤不影響下游系統
go chassis引用幷包裝了https://github.com/afex/hystrix-go帶來了熔斷和降級功能。
當運行時內部處理中的協程達到一定閾值，錯誤率達到一定閾值，或者超時達到一定閾值時，就會觸發熔斷，用戶可按需定製調教熔斷器配置項設定這些參數。
hystrix-go內部的熔斷邏輯
go chassis使用統一的invocation抽象來代表每一次遠程調用，hystrix-go使用command抽象來封裝任何一個執行片段，invocation會被強制封裝到command中，並在一個circuit中執行。
每個Circuit都是唯一的Name，並且有一個Ticket桶，用來存放ticket，一開始它是關閉狀態，即一切運轉正常
調用將被強制性的包裝進入circuit獨立協程池中，並領取一個ticket。
command最終只有2種狀態，超時，或者完成。每當達到這兩個狀態就會歸還ticket
在這裏可以看到ticket機制其實跟限流中的令牌桶算法很像。
當超時或者拿不到ticket時就會被記爲一次錯誤，當錯誤達到一定閾值，circuit就會打開，拒絕發送網絡請求
服務級別隔離
每個service內部會有多個circuit，每個circuit對應一個上游微服務。當service3出現問題時(如死鎖，或是併發量太大)，將物理進行隔絕，即不再發送任何請求，以保證系統健康，service1依然可以正常和2,4交互，保證大部分業務正常。
這麼來看還是很理想的，serivce3的錯誤調用不至於拖垮service1(如果死鎖了，很容易就拖垮service1，導致這個由四個服務組成的系統癱瘓)，但真的如此麼，讓我們看看層級複雜些的系統。
爲何服務級別隔離還不夠?
每個服務都是基於go chassis開發的
假設api2需要調用service4完成，api1調用3完成，api3調用5完成
service4內的死鎖導致api2失敗了，最終觸發熔斷。service1將整個service2全部隔離了，導致一個小小的死鎖，引發了系統快速失敗。
看上去熔斷在這裏反而起到了壞的效果，那讓我們看看沒熔斷會發生什麼
不加入熔斷
這時就看哪個客戶端做了超時處理了，因爲死鎖的存在，會導致整條調用鏈路掛死，最終導致客戶端端口耗盡後，進而快速失敗
現在來看，死鎖在一個不健壯的系統中是一定會拖垮整個分佈式系統的，無解
有熔斷和沒熔斷效果都一樣，最終都是快速失敗。那麼如何解決
API級別熔斷
每個circuit只負責一個API的執行，監控，隔離
當service2調用service4時，單獨的接口進入到隔離狀態而不影響其他API調用。
總結
通過這篇文章我們知道了服務級別的錯誤隔離是不夠的，結構不復雜的系統尚可接受，但是複雜後不能因爲一個API的錯誤而隔離整個服務，而是細粒度的進行隔離。go chassis提供了API級別熔斷幫助開發者快速隔離問題服務。
熔斷的手段有超時實踐，併發數，錯誤率等。它強制性的保護起每一次遠程調用，無需開發者自己編寫代碼處理超時，死鎖，網絡錯誤等問題，解放了開發者，讓他們更多的去關注業務代碼而不是分佈式系統帶來的複雜性