Eureka Server is an application that holds information about all client-service applications. Every Microservice will register into the Eureka server and the Eureka server knows all the client applications running on each port and IP address. Eureka Server is also known as Discovery Server.
What is Service Discovery?
Imagine a scenario in which one REST service (Service A) is trying to invoke another REST service (Service B). In order to make a request, Service A needs to know the network location (IP address and port) of Service B.
However, this approach is nearly impossible in a cloud-based microservice architecture due to the following reasons.
Increased number of services: This results in an increased number of services that form a complex communication mesh. Therefore, it is difficult for one service to maintain the network locations of all the other services that it has to communicate with, in a property file.
Dynamically assigned network locations: Microservices are generally deployed in the cloud. Server instances in the cloud have dynamically assigned network locations. In addition, due to its basic features such as auto-scaling, servers just come and go in the cloud. Each time a service is started in a new instance, its network location changes. Therefore, it is hard to maintain the target IP addresses and port numbers of a particular microservice in a property file, as the values tend to change quite frequently.
The service discovery mechanism uses a central registry to maintain the network locations of all the microservices. If for some reason the IP address and the port number of a particular microservice change, new values will be immediately re-registered in the registry.
Service discovery helps to solve the above problem by providing away
Spring Cloud is a framework for building robust cloud applications and it provides a solution to the commonly encountered patterns when developing a distributed system.
Spring Cloud Netflix is the most popular project that is part of Spring Cloud.
Netflix Eureka
Eureka mainly consists of main components, let’s see what they are:
Eureka Server: It is an application that contains information about all client service applications. Each microservice is registered with the Eureka server and Eureka knows all the client applications running on each port and IP address. Eureka Server is also known as Discovery Server.
Eureka Client: It’s the actual microservice and it registers with the Eureka Server, so if any other microservice wants the Eureka Client’s address then they’ll contact the Eureka Server. All operations with Eureka Client may take some time to be reflected on Eureka Server, and then on other Eureka Clients.
Eureka Client-Server Communication
Register: Eureka client registers the information about the running instance to the Eureka server.
Renew: Eureka’s client needs to renew the lease by sending heartbeats every 30 seconds. The renewal informs the Eureka server that the instance is still alive.
Special Note: Eureka server doesn’t poll service instances (client) to find out their availability. Instead, clients send a heartbeat to the Eureka server to inform their availability.
Fetch Registry: Eureka clients fetch the registry information from the server and cache it locally. After that, the clients use that information to find other services.
Cancel: Eureka client sends a cancel request to Eureka server on shutdown. This removes the instance from the server’s instance registry thereby effectively taking the instance out of traffic.
The crux of the microservices pattern is to create an independent service that can be scaled and deployed independently. So in a complex business domain, more than 50-100 microservices are very common. Let’s imagine a system where we have fifty microservices. Now we have to implement a UI which is kind of a dashboard, so it calls multiple services to fetch and show the important information in the UI.
From a UI developer perspective, to collect information from fifty underlying microservices, it has to call fifty REST APIs, as each microservice exposes a REST API for communication. So the client has to know the details of all REST API and URL patterns/ports to call them.
Moreover, think about the common aspects of a web program, like CORS, authentication, security, and monitoring in terms of this design- each microservice team has to develop all these aspects into its own service, so the same code has been replicated over fifty microservices. Changes in the authentication requirements or CORS policy will ripple overall services. It is against the DRY principle, so this type of design is very error-prone and rigid. To make it robust, it has to be changed in such a way so that we have only one entry point where all common aspects code is written and the client communicates with that common service. Here, the Zuul (The Gatekeeper/Demigod) concept pops up.
Zuul is the front door for all requests from devices and websites to the backend. As an edge service application, Zuul is built to enable dynamic routing, monitoring, resiliency, and security. Routing is an important part of a microservice architecture.
It receives all the requests coming from the UI and then delegates the requests to internal microservices. So, we have to create a brand new microservice that is Zuul-enabled, and this service sits on top of all other microservices. It acts as an Edge service or client-facing service. Its Service API should be exposed to the client/UI. The client calls this service as a proxy for an internal microservice, then this service delegates the request to the appropriate service.
This blog is from Mindbowser‘s content team – a group of individuals coming together to create pieces that you may like. If you have feedback, please drop us a message on contact@mindbowser.com
Get the latest updates by sharing your email.
Flexible Engagement Model | Secure & Scalable Apps | First Time Right Process
Mindbowser helped us build an awesome iOS app to bring balance to people’s lives.
We had very close go live timeline and MindBowser team got us live a month before.
They were a very responsive team! Extremely easy to communicate and work with!
We’ve had very little-to-no hiccups at all—it’s been a really pleasurable experience.
Mindbowser is one of the reasons that our app is successful. These guys have been a great team.
Mindbowser was very helpful with explaining the development process and started quickly on the project.
The greatest benefit we got from Mindbowser is the expertise. Their team has developed apps in all different industries with all types of social proofs.
Mindbowser is professional, efficient and thorough.
Very committed, they create beautiful apps and are very benevolent. They have brilliant Ideas.
MindBowser was great; they listened to us a lot and helped us hone in on the actual idea of the app.” “They had put together fantastic wireframes for us.
They're very tech-savvy, yet humble.
Ayush was responsive and paired me with the best team member possible, to complete my complex vision and project. Could not be happier.
As a founder of a budding start-up, it has been a great experience working with Mindbower Inc under Ayush's leadership for our online digital platform design and development activity.
The team from Mindbowser stayed on task, asked the right questions, and completed the required tasks in a timely fashion! Strong work team!
They are focused, patient and; they are innovative. Please give them a shot if you are looking for someone to partner with, you can go along with Mindbowser.
We are a small non-profit on a budget and they were able to deliver their work at our prescribed budgets. Their team always met their objectives and I'm very happy with the end result. Thank you, Mindbowser team!!