Java Chassis 3技術(shù)解密：過載狀態(tài)下的快速失敗

在 熔斷機制的改進路程 技術(shù)解密中，總結(jié)了如何設(shè)計一個優(yōu)雅的熔斷機制。 作為微服務(wù)最重要的治理策略之一，熔斷機制能夠在故障場景起到防止雪崩效應(yīng)的作用。過載狀態(tài)是一種特殊的故障場景，主要指超出了系統(tǒng)處理能力的請求量。 在過載狀態(tài)，熔斷機制可能無法起到預(yù)期的效果。 為了對過載狀態(tài)下的防護有個比較直觀的認識， 我們先討論幾個典型場景：

• 假設(shè)系統(tǒng)啟用了熔斷機制，并且設(shè)置了隔離倉來檢測過載情況。 當系統(tǒng)流量過載的時候，隔離倉觸發(fā)過載保護，熔斷機制會短暫隔離對于實例的訪問，并將流量轉(zhuǎn)移到其他實例。 由于總的處理實例數(shù)減少，系統(tǒng)實際能夠處理的負荷在熔斷機制生效的場景下，會進一步降低。 這意味著，相較于沒有熔斷機制，過載場景熔斷機制反而更容易觸發(fā)雪崩效應(yīng)。
• 實際業(yè)務(wù)場景中，一些接口比較耗時，其他接口都很快的情況非常常見。 如果對耗時接口開啟隔離倉進行過載防護，會增加耗時接口的失敗率；如果不開啟過載防護，耗時接口的并發(fā)增加，直觀的表現(xiàn)是用戶響應(yīng)時間的增加。在一些業(yè)務(wù)系統(tǒng)看來，用戶體驗的下降的影響遠小于故障率增加的影響。 微服務(wù)治理策略對于這類系統(tǒng)，也可能帶來適得其反的效果。

在過載場景，不能進入熔斷狀態(tài)，這需要額外的保護機制來防止過載。 快速失敗機制是防止過載的最常用手段，雖然存在性能要求不高的業(yè)務(wù)場景，快速失敗會導(dǎo)致錯誤率提升這種看似矛盾的情況，但是沒有讓快速失敗機制關(guān)上大門，恰當?shù)目焖偈〔⒋钆錁I(yè)務(wù)上的重試的處理還可以明顯改善用戶體驗。 快速失敗機制的要求很簡單，就是盡早的拒絕過載流量，盡可能減少過載流量占用的CPU和其他資源時間。

限流

限流是最常用的快速失敗措施。 但有個細節(jié)經(jīng)常會被忽略：流量經(jīng)常是不均衡的，瞬時流量超過閾值，不代表這些流量就應(yīng)該被拒絕掉。 一個良好的限流措施，需要對流量進行適當?shù)氖崂恚詼p少不必要的限流。 比如下圖，限流的核心作用是將每個時間片內(nèi)，不均勻的流量，變成均勻的流量。

限流發(fā)生的時機越早越好。通常會在 edge service 應(yīng)用限流策略。

## 服務(wù)治理配置
servicecomb:
  matchGroup:
    allOperation: |
      matches:
        - apiPath: 
            prefix: "/"
  rateLimiting:
  ## 限流器每1毫秒允許通過10個請求，如果一個請求超過1000毫秒沒有獲取到
  ## 許可，將被拒絕
    allOperation: |
      rate: 10
      limitRefreshPeriod: 1
      timeoutDuration: 1000

上述限流策略限制了單位時間內(nèi)進入 edge service 的請求數(shù)量，并能對請求進行梳理。限制數(shù)量可能在應(yīng)用程序生命周期過程中難于規(guī)劃，需要通過系統(tǒng)性的性能測試來評估限制大小。 一個比較好的策略是通過并發(fā)數(shù)來限制流量。在 edge service， 可以限制發(fā)往某個下游的實例當前正在處理的請求數(shù)。

