Menu
I understand from the documentation with the use of Netflix Zuul & Eureka (maybe Ribbon too) you can build an active load balancer. I have always used AWS ELB, ALB (ECS for container management) with R53.
Apart from the vendor portability, Is there any advantage of using Netflix approach than using AWS provided ALB/ELB? Is there any use case you have to use Netflix OSS rather than out of the box AWS ELBs?
723
Zuul acts as the API gateway, providing a uniform, single point of entry into the set of microservices, while Eureka is essentially used as a “meta data” transport. Each client application instance (read microservice) registers its instance information (location, port, etc.)
Regarding Zuul, there is a RibbonRoutingFilter that routes your request to an actual service instance. RibbonRoutingFilter is using Ribbon to choose a server from the list that is given from your configuration or from Eureka. So if you want to use Zuul as a load-balanced reverse proxy, Zuul needs Ribbon.
Netflix still uses eureka 1.
Internally, Zuul uses Netflix Ribbon to look up for all instances of the service from the service discovery (Eureka Server).
The load balancer does not manage client-side resiliency, such as retries, backoffs, service registry and routing. Netflix OSS offers middle-tier load balancing and several resiliency features. You would find similar features in AWS AppMesh and AWS Cloud Map. The load balacer is just the endpoint that can route clients to functions, containers or instances. Using a load balancer and service meshes (from Netflis OSS and/or AWS) certainly contribute to application reliability.
180
The Netflix OSS stack can work with ALB and ELB etc. For example you still need some sort of API Gateway (what Zuul allows you to implement) to protect your routes even when working with ALB or ELB. Ribbon and Eureka can be used for Service Discovery in addition (or you could simply hardcode the routes to your other microservices in the Zuul config and not bother with standing up a Eureka server). So you can use Zuul as a container which shares the same ALB as your other microservices in ECS, and have all requests from your front-end hit the route to Zuul first, and then based off of the request have Zuul decide which microservice route to proxy the request to. If you aren't using ECS or containers, this same architectural pattern works just fine for EC2 VMs as well.
29
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
