search

xetys / jhipster-ribbon-hystrix

A microservice demo project using JHipster 3.0 and applying Netflix Ribbon / Hystrix at service level
GNU General Public License v3.0
18 stars 11 forks source link

What if Foo fails? #1

Open sakhtar1979 opened 8 years ago

sakhtar1979 commented 8 years ago

Hi, I think it makes more sense to do Hystrix fallback in the Gateway itself. I think something like this makes more sense: (Image taken from one of the best post I have seen on this subject in a while: http://callistaenterprise.se/blogg/teknik/2015/04/15/building-microservices-with-spring-cloud-and-netflix-oss-part-2/

image

To align it with JHipster the Product Composite can be considered as Gateway and I like the fact that Zuul is not embedded inside the gateway rather it should be a standalone server.

xetys commented 8 years ago

In JHipster architecture the gateway is the edge server in that figure. using hystrix in gateway might make sense, but this doesn't replace "per-service" usage. Consider your "order"-service will directly perform load balanced requests to "product-composite". In this case going over gateway will add extra (totally unnecessary) requests, which will harm your performance. Removing hystrix from clients will lead to fatal failures in a heavy loaded application. This makes at least as much sense as using decentralized load balancing instead of central load balancers...

sakhtar1979 commented 8 years ago

That makes perfect sense. Though there will be some varioations based on every use case but general rule of thumb that any microservice to microservice call can used with Hystrix. My point is that the out of box Jhipster genereated apps like the one you created in your blog (foo, bar and foobar gateway), the gateway should use Hystrix on the gateway to foo or gateway to bar calls. And then if Foo needs to cal Bar directly then in this case Foo should directly call it and use Hystrix. The other point was that to me Zuul makes more sense to be a stanalone edge server and probably only needs to be used by external clients (Like e.g Twitter exposing there API to the rest of the world), for a closely knitted microservices we may just not use Zuul at all and use other services via Eureak where use UAA for security. So that way Zuul will be centralized and only use acroos application and organizational boundries.