Eureka Service and Zuul API Gateway

What is Eureka Server?

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.

You can also check out our video on Eureka Sever And Zuul API below

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.

• It is difficult to manage in a configuration file
• It is error-prone when some mismanagement happens
• It lacks the flexibility to change the IP or port at a later point in time

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

• To register a service ie when a new service becomes online it registers itself to the service discovery service with its IP and port
• Helps services to find other services ie helps Service-A to find Service-B
• Health check to check the health of an instance and to remove it when it is not well.
• To deregister when a service becomes offline.
• Thus it helps to utilize the full capability of the cloud to dynamically scale and shrink based on the requirements and also make the architecture loosely coupled to each other

What is Spring Cloud and What is It Used For?

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.

Netflix Zuul

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.