Ali’s Sentinel-killing Device 17 questions?

1, the preface

This is the fifth article in the spring Cloud Advanced column. This article introduces alibaba’s open source traffic guard Sentinel, an excellent open source project, which is very mature after nearly 10 years of double 11. Previous articles are as follows:

• How strong is Nacos, the soul ferryman of microservices, in 55 images?
• OpenFeign kills series 9 asks, who can stand that?
• Ali interview asked: Nacos, Apollo, Config configuration center how to select? These 10 dimensions tell you!
• Ali failed in the interview: How to select 5 kinds of microservice registry? These dimensions tell you!

The table of contents is as follows:

2. What is Sentinel?

Sentinel means guard; In Redis it is called sentry, which monitors master/slave switching, but in microservices it is called traffic guard.

Sentinel takes flow as the entry point to protect the stability of service from multiple dimensions such as flow control, fusing downgrading and system load protection.

Sentinel has the following characteristics:

• Rich application scenarios: Sentinel has undertaken the core scenarios of Alibaba’s double Eleven traffic drive in the past 10 years, such as SEC killing (i.e. burst traffic control within the range of system capacity), message peaking and valley filling, cluster flow control, real-time fusing of unavailable downstream applications, etc.
• Complete real-time monitoring: Sentinel also provides real-time monitoring capabilities. From the console, you can see a summary of the performance of a single machine-by-second data, or even a cluster of less than 500 machines, for accessing the application.
• Extensive Open source ecosystem: Sentinel provides out-of-the-box integration modules with other open source frameworks/libraries, such as Spring Cloud, Apache Dubbo, gRPC, Quarkus. You can quickly access Sentinel by introducing the appropriate dependencies and simple configuration. Sentinel also provides native implementations of Java, Go, C++ and other languages.
• Comprehensive SPI extension mechanism: Sentinel provides an easy-to-use, comprehensive SPI extension interface. You can quickly customize the logic by implementing an extension interface. For example, customize rule management and adapt dynamic data sources.

Key features of Sentinel are shown below:

Sentinel is divided into two parts:

• The core library (Java client) is independent of any framework/library, can run in all Java runtime environments, and has good support for frameworks such as Dubbo/Spring Cloud.
• The Console (Dashboard) is based on Spring Boot and can be packaged to run directly without the need for additional application containers such as Tomcat.

In short: Sentinel is awesome, Hystrix………

3. What is the difference between Sentinel and Hystrix?

Without further explanation, in a word: Hystrix give up and use sentinel……

The specific differences are shown below:

4. How to choose sentinel version?

Because Chen is writing a series of advanced Spring Cloud, using aggregation projects, the version will remain the same as the previous article. It is not clear to see this article: fifty-five graphs tell you how strong Nacos is for the soul ferrier of microservices.

< span style = “box-sizing: border-box; color: RGB (74, 74, 74); line-height: 22px; font-size: 14px! Important; white-space: normal; word-break: break-all;”

Note: must be in accordance with the official recommended version adaptation, otherwise unexpected bugs appear………

5. How to install Sentinel console?

Sentinel, like Nacos, has a console, but instead of building a microservice manually, it’s already there. You just need to download the required JAR package and run it. Download: github.com/alibaba/Sen…

Just choose the required version and download it. I choose version 1.7.1 here, and the downloaded JAR package is shown as follows:

Of course you can build it from source code: MVN Clean Package

Note: JDK version must >=1.8

In this case, we just need to run the jar package as follows:

java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar Sentinel dashboard - 1.7.1. JarCopy the code

The meanings of the parameters are as follows:

• – dserver. port: specifies the boot port. The default port is 8080

• – dproject. name: specifies the name of the service

• – Dcsp. Sentinel. Dashboard. Server: specify the address of the sentinel console, is used to register into the implementation monitoring themselves

After successful startup, the browser will visit http://localhost:8080. The login page is as follows:

Default username and password: sentinel/sentinel

After successful login, the following page is displayed:

As you can see, only one service is currently monitored, Sentinel-Dashboard, and that service is itself.

Note: the above parameters are optional and not necessary.

The question is: How do I change the default username and password that will not work in a production environment?

Since Sentinel 1.6.0, Sentinel has supported custom user names and passwords, which need to be specified when executing the jar command:

Java - Dsentinel. Dashboard. The auth. Username = admin - Dsentinel. Dashboard. The auth. Password = 123 - jar sentinel - dashboard - 1.7.1. JarCopy the code

You can set the following parameters:

• -Dsentinel.dashboard.auth.username=sentinelUsed to specify the console login user namesentinel;
• -Dsentinel.dashboard.auth.password=123456The login password used to specify the console is123456; If these two parameters are omitted, the default user name and password are bothsentinel;
• -Dserver.servlet.session.timeout=7200Specifies the expiration time of the Spring Boot server session, for example7200Represents 7200 seconds;60mIndicates 60 minutes. The default value is 30 minutes.

Note: When deploying multiple consoles, sessions are not shared between instances by default, and this needs to be modified.

In addition to username and password related configurations, the Sentinel Console provides additional configurable options, as shown below:

6. How do microservices access sentinel console?

Why would a microservice integrate with the Sentinel console? Doesn’t Sentinel provide an API?

Spring Boot officially advocates convention > configure > code rules, so why not hardcode?

Therefore, the rest of this article is mainly explained with sentinel console, you can learn about the use of API according to the official documentation, the explanation is very clear.

Okay, so how does microservices access the Sentinel console?

