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
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 …..