Introduction to Resiliency4j – Part 1

Reading Time: 2 minutes

Welcome to the world of microservices. Have you ever thought about the challenges that we face in this world? Generally in this journey, we face the following challenges.
1) Managing the microservices
2) Fault tolerance
3) Monitoring
4) Deployment
So, coming to the point, in this blog, we will discuss one of the fault tolerance libraries.

What is Fault Tolerance?

Consider an XYZ system consisting of a number of microservices deployed independently interacting with each other. What if one of the instances is down. This results in the breakdown of the system. So, implementing fault tolerance provide you with a fallback when microservice fails.  Nowadays, we have different alternatives for implementing fault tolerance like resiliency4j, Hystrix, etc

What is resiliency4j?

1) One of the easy to use fault-tolerance library inspired by Netflix Hystrix.
2) Uses Vavr library which makes it lightweight as it does not have any external dependency.
3) Designed for java 8 and functional programming.
4) Offer features like Circuit breaker, Retry, Bulkhead and RateLimiter.
5) Provide HOF, lambda expression or method reference with Circuit breaker, Retry, Bulkhead and RateLimiter.
6) Also provide core modules like resilience4j-circuitbreaker: Circuit breaking, resilience4j-ratelimiter: Rate limiting, resilience4j-bulkhead: Bulkheading,
resilience4j-retry: Automatic retrying
7) If we want to go all-in, we can pick resilience4j-all instead of core modules.

Resiliency4j features:

Retry :
This mechanism retries the failed operation for a number of times and then provides fallback which either returns data or some default value.

CircuitBreaker :
This mechanism prevents cascade requests when a remote service is down. Generally, it has the following states: Closed, open and half-open.

Rate Limiters :
It helps to preserve the service from getting overloaded. We generally define the number of requests the application should process during the time interval.

Bulkhead :
This mechanism limits the number of concurrent calls to a service.

Comparison between resiliency4j and Hystrix

1) Hystrix has a dependency on Archaus which further dependent on other external libraries which make it less lightweight as compare to resiliency4j.

2) Hystrix calls to the external system have to be wrapped in Hystrix command, but resilency4j provides lambda expression, HOF, etc with Circuit breaker.

3) Resiliency4j performs a configurable number of executions and then compares the output against the threshold value which is also configurable and then determines whether to close the circuit or not. While Hystrix in the half-open state performs one single execution and then determine the circuit closing.

Conclusion:

I hope you are pretty much clear about the resiliency 4j library, its features, and comparison with Hystrix. In the next blog, we will see how we can implement these features with the Springboot application.
Hope this is helpful. Please feel free to provide your suggestions.

References:

https://resilience4j.readme.io/docs
https://www.baeldung.com/resilience4j
https://dzone.com/articles/libraries-for-microservices-development

blog-footer-1

Advertisements
Knoldus Pune Careers - Hiring Freshers

Get a head start on your career at Knoldus. Join us!