1. Introduction of Sentinel Service Protection Framework
Why does the interface visit too much crash
QPS = 1 can only be accessed once per second.
Number of threads = semaphore isolation, which is the maximum number of threads used by the interface
dash board?
Fail fast
Sentinel defaults the current limit rule is not persistent, to persist, use zk, nacos, Apollo
To limit the current in the gateway, we must integrate the gateway
2. What are the options for service interface protection?
Black and white list
Realize current limit / fuse mechanism for IP
Service degradation
Service isolation mechanism
Service current limit: The purpose is to protect our services. In the case of high concurrency, if the client requests the server to reach a certain limit (set threshold), the number of requests exceeds the set threshold, open the self-protection mechanism, and directly execute our Service downgrade method, will not execute our business logic, take the local falback method
Service degradation: In the case of high concurrency, in order to prevent users from waiting, use current limit or fuse mechanism to protect our service, will not execute business logic, take the local falback method
Service avalanche: By default, the tomcat / jetty server has only one thread pool to handle all interface requests. In the case of high concurrency, access to the same interface occupies all thread pool connections, making other interfaces inaccessible
Service avalanche solution:
service isolation mechanism: thread pool isolation or semaphore isolation mechanism
thread pool isolation: each interface has its own independent thread pool to maintain our requests, and each thread pool does not affect each other, that is, each interface has an independent The disadvantage of using a thread pool is that it occupies a very large
amount of server memory. Semaphore isolation: setting allows one of our interfaces to have a threshold number of threads to handle the interface. If it exceeds the number of threads, it denies access.
3. What is the difference between Sentinel and hytrix?
Four, current limit configuration two schemes
1. Use manual code configuration
2. Sentinel console configuration
3. By default, Sentinel does not persist data and needs to be independently persisted
Steps to achieve:
1. Create flow control (limiting) rules
Five, sprngboot integrated console
Console configuration
Download the corresponding Sentinel-Dashboard
https://github.com/alibaba/Sentinel/releases/tag/1.7.1 and run.
Run the execution command
java -Dserver.port = 8718 -Dcsp.sentinel.dashboard.server = localhost: 8718 -Dproject.name = sentinel-dashboard -Dcsp.sentinel.api.port = 8719 -jar
The account password is sentinel
login address 127.0.0.1:8718
springboot configuration
1, yml configuration sentinel
2, the default resource name is the interface address such as / xxx
3, the interface is annotated, and the current limit friendly prompt blockHandler
six,
7. Service fuse and service degradation
Service fuse: The interface call time (service response time) exceeds the specified time
Service degradation: the interface cannot be accessed again for a period of time The
interface call time (service response time) exceeds the specified time, and the interface cannot be accessed again for a period of time
8. Four schemes for persistence of sentinel rule data
1. Nacos distributed configuration center: interface, no need to restart the server, recommended
2. Ctrip Apollo: interface, no need to restart the server, recommended
3. ZK, no interface, not recommended
4. Stored in local files: easy data Inconsistent data, not recommended?
The configured current limit will be cleared after the server restarts
Sentinel reads the flow control rules on naocs to memory when it starts
Integrating nacos is as long as yml is configured. The rules are written on nacos. After integration, you cannot configure the flow control rules in the code yourself, otherwise the rules on nacos will be overwritten.
Nine, Sentinel integration gateway to achieve current limiting
Because when accessing, they are all accessed through the gateway
1. Yml configuration
2. Add two configuration classes, one integrated configuration, one rule configuration
3. Introduce integrated dependencies
4. Eliminate conflicts in gateway web dependency package
4. Rewrite the default prompt method
Ten, to achieve dynamic fuse degradation of services
Reaching the threshold and taking the service downgrade fallback method will not really execute our business logic
Three strategies for service degradation:
1. rt (average response time): The access response time of the interface exceeds the specified threshold within one second, which triggers the service fuse and calls the service degradation method. Within the specified time (time window second), it cannot be accessed again Interface, accessed five times in one second, the average response time of five times exceeds the threshold, the maximum threshold is 4.9 seconds, the maximum threshold must be changed to change the configuration
2, abnormal ratio: the ratio of abnormal requests in one second exceeds the specified threshold, service Downgrade, time window (seconds)
-3. Abnormal times: The number of abnormal requests in one minute exceeds the specified threshold, service degradation, time window (minutes)-
Can use multiple strategies simultaneously
eleven,
twelve,
thirteen,
fourteen,
fifteen,
sixteen,
17.
eighteen,
19.
twenty,
twenty one,
twenty two,
twenty-three,
twenty four,
twenty five,
Twenty-six,
Twenty-seven,
Twenty-eight,
Twenty-nine,
thirty,