1. Create a micro-service module and register it in Nacos

The registry here still uses NacOS, but for those who don’t, see the first NACOS article in this column: 55 charts that tell you just how strong Is Nacos, the soul ferrier of microservices?

Create a new micro-service module: Sentinel-Service9008, the related code is not posted.

Related configurations are as follows:

server:
  port: 9008
spring:
  application:
    Specify the service name, the name in nacOS
    name: sentinel-service
  cloud:
    nacos:
      discovery:
        The IP address in nacOS-server is the port number
        server-addr: 127.0. 01.: 8848
management:
  endpoints:
    web:
      exposure:
        Special characters exist in the ## yML file and must be enclosed in single quotation marks; otherwise, an error will be reported during startup
        include: The '*'
Copy the code

Source code will be uploaded, access to see the end of the article!

2. Add dependencies

In addition to the Nacos dependency, we also need to add a sentinel dependency:

<! -- Sentinel dependence -->
<dependency>
	<groupId>com.alibaba.cloud</groupId>
	<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
Copy the code

Only sentinel dependencies are posted, nacos dependencies are not posted anymore, see source code!

3. Add the configuration integrated console

Just add the following configuration to integrate the Sentinel console:

spring:
  cloud:
    sentinel:
      transport:
      	## Specifies the console address. The default port is 8080
        dashboard: localhost:8080
Copy the code

4. Create a test interface

Create a new test interface for testing related rules as follows:

@RestController
@RequestMapping("/sentinel")
public class FlowLimitController {

    @GetMapping("/test")
    public String test(a){
        return "Received a message --------"; }}Copy the code

5. Start microservices

Then start the service, 9008 browser enter: http://localhost:9008/sentinel/test, view the sentinel console at this time, will see sentinel – service this service has been monitoring, the diagram below:

Note: Sentinel is lazy loading and only resources accessed once are monitored.

Lazy loading can be turned off by configuring it to connect to the Sentinel console when the project starts, as follows:

spring:
    sentinel:
      # Cancel console lazy loading and connect to Sentinel upon project startup
      eager: true
Copy the code

7. How to configure flow control?

Flow control monitors application traffic indicators, such as QPS or concurrent threads, and controls the traffic when it reaches a specified threshold to avoid being overwhelmed by instantaneous traffic peaks and ensure high availability of applications.

QPS: Requests per second, that is, the number of requests that the server can process per second if requests are continuously sent to the server.

Number of concurrent threads: Refers to the number of concurrent requests applied by the press.

Multiple traffic limiting rules can be created for a resource. A traffic limiting rule consists of the following elements:

• Resource: indicates the name of the resource, which is the object of the traffic limiting rule.
• Count: traffic limiting threshold
• Grade: indicates the type of traffic limiting threshold (1: QPS 0: number of concurrent threads). The default value is QPS
• limitApp: Call source for flow control, ifdefaultThe call source is not identified. The default value is default
• Strategy: The judgment is based on the resource itself **(0), other associated resources (1), or link entry (2)**. The default value is based on the resource itself.
• ControlBehavior: flow control effect (reject directly (0), wait in queue (2), or preheat and cold start (1)). The default value is Reject directly.

Above current limiting element corresponding class is com. Alibaba. CSP. The sentinel. Slots. Block. Flow. FlowRule, the elements below:

Note: The values and defaults for each element must be remembered for later configuration.

The corresponding rules of the above elements in sentinel console are shown as follows:

1. Three flow control effects

Flow control effects are divided into three types, corresponding to controlBehavior, as follows:

Fail fast

By default, when QPS exceeds the threshold of any rule, new requests are immediately rejected by throwing a FlowException.

warm up

Preheat/cold start mode. When the system has been at a low water level for a long time, when the flow suddenly increases, directly pulling the system to a high water level can suddenly overwhelm the system. Through the “cold start”, the flow slowly increases to the upper limit of the threshold in a certain period of time, giving the cold system a time to warm up, preventing the cold system from being overwhelmed.

Note: This effect only applies to QPS flow control, not concurrent thread flow control.

Preheat the underlying is based on the token bucket algorithm, the source code for class due to the com. Alibaba. CSP. Sentinel. Slots. Block. Flow. Controller. WarmUpController.

There is a cooling factor coldFactor in the algorithm, the default value is 3, that is, the QPS request starts from threshold / 3 and gradually rises to the set QPS threshold after the warm-up time.

For example, set the QPS threshold to 3, the flow control effect to warm up, and the preheating time to 5 seconds, as shown below:

What happens after this configuration: QPS will initially warm up from (3/3/=1) one request per second until it reaches 3 requests per second after 5 seconds. Dynamic renderings are as follows:

It can be clearly seen from the above animation that the first few seconds of flow control are frequent until 5 seconds, when the QPS threshold reaches 3.

Specific algorithm principle please see: github.com/alibaba/Sen…

Waiting in line

Uniform queuing strictly controls the interval between requests passing, that is, requests passing at an even speed, which corresponds to the leak-bucket algorithm. Source code for class: due to the com. Alibaba. CSP. Sentinel. Slots. Block. Flow. The controller. RateLimiterController

Note: This effect only applies to QPS flow control, not concurrent thread flow control.

A simple example: if you go to the college canteen and only one aunt is serving, everyone has to queue up to get food. Only one person gets food at a time while everyone else is waiting in line.

The difference is that Sentinel has a timeout wait time, and any time beyond this preset time will be restricted.

The function of this mode is shown as follows:

