[[430448]]

在分布式系統(tǒng)中，如果某個服務(wù)節(jié)點(diǎn)發(fā)生故障或者網(wǎng)絡(luò)發(fā)生異常，都有可能導(dǎo)致調(diào)用方被阻塞等待，如果超時時間設(shè)置很長，調(diào)用方資源很可能被耗盡。這又導(dǎo)致了調(diào)用方的上游系統(tǒng)發(fā)生資源耗盡的情況，最終導(dǎo)致系統(tǒng)雪崩。

如下圖：

如果 D 服務(wù)發(fā)生了故障不能響應(yīng)， B 服務(wù)調(diào)用 D 時只能阻塞等待。假如 B 服務(wù)調(diào)用 D 服務(wù)設(shè)置超時時間是 10 秒，請求速率是每秒 100 個，那 10 秒內(nèi)就會有 1000 個請求線程被阻塞等待，如果 B 的線程池大小設(shè)置 1000 ，那 B 系統(tǒng)因?yàn)榫€程資源耗盡已經(jīng)不能對外提供服務(wù)了。而這又影響了入口系統(tǒng) A 的服務(wù)，最終導(dǎo)致系統(tǒng)全面崩潰。

提高系統(tǒng)的整體容錯能力是防止系統(tǒng)雪崩的有效手段。

在 Martin Fowler 和 James Lewis 的文章 《Microservices: a definition of this new architectural term》 ^[1] 中，提出了微服務(wù)的 9 個特征，其中一個是容錯設(shè)計。

要防止系統(tǒng)發(fā)生雪崩，就必須要有容錯設(shè)計。如果遇到突增流量，一般的做法是對非核心業(yè)務(wù)功能采用熔斷和服務(wù)降級的措施來保護(hù)核心業(yè)務(wù)功能正常服務(wù)，而對于核心功能服務(wù)，則需要采用限流的措施。

今天我們來聊一聊系統(tǒng)容錯中的限流、熔斷和服務(wù)降級。

當(dāng)系統(tǒng)的處理能力不能應(yīng)對外部請求的突增流量時，為了不讓系統(tǒng)奔潰，必須采取限流的措施。

1.1 限流指標(biāo)

1.1.1 TPS

系統(tǒng)吞吐量是衡量系統(tǒng)性能的關(guān)鍵指標(biāo)，按照事務(wù)的完成數(shù)量來限流是最合理的。

但是對實(shí)操性來說，按照事務(wù)來限流并不現(xiàn)實(shí)。在分布式系統(tǒng)中完成一筆事務(wù)需要多個系統(tǒng)的配合。比如我們在電商系統(tǒng)購物，需要訂單、庫存、賬戶、支付等多個服務(wù)配合完成，有的服務(wù)需要異步返回，這樣完成一筆事務(wù)花費(fèi)的時間可能會很長。如果按照 TPS 來進(jìn)行限流，時間粒度可能會很大大，很難準(zhǔn)確評估系統(tǒng)的響應(yīng)性能。

1.1.2 HPS

每秒請求數(shù)，指每秒鐘服務(wù)端收到客戶端的請求數(shù)量。

1.1.3 QPS

服務(wù)端每秒能夠響應(yīng)的客戶端查詢請求數(shù)量。

1.2 限流方法

1.2.1 流量計數(shù)器

這是最簡單直接的方法，比如限制每秒請求數(shù)量 100 ，超過 100 的請求就拒絕掉。

但是這個方法存在 2 個明顯的問題：

• 單位時間(比如 1s )很難把控，如下圖：

這張圖上，從下面時間看， HPS 沒有超過 100 ，但是從上面看 HPS 超過 100 了。

• 有一段時間流量超了，也不一定真的需要限流，如下圖，系統(tǒng) HPS 限制 50 ，雖然前 3s 流量超了，但是如果讀超時時間設(shè)置為 5s ，并不需要限流。

1.2.2 滑動時間窗口

滑動時間窗口算法是目前比較流行的限流算法，主要思想是把時間看做是一個向前滾動的窗口，如下圖：

開始的時候，我們把 t1~t5 看做一個時間窗口，每個窗口 1s ，如果我們定的限流目標(biāo)是每秒 50 個請求，那 t1~t5 這個窗口的請求總和不能超過 250 個。

這個窗口是滑動的，下一秒的窗口成了 t2~t6 ，這時把 t1 時間片的統(tǒng)計拋棄，加入 t6 時間片進(jìn)行統(tǒng)計。這段時間內(nèi)的請求數(shù)量也不能超過 250 個。

