Spring Cloud: Service Discovery With Eureka

Learn the fundamentals of Service Discovery and Spring Cloud Eureka with code examples.

One of the main building blocks of a micro-service architecture is service discovery. Spring cloud provides multiple solutions such as Eureka, Zookeeper, Cloud Foundry and Consul to facilitate the process of service discovery. This piece is aimed at providing you a simple explanation of service discovery with Eureka. I will be covering the following topics in this article.

• What is Service Discovery?
• What is Spring Cloud Eureka?
• Implementing a Eureka Server and a Client
• Inter-Microservice Communication via Eureka
• Understanding Eureka Client-Server Communication

What is Service Discovery?

A distributed system typically comprises a large number of services which communicate with each other to perform certain operations. Service discovery is the process of one service dynamically discovering the network location (IP address and port) of another service to communicate with it.

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. In a conventional SOA (Service Oriented Architecture) ecosystem, services’ network locations would hardly change, as they are deployed in on-premise data centers. Consequently, you can afford to maintain the network locations of services in configuration files, which will be updated infrequently. For example, Service A can maintain the IP address and port of Service B in a configuration file and use those values when making a request. Following figure illustrates this flow.

However, this approach is nearly impossible in a cloud based microservice architecture due to following reasons.

Increased number of services: As you may well aware, microservice architecture is all about breaking down monoliths into fine grained services. This results in an increased number of services that forms 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 cloud have dynamically assigned network locations. In addition, due to its basic features such as auto scaling, servers just come and go in 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.

These complications raised the need to have a more sophisticated mechanism for microservices to dynamically discover the network locations of other microservices for communication. The concept of service discovery was introduced as a result. 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 changes, new values will be immediately re-registered in the registry.

What is Spring Cloud Eureka

Eureka is a REST based service which is primarily used for acquiring information about services that you would want to communicate with. This REST service is also known as Eureka Server. The Services that register in Eureka Server to obtain information about each other are called Eureka Clients. Following diagram illustrates how Eureka clients and server fit in together.

As the above diagram indicates, Service A and Service B are registered in Eureka server. If any of the these two services want communicate with the other service, it can obtain the target IP address and the port via the Eureka server.

Implementing a Eureka Server and a Client

Setting up a Spring based Eureka server and a client is fairly straight forward. Spring.io provides a very concise step by step guide here, which will help you to quickly setup an Eureka server and a client.

And also, I implemented a sample Eureka server and a client which I will use to cover this section. Please note that I will not go through step by step, but will explain the important points. You can find the code for this sample application here.

Setting Up the Eureka Server

“pom.xml” File

• You have to mainly import spring-cloud and spring-cloud-starter-netflix-eureka-server dependencies in this file.

“application.properties” File

• Spring Boot applications by default run on port 8080 . I have overridden that to 8761 , so that Eureka server wouldn’t conflict with out Eureka client application (Eureka client will run on 8080).
• When Eureka starts up, it will try to register itself as a client. For convenience, I used eureka.client.register-with-eureka = false configuration to prevent Eureka server from registering itself in the server upon startup.
• In a real world scenario, we may have multiple Eureka server nodes acting together as peer registries. When a Eureka server starts up, by default it searches for other peer registries. In order to prevent this in our local setup, I used eureka.client.fetch-registry = false configuration.
• I have used logging.level.com.netflix.eureka = OFF and logging.level.com.netflix.discovery = OFF properties to turn off the verbose logging.

“EurekaServerApplication.java” File

• The @EnableEurekaServer annotation is used to make our Spring Boot application acts as a Eureka Server.

Setting Up the Eureka Client

“pom.xml” File

You have to use spring-boot-starter-web , spring-cloud and spring-cloud-starter-netflix-eureka-client dependencies. spring-boot-starter-web dependency is used as this application is web service which registers in the Eureka server.

“bootstrap.properties” File

• spring.application.name property is used to indicate the service name. Eureka client service registers in the Eureka server with whatever the name you have provided for this property. Service’s network location will be attached to it’s service name. This value will be used by other microservices to obtain the network location via the service registry.
• bootstrap.properties file is picked up before the application.properties file by Spring Boot. spring.application.name property is used in the earliest phases of service’s configuration. Therefore, by convention, this property resides in the bootstrap.properties file.

“application.properties” File

• eureka.client.serviceUrl.defaultZone indicates the location of the Eureka server. Client service will use this URL to access the Eureka server application. In this particular instance, the URL is set to http://localhost:8761/eureka .

“EurekaClientServiceApplication.java” File

• As stated in a previous section, Spring Cloud supports multiple discovery solutions such as Eureka, Consul, Zookeeper and Cloud Foundry. The @EnableDiscoveryClient instructs Spring Boot to scan the classpath and identify the service discovery implementation used (In this case Eureka as spring-cloud-starter-netflix-eureka-server dependency is used). Afterwards, Spring Boot activates DicoveryClient implementation and register the service name and the corresponding network location in the Eureka server.
• There is another annotation namely @EnableEurekaClient that you can use to create an Eureka client application. In contrast to @EnableDiscoveryClient , @EnableEurekaClient can only be used with Eureka.

Starting the Eureka Server and Client

Starting the Eureka Server

Step 1: Navigate to the root directory of your Eureka server project using the command line, and execute the below Maven command. This command will package your code into a JAR file and place it under <eureka_server_root_directory>/target folder.

mvn install

Step 2: Navigate to the <eureka_server_root_directory>/target folder using the command line, and execute the below command to start the Eureka server.

java -jar <eureka_server_jar_file_name>

At the application startup, you should see a log snippet that looks like below.

Starting the Eureka Client

Step 1: Navigate to the root directory of your Eureka client project using the command line, and execute the below Maven command. This command will package your code into a JAR file and place it under <eureka_client_root_directory>/target folder.

mvn install

Step 2: Navigate to the <eureka_client_root_directory>/target folder using the command line, and execute the below command to start the Eureka server.

java -jar <eureka_client_jar_file_name>

At the application startup, you should see a log snippet that looks like below.

Testing the Setup

Step 1: Navigate to the below URL and you should be able to see the Eureka server dashboard.

http://localhost:8761

Inter-Microservice Communication via Eureka

Imagine a scenario in which microservice A is trying to invoke microservice B. As we discussed before, microservices do not maintain hard-coded network locations for communication. Following figure illustrates how microservice A uses Eureka to obtain the network location of service B and make a request.

1. Service A and service B registers in Eureka server, providing their application names and network locations.
2. Service A intends to access Service B. Therefore, it possesses the application name (not the network location) of service B.
3. Service A presents the application name of Service B to Eureka server and obtains the corresponding network location.
4. Service A uses the obtained network location of service B to make a request (via http or some other protocol).

Eureka Client Server Communication

• Register: Eureka client registers the information about the running instance to the Eureka server.
• Renew: Eureka 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 Eureka server to inform their availability.
• Fetch Registry: Eureka clients fetches the registry information from the server and caches 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.

Conclusion

The prime objective of this piece was to give you an introduction about using Eureka for service discovery. In a real world scenario, a microservice ecosystem could have thousands of services deployed in different regions of the world. In that case, it may not be practical to have just one Eureka cluster. Instead, we will have to deploy multiple Eureka clusters in different regions to minimize the latency and increase the availability. This is illustrated in the below figure.

In my next article, I’m planning to explain how to create a multi-site Eureka cluster and test it locally.