Java?Chassis3熔斷機制的改進路程技術解密

更新時間：2024年01月17日 09:26:16 作者：liubao68

這篇文章主要介紹了Java?Chassis?3技術解密之熔斷機制的改進路程實例分析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪

Java Chassis 3技術解密：熔斷機制的改進路程

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

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

可以看出，設計一個良好的熔斷機制是非常復雜的，Java Chassis 3的熔斷機制也經歷了多次調整和優(yōu)化。

Spring Cloud Circuit Breaker

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

@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")));
	}
}

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

Java Chassis Bizkeeper

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

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

目標對象是當前訪問的方法，可以指定所有方法、某個Schema的所有方法、某個具體方法。故障檢測方法有異常、超時錯誤兩種。熔斷的策略為快速失敗模式。

由于 Hystrix 已經停止維護，這個機制在 Java Chassis 3已經刪除。

Java Chassis Instance Isolation

這個機制是基于 loadbalancer filter 開發(fā)的實例隔離功能。

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

目標對象是實例。故障檢測方法是基于異常。熔斷的策略為不再訪問故障實例，只訪問其他非故障實例。

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

Java Chassis 3 的熔斷機制

Java Chassis 3 針對 Provider 和 Consumer 兩個視角，提供了熔斷機制。兩個機制的故障檢測的方法、熔斷策略和熔斷恢復策略是相同的，只是在目標對象不一致。

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提供了基于慢請求、異常、錯誤碼，以及 AbstractCircuitBreakerExtension、AbstractInstanceIsolationExtension 接口讓開發(fā)者自定義等故障檢測方法。對于性能場景，還可以基于隔離倉增加并發(fā)數(shù)限制故障檢測方法。

Provider 視角的隔離倉配置：

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

Consumer 視角的隔離倉配置：

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

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

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

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

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

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

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

以上就是Java Chassis 3技術解密：熔斷機制的改進路程的詳細內容，更多關于Java Chassis 3技術解密：熔斷機制的改進路程的資料請關注腳本之家其它相關文章！

您可能感興趣的文章: