What are Hystrix benefits over normal exception handling?

user_3153769 0
Viewed 6567

I'm really new to Hystrix topic and concept of resilient services, I was going through some course and this question came into my mind.

In Hystrix I need to define fallback method for a graceful degradation, this method is then called when circuit is broken. But I can imagine to just wrap code with try and catch and when particular exceptions appear (for timeout for instance) call fallback method in catch clause. When called service is up then normal code would be called.

Of course, with Hystrix I can additionally monitor this, but what else it gives me?. I'm pretty sure that I don't understand whole concept.

hystrix microservices spring-cloud spring java
4 Answers

As you said, it can be simply wrapped under try-catch block then why choose Hystrix or some other library? What i experienced:

  • Already test proven library.
  • Ability to skip original intended calls and fallback. Note that if you wrap it under try-catch, there will be still be an attempt to connect and send command which will eventually timeout due to degraded dependency. Knowing this information prior to call will enable to skip the calls for sometime (as per configuration) and you can save those resources
  • Provides circuit breaking using Sliding Time Window as well
  • Metrics and Dashboarding provided Out of the Box which can help you peek into your system and dependent connection
  • Implements BulkHead by using different Thread Pools
  • Lower maintenance cost
  • Health check ability. It provides a health check class which plugins with Health monitoring APIs
user_84568160

Hysterix is used to stop cascading failures, I'll give you an example to explain what I mean: Lets pretend you have 3 components: 1) Frontend, 2) Backend A and 3) Backend B.
Frontend talks to Backend A and Backend A asks backend B to do some sort of lookup. The Frontend receives 50k requests per second, which means 50k requests are going to Backend A and another 50k requests going to Backend B. If Backend B Becomes unhealthy, that is 50k sockets you're holding open between Backend B to Backend A, and another 50k sockets open between Backend A and the Frontend. What will end up happening is all the servers involved in the transaction will all start to hang because all the sockets are being held open. The sockets will fill up really fast, at 50k a second, with a 20 second timeout, thats 1 million open sockets between each server! the result of Backend B timing out will mean requests to Backend A will timeout which will mean requests to the Frontend will also time out. Hysterix (or the idea of circuit breaking) is pretty much introducing a switch where when a server becomes unhealthy, it will have some sort of way to deal with the errors such as stopping all future requests and just give a predefined response instantly, resulting in the sockets closing straight away and no cascading failures occuring. This results in increased resilience and better fault tolerance.

user_80797540

The main difference is that Hystrix opens the circuit (it is an analogy to electrical circuits) when it detects an error and does not invoke downstream services until some time has elapsed. This behaviour prevents an avalanche of errors in cascading. It is similar to a smart traffic light that turns red and doesn't let you pass because it knows that you are going to have an accident a little later. After a configurable time, the circuit is closed again. You can see 'Circuit opened / closed' at Hystrix dashboard:

enter image description here

It is also well explained by Chris Richardson at pattern - circuit breaker

user_13315390
Related