This approach is suitable for requests coming in spikes, when we do not want to pass all requests at once, which may overwhelm the system; We also expect the system to process these requests at a steady pace, so as to “fill the gap” rather than reject all requests.

For example, set the QPS threshold to 1 and the timeout wait time to 10000 milliseconds, as shown in the following figure:

The effect is as follows:

As can be seen from the figure above: continuous click refresh request, although the QPS threshold is set to 1, it is not restricted, but is waiting, because the timeout wait time is set to 10 seconds.

Specific algorithm principle please see: github.com/alibaba/Sen…

2. Three flow control modes

There are three flow control modes, corresponding to element Strategy, as follows:

• Direct reject: When the interface reaches the traffic limiting condition, the interface directly limits traffic
• Association: When the associated resource reaches the threshold, traffic limits itself
• Link: Records only the traffic on the specified link. (If the traffic from the specified resource reaches the threshold, the traffic can be restricted.)

The following three flow control modes are introduced in detail.

Direct refused to

As the name implies: The default flow control method, when the QPS exceeds the threshold of any rule, new requests will be immediately rejected by throwing a FlowException. The examples above are all configured to reject this mode directly, and I won’t go into details here.

associated

Typical usage scenarios: one is the payment interface, and the other is the ordering interface. Once the payment interface reaches the threshold, the ordering interface should be restricted. Otherwise, the user experience will be greatly affected if consumers are still placing orders and waiting or being directly refused to pay.

In short: A associates B, and once B reaches A threshold, A is restricted

To demonstrate the effect, create the following two interfaces:

@RestController
@RequestMapping("/sentinel")
public class FlowLimitController {