## 服務(wù)治理配置
servicecomb:
  matchGroup:
    allOperation: |
      matches:
        - apiPath: 
            prefix: "/"
  instanceBulkhead:
    ## 隔離倉限制正在處理的請求數(shù)為20個，新來的請求等待1000毫秒沒有獲取到許可，將被拒絕。
    allOperation: |
      maxConcurrentCalls: 100
      maxWaitDuration: 1000

相比較于單位時間內(nèi)請求數(shù)， 當前正在處理的請求數(shù)能夠很好的反饋當前的系統(tǒng)繁忙程度，因為一個請求的時延增加，會導(dǎo)致當前正在處理的請求數(shù)增加。對于CPU密集型任務(wù)， 可以設(shè)置稍微小一點的值；對于IO密集型任務(wù)，可以設(shè)置稍微大一點的值。

線程池隊列

在線程池入隊和出隊的時候，進行快速失敗，也是非常常用而且比較有效的手段。 但是這類機制不適用于edge service純異步工作模式場景， 更加適合于微服務(wù)的同步工作模式。

servicecomb:
  executor:
    default:
      maxQueueSize-per-group: 1000

上述配置限制了線程池的隊列大小， 少量的過載請求會被排隊，隊列超限后就會快速拒絕并失敗。

servicecomb:
  rest:
    server:
      requestWaitInPoolTimeout: 1000

Java Chassis在出隊的時候，也會檢測任務(wù)等待的時間。 如果等待時間過長， 也會立即拒絕改任務(wù)，避免額外的處理資源浪費。

全局的超時檢測

一般的RPC系統(tǒng)會針對請求發(fā)送到響應(yīng)接收設(shè)置請求超時時間。 微服務(wù)系統(tǒng)結(jié)構(gòu)通常的調(diào)用關(guān)系比較復(fù)雜。 比如一個請求鏈路可能涉及 a -> b -> c -> d。 如果我們的設(shè)計目標是請求處理時間小于30s， 如果在 b 接收到 a 的請求的時候， 發(fā)現(xiàn)已經(jīng)處理了 30s， b完全可以不需要請求c來處理這個請求， 快速失敗。 Java Chassis 能夠在任務(wù)處理的關(guān)鍵階段，進行全局的已經(jīng)處理的時間檢查。

全局的超時檢測可以處理對快速失敗有非常特殊要求的業(yè)務(wù)場景，考慮到多數(shù)情況下都會很少使用，這里不在詳細描述其技術(shù)細節(jié)， 感興趣的開發(fā)者可以參考Java Chassis的開發(fā)指導(dǎo)。

客戶故事：系統(tǒng)毛刺（指系統(tǒng)中極低概率的請求緩慢或者處理超時）是困擾覺大多數(shù)應(yīng)用的老大難問題。 因為導(dǎo)致系統(tǒng)毛刺的因素非常多，包括請求的分布不均衡、CPU調(diào)度的不可預(yù)期、垃圾回收等等。 系統(tǒng)毛刺給客戶的用戶體驗評價帶來很多負面的影響，整體請求成功率偏低，平均響應(yīng)時延偏高。 為了改善毛刺，早期的主要機制是設(shè)置請求超時時間，包括設(shè)置某個具體微服務(wù)的請求超時時間，或者根據(jù)調(diào)用的順序，配置逐級遞減的超時時間。 超時時間的配置確實起到了快速失敗的目的，然而在HTTP場景下，超時會導(dǎo)致關(guān)閉連接并重新建連，在大并發(fā)場景，會引入更長時間的毛刺和請求超時。 引入流量梳理和隔離倉機制后，系統(tǒng)毛刺問題和超時導(dǎo)致的連接重連問題得到了極大的改善。

以上就是Java Chassis3過載狀態(tài)下的快速失敗解決分析的詳細內(nèi)容，更多關(guān)于Java Chassis3過載狀態(tài)失敗解決的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論