Circuit breaker, current limiting, downgrade——SpringCloud Alibaba Sentinel

Introduction to Sentinel

Sentinel is an open source high-availability traffic protection component developed by the Alibaba middleware team for distributed service architecture. It mainly takes traffic as the entry point and helps from multiple dimensions such as current limiting, traffic shaping, circuit breaker degradation, system load protection, and hotspot protection. Developers ensure the stability of microservices

Sentinel provides two service components:

Sentinel is used to implement functions such as service interruption and downgrading in microservice systems.
Sentinel Dashboard is used to monitor traffic calls and other situations in microservice systems

Current limiting algorithm

There are many ways to limit current, commonly used ones include counters, leaky buckets, token buckets, etc.

1. Counter

Using a counter is a relatively simple current limiting algorithm, which generally limits the number of requests that can pass in one second. For example, if the current limit QPS is 100, the implementation idea of the algorithm is to start counting from the first request. In the next 1 second, the count will be increased by 1 for each request. If the accumulated number reaches 100, subsequent requests will be counted. All will be rejected. Wait until the end of 1 second, restore the count to 0, and start counting again. If 100 requests are processed in the first 10 milliseconds of the unit time of 1 second, then all requests will be rejected in the next 990 milliseconds. We call this phenomenon a spike phenomenon.

2. Leaky bucket algorithm

The idea of the leaky bucket algorithm is very simple. A leaky bucket with a fixed capacity flows out water droplets at a constant fixed rate. If the bucket is empty, there is no need for water drops to flow. We can drop water into the leaky bucket at any rate. If the inflow of water drops exceeds the capacity of the bucket, the inflow of water drops will overflow (discarded), while the capacity of the leaky bucket remains unchanged. The leaky bucket algorithm provides a mechanism by which burst traffic can be shaped to provide stable traffic for the network.

3. Token Bucket Algorithm

The token bucket algorithm is one of the more common current limiting algorithms and can be used to limit interface current. Tokens are put into the token bucket at a fixed rate, and when the bucket is full, newly added tokens are discarded or rejected. When a request arrives, 1 token is removed from the bucket. Tokens in the token bucket can not only be removed, but also added to it. Therefore, in order to ensure that data can pass through the interface at any time, tokens must be constantly added to the bucket. It can be seen that the speed of adding tokens to the bucket determines the speed of data passing through the interface. We control the traffic of the interface by controlling the speed of adding tokens to the token bucket.

4. The difference between leaky bucket algorithm and token bucket algorithm

The leaky bucket algorithm selects outgoing requests at a constant fixed selection rate, and the incoming request rate is arbitrary. When the number of incoming requests accumulates to the leaky bucket capacity, new incoming requests are rejected.
The token bucket algorithm adds tokens to the bucket at a fixed rate. Whether the request is processed depends on whether there are enough tokens in the bucket. When the number of tokens reduces to zero, new requests are rejected.
The token bucket algorithm allows burst requests, which can be processed as long as there are tokens, allowing a certain degree of burst traffic.
The leaky bucket algorithm limits the constant outflow rate, thereby smoothing the burst inflow rate.

Sentinel Dashboard

Sentinel provides a lightweight open source console that includes the following functions:

Check the machine list and health status: collect the heartbeat packets sent by the Sentinel client to determine whether the machine is online
Monitoring (stand-alone and cluster): Through the monitoring API exposed by the Sentinel client, application monitoring information is regularly pulled and aggregated, and ultimately second-level real-time monitoring can be achieved
Rule management and push: unified management of push rules
Authentication: In a production environment, authentication is very important. Each developer here needs to customize it according to his or her actual situation.

You can download the Sentinel installation package from GitHub: https://github.com/alibaba/Sentinel/

What you download is a jar package (sentinel-dashboard-1.8.6.jar), which can be started directly through Java commands, such as running in java -jar mode. The default port is 8080, accessed through http://localhost:8080/, and the user The default name and password are sentinel

Client access console

Introduce dependencies

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

The configuration file is configured as follows:

