微服務分佈式系統熔斷實戰-爲什麼咱們須要API級別熔斷？

熔斷在分佈式系統的做用已經被強調過不少次了

能夠經過這篇文章來了解價值,Netflix在本身的分佈式系統中應用熔斷技術來保護系統

blog.51cto.com/developeryc…

內部的實現機制能夠參考

martinfowler.com/bliki/Circu…

本篇文章將介紹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級別熔斷幫助開發者快速隔離問題服務。

熔斷的手段有超時實踐，併發數，錯誤率等。它強制性的保護起每一次遠程調用，無需開發者本身編寫代碼處理超時，死鎖，網絡錯誤等問題，解放了開發者，讓他們更多的去關注業務代碼而不是分佈式系統帶來的複雜性

項目資料

go chassis開發框架：https://github.com/go-chassis/go-chassis

熔斷文檔：https://go-chassis.readthedocs.io/en/latest/user-guides/cb-and-fallback.html

go chassis系列文章： 

https://juejin.im/post/5ba34495e51d450e9e440d1f

https://juejin.im/post/5ba460556fb9a05d2469bb81