Menu
We are working on a cloud native app to be deployed in Cloud Foundry and after initial "let's use all the goodies from Netflix", we started to question if the overlap with CF is justifying usage of Netflix components.
Especially in case of Eureka, we were planning to use it for service discovery, but then very similar capability is provided out of the box by CF and routes. What we would miss is runtime registration of services (which in case of architecture that doesn't change frequently is not a big challenge and would be in fact a static map of serviceID -> CF route) and heartbeat (on the apps level, since I assume on the container level CF is making sure everything is fine).
So now I wonder - how do you use it in your applications (real-life apps) when using CF? What are the benefits of keeping it in the architecture?
Thank you,
Leszek
PS. Interesting note is that if the eureka stores simple map of serviceID -> CF route, then if I am right, value of Zuul also goes down (since LB would be delivered by CF and gorouter is a very good option).
383
With Netflix Eureka, each client can simultaneously act as a server to replicate its status to a connected peer. In other words, a client retrieves a list of all connected peers in a service registry, and makes all further requests to other services through a load-balancing algorithm.
Eureka Server is an application that holds the information about all client-service applications. Every Micro service will register into the Eureka server and Eureka server knows all the client applications running on each port and IP address. Eureka Server is also known as Discovery Server.
In a microservices-based application, you could have many Eureka servers. Each Eureka server also behaves as a Eureka client and tries to register with other Eureka servers. This way, if one of them fails, you have other instances that can fill the role of a discovery server.
When a client registers with Eureka, it provides meta-data about itself such as host and port, health indicator URL, home page etc. Eureka receives heartbeat messages from each instance belonging to a service. If the heartbeat fails over a configurable timetable, the instance is normally removed from the registry.
Eureka uses application IDs to do service discovery, which exist only in the context of your application design. Cloud Foundry routing uses URLs for addressing, which introduces a dependency in your code on the underlying infrastructure.
If I need to access account-service, I'd like to ask for it by that name. The URL for that service will be different depending whether I am testing on my local machine, running a deployed QA instance, or running in production. I don't want my app to have to know where it's running, and which URLs map to which environment. It's likely that those URLs can change over time, anyway.
If I use Eureka, then I just ask for account-service, and the environment-specific issues are abstracted away from my app.
182
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