spring:
    cloud:
        sentinel:
            transport:
                port: 18000  # 指定应用与sentinel控制台交互的端口
                dashboard: localhost:8080   # sentinel后台地址
            eager: true	# 开启sentinel,默认开启

Sentinel current limit

The principle of Sentinel flow control is to monitor indicators such as QPS or the number of concurrent threads of application traffic, and control the flow when it reaches a specified threshold to avoid being overwhelmed by instantaneous traffic peaks, thus ensuring the high availability of the application.

Using annotations to implement current limiting is as follows:

@Slf4j
@RestController
public class TestCon {
    
    

    @GetMapping("/test/byResource")
    @SentinelResource(value = "byResource", blockHandler = "handleException")
    public void byResource() {
    
    
        log.info("按资源名称限流");
    }

    public void handleException(BlockException exception) {
    
    
        log.error("触发失败回调方法", exception);
    }
}

@SentinelResourceAnnotations are used to define resources. Optional attributes are as follows:

value: Specifies the resource name
blockHandler / blockHandlerClass: Specifies the name of the function that handles BlockExccption exceptions. The function must be public, the return type must be consistent with the original method, the function parameter type must match the original method and a BlockException type parameter must be added at the end. The function is in the same class as the original method by default. If you want to use functions of other classes, you can configure blockHandlerClass and specify the methods in blockHandlerClass. Note that the corresponding function must be a static function, otherwise it cannot be parsed.
```
// TestCon.java
@GetMapping("/test/byResource")
@SentinelResource(value = "byResource", blockHandler="handleBolckForTest", blockHandlerClass={
      
      BlockHandlerClassTest})
public void byResource() {
      
      
    log.info("按资源名称限流");
}

// BlockHandlerClassTest.java
public static String handleBolckForTest(String name,int age, BlockException exception){
      
      
	xxxxx
}
```
fallback / fallbackClass: used to provide fallback processing logic when an exception is thrown. It can handle all types of exceptions (except exception types excluded in exceptionsToIgnore). The return value type must be consistent with the original function return value type. Method parameters The list needs to be consistent with the original function, or an additional Throwable type parameter can be added to receive the corresponding exception. The fallback function needs to be in the same class as the original method by default. If you want to use functions of other classes, you can specify fallbackClass as the corresponding Class object of the class. Note that the corresponding function must be a static function, otherwise it cannot be parsed.

In the flow control rules of the Sentinel console, add a new flow control rule, as shown in the figure:

Insert image description here

Resource name: needs @SentineResourceto be consistent with the value attribute value of the annotation
For sources: The default is default, which means to limit the flow of all sources. Sometimes we want to limit the flow based on the superior microservice or request source. We can configure it accordingly according to our own needs.
Threshold type: Sentinel current limiting policy has two statistical types, one is to count the number of concurrent threads, and the other is to count QPS
- When QPS exceeds a certain threshold, measures are taken to control traffic, including:
  - Direct rejection: The default flow control method. When QPS exceeds the threshold of any rule, new requests will be immediately rejected and a FlowExccption will be thrown.
  - Warm Up: Preheating/cold start mode. When the system is at a low water level for a long time, when the flow rate suddenly increases, directly raising the system to a high water level may instantly crush the system. Cold start allows the flow rate to slowly increase. , gradually increases to the upper limit of the threshold within a certain period of time, giving the cold system a time to warm up and preventing the cold system from being overwhelmed.
  - Uniform queuing: Strictly control the interval time between requests, that is, let the requests pass at a uniform speed, corresponding to the leaky bucket algorithm
Flow control mode:
- Direct: When the interface reaches the current limiting condition, the current limiting is enabled.
- Association: When the interface associated with the specified interface reaches the current limiting condition, enable current limiting for the specified interface. For example: set the associated resource to byResource2, then when byResource2 reaches the current limiting condition, byResource will be unavailable.
- Link: When the resource coming from an interface reaches the current limiting condition, current limiting is enabled. For example: There are two interfaces, getResource1 and getResource2, that can call byResource resources. If getResource1 is set and the current limiting condition is reached, it will no longer be able to pass through. getResource1 calls byResource, but getResource2 is not affected