Circuit Breaker

The circuit breaker rule is based on Resilience4j and works on the server. The principles are as follows:

When the specified value of failureRateThreshold or slowCallRateThreshold is reached, the circuit breaker is triggered and response code 429 is returned. SlowCallDurationThreshold indicates the slow call duration threshold. minimumNumberOfCalls indicates the minimum number of requests that meet the circuit breaker requirement. For example, if the value of minimumNumberOfCalls is 10, at least 10 calls must be recorded to calculate the failure rate. If only nine calls are recorded, CircuitBreaker will not be enabled even if all the nine calls fail. slidingWindowType specifies the type of the sliding window. The default value is count (based on the number of requests) or time (based on the time window). If the sliding window type is count, the latest slidingWindowSize calls are recorded and counted. If the sliding window type is time, the calls in the latest slidingWindowSize seconds are recorded and counted. slidingWindowSize specifies the size of the sliding window. The unit can be the number of requests or second, depending on the sliding window type.

• Circuit breaker of Java chassis is used for microservice consumers. The circuit breaker module must be integrated into microservice applications and the bizkeeper-consumer processing chain must be enabled.
  Configuration example:

  servicecomb:
    handler:
      chain:
        Consumer:
          default: bizkeeper-consumer

  Add the following dependency to the POM file:

  <dependency>
    <groupId>org.apache.servicecomb</groupId>
    <artifactId>handler-bizkeeper</artifactId>
    <version>${project.version}</version>
  </dependency>
  NOTE:

  The microservice development framework Java Chassis 2.x is used as an example.

• Spring Cloud Huawei uses Aspect to intercept RequestMappingHandlerAdater to implement circuit breaker. After Spring Cloud Huawei is integrated, the client circuit breaker module spring-cloud-starter-huawei-governance is integrated by default. You only need to enable a specific client circuit breaker policy.

  Configuration example:

  servicecomb:
    matchGroup:
      AllOperation: |
        matches:
          - apiPath:
              prefix: "/"
    instanceIsolation:     
      AllOperation: |      
        minimumNumberOfCalls: 10      
        slidingWindowSize: 10      
        slidingWindowType: COUNT_BASED      
        failureRateThreshold: 20
        recordFailureStatus:
          - 502
          - 503

  The default policy takes effect when the error code is 502 or 503. In 1.11.4-2021.0.x/1.11.4-2022.0.x and later versions, the response header takes effect in special scenarios.

  The default key of the response header is X-HTTP-STATUS-CODE. You can also customize the key by configuring the following on the client:

  spring:
    cloud:
      servicecomb:
        governance:
          response:
            header:
              status:
                key: 'X-HTTP-EEROR-STATUS-CODE'

  The response code set in the response header can also be customized. However, you need to add the corresponding error code to the fault tolerance policy. For example, if you set X-HTTP-STATUS-CODE=511, add error code 511. The configuration is as follows:

  servicecomb:
    matchGroup:
      AllOperation: |
        matches:
          - apiPath:
              prefix: "/"
    instanceIsolation:     
      AllOperation: |      
        minimumNumberOfCalls: 10      
        slidingWindowSize: 10      
        slidingWindowType: COUNT_BASED      
        failureRateThreshold: 20
        recordFailureStatus:
          - 502
          - 503
          - 511

  The preceding configuration enables the client circuit breaker policy for all instances. This policy uses the COUNT_BASED sliding window policy. The window size is 10 requests. When the number of requests reaches 10, the error rate starts to be calculated. If the error rate reaches 20%, circuit breaker is performed for subsequent requests. The default sliding window policy is TIME_BASED. The system checks the response code first. If the abnormal response code meets the policy setting, the fault tolerance function is enabled. If the abnormal response code does not meet the policy setting, the system checks whether the response code set in the header meets the requirement.