1. 程式人生 > >微服務分散式系統熔斷實戰-為何我們需要API級別熔斷?

微服務分散式系統熔斷實戰-為何我們需要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