    /** **@return* /
    @GetMapping("/order")
    public String order(a)  {
        return "Order successful..........";
    }

    /** * Payment interface *@return* /
    @GetMapping("/pay")
    public String pay(a)  {
        return "Payment successful.........."; }}Copy the code

The flow control rule configuration is as follows:

Note: After the association, the traffic limiting rule is set for the associated resource, namely /sentinel/pay, but the real traffic limiting rule is /sentinel/order.

How do you demonstrate that? Simple, just keep asking /sentinel/pay to reach the threshold and then ask /sentinel/order.

POSTMAN is used to make continuous requests to /sentinel/pay, and then the browser requests /sentinel/order. The result is as follows:

You can see that the order interface is restricted………….

3. Two types of statistics

Flow control is divided into two statistical types, namely QPS and number of concurrent threads. Many people do not understand the difference between these two statistical types.

For example: Chen brought 100 million yuan to the bank to deposit money, but the security guard at the bank gate had to check the health code, and only four people could enter the bank at the same time every second, and there were only two staff members working in the bank, as shown in the picture below:

At this point, QPS means: the section from the security guard to the bank is the number of people allowed to enter the bank by the security guard.

In this case, the meaning of the number of concurrent threads: the bank has only two staff working, so it can only handle two tasks at most at the same time, where the threshold of the number of concurrent threads is 2.

8. How to configure degradation rules?

Fuse downgrading is also common in daily life, with the following scenarios:

• Circuit breakers in the stock market, when prices hit the melting point, halt trading for a period of time, or trading can continue but prices are quoted within a certain range.
• High voltage causes fuse to trigger fuse protection

In a large distributed system, the dependency of a request is shown below:

If at this time, a service has some exceptions, such as:

• Service provider unavailable (hardware failure, program bug, network failure, high volume of user requests)
• Retry caused heavy traffic. Procedure
• The service caller uses synchronous invocation to generate a large number of waiting threads occupying system resources. Once the thread resources are exhausted, the service provided by the caller will become unavailable

Then the whole service will be unusable, in the old saying: a thousand miles of dam is destroyed by a nest.

It is said that programming comes from life, and architects design fuse downgrading strategies of services based on life experience to solve such problems well.

The fuse degrade rule corresponds to the degrade rule column of Sentinel console, as shown below:

Several attributes involved in fusible degradation are listed below:

In the source code for class due to: com. Alibaba. CSP. The sentinel. Slots. Block. Degrade. DegradeRule.

Three circuit breaker strategies

Sentinel offers the following circuit breaker strategies:

1. Average response time (DEGRADE_GRADE_RT): When five requests are continuously entered within 1s, the average response time (in seconds) at the corresponding time exceeds the threshold (count, in ms), then in the next time window (DegradeRuleIn thetimeWindow, in s), all calls to this method will automatically fuse (throw)DegradeException). Note that the RT upper limit of Sentinel default statistics is 4900 ms,Anything above this threshold counts as 4900 msIf you need to change the upper limit, you can start the configuration item-Dcsp.sentinel.statistic.max.rt=xxxTo configure.
2. Abnormal ratio (DEGRADE_GRADE_EXCEPTION_RATIO): If the number of requests per second of the resource >= 5,andThe ratio of total exceptions per second to pass exceeds the threshold (DegradeRuleIn thecount) after that, the resource enters the degraded state, that is, in the next time window (DegradeRuleIn thetimeWindow, in s), all calls to this method are automatically returned. The threshold range for abnormal ratio is[0.0, 1.0], represents 0-100%.
3. Abnormal number (DEGRADE_GRADE_EXCEPTION_COUNT): When the resource is nearly 1 minuteThe number of abnormalWhen the threshold is exceeded, fuses are performed. Notice That the statistical time window is minute, iftimeWindowIf the value is less than 60 seconds, the circuit breaker may enter the circuit breaker again after ending the circuit breaker.

To demonstrate an average response time fuse, create an interface as follows:

@RestController
@RequestMapping("/sentinel/provider")
@Slf4j
public class FlowLimitController {

    @GetMapping("/test")
    public String test(a) throws InterruptedException {
        // Sleep for 3 seconds
        Thread.sleep(3000);
        log.info("Received a message ----test");
        return "Received a message --------"; }}Copy the code

In the console, set the average response time for this interface as 200 ms and the time window as 1 second. Roughly meaning: After the average response time is greater than 200 ms, the interface will be directly fused in the following 1 second, as shown below:

Start a 10-thread loop with Jmeter, then access the interface in a browser, and return the following result:

Why is that? Since the interface was asleep for 3 seconds, the average response time must be greater than 200 ms, so it was directly fussed.

Note: in this case, the default message is returned directly after the fusing. We will explain how to customize the fusing return message later.

9. How to limit the flow of hotspot parameters?

As the name implies, a hotspot is frequently accessed data, and most of the time, it must be hoped to collect Top K data with a certain access frequency and limit its flow.

For example, the commodity ID in the seckill system is terrible for the concurrent volume of hot commodities at that moment, so it must be limited.

Sentinel uses LRU strategy to count the most frequently accessed hotspot parameters and combines with token bucket algorithm to control the flow at parameter level.

Note: Hotspot parameter limiting applies only to QPS.

Official documentation: github.com/alibaba/Sen…

Now that you understand the concept, let’s take a look at how the Sentinel console sets the hotspot parameter limiting, as shown below:

Rules on due to the source code in com. Alibaba. CSP. Sentinel. Slots. Block. Flow. The param. ParamFlowRule this class, various attributes meaning below:

Now that you understand the rules, let’s demonstrate how hot parameters limit traffic.

Note: The hotspot parameter flow limiting applies only to the eight basic types.

1. Create a resource

Now create a service and define a resource using the @SentinelResource annotation, which we’ll cover in more detail, but ignore. The code looks like this:

@Service
@Slf4j
public class FlowServiceImpl implements FlowService {

    / * * *@SentinelResourceThe value attribute of the blockHandler property specifies the resource name, and the unique * blockHandler property specifies the bottom-pocket method */
    @Override
    @SentinelResource(value = "OrderQuery",blockHandler = "handlerQuery")
    public String query(String p1, String p2) {
        log.info(P1: {}, p2: {}",p1,p2);
        return "Product Enquiry: Success";
    }

    /** * this method will be called to handle */ once the flow is limited
    public String handlerQuery(@RequestParam(value = "p1",required = false) String p1,
                               @RequestParam(value = "p2",required = false)String p2,
                               BlockException exception){
        log.info(P1: {}, p2: {}",p1,p2);
        return "Query commodities: fusible......"; }}Copy the code

What does this code mean? As follows:

• If the query interface is not restricted, return: query item: SUCCESS
• If the query interface is throttled, it enters a bottom-pocket methodhandlerQueryMethod, return: query commodity: fusible……

2. Create a Controller interface

Let’s create a controller to test with the following code:

@RestController
@RequestMapping("/sentinel/provider")
@Slf4j
public class FlowLimitController {
    @Autowired
    private FlowService flowService;

    @GetMapping("/order/query")
    public String query(@RequestParam(value = "p1",required = false) String p1, @RequestParam(value = "p2",required = false)String p2){
        returnflowService.query(p1,p2); }}Copy the code

You can see that the interface has two parameters, p1 and p2.

3. Add traffic limiting rules for hotspot parameters

On the Sentinel console, click Hotspot Rules -> Add Hotspot Traffic Limiting Rule to add the following rule:

If the 0th QPS parameter in the OrderQuery resource is more than once a second, the flow will be limited. Here, the parameter index starts at 0, and the 0th parameter is p1 in the corresponding interface.

The first test: direct access to the browser: http://localhost:9009/sentinel/provider/order/query? P1 =22& P2 =1222, click continuously to see that the interface has been fuse degraded, as shown below:

This verifies the above configuration of hotspot parameter limiting.

The second test: browser input: http://localhost:9009/sentinel/provider/order/query? P2 =1222, click continuously and you will see that this interface has not been fuse degraded, as shown below:

Note: For hotspot parameter limiting, only parameter requests containing the specified index will be restricted.

At this point, the product says: the number of hits of the product with ID 100 is too few. Please adjust the traffic limiting rule of this product. What to do at this point?

Don’t worry, Sentinel obviously takes this into account and provides the parameter exception configuration, which is configured for product requirements as follows:

According to the above configuration, when the parameter value p1 is equal to 100, the traffic limiting threshold is set to 100. That is to say, the QPS of the request p1=100 is relaxed to more than 100 requests per second before traffic limiting.

Validation: browser input address: http://localhost:9009/sentinel/provider/order/query? P1 =100, no matter how fast you click on it, it is not demoted by fuse. Obviously, the configuration is in effect, as shown below:

The source code is available in the sentinel-OpenIgn – Provider9009 module. The source code is available at the end of the article.

10. How to limit the current based on system adaptation?

The previous hotspot parameters and common traffic limiting are for a certain interface. Here, the system adaptive traffic limiting is for the incoming traffic of the whole system, and monitors application indicators from several dimensions, such as load of a single machine, CPU usage, average RT, incoming QPS and number of concurrent threads. Let the system run as far as possible in the maximum throughput at the same time to ensure the overall stability of the system.

Sentinel console corresponds to the following figure:

There are five threshold types as follows:

• The Load adaptive(Only for Linux/ UNIX-like machines) : Load1 of the system is used as an inspiration indicator for adaptive system protection. System protection (BBR phase) is triggered when system load1 exceeds the set heuristics value and the current number of concurrent threads in the system exceeds the estimated system capacity. System capacity is determined by the systemmaxQps * minRtEstimated. The setting reference value is generallyCPU cores * 2.5.
• CPU Usage (version 1.5.0+) : When the CPU usage exceeds the threshold, system protection is triggered (value range: 0.0 to 1.0).
• Average RT: System protection is triggered when the average RT of all inlet traffic on a single machine reaches a threshold, in milliseconds.
• Number of concurrent threads: System protection is triggered when the number of concurrent threads for all incoming traffic on a single machine reaches a threshold.
• Inlet QPS: System protection is triggered when the QPS of all inlet flows on a single machine reaches the threshold.

Official documentation: github.com/alibaba/Sen…

The configuration of system rules is relatively simple. Here, the entrance QPS is used as an example to demonstrate the real situation. In order to demonstrate the real situation, remove all traffic limiting rules and add system rules, as shown below:

Rules of the QPS system configuration, the micro service in all interfaces will be limited by this rule, such as visit: http://localhost:9009/sentinel/provider/pay, click on a row, the diagram below:

You can see that the flow limiting has been implemented, not only on this interface, but on all interfaces.

Note: The entry QPS rule in the system rule is not recommended to be configured. Once configured, the entire service may be unavailable.

11. How to customize the abnormal information returned by traffic limiting?

In the previous example, the exception information returned by either fuse degrade or limiting is Blocked by Sentinel (flow Limiting), which is the default exception information of Sentinel.

It was clear that the default exception information was not sufficient for our business needs, so we needed to customize our own exception return information based on the front and back end rules.

Here we’ll use a @sentinelResource annotation, also mentioned above, that has two properties about limiting traffic to the bottom, as follows:

• blockHandler: Corresponding processingBlockExceptionThe function name of. The access range of the blockHandler function must bepublic, the return type needs to match the original method, and the parameter type needs to match the original method and add an extra parameter at the end, of typeBlockException. The blockHandler function needs to be in the same class as the original method by default.
• blockHandlerClass: specifyblockHandlerClassOf the corresponding classClassObject, note that the corresponding function must bestaticFunction, otherwise unparsed.

Official documentation: github.com/alibaba/Sen…

Use the @sentinelResource annotation to customize a stream limiting exception return message. First, you can customize a resource and specify the bottom of the loop method as handler.

Step 2: Write a method to the bottom of the deserving, must be in the same class, code as follows:

Step 3: Add a new flow limiting rule to the resource QueryOrder as shown below:

Step 4: Write a controller, the code will not be published, write yourself, ha ha…

Step 5: Call the interface, click the button, the return message defined in the bottom method will appear, as shown below:

This is basically a success, but there’s a problem: the bottom-of-the-pocket methods have to be in the same class as the business methods, so isn’t the code very coupled?

The @SentinelResource attribute blockHandlerClass solves this problem perfectly by putting bottom-pocket methods in a single class, as described below.

Step 1: Create a separate class called CommonHandler to place the backpocket method as follows:

Step 2: Specify blockHandlerClass as the above class in the @SentinelResource annotation, and blockHandler specifies the bottom-pocket method name as follows:

Good, so far finished, oneself according to try…….

The above source code is available in the sentinel-OpenIgn – Provider9009 module. See the source code at the end of this article.

12. How to degrade exceptions?

Programmers create bugs every day. No code is perfect, and no programmer is perfect. We can’t avoid runtime exceptions, but we can catch them when they happen and deal with them.

Exceptions are degraded using the @SentinelResource annotation, which has the following attributes:

• fallback: The optional fallback function name that provides fallback handling logic when an exception is thrown. The fallback function is available for all types of exceptions (exceptexceptionsToIgnoreThe type of exception that is excluded). Fallback function signature and position requirements:
  • The return value type must be the same as that of the original function;
  • The method argument list needs to be the same as the original function, or it can be an extra oneThrowableType to receive the corresponding exception.
  • The fallback function needs to be in the same class as the original method by default. You can specify if you want to use a function from another classfallbackClassOf the corresponding classClassobject
• fallbackClass: specifies the corresponding classClassObject, note that the corresponding function must be static, otherwise it cannot be parsed.
• defaultFallback(since 1.6.0) : Default fallback function name, optional, usually used for generic fallback logic (that is, can be used for many services or methods). The default fallback function can be used for all types of exceptions (exceptexceptionsToIgnoreThe type of exception that is excluded).If both fallback and defaultFallback are configured, only fallback takes effect. DefaultFallback signature requirements:
  • The return value type must be the same as that of the original function;
  • The method parameter list needs to be emptyOr you can have an extra oneThrowableType to receive the corresponding exception.
  • DefaultFallback needs to be in the same class as the original method by default. You can specify if you want to use a function from another classfallbackClassOf the corresponding classClassObject, note that the corresponding function must be static, otherwise it cannot be parsed.
• ExceptionsToIgnore (since 1.6.0) : Specifies which exceptions are excluded and are not counted in the exception statistics or fallback logic. Instead, it is thrown as is.

Starting with version 1.8.0, defaultFallback supports configuration at the class level.

Note: The fallback function before 1.6.0 only handles DegradeException, not service exception.

Official documentation: github.com/alibaba/Sen…

Define an interface to create an order and manually create a 1/0 exception as follows:

The above interface does not perform exception degradation, so calling this interface directly returns an exception message, which is very unfriendly, as shown below:

We can use fallback to specify a bottom-of-the-pocket method for exception degradation, in which case the business method is transformed as follows:

Using the fallbackClass property to specify a single class to handle exception degradation reduces the coupling of the code, and the fallback property specifies the method to degrade the bottom of the loop, as shown in the following code:

At this time, the interface is accessed again, although there is an exception, but it does return the return information of the degraded bottom method, as shown in the following figure:

At this point, the handling requirements for exception degradation are basically met, but the question remains: can you handle all exceptions in a single method?

The answer is yes and must be yes, using the defaultFallback attribute to specify the defaultFallback method. The business method becomes the following code:

The defaultFallback property specifies the default demoted bottom-pocket method, which is coded as follows:

Ok, exception degradation is covered here, but one question remains: if blockHandler and Fallback are both configured, which will take effect?

Conclusion: If both blockHandler and Fallback are configured, only the blockHandler processing logic is entered when a BlockException is thrown due to traffic limiting demotion. If blockHandler, FallBack, and defaultFallback are not configured, BlockException will be thrown when traffic limiting is degraded.

Create createOrder (blockHandler, fallback);

At this time, no rules are configured and the interface is directly accessed. It can be seen that the abnormal degradation processing is directly entered, as shown in the following figure:

For createOrder, we configure a downscaling rule: if more than 2 exceptions occur within 60 seconds, we limit the flow directly.

When we access this interface again, we can see that the first two times directly enter the method specified by Fallback (the number of exceptions does not reach the threshold of flow limiting). After two times, the flow is restricted and enters the blockHandler method. The effect is shown in the following figure:

The above source code is available in the sentinel-OpenIgn – Provider9009 module. See the source code at the end of this article.

13. How to set sentinel blacklist and whitelist?

As the name implies, blacklist means blocked, and blocked means inaccessible. Sentinel can pass or not according to the source of the request. If the whitelist is configured, only the source of the request is in the whitelist. If the blacklist is configured, the request source in the blacklist does not pass, and the rest of the requests pass.

The sentinel console configuration of due rules is shown as follows:

The rules of due to the source code for the com. Alibaba. CSP. Sentinel. Slots. Block. Authority. AuthorityRule, several properties are as follows:

• resource: Resource name, which is the object of the traffic limiting rule.
• limitApp: Indicates the corresponding blacklist/whitelist. Different origin is used.Space, such asappA,appB.
• strategy: Restricted mode,AUTHORITY_WHITEIs whitelist mode,AUTHORITY_BLACKThe mode is blacklist. The default mode is whitelist.

Official documentation: github.com/alibaba/Sen…

Here’s the question: What is the source of the request and how do you get it?

Sentinel provides an interface, RequestOriginParser, which we can implement to parse the request source name according to our own business rules.

Here I use IP as the source of the differentiated request, with the following code:

Then set 127.0.0.1 as the blacklist, as shown below:

Direct access: http://127.0.0.1:9009/sentinel/rate/order/query? Id =1002, the result is as follows:

You can see the restricted flow oh……………..

All right, so much for the black and white list.

The above source code is available in the sentinel-OpenIgn – Provider9009 module. See the source code at the end of this article.

14. How to persist traffic limiting rules?

The default traffic limiting rules of Sentinel are stored in memory. As long as the traffic limiting rules will disappear after the service restarts, this operation is definitely not allowed in actual production. Therefore, the persistence of traffic limiting rules is imminent.

Sentinel official documentation provides two persistence modes, which are as follows:

However, the Push mode is officially recommended. Chen introduces the persistent traffic limiting rules in Push mode. Nacos is used as the configuration center.

Embezzled an official architecture diagram as follows:

1. Add dependencies

Here we need to add a dependency as follows:

<dependency>
      <groupId>com.alibaba.csp</groupId>
      <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>
Copy the code

2. Configure related information in the configuration file

Since Nacos is used as the configuration center, you must configure the relevant address, dataId…

Add the following configuration to the application.yml configuration file:

spring:
  cloud:
    sentinel:
      ## nacOS persistent configuration
      datasource:
        Configure the flow control rule with any name
        ds-flow:
          nacos:
            Address of ## nacos
            server-addr: 127.0. 01.: 8848
            ID # # configuration
            dataId: ${spring.application.name}-flow
            Configure groups. Default is DEFAULT_GROUP
            groupId: DEFAULT_GROUP
            Configure the format of the storage
            data-type: json
            # # -type rule set match rule type, a total of seven major types, in com. Alibaba. Cloud. Sentinel. The datasource. RuleType this enumeration class
            rule-type: flow
        Configure the reversion rule with any name
        ds-degrade:
          nacos:
            Address of ## nacos
            server-addr: 127.0. 01.: 8848
            ID # # configuration
            dataId: ${spring.application.name}-degrade
            Configure groups. Default is DEFAULT_GROUP
            groupId: DEFAULT_GROUP
            Configure the format of the storage
            data-type: json
            # # -type rule set match rule type, a total of seven major types, in com. Alibaba. Cloud. Sentinel. The datasource. RuleType this enumeration class
            rule-type: degrade
Copy the code

The above configuration only shows some configuration related to persistence, other relevant configuration code is not posted, later to see the source code.

Spring. Cloud. Sentinel. You can configure multiple rules under the datasource, XXL here only configure the current limit and degradation rules, trying to match the other rules, through the rule – type to distinguish different rules, Its values are com. Alibaba. Cloud. Sentinel. The datasource. This enumeration class, RuleType corresponds to the sentinel of several statistical rules.

3. Add the corresponding rule configuration in Nacos

The flow limiting rule in the preceding configuration is as follows:

The corresponding degrade rule in the above configuration is shown below:

After all the release, there are two configurations in Nacos, as shown below:

In the figure above, you can see that our two rules have been configured in Nacos. Let’s see if sentinel is in effect, as shown below:

Oh, it’s working. Since it’s push mode, when you click publish configuration in NACOS, the rule configuration will be pushed to Sentinel.

The above source code is available in the sentinel-OpenIgn – Provider9009 module. See the source code at the end of this article.

Foreshadowing: Push mode can only ensure that changes in Nacos are pushed to the Sentinel console, ** But how can changes in limiting rules in the Sentinel console be pushed to Nacos? ** Don’t worry,………….. will be introduced below

4. How to write in JSON?

A lot of people are wondering what configuration is in JOSN. XXL, actually very simple, is to introduce all kinds of rules are explicitly tell you each rule of the corresponding source implementation class, such as flow control rules of the corresponding class is com. Alibaba. CSP. The sentinel. Slots. Block. Flow. FlowRule, various properties of JOSN is also derived from this class.

Below Chen lists the JSON configuration of each rule, which can be changed according to the development.

1. Flow control rules

[{/ / resource name
    "resource": "/test".// For the source, if it is default, call the source regardless
    "limitApp": "default".// Traffic limiting threshold type (1:QPS; 0: number of concurrent threads)
    "grade": 1./ / threshold
    "count": 1.// Whether cluster mode is used
    "clusterMode": false.// Flow control effect (0: fast failure; 1:Warm Up; 2: Waiting in line)
    "controlBehavior": 0.// Flow control mode (0: direct; 1: association; 2: link)
    "strategy": 0.// Preheat time (seconds, this parameter is required for preheat mode)
    "warmUpPeriodSec": 10.// Timeout time (this parameter is required in queuing mode)
    "maxQueueingTimeMs": 500.// Associate resource, import resource (association, link mode)
    "refResource": "rrr"}]Copy the code

2. Demotion rules

[{/ / resource name
    "resource": "/test1"."limitApp": "default".// Fuse policy (0: slow call ratio, 1: exception ratio, 2: exception count)
    "grade": 0.// Maximum RT, proportion threshold, number of exceptions
    "count": 200.// Slow call ratio threshold, only slow call ratio mode is valid (introduced in 1.8.0)
    "slowRatioThreshold": 0.2.// Minimum number of requests
    "minRequestAmount": 5.// When the unit is counted (default: 1000)
    "statIntervalMs": 1000.// Fuse duration
    "timeWindow": 10}]Copy the code

3. Hotspot rules

[{/ / resource name
    "resource": "/test1".// Current limiting mode (QPS mode, unchangeable)
    "grade": 1.// Parameter index
    "paramIdx": 0.// Single-machine threshold
    "count": 13.// Count the window duration
    "durationInSec": 6.// Whether the cluster defaults to false
    "clusterMode": the defaultfalse.// 
    "burstCount": 0.// Cluster mode configuration
    "clusterConfig": {
      // 
      "fallbackToLocalWhenFail": true.// 
      "flowId": 2.// 
      "sampleCount": 10.// 
      "thresholdType": 0.// 
      "windowIntervalMs": 1000
    },
    // Flow control effect (support fast failure and uniform queuing mode)
    "controlBehavior": 0.// 
    "limitApp": "default".// 
    "maxQueueingTimeMs": 0.// Advanced options
    "paramFlowItemList": [{// Parameter type
        "classType": "int".// Traffic limiting threshold
        "count": 222./ / parameter values
        "object": "2"}}]]Copy the code

4. System rules

A negative value indicates that there is no threshold check. You do not need to delete parameters

[{// RT
    "avgRt": 1.// CPU usage
    "highestCpuUsage": - 1.// LOAD
    "highestSystemLoad": - 1./ / the number of threads
    "maxThread": - 1./ / entrance QPS
    "qps": - 1}]Copy the code

5. Authorization Rules

[{/ / resource name
    "resource": "sentinel_spring_web_context".// Flow control application
    "limitApp": "/test".// Authorization type (0 represents whitelist; 1 indicates the blacklist.)
    "strategy": 0}]Copy the code

Note: Some of the optional attributes in the above JOSN can be removed if they are not needed.

Official documentation: github.com/alibaba/Sen…

15. How to push traffic limiting rules to Nacos for persistence?

The default persistence of Sentinel can only be pushed from nacOS to the Sentinel console, but in real production changes can be pushed in both directions. How to solve this problem?

In fact, the Sentinel official documentation has a solution, but you need to modify the sentinel console source code to achieve this.

Sentinel only helps us to implement the demo of flow control rules, and we need to modify the rest by ourselves, which is not very humane….

Download the source code for sentinel console at github.com/alibaba/Sen…

Flow control rule source code modification

In the test directory of the source code, there are demos provided by Sentinel, including Apollo, NACOS and ZooKeeper, as shown below:

Here we are Nacos, so we only need the demo under the Nacos package. The modification procedure is as follows:

1. Remove the ScoP dependent on Sentinel-datasource-NACos

The sentinel-datasource-nacos dependency defaults to

test
, so we need to remove this as follows:

<! -- for Nacos rule publisher sample -->
<dependency>
       <groupId>com.alibaba.csp</groupId>
       <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>
Copy the code

If you integrate ZooKeeper or Apollo, change the corresponding dependencies as well.

2. Copy the entire nacOS package in the test environment to main

Copies the nacos package to com. Alibaba. CSP. Sentinel. Dashboard. The rule under this package, the diagram below:

Copy the code from FlowControllerV2 to FlowControllerV1

Com. Alibaba. CSP. Sentinel. Dashboard. Controller. The v2. This is to provide the demo, sentinel FlowControllerV2 Only need to cover all the code to com. Alibaba. CSP. The sentinel. Dashboard. Controller. FlowControllerV1.

Modify the code in FlowControllerV1

Of course, it can’t be overwritten directly, but some modifications should be made as follows:

• Change the request URL in RequestMapping to/v1/flow
• Modify theruleProvider,rulePublisherThe modified code is as follows:

	@Autowired
    // Use nacOS dependencies
    @Qualifier("flowRuleNacosProvider")
    private DynamicRuleProvider<List<FlowRuleEntity>> ruleProvider;
    @Autowired
    // Use nacOS dependencies
    @Qualifier("flowRuleNacosPublisher")
    private DynamicRulePublisher<List<FlowRuleEntity>> rulePublisher;
Copy the code

5. Note the configuration of NACOS

Com. Alibaba. CSP. Sentinel. Dashboard. Rule. Nacos. NacosConfigUtil this utility class is corresponding to the current limiting rules in nacos some configuration items, a groupId, dataId… The configuration is as follows:

Need to unify both sides, you can modify.

Com. Alibaba. CSP. Sentinel. Dashboard. Rule. Nacos. NacosConfig this class has a method below:

The default specified NACOS address is local, which needs to be changed.

6, complete

The above steps have transformed the flow control rules of the Sentinel console and packaged the start console code as follows:

mvn clean install -DskipTests=true -pl sentinel-dashboard -am
Copy the code

After startup, add flow control rules in the console, and you can see that they will also be synchronously pushed to nacOS, including additions, deletions and changes.

Other rule changes are also very simple. I won’t go into details here, but I’ll write a separate article later.

16. How to do cluster flow control?

First a simple question: why does ** need cluster flow control? Does the single-machine flow control smell good? Here’s why:

• For microservices, to ensure high availability, it must be a cluster. Suppose there are 100 clusters. If you want to set flow control rules, do you need to set each microservice once? Maintenance costs are too high
• Single flow control will also cause uneven flow, and the total flow control threshold does not reach some micro-services have been restricted, which is a very bad problem. Therefore, single flow control is not recommended for clusters in actual production.

So how to solve the above problems? Sentinel provides us with the rules of cluster flow control. The idea is simply to provide a dedicated server to count the total number of calls, with other instances communicating with the server.

Cluster flow control can accurately control the total number of calls in the whole cluster. Combined with single-node flow limiting and bottom pocket, the flow control effect can be better played.

Cluster flow control has two identities:

• Token Client: a cluster flow control Client that communicates with the owning Token Server to request a Token. The cluster traffic limiting server returns the result to the client to determine whether to limit traffic.
• Token Server: the flow control Server of the cluster processes the requests from the Token Client and determines whether to issue the Token based on the configured cluster rules.

There are two modes of cluster limiting for Sentinel, which are as follows:

• Alone mode: That is, it is started as an independent Token Server process and deployed independently. It is isolated, but requires additional deployment operations. The independent mode is suitable for providing flow control services for the cluster as Global Rate Limiter.
• Embedded mode: As a built-in Token server, the service is started in the same process. In this mode, all instances in the cluster are peer, and the Token server and client can be changed at any time. Therefore, there is no need to deploy the token server and client separately. However, due to poor isolation, the total QPS of the Token Server needs to be limited to prevent the application itself from being affected. The embedded mode is suitable for flow control within an application cluster.

The embedded mode is used as an example to describe how to configure it.

Take the sentinel-OpenFeign-Provider9009 module as a demonstration and directly start three clusters with ports 9009, 9011 and 9013, as shown below:

The sentinel console will see that three instances have been monitored, as shown below:

In this case, you only need to specify one service on the console as token Server and the other services as Token clients. Cluster flow control -> Add token Server. The operations are as follows:

Select one as the server and the other two as clients, and you are already configured as shown below:

At this point, cluster flow control rules can be added directly on the Sentinel console or configured through Nacos. The following is the configuration using Nacos, as shown below:

After Nacos is pushed successfully, the configuration of the flow control rule will be seen in sentinel console, as shown below:

OK, so far the cluster flow control here is introduced, after the configuration can try the effect, Chen will no longer demonstrate.

Official documentation: github.com/alibaba/Sen…

17. How to configure traffic limiting on the gateway?

This content will be discussed in detail in the follow-up introduction to the gateway. I will not go into details here. If you want to know more, you can see the official documents.

Official documentation: github.com/alibaba/Sen…

18. How to integrate openFeign to achieve fusible downgrading?

This was covered in detail in the last openFeign article: openFeign Kills serial 9 asks, Who can stand this? Chen here is no longer repeated introduction, do not know can see this article above.

One last word

Chen code word is not easy, this article has been written for two weeks, if you feel good, like, forward, look at the collection support, thank you!

The above source code has been uploaded to GitHub, need the public number [code monkey technology column] reply keywords 9528 to obtain.