滑動時間窗口的優(yōu)點(diǎn)是解決了流量計數(shù)器算法的缺陷，但是也有 2 個問題：

• 流量超過就必須拋棄或者走降級邏輯

• 對流量控制不夠精細(xì)，不能限制集中在短時間內(nèi)的流量，也不能削峰填谷

1.2.3 漏桶算法

漏桶算法的思想如下圖：

在客戶端的請求發(fā)送到服務(wù)器之前，先用漏桶緩存起來，這個漏桶可以是一個長度固定的隊(duì)列，這個隊(duì)列中的請求均勻的發(fā)送到服務(wù)端。

如果客戶端的請求速率太快，漏桶的隊(duì)列滿了，就會被拒絕掉，或者走降級處理邏輯。這樣服務(wù)端就不會受到突發(fā)流量的沖擊。

漏桶算法的優(yōu)點(diǎn)是實(shí)現(xiàn)簡單，可以使用消息隊(duì)列來削峰填谷。

但是也有 3 個問題需要考慮:

• 漏桶的大小，如果太大，可能給服務(wù)端帶來較大處理壓力，太小可能會有大量請求被丟棄。

• 漏桶給服務(wù)端的請求發(fā)送速率。

• 使用緩存請求的方式，會使請求響應(yīng)時間變長。

1.2.4 令牌桶算法

令牌桶算法就跟病人去醫(yī)院看病一樣，找醫(yī)生之前需要先掛號，而醫(yī)院每天放的號是有限的。當(dāng)天的號用完了，第二天又會放一批號。

算法的基本思想就是周期性的執(zhí)行下面的流程：

客戶端在發(fā)送請求時，都需要先從令牌桶中獲取令牌，如果取到了，就可以把請求發(fā)送給服務(wù)端，取不到令牌，就只能被拒絕或者走服務(wù)降級的邏輯。如下圖：

1.2.5 分布式限流

如果在分布式系統(tǒng)場景下，上面介紹的 4 種限流算法是否還適用呢？

以令牌桶算法為例，假如在電商系統(tǒng)中客戶下了一筆訂單，如下圖：

如果我們把令牌桶單獨(dú)保存在一個地方(比如 redis 中)供整個分布式系統(tǒng)用，那客戶端在調(diào)用組合服務(wù)，組合服務(wù)調(diào)用訂單、庫存和賬戶服務(wù)都需要跟令牌桶交互，交互次數(shù)明顯增加了很多。

有一種改進(jìn)就是客戶端調(diào)用組合服務(wù)之前首先獲取四個令牌，調(diào)用組合服務(wù)時減去一個令牌并且傳遞給組合服務(wù)三個令牌，組合服務(wù)調(diào)用下面三個服務(wù)時依次消耗一個令牌。

1.2.6 hystrix限流

hystrix可以使用信號量和線程池來進(jìn)行限流。

1.2.6.1 信號量限流

hystrix 可以使用信號量進(jìn)行限流，比如在提供服務(wù)的方法上加下面的注解。這樣只能有20個并發(fā)線程來訪問這個方法，超過的就被轉(zhuǎn)到了errMethod這個降級方法。

@HystrixCommand( 
 commandProperties= { 
   @HystrixProperty(name="execution.isolation.strategy", value="SEMAPHORE"), 
   @HystrixProperty(name="execution.isolation.semaphore.maxConcurrentRequests", value="20") 
 }, 
 fallbackMethod = "errMethod" 
) 

1.2.6.2 線程池限流

hystrix 也可以使用線程池進(jìn)行限流，在提供服務(wù)的方法上加下面的注解，當(dāng)線程數(shù)量

@HystrixCommand( 
    commandProperties = { 
            @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD") 
    }, 
    threadPoolKey = "createOrderThreadPool", 
    threadPoolProperties = { 
            @HystrixProperty(name = "coreSize", value = "20"), 
   @HystrixProperty(name = "maxQueueSize", value = "100"), 
            @HystrixProperty(name = "maximumSize", value = "30"), 
            @HystrixProperty(name = "queueSizeRejectionThreshold", value = "120") 
    }, 
    fallbackMethod = "errMethod" 
) 

相信大家對斷路器并不陌生，它就相當(dāng)于一個開關(guān)，打開后可以阻止流量通過。比如保險絲，當(dāng)電流過大時，就會熔斷，從而避免元器件損壞。

服務(wù)熔斷是指調(diào)用方訪問服務(wù)時通過斷路器做代理進(jìn)行訪問，斷路器會持續(xù)觀察服務(wù)返回的成功、失敗的狀態(tài)，當(dāng)失敗超過設(shè)置的閾值時斷路器打開，請求就不能真正地訪問到服務(wù)了。

