Microservices Circuit-Breaker Pattern Implementation: Istio vs. Hystrix

https://www.exoscale.com/syslog/istio-vs-hystrix-circuit-breaker/

by nfrankel • 8 years ago

86 19 8 years ago

exoscale.com

sgt• 8 years ago

Also worth reading: https://vertx.io/docs/vertx-circuit-breaker/java/

dlojudice• 8 years ago

And this: Pattern: Service Mesh - http://philcalcado.com/2017/08/03/pattern_service_mesh.html

Daishiman• 8 years ago

These microservice design patterns bring back horrible memories of the design overarchitecture that was in vogue back in the J2EE years, where you basically need patterns to deal with the issues your new patterns bring up.

Of course in practice most reasonable people choose to deal with these things by dealing with complex failures in the most simple way, but the proliferation of these "solutions" IMO bring in more trouble than it could be possibly worth.

bpicolo• 8 years ago

Hystrix is in maintenance mode - README says Netflix is moving towards e.g. https://github.com/resilience4j/resilience4j

Netflix Hystrix is now officially in maintenance mode, with the following expectations to the greater community: Netflix will no longer actively review issues, merge pull-requests, and release new versions of Hystrix.

ramchip• 8 years ago

It’s mentioned in the article:

Netflix has recently announced it has stopped development of the Hystrix library in favor of the less well-known Resilience4J project.
Even if the client code might be a bit different, the approach between Hystrix and Resilience4J is similar.

SuddsMcDuff5• 8 years ago

Usually better to use asynchronous communication between services.

discreteevent4• 8 years ago

With a good old fashioned message broker for guaranteed eventual delivery, decoupling, discovery and elasticity (if you can fit it in to your setup)

sigmonsays• 8 years ago

I can't tell if this is a joke or not.

bni• 8 years ago

On its own this is a worthless hand wavy statement.

How do you accomplish this when you have a synchronous client (ie a user waiting in his web browser)? Should the browser poll for the result? How could you possibly implement something like this in the real world?

discreteevent4• 8 years ago

If it is synchronous or transactional then don't use microservices. Plenty of things can be done asynchronously provided the use case is ok with eventual consistency or within a non urgent time limit.

BTW now that the browser supports websockets (a bidirectional protocol the rest of the world had since the 70s!), you don't have to poll.

SuddsMcDuff5• 8 years ago

Your comment seems to be a slightly clumsy way of saying "I don't know much about this area of software design, please tell me more", so I'll respond to it in that spirit.

Firstly my terse hand wavey statement was at least clear on the fact that it was talking about communication between services. It said nothing about web browsers or any other human interface.

But since this relatively narrow context is clearly the one which you can most relate to, I'll stay within it. If you think about it, the HTTP request/response cycle is actually an illusion of synchronous communication on top of a transport mechanism which is fundamentally asynchronous. It's an abstraction layer which shields you from the complexities of asynchronous communication. Broadly speaking this is known as the [request/response](https://en.wikipedia.org/wiki/Request%E2%80%93response) pattern.

HTTP by no means the only implementation of the request/response pattern. Even in asychronous messaging systems it's not unusual to see it implemented - https://www.enterpriseintegrationpatterns.com/patterns/messa....

But request/reply is just one of the patterns which exists in the realm of asynchronous communication. There are other, much more common patterns such as send/receive and publish/subscribe. Exploring these patterns opens up whole new approaches to software design.

I wholeheartedly recommend the book [Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/) by Gregor Hohpe and Bobby Woolf. It's quite old now but is still the best and most complete introduction to asynchronous design.

An alternative perspective is from the viewpoint of [Command Query Separation](https://en.wikipedia.org/wiki/Command%E2%80%93query_separati...), and it's relative at the architural level, [Command Query Responsibility Segregation](https://martinfowler.com/bliki/CQRS.html).

sagichmal2• 8 years ago

It is almost never better to use async communication between services. The failure modes are strictly more, and finding and fixing problems is substantially harder.

https://programmingisterrible.com/post/162346490883/how-do-y...

discreteevent4• 8 years ago

Part of that article seems to be saying: I don't see any point in having suspension in vehicles. When I overload my truck it handles like shit.

SuddsMcDuff5• 8 years ago

Are you basing that on personal experience, or just on that blog post?

voycey• 8 years ago

That cookie notification is absolutely atrocious - is there really any need for a full screen popover??

Microservices Circuit-Breaker Pattern Implementation: Istio vs. Hystrix

Related Stories