preface
One of the more popular news in GitHub recently is the deprecation of trending; Indeed, as an organization that pursues the value of technology, github abandons the worthless trending, which is a good thing, some inferior projects have occupied the top of the list for a long time, and indeed have a very big evil that misleads technology; Also as a domestic website that claims to be the largest IT technology forum in China, this issue should also be taken seriously; Look at the first few articles on the list, it’s really shabby; Today in the list to see an article written springcloud, the fuse stays on the basis of the springboot 2.1.x version, such an article, can still be called innovation; so today we will take a good look at several mainstream fuses in Springcloud
Fuse
In the microservice architecture, the service is split into a number of single microservice units (Springboot programs), and the services are called RPC through the service discovery mechanism and borrow HTTP/TCP. Considering the possible network reasons or the service itself, when the service or RPC network is unusable (accessible), if there is a problem with a source service, such as network latency, it will have a corresponding impact on the invocation service, and sometimes even due to too many simultaneous access targets, it will lead to service paralysis and even lead to a “avalanche” of the service. Fuses are a strategy for dealing with this risk of disaster; That is, when the service can not be used is or the service reaches a certain critical point, the service is blocked in the way of processing, in this way, such a disaster service can be tolerated, without making the really big system collapse, a bit like the circuit break box in the home electricity, a line load is too heavy, just cut off the line, and the entire home line can still provide services.
Fuses in several Springcloud frames
Note here that there are many products of fuses; What we particularly emphasize here is that the fuse here is in the Springcloud architecture, that is, it is built in the Springcloud architecture system, and without Springcloud, these products are lifeless; It can only be used in the Java environment, and your microservices must also be implemented in Java, and to be quick to build, you must also use the components that Springboot has provided in springcloud (of course, you can call themselves through the APIs of these products)
Isolation level
Semaphore mode
In this mode, receiving requests and executing downstream dependencies are done within the same thread, and the implementation is also very simple, a simple counter, when the request enters the fuse, execute tryAcquire(), the counter plus 1, if the result is greater than the threshold, it returns false, a semaphore rejection event occurs, and the degradation logic is executed. When the request leaves the fuse, release() is performed, and the counter is minus 1. hmi screen panel
Semaphore patterns are all in a thread context; There is no performance overhead associated with thread context switching, so most scenarios should choose semaphore mode, but in the following case, semaphore mode is not a good choice.
For example, an interface relies on 3 downstreams: serviceA, serviceB, serviceC, and the data returned by these 3 services is not dependent on each other, in this case, if the fuse degradation for A, B, C uses the semaphore mode, then the interface time consumption is equal to the sum of the time it takes to request A, B, and C services, which is undoubtedly not a good solution.
Thread pool mode
In this mode, user requests are submitted to their respective thread pools for execution, separating the threads executing each downstream service, thus achieving resource isolation. When the thread pool is too late to process and the request queue is stuffed, new incoming requests will fail quickly, avoiding dependency problems from spreading. Thread pool mode is split due to thread resource segmentation; Reduce the impact of the dependent service failure, such as the ServiceA service exception, resulting in a large number of requests timeout, the corresponding thread pool is full, then does not affect the serviceB, ServiceC calls.
But the biggest drawback of the thread pool pattern: requests are executed in the thread pool, which definitely introduces the overhead of task scheduling, queuing, and context switching. Because it involves cross-threading, there is a problem with the transmission of ThreadLocal data, such as the ThreadLocal variable initialized in the main thread, which cannot be obtained in the thread pool thread; Here the author used Hystrix’s thread pool isolation method in the early microservice project, encountered similar pits, of course, know the underlying reasons have corresponding countermeasures; Here is a separate article to talk about this pit.
The current state of the three mainstream fuses
Hystrix
Netfix has discontinued the Hystrix project, starting with the SpringCloud version 2020.0.x project, many netfix components have been removed from springcloud support, including Eureka, Hystrix, Ribbon; So the Hystrix fuse has been abolished from the Springcloud solution, and if you’ve used Hystrix in your project, then please find a replacement product when your SpringCloud upgrades next time; If your project hasn’t started yet, then don’t use Hystrix anymore, use Springcloud’s official recommended Environment;
Resilience4j
After Hystrix was removed from the SpringCloud family, SpringCloud officially recommended another project, Resilienc4j, which is still relatively niche, and this open source project can be found on github; In the comparison of the three products in the figure above, we can see that in the three products, resilience4j is a moderate positioning; There is not much support in terms of function, but the function can also cover most of the requirements for fuses; As far as the author’s personal use is concerned, the current resilience documentation is relatively not rich enough, not much is used, the document is relatively difficult to find, but resilience4j is very lightweight, as the development needs to have some of its own customization of the fuse, it is recommended to use this product; At present, the support of resilience for feign can only be said to be supported, but it is not particularly convenient to support, if you want to support the application of feign more conveniently, you can only further encapsulate on the basis of resilience4j. Overall, it is superior to Hystrix and can be expanded and applied flexibly.
Sentinel
First of all, this is a product produced by Alibaba; All of his features are common to Alibaba products; Dirty, messy, but not bad! In the comparison of the three products in the figure above, you can see most of the comparison aspects, Sentinel is the winner, indeed, from a functional point of view, Sentinel is relative to the other two, is more comprehensive, but also provides a Sentinel dashboard, can be viewed graphically, through the integration with nacos, you can put the read-only configuration, to achieve a read-write configuration; But the whole project is too encapsulated, giving you not enough space for expansion and application; For technicians and projects that are not very demanding, Sentinel is recommended; However, if there is a certain requirement, it is recommended to use Resilienc4j.
