Java Chassis 3技術(shù)解密：熔斷機(jī)制的改進(jìn)路程

熔斷機(jī)制是微服務(wù)治理非常重要的手段。當(dāng)應(yīng)用程序出現(xiàn)局部故障，比如多個(gè)微服務(wù)實(shí)例的其中一個(gè)實(shí)例故障，或者一個(gè)微服務(wù)實(shí)例的多個(gè)接口中的一個(gè)故障，恰當(dāng)?shù)娜蹟鄼C(jī)制能夠避免出現(xiàn)雪崩效應(yīng)。熔斷機(jī)制通常有如下幾個(gè)重要的技術(shù)部件。

• 熔斷的目標(biāo)對(duì)象。目標(biāo)對(duì)象可以是一個(gè)實(shí)例的某個(gè)服務(wù)接口，也可以是正在訪問(wèn)的某個(gè)微服務(wù)實(shí)例，也可以是正在訪問(wèn)的某個(gè)微服務(wù)實(shí)例的某個(gè)接口。 站在Provider視角和站在Consumer視角，會(huì)有不同的目標(biāo)對(duì)象。需要對(duì)目標(biāo)對(duì)象進(jìn)行準(zhǔn)確的抽象，才能夠提供一個(gè)好用的熔斷機(jī)制。
• 故障檢測(cè)方法。對(duì)目標(biāo)對(duì)象的每次訪問(wèn)，需要對(duì)訪問(wèn)結(jié)果進(jìn)行檢查和分類，并統(tǒng)計(jì)相關(guān)指標(biāo)。通常檢查的結(jié)果包括拋出異常、返回狀態(tài)碼、請(qǐng)求處理時(shí)延等。 還需要考慮適當(dāng)?shù)乃惴ㄟM(jìn)行指標(biāo)統(tǒng)計(jì)，比如采用基于時(shí)間或者基于請(qǐng)求數(shù)量的滑動(dòng)窗口算法。
• 熔斷的策略。當(dāng)故障積累的時(shí)候，如何避免故障積累，產(chǎn)生雪崩效應(yīng)。常見的策略包括：快速失敗，對(duì)目標(biāo)對(duì)象的訪問(wèn)，立即拋出異常，返回失?。桓綦x錯(cuò)誤對(duì)象，當(dāng)目標(biāo)對(duì)象存在可替換副本，比如其他的微服務(wù)實(shí)例，不再訪問(wèn)故障實(shí)例，只訪問(wèn)其他非故障實(shí)例。
• 熔斷的恢復(fù)策略。目標(biāo)對(duì)象的熔斷時(shí)長(zhǎng)，如何從熔斷狀態(tài)中恢復(fù)也是非常重要的。

可以看出，設(shè)計(jì)一個(gè)良好的熔斷機(jī)制是非常復(fù)雜的，Java Chassis 3的熔斷機(jī)制也經(jīng)歷了多次調(diào)整和優(yōu)化。

Spring Cloud Circuit Breaker

從 Spring Cloud 官網(wǎng)提供的例子以及開發(fā)指南，可以簡(jiǎn)單的分解下上述技術(shù)部件：

@Service
public static class DemoControllerService {
	private ReactiveCircuitBreakerFactory cbFactory;
	private WebClient webClient;
	public DemoControllerService(WebClient webClient, ReactiveCircuitBreakerFactory cbFactory) {
		this.webClient = webClient;
		this.cbFactory = cbFactory;
	}
	public Mono<String> slow() {
		return webClient.get().uri("/slow").retrieve().bodyToMono(String.class).transform(
		it -> cbFactory.create("slow").run(it, throwable -> return Mono.just("fallback")));
	}
}

