What comes after Hystrix
A few days ago Netflix made an important change in Hystrix’ README.md, announcing that the project “is no longer in active development, and is currently in maintenance mode”:
Over the past few months, maintenance seems to have slowed.
Netflix is now calling for members of the community to take ownership of the project, but I have been unable to find any indication that someone will do so.
Given that many companies (including willhaben) and frameworks (e.g. spring) use Hystrix as an implementation of the circuit breaker pattern, it is a troubling to think that no new releases or bug fixes are in sight.
What do we use Hystrix for?
As I mentioned, Hystrix implements the circuit breaker pattern. A circuit breaker object wraps a call to a different service (e.g. a call to a REST API) and keeps track of failures for this call.
If the number of failures reach a predefined threshold, the circuit breaker “opens”, which means that, instead of calling the underlying service, it returns a fixed (fallback or error) value, so that the failure does not propagate across services. After some time, the circuit “closes” again and permits calls to the underlying service.
The statistics data the circuit breaker object collects is also a valuable source of information, as it can be used for monitoring and alarming. Micrometer for example has built-in support that allows Hystrix to collect metrics.
Is resilience4j an alternative?
Resilience4j is a library mentioned in Netflix‘s announcement as an alternative, so let’s compare Hystrix and resilience4j.
The resilience4j repository consists of several implementations patterns, including a circuit breaker, time limiter, rate limiter, retry and cache. Hystrix implements two of these: the circuit breaker and time limiter.
To compare the APIs, I uploaded a small example to github.
To create a circuit breaker object with Hystrix, we have to extend from the HystrixCommand class and implement the methods run and getFallback. In the constructor, we set a wealth of parameters including execution timeout and threshold.
In comparison, the Resilience4jWrapper initially seems to be more complicated. There is no command class to extend, but there are decorator functions to wrap our service call. To get the same functionality as in the Hystrix example, we need to apply two patterns: CircuitBreaker and TimeLimiter. There is also no built-in fallback mechanism, so we have to implement it ourselves with try…catch or use the included Try helper from vavr.
Resilience4j spring boot integration and monitoring
If you use Hystrix in a project with spring boot, you probably won’t write your circuit breaker class this way, but will instead use the @HystrixCommand annotation.
You can do something similar with resilience4j, as this demo shows. Similar to Hystrix, by attaching the “@CircuitBreaker” annotation to a class, it automatically applies the pattern that you can configure in the application.yml file. However, there is currently no way to configure a timeout in a similar fashion.
There is also support for Micrometer and integration into the spring acutator with the CircuitBreakerHealthIndicator class.
Conclusion
Resilience4j is a relatively new project, its first release was only in 2016, compared to Hystrix’s 2012 debut. In terms of popularity, Hystrix is also in the lead, if you compare stars on github (15k vs. 2k). Wheter or not resilience4j can live up to the Hystrix standards in production remains to be seen. If you want to switch, be aware of the differences in the implementation, which will definitely have an impact on how the system behaves.
