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

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

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

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

限流

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

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

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

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

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

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

線程池隊(duì)列

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

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

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

servicecomb:
  rest:
    server:
      requestWaitInPoolTimeout: 1000

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

全局的超時(shí)檢測(cè)

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

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

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

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

最新評(píng)論