為了更好地理解，我畫了下面的時序圖：

2.1 斷路器的狀態(tài)

斷路器有 3 種狀態(tài)：

• CLOSED ：默認(rèn)狀態(tài)。斷路器觀察到請求失敗比例沒有達(dá)到閾值，斷路器認(rèn)為被代理服務(wù)狀態(tài)良好。
• OPEN ：斷路器觀察到請求失敗比例已經(jīng)達(dá)到閾值，斷路器認(rèn)為被代理服務(wù)故障，打開開關(guān)，請求不再到達(dá)被代理的服務(wù)，而是快速失敗。
•  

HALF OPEN 
CLOSED 
OPEN 

斷路器的狀態(tài)切換圖如下：

2.2 需要考慮的問題

使用斷路器需要考慮一些問題：

• 針對不同的異常，定義不同的熔斷后處理邏輯。

• 設(shè)置熔斷的時長，超過這個時長后切換到 HALF OPEN 進(jìn)行重試。

• 記錄請求失敗日志，供監(jiān)控使用。

•  

connection timeout 
telenet 
HALF OPEN 

• 補(bǔ)償接口，斷路器可以提供補(bǔ)償接口讓運(yùn)維人員手工關(guān)閉。

• 重試時，可以使用之前失敗的請求進(jìn)行重試，但一定要注意業(yè)務(wù)上是否允許這樣做。

2.3 使用場景

• 服務(wù)故障或者升級時，讓客戶端快速失敗

• 失敗處理邏輯容易定義

• 響應(yīng)耗時較長，客戶端設(shè)置的 read timeout 會比較長，防止客戶端大量重試請求導(dǎo)致的連接、線程資源不能釋放

3 服務(wù)降級

前面講了限流和熔斷，相比來說，服務(wù)降級是站在系統(tǒng)全局的視角來考慮的。

在服務(wù)發(fā)生熔斷后，一般會讓請求走事先配置的處理方法，這個處理方法就是一個降級邏輯。

服務(wù)降級是對非核心、非關(guān)鍵的服務(wù)進(jìn)行降級。

3.1 使用場景

• 服務(wù)處理異常，把異常信息直接反饋給客戶端，不再走其他邏輯

• 服務(wù)處理異常，把請求緩存下來，給客戶端返回一個中間態(tài)，事后再重試緩存的請求

• 監(jiān)控系統(tǒng)檢測到突增流量，為了避免非核心業(yè)務(wù)功能耗費(fèi)系統(tǒng)資源，關(guān)閉這些非核心功能

• 數(shù)據(jù)庫請求壓力大，可以考慮返回緩存中的數(shù)據(jù)

• 對于耗時的寫操作，可以改為異步寫

• 暫時關(guān)閉跑批任務(wù)，以節(jié)省系統(tǒng)資源

3.2 使用hystrix降級

3.2.1 異常降級

hystrix降級時可以忽略某個異常，在方法上加上 @HystrixCommand 注解：

下面的代碼定義降級方法是 errMethod ，對 ParamErrorException 和 BusinessTypeException 這兩個異常不做降級處理。

@HystrixCommand( 
 fallbackMethod = "errMethod", 
 ignoreExceptions = {ParamErrorException.class, BusinessTypeException.class} 
) 

3.2.2 調(diào)用超時降級

專門針對調(diào)用第三方接口超時降級。

下面的方法是調(diào)用第三方接口3秒未收到響應(yīng)就降級到errMethod方法。

@HystrixCommand( 
    commandProperties = { 
            @HystrixProperty(name="execution.timeout.enabled", value="true"), 
            @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds", value="3000"), 
    }, 
    fallbackMethod = "errMethod" 
) 

限流、熔斷和服務(wù)降級是系統(tǒng)容錯的重要設(shè)計模式，從一定意義上講限流和熔斷也是一種服務(wù)降級的手段。

熔斷和服務(wù)降級主要是針對非核心業(yè)務(wù)功能，而核心業(yè)務(wù)如果流程超過預(yù)估的峰值，就需要進(jìn)行限流。

對于限流，選擇合理的限流算法很重要，令牌桶算法優(yōu)勢很明顯，也是使用最多的限流算法。

在系統(tǒng)設(shè)計的時候，這些模式需要配合業(yè)務(wù)量的預(yù)估、性能測試的數(shù)據(jù)進(jìn)行相應(yīng)閾值的配置，而這些閾值最好保存在配置中心，方便實(shí)時修改。