目標(biāo)對(duì)象是由開發(fā)者在代碼中指定的。 對(duì)于接口方法這類目標(biāo)對(duì)象，開發(fā)起來(lái)是比較容易的，但是對(duì)于實(shí)例，則非常麻煩，而且無(wú)法動(dòng)態(tài)的調(diào)整目標(biāo)對(duì)象，在開發(fā)的時(shí)候就需要確定好。 故障檢測(cè)方法主要是基于異常，即目標(biāo)對(duì)象拋出異常的時(shí)候，會(huì)觸發(fā)熔斷。熔斷的策略為快速失敗模式。

Java Chassis Bizkeeper

Java Chassis 的早期版本，基于 Bizkeeper 提供了熔斷功能。 Bizkeeper 集成了 Hystrix 組件。下面是一個(gè)配置示例。

servicecomb:
  handler:
    chain:
      Consumer:
        default: bizkeeper-consumer
  isolation:
    Consumer:
      timeout:
        enabled: true
      timeoutInMilliseconds: 30000
  circuitBreaker:
    Consumer:
      enabled: true
      sleepWindowInMilliseconds: 15000
      requestVolumeThreshold: 20
  fallback:
    Consumer:
      enabled: true
  fallbackpolicy:
    Consumer:
      policy: throwException

目標(biāo)對(duì)象是當(dāng)前訪問(wèn)的方法，可以指定所有方法、某個(gè)Schema的所有方法、某個(gè)具體方法。故障檢測(cè)方法有異常、超時(shí)錯(cuò)誤兩種。熔斷的策略為快速失敗模式。

由于 Hystrix 已經(jīng)停止維護(hù)，這個(gè)機(jī)制在 Java Chassis 3已經(jīng)刪除。

Java Chassis Instance Isolation

這個(gè)機(jī)制是基于 loadbalancer filter 開發(fā)的實(shí)例隔離功能。

servicecomb:
  loadbalance:
    isolation:
      enabled: false
      errorThresholdPercentage: 0
      enableRequestThreshold: 5
      singleTestTime: 60000
      continuousFailureThreshold: 5
      maxSingleTestWindow: 60000 # 為了保證在并發(fā)情況下只有一個(gè)實(shí)例放通，會(huì)鎖定放通實(shí)例。這個(gè)時(shí)間表示最大鎖定時(shí)間。
      minIsolationTime: 3000 # 最短隔離時(shí)間。并發(fā)情況下，實(shí)例隔離后進(jìn)行中的請(qǐng)求可能快速刷新隔離狀態(tài)，增加最短隔離時(shí)間。
      recoverImmediatelyWhenSuccess: true # 放通實(shí)例，如果調(diào)用成功，立即清除統(tǒng)計(jì)狀態(tài)，保證后續(xù)請(qǐng)求能夠使用該實(shí)例。 

目標(biāo)對(duì)象是實(shí)例。 故障檢測(cè)方法是基于異常。 熔斷的策略為不再訪問(wèn)故障實(shí)例，只訪問(wèn)其他非故障實(shí)例。

該功能在故障統(tǒng)計(jì)方面沒(méi)有滑動(dòng)窗口等算法，在計(jì)算錯(cuò)誤率的時(shí)候，會(huì)存在不穩(wěn)定波動(dòng)。 錯(cuò)誤率計(jì)算問(wèn)題會(huì)導(dǎo)致隔離和隔離恢復(fù)出現(xiàn)問(wèn)題，可以看出，他的恢復(fù)機(jī)制設(shè)計(jì)參數(shù)比較多。 這個(gè)機(jī)制在 Java Chassis 3已經(jīng)刪除。

Java Chassis 3 的熔斷機(jī)制

Java Chassis 3 針對(duì) Provider 和 Consumer 兩個(gè)視角，提供了熔斷機(jī)制。 兩個(gè)機(jī)制的故障檢測(cè)的方法、熔斷策略和熔斷恢復(fù)策略是相同的，只是在目標(biāo)對(duì)象不一致。

Provider 視角的熔斷配置：

