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

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

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

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

限流

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

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

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

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

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

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

線程池隊(duì)列

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

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

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

servicecomb:
  rest:
    server:
      requestWaitInPoolTimeout: 1000

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

全局的超時檢測

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

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

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

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

最新評論