Hystrix focuses on the fault-tolerant mechanism of isolation and fuse, the call of timeout or fuse will fail quickly, and it can provide a fallback mechanism, while Sentinel focuses on the following relations:
Diversified flow control
Fuse upgrade
System load protection
Real-time monitoring and console
It can be seen that the problems solved by the two are still very different. Let's compare them separately.
Hystrix's resource model is designed in command mode, which encapsulates the calling and fallback logic of external resources into a command object (HystrixCommand? /? HystrixObservableCommand), whose underlying execution is based on RxJava. When creating each command, you should specify commandKey and groupKey (used to distinguish resources) and the corresponding isolation policy (thread pool isolation or semaphore isolation). In the thread pool isolation mode, the parameters corresponding to the thread pool (thread pool name, capacity, queuing timeout, etc.). ) needs to be configured, and then the command will be executed in the specified thread pool according to the specified fault-tolerant policy; The maximum number of concurrency needs to be configured in semaphore isolation mode, and Hystrix will limit its concurrent calls when executing commands.
Sentinel's design is simpler Compared with Hystrix command's strong dependence on isolation rules, Sentinel's resource definition is less coupled with rule configuration. Hystrix's command strongly depends on the configuration of isolation rules, because isolation rules will directly affect the execution of the command. Hystrix will analyze the isolation rules of commands to create RxJava scheduler and schedule execution on it. If it is a thread pool mode, the thread pool at the bottom of the scheduler is the configured thread pool. If it is a semaphore mode, it is simply packaged as the scheduler for the current thread execution. Sentinel does not specify the execution model, nor does it care how the application is executed. The principle of Sentinel is simple: according to the rules of corresponding resource allocation, the corresponding current limiting/degradation/load protection strategy is implemented for resources. In Sentinel, resource definition and rule configuration are separated. Users first define resources (buried points) for corresponding business logic through Sentinel API, and then can configure rules when needed. There are two ways to bury points:
Trying to capture mode (via SphU.entry (...)), the user performs exception handling/fallback in the catch block.
If-else mode (via SphO.entry (...)), exception handling/fallback is performed when false is returned.
Sentinel provides a variety of rule configuration methods. Besides going straight through? Loading rules? The API registers rules outside the memory state, and users can also register various external data sources to provide dynamic rules. Users can dynamically change the rule configuration according to the current real-time situation of the system, and the data source will push the changes to Sentinel and take effect immediately.
Isolation is one of the core functions of Hystrix. Hystrix provides two isolation strategies: thread pool isolation and semaphore isolation, among which thread pool isolation is the most recommended and commonly used. Hystrix's thread pool isolation creates different thread pools for different resources, and different service calls occur in different thread pools, which can quickly fail in the case of thread pool queuing, timeout and other blocking situations, and can provide a fallback mechanism. The advantage of thread pool isolation is that it has a high degree of isolation, and can process the thread pool of one resource without affecting other resources, but at the expense of thread context switching, especially for low-latency calls.
However, in reality, thread pool isolation does not bring much benefit. The first is that too many thread pools will greatly affect performance. Consider a scenario in which Hystrix is used in a Servlet container like Tomcat, and the number of threads in Tomcat itself is very large (there may be dozens or hundreds). If you add the thread pool created by Hystrix for various resources, the total number of * * * threads will be very large (hundreds of threads), which will cause great losses when switching contexts. In addition, the complete isolation of thread pool mode enables Hystrix to handle the queuing and timeout of thread pools with different resources respectively, but this is actually a problem that needs to be solved in timeout fuse and flow control. If the component has the ability of timeout fusion and flow control, thread pool isolation is unnecessary.
Sentinel can provide the function of semaphore isolation through the flow control of concurrent thread counting mode. This isolation is very lightweight, only limiting the number of concurrent calls to a resource, rather than explicitly creating a thread pool, so the overhead is small, but the effect is good. Combined with the fuse degradation mode based on response time, unstable resources can be automatically degraded when the average response time is high, so as to avoid too many slow calls occupying concurrency and affecting the whole system. Hystrix's semaphore isolation is relatively simple, so it can't automatically downgrade the slow call, so it can only wait for the client to time out, so there may still be cascading blocking.
Comparison of fuze degradation The fuze degradation of sentinel and Hystrix is essentially based on fuze mode.
? Sentinel and Hystrix both support fuze degradation based on failure rate (anomaly rate)? At this point, all calls to this resource will be blocked and will not be resumed heuristically until the specified time window has passed. As mentioned above, Sentinel also supports fuse degradation based on average response time, which can automatically blow when the service response time continues to soar, reject more requests, and recover after a period of time. This can prevent cascading congestion caused by very slow calls.
Real-time index statistics to achieve comparison
Hystrix and Sentinel are both based on sliding windows. Hystrix before 1.5 is a sliding window realized by circular array, and the statistical information of each bucket is updated through the operation of lock and CAS. Hystrix 1.5 began to reconstruct the realization of real-time index statistics, abstracting the data structure of index statistics into the form of reaction flow, which is convenient for consumers to use index information. At the same time, the bottom layer is transformed into an event-driven mode based on RxJava, which sends out corresponding events when the service call is successful/failed/overtime. Through a series of transformations and aggregation, a real-time indicator statistical data stream is finally obtained, which can be consumed by fuses or Dashboard.
Sentinel currently abstracts the statistical interface of metrics, and the bottom layer can have different implementations. At present, the default implementation is a sliding window based on LeapArray, and reactive stream and other implementations may be introduced as needed.
Characteristics of sentry
In addition to the * * * functions mentioned above, Sentinel also provides the following functions:
Lightweight, high performance?
Sentinel is a fully functional and highly available flow control component, and its core sentinel-core has no unnecessary dependence. Less than 200K after packaging, very lightweight, developers can safely introduce? Sentinel core? Don't worry about dependencies, sentinel provides a variety of extension points, which users can easily expand according to their needs and seamlessly switch to Sentinel.
The performance loss caused by introducing Sentinel is very small. Only when the QPS of a single business machine exceeds 25 W will there be some significant impact (about 5%- 10%), and the loss can be almost ignored when the QPS of a single business machine is not too large.
flow control
Sentinel can run different indicators for different calls? Such as QPS, number of concurrent calls, system load, etc. ) and the random request is adjusted to an appropriate shape.
Sentinel supports a variety of traffic shaping strategies, and when the QPS is too high, it can automatically adjust the traffic to the appropriate shape. Commonly used are:
Direct rejection mode: that is, directly reject the exceeded request.
Slow-start preheating mode: when the flow surges, control the flow, let the flow increase slowly, and gradually increase to the upper limit of the threshold within a certain period of time, so as to give the cooling system a preheating time to avoid the cooling system being crushed.
Unified model? The uniform speed mode implemented in leaky bucket strictly controls the time interval for requests to pass. At the same time, accumulated requests will be queued, and requests that exceed the timeout period will be rejected directly.
Sentinel uterus
The isolation strategy is based on concurrent thread pool isolation/semaphore isolation.
Fuze degradation strategy is based on response time or failure rate.
Real-time indicator to realize sliding window sliding window (based on RxJava)
Rule configuration supports multiple data sources.
Extensible form of multiple extension point plug-ins
Annotation-based support will be released soon.
Call link information supports synchronous calls, but does not support synchronous calls.
Current limiting is based on QPS/ concurrency, which supports current limiting based on call relationship, but does not.
Traffic shaping supports slow start, but constant speed mode does not.
System load protection support is not supported.
Real-time monitoring APIs are various and relatively simple.
The console is ready to use. It can configure rules, check secondary monitoring, machine discovery and other imperfections.
Adapting servlets of common frameworks, servlets such as Spring Cloud, Dubbo and gRPC, and Netflix of Spring Cloud.
Article source/educast/article/details/88735339