servicecomb:
  circuitBreaker:
    allOperation: |
      minimumNumberOfCalls: 10
      slidingWindowSize: 20
      slidingWindowType: COUNT_BASED
      failureRateThreshold: 50
      recordFailureStatus: 
        - 502
        - 503
      slowCallRateThreshold: 100
      slowCallDurationThreshold: 3000
      waitDurationInOpenState: 10000 
      permittedNumberOfCallsInHalfOpenState: 10

Consumer 視角的熔斷配置：

servicecomb:
  instanceIsolation:
    allOperation: |
      minimumNumberOfCalls: 10
      slidingWindowSize: 20
      slidingWindowType: COUNT_BASED
      failureRateThreshold: 50
      slowCallRateThreshold: 100
      recordFailureStatus: 
        - 502
        - 503
      slowCallDurationThreshold: 3000
      waitDurationInOpenState: 10000 
      permittedNumberOfCallsInHalfOpenState: 10

Java Chassis提供了基于慢請(qǐng)求、異常、錯(cuò)誤碼，以及 AbstractCircuitBreakerExtension、AbstractInstanceIsolationExtension 接口讓開發(fā)者自定義等故障檢測(cè)方法。 對(duì)于性能場(chǎng)景，還可以基于隔離倉(cāng)增加并發(fā)數(shù)限制故障檢測(cè)方法。

Provider 視角的隔離倉(cāng)配置：

servicecomb:
  bulkhead:
    allOperation: |
      maxConcurrentCalls: 20
      maxWaitDuration: 1000

Consumer 視角的隔離倉(cāng)配置：

servicecomb:
  instanceBulkhead:
    allOperation: |
      maxConcurrentCalls: 20
      maxWaitDuration: 1000

Provider 視角的熔斷器，熔斷策略是快速失敗，拋出異常；Consumer 視角的熔斷器，熔斷策略是為不再訪問(wèn)故障實(shí)例，只訪問(wèn)其他非故障實(shí)例。

在前面的示例中，allOperation 代表了熔斷對(duì)象。 Java Chassis 3的熔斷對(duì)象定義也是非常簡(jiǎn)單和靈活的：

servicecomb:
  matchGroup:
    allOperation: |
      matches:
        - apiPath:
            exact: "/"
          method:
            - POST
          headers:
            Authentication: 
              prefix: Basic
          serviceName: exampleService

站在Provider 視角， 上述定義表示熔斷對(duì)象是來(lái)自 exampleService 的設(shè)置了認(rèn)證頭的所有 POST 方法； 站在Consumer 視角， 上述定義表示熔斷對(duì)象是發(fā)往 exampleService 的某個(gè)具體的實(shí)例，并且設(shè)置了認(rèn)證頭的所有 POST 方法。

Java Chassis 3熔斷機(jī)制逐步成為是一個(gè)簡(jiǎn)單易用， 滿足絕大部分業(yè)務(wù)場(chǎng)景需要的通用設(shè)計(jì)規(guī)范。

客戶故事：客戶期望建立一種持續(xù)演進(jìn)的故障處理機(jī)制，以降低隨著系統(tǒng)長(zhǎng)期運(yùn)行，隨機(jī)故障、系統(tǒng)變慢等場(chǎng)景對(duì)整體故障的影響，動(dòng)態(tài)適應(yīng)持續(xù)變化的環(huán)境對(duì)可靠性帶來(lái)的挑戰(zhàn)。Java Chassis 3的服務(wù)治理配置機(jī)制，可以使得客戶不需要修改代碼和重啟應(yīng)用，就能夠動(dòng)態(tài)調(diào)整耗時(shí)接口和故障接口的熔斷策略。通過(guò)規(guī)范賦能，運(yùn)維人員就能夠解決一些常見的過(guò)載防護(hù)問(wèn)題。

以上就是Java Chassis 3技術(shù)解密：熔斷機(jī)制的改進(jìn)路程的詳細(xì)內(nèi)容，更多關(guān)于Java Chassis 3技術(shù)解密：熔斷機(jī)制的改進(jìn)路程的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論