Previous article: Nacos Configuration Center
Table of contents
Sentinel introduction ( official introduction )
Sentinel is a flow control, circuit breaker and degradation component for cloud-native microservices. Replace Hystrix to address problems: service avalanche, service degradation, service circuit breaker, service current limiting
Hystrix：
Service consumer -> Call service provider
Introduce Hystrix on the caller -> Create a separate Dashboard project -> Turbine
1) Build your own monitoring platform dashboard
2) No UI interface is provided for configuration such as service circuit breaker and service degradation (while It was writing code that invaded our source program environment)
Sentinel:
1) Independently deployable Dashboard/console components
2) Reduce code development and complete fine-grained control (delivery microservices) through UI interface configuration
Sentinel has the following characteristics:
Rich application scenarios : Sentinel has taken over the core scenarios of Alibaba’s Double Eleven traffic promotion in the past 10 years, such as flash sales (that is, burst traffic is controlled within the range that the system capacity can bear), message peak-shaving and valley-filling, and real-time circuit breaker for downstream users. Unavailable applications, etc.
Complete real-time monitoring : Sentinel also provides real-time monitoring functions. You can see the second-level data of a single machine connected to the application in the console, and even the summary operation status of a cluster of less than 500 machines.
Extensive open source ecosystem : Sentinel provides out-of-the-box integration modules with other open source frameworks/libraries, such as integration with Spring Cloud, Dubbo, and gRPC. You only need to introduce the corresponding dependencies and perform simple configuration to quickly connect to Sentinel.
Complete SPI extension points : Sentinel provides easy-to-use, complete SPI extension points. You can quickly customize logic by implementing extension points. For example, customized rule management, adapted data sources, etc.
Sentinel ’s main features:
Sentinel ’s open source ecosystem:
Sentinel deployment
Download address: https://github.com/alibaba/Sentinel/releases We use v1.8.0
to start: java -jar sentinel-dashboard-1.8.0.jar &
username/password: sentinel/sentinel
Service transformation
- consumer services
lagou-service-autodeliver-8094-sentinel
- rely
<dependencies>
<!--sentinel 核⼼环境 依赖-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<!-- <dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>-->
</dependencies>
- Configuration
server:
port: 8094
spring:
application:
name: m-service-autodeliver
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850
sentinel:
transport:
dashboard: 127.0.0.1:8888
port: 8719
#针对的被调⽤⽅微服务名称,不加就是全局⽣效
m-service-autodeliver:
ribbon:
#请求连接超时时间
ConnectTimeout: 2000
#请求处理超时时间
ReadTimeout: 5000
#对所有操作都进⾏重试
OkToRetryOnAllOperations: true
####根据如上配置，当访问到故障请求的时候，它会再尝试访问⼀次当前实例（次数由MaxAutoRetries配置），
####如果不⾏，就换⼀个实例进⾏访问，如果还不⾏，再换⼀次实例访问（更换次数由MaxAutoRetriesNextServer配置），
####如果依然不⾏，返回失败信息。
MaxAutoRetries: 0 #对当前选中实例重试次数，不包括第⼀次调⽤
MaxAutoRetriesNextServer: 0 #切换实例的重试次数
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #负载策略调整
# 暴露健康接⼝的细节
management:
endpoints:
web:
exposure:
include: "*"
endpoint:
health:
show-details: always
#负载策略调整
logging:
level:
# Feign⽇志只会对⽇志级别为debug的做出响应
com.w.edu.service.ResumeServiceFeignClientFallback: debug
-
nacos cluster
-
Access the interface http: http://localhost:8094/autodeliver/checkState/1545132 multiple times to observe the Sentinel console
Sentinel Key Concepts
Flow control rules - cluster point links, flow control rules
direct mode
- QPS type : (Number of requests per second) Limit the flow when the QPS calling the resource reaches the threshold
-
Whether the new flow control rule
is clustered : Whether it is clustered. Current limiting Flow
control mode :
Direct : When the resource call reaches the current limiting condition, the flow is limited directly.
Association : When the associated resource call reaches the threshold, the flow is limited. Own
link : Only the specified link is recorded. Traffic
flow control effect on the road :
Fast failure : Direct failure, throwing an exception
Warm Up : According to the value of the cold load factor (default 3), from the threshold/cold load factor, after the warm-up time, the set QPS threshold is
reached
Queuing and waiting : queue at a uniform speed to allow requests to pass at a uniform speed. The threshold type must be set to QPS, otherwise it will be invalid. -
Multiple accesses within 1 second, fast failure
- Number of threads: When the number of threads calling resources reaches the threshold, the current is limited.
- Multiple accesses within 1 second, fast failure
association mode
When the associated resource call reaches the threshold, it limits itself. For example, the user registration interface needs to call the ID card verification interface (often the ID card verification interface). If the ID card verification interface request reaches the threshold, use the association to call the user registration interface. perform current limiting
@RestController
@RequestMapping("/user")
public class UserController {
/**
* ⽤户注册接⼝
* @return
*/
@GetMapping("/register")
public String register() {
System.out.println("Register success!");
return "Register success!";
}
/**
* 验证注册身份证接⼝（需要调⽤公安户籍资源）
* @return
*/
@GetMapping("/validateID")
public String findResumeOpenState() {
System.out.println("validateID");
return "ValidateID success!";
}
}
-
Create current limiting rules
-
Multiple accesses within 1 second, intensive requests to the /user/validateID verification interface, we will find that the /user/register interface is also restricted.
link mode
Link refers to the request link (call chain)
In link mode, the traffic of the call link entry where the resource is located is controlled. The inlet resource needs to be configured in the rule, that is, the context name of the call link inlet.
A typical call tree is shown in the figure below: (Provided by Alibaba Cloud)
In the figure above, requests from portals Entrance1and Entrance2 are all called to resource NodeA. Sentinel allows
resource flow limitation based only on the statistical information of a certain call portal. For example, in link mode, set the entrance resource to to Entrance1indicate that only
Entrance1calls from the entrance will be recorded in NodeA's current limiting statistics, regardless of incoming Entrance2 calls.
flow control effect
Fast failure : direct failure, throwing an exception.
Warm Up : According to the value of the cold load factor (default 3), from the threshold/cold load factor, after the warm-up time, the set QPS threshold is reached. Queue waiting: queue at a uniform speed to make requests
uniform . Passed, the threshold type must be set to QPS, otherwise it will be invalid
fail fast
Fails directly and throws an exception
Warm Up
Through the Warm Up mode (preheating mode), the passing traffic slowly increases. After the set warm-up time, it reaches the set value of the system processing request rate.
Warm Up mode will start from 1/3 of the set QPS threshold and slowly increase upward to the QPS setting value by default.
Waiting in line
In the queuing and waiting mode, the interval time between requests is strictly controlled, that is, the requests are passed at a uniform speed, and some requests are allowed to be queued and waited. It is usually used in scenarios such as peak-cutting and valley-filling of message queues. A specific timeout needs to be set. When the calculated waiting time exceeds the timeout, the request will be rejected.
When a lot of traffic comes, the requests are not rejected directly, but the requests are queued and passed (processed) one by one at a constant speed. If the requests can wait, they will be processed. If they cannot wait (waiting time > timeout time), they will be rejected.
queue effect
