CODEWITHSUNDEEP
javaspringspring-bootmicroserviceshystrix
vinayan.as
vinayan.as

Reputation: 43

why hystrix or any other circuit breaker for a microservice?

I am developing microservice with spring boot and spring cloud. I came to know about hystrix and circuit breaker pattern. I know that circuit breakers are for responding with alternate response in case of errors from downstream microservices on which I depend on to get the data. My question is, if I don't have any meaningful alternative response to provide, why would I need a circuit breaker at all?

Upvotes: 4

Views: 2667

Answers (2)

so-random-dude
so-random-dude

Reputation: 16495

Short answer: mainly to Stop cascading failures in a complex distributed system.

I don't have any meaningful alternative response to provide, why would I need a circuit breaker at all?

This question is relevant only if your server serves just a single REST end point (and a single HTTP verb). But almost always, that is not the case. Even the 'micro'services will have combination of multiple endpoints + multiple http verbs. You don't want one endpoint to hung up on a slow upstream service and pileup threads after threads keep waiting and eventually bringdown your entire application.

Take a look at the official documentation

What Is Hystrix For? --- Hystrix is designed to do the following:

  • Give protection from and control over latency and failure from dependencies accessed (typically over the network) via third-party
    client libraries.
  • Stop cascading failures in a complex distributed system.
  • Fail fast and rapidly recover.
  • Fallback and gracefully degrade when possible.
  • Enable near real-time monitoring, alerting, and operational control.

"Fallback and gracefully degrade when possible" is just one among the features that hystrix offers.

Upvotes: 6

Maks Shal
Maks Shal

Reputation: 43

Hystrix may also be usefull if you refactor your monolith application to split it into several microservices. When putting it into production, you may want to leave your old monolith code for some time as an alternate response. So if microservices are unavailable, just the old code will be executed, so basically you reduce risks. If everything works fine, you may just remove old code from monolith and keep using microservices.

By extending HystrixCommand class this can be done easily.

public class MicroserviceCommand extends HystrixCommand<String>
{
    @Override
    protected String run()
    {
        //return response from your new microservice
    }

    @Override
    protected String getFallback()
    {
        //microservice is not available, 
        //so execute old code which was not removed from application yet
    }
}

Upvotes: 0

Related Questions