Microservices: Declare Zuul routes with Eureka serviceId (Spring Cloud + Zuul + Eureka)

 

In a previous article, we have declared/defined the Zuul routes by providing the service details (URL) manually (Click here to visit that article). That means we have provided the domain name or ip address  and port number of each service.  Just think of a situation where the application contains a large number of microservices. Do you think that it is practical to find (manually) the server details (ip address/domain) and port details of every service? If that is difficult, then how do we declare the zuul route mapping to expose each service through the Zuul Proxy?

“The solution is to perform the Zuul routes mapping with serviceId registered in the Eureka Server“.

 

Here i am not going to discuss about the importance of Netflix Zuul Proxy or Netflix Eureka server.  I have already written two separate articles on both of those areas. If you need to refresh your knowledge on those areas, please refer the relevant articles.

• Click here to view the article on Netflix Zuul Proxy.
• Click here to view the article on Netflix Eureka Server. 

 

What we are going to do here?

In order to demonstrate the serviceId based Zuul route mapping, we will be creating following set of applications.

• Eureka Server :- Spring Boot Applciation to act as Eureka Server. All the microservices will be registered here.
• Zuul Proxy: – Spring Boot Application to act as Zuul Reverse Proxy. This is the centralized gateway for directing all the requests for the misroservices. Zuul proxy will communicate with Eureka server to get the details (ip address and port) of the relevant microservice for delegating the client request.
• student-service :- just dummy microservice for representing the backend business service.

 

Lets create them one by one. The full source code of this application can be found at GitHub.

 

Eureka Server

Eureka Server is just another spring boot application with Spring Cloud Netflix Eureka dependency. Then annotate the main spring boot configuration class with @EnableEurekaServer annotation.

Therefore create a spring boot application with Eureka dependency.

 

Then  add the @EnableEurekaServer annotation to the main Spring Boot Application configuration class (That is the class annotated with @SpringBootApplication annotation)

	import org.springframework.boot.SpringApplication;
	import org.springframework.boot.autoconfigure.SpringBootApplication;
	import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
	@EnableEurekaServer
	@SpringBootApplication
	public class EurekaServerApplication {
	public static void main(String[] args) {
	SpringApplication.run(EurekaServerApplication.class, args);
	}
	}

view raw

EurekaServerApplication.java

hosted with ❤ by GitHub

 

 

application.properties (Eureka Server)

	server.port=8761
	eureka.client.register-with-eureka=false
	eureka.client.fetch-registry=false
	logging.level.com.netflix.eureka=OFF
	logging.level.com.netflix.discovery=OFF

view raw

application.properties

hosted with ❤ by GitHub

Microservices : Service Registration and Discover in Netflix Eureka

 

The importance of Service Registry and Discovery

In the Microservices architecture, your application may consist of many number of microservices. each of them may be deployed in different servers and different ports.  The microservices may need to communicate with each other to execute some tasks or operations. For instance, one microservice may need to access the service endpoint  (REST endpoint) in some other microservice for application related operation.  “how do they communicate with each other?” 

If I ask you this question, you will directly tell me that one service can access the other service with the IP address and the port number of that service.

YES! you are correct. But keep this in mind that this approach (using ip address and port number) has following limitations.

• It is not practical to know the IP address and port number of each microservice as there are multiple microservices available. Assume that there are hundred of microservices available. In this case, do you think that it is practical to know the ip address and port number of each service? It is not right?

 

• Assume a situation where a microservice is migrated to (deployed in) some other server with different IP address and port. If we have used the IP address and port number in the source code for making RestClient requests, then we will have to change them in the source code and re-build and deploy the affected services. whenever the ip address or port number get changed, we have to do the same. Dont you think that it is a sort of bad coding and programming practice? Absolutely it is right? (The issue raised again in a situation where we have multiple environments like dev, qa, uat and production)

 

 

How do we overcome above problems and move forward?

The solution is “Service Registration and Discovery“.

The microservices should register themselves in the centralized location with an identifier and server details. This is known as “Service Registration“.  Each microservice should be able to look up the list of registered services in the centralized location and it is known as “Service Discovery”

 

What are the implementation for the Service Registration and Discovery?

There are multiple implementations for the Service Registration and Discovery Server

• Netflix Eureka
• Consul
• Zookeeper

In this article, we are going to discuss about Netflix Eureka

 

 

What is Eureka Server? How it works?

Eureka Server is an implementation for the “Service Registration and Discovery” pattern. Eureka Server keeps a track of registered microsevices and therefore It is known as registry of microservices (that are related to the application).

Each microservice should register with Eureka server by providing their details such as host name, ip address, port, and health indicators etc… Then the Eureka service will register each microservice with unique identifier known as serviceId. The other services can use this serviceId to access the particular service.

The Eureka server will maintain a list of registered microservices with their provided details. Eureka server expects continuos ping messages (known as heartbeats) from the registered microservices to verify they are alive (up and running).  If any service fails to send the heartbeat (ping message) continuously, it will be considered as a dead service and will be removed from the registry.  Therefore Eureka server will maintain only a registry of up and running microservices.

On the other hand, the microservices can register themselves as service discover clients with Eureka Server. The Eureka Server will allow the discover clients (microservices) to look up the other registered services and fetch their information. If any service needs to communicate with any other service, it can register with the Eureka server as a discover client and fetch the information of the targeted service (server address and port number etc…).  In this way, microservices can communicate with each other without maintaining the IP addresses and port numbers manually.

 

Lets do some codings …..

The full source related to this article can be found at GitHub.