Microservices are at center while designing any application with multiple parts which are required to be scaled horizontally to serve growing demand. It helps breaking system into small independent components making it easier to manage/develop and scale. But before deploying the architecture we need to answer few questions
• How these microservices will discover each other?
• How we will ensure High Availability of these microservices?
• How our end service dealing with user will consume these microservices?
How these microservices will discover each other?
We need a central location where these services running on different machines can register themselves and declare the ip address and port at which they are running for example we have an addition service running on ip address 192.2.3.4 and port 8080 this service will register itself to some central location with name additionservice and ip, port
| Name | IP/Port |
|---|---|
| additionservice | 192.2.3.4:8080 |
Any other service who wants to perform addition will discover details of addition service by looking up to this central repository using service name additionservice
Spring Cloud Netflix provides many different components to perform service discovery , load balancing and handling failures of these services
Eureka is the Netflix Service Discovery Server and Client and act as central location for service registry every service in our ecosystem will register it self with Eureka along with some meta data information such as ip and port
If we scale our micorservice by launching one more instance to run on some different ip say 192.2.3.5 and port 8080. We will have entry in our Eureka Server as
| Name | IP/Port | No.Ofinstances |
|---|---|---|
| additionservice | 192.2.3.4:8080,192.2.3.5:8080 | 2 |
We can deploy some smart load balancing at client side so when it discovers the service endpoints from our service discovery Eureka Server gets two ip addresses and smartly distributes the load across these endpoints
Having multiple instances of service makes our service Highly Available and at same point by introducing the concept of central service registry it decouples client from having know how of where the services are deployed and running even if we change the location of these services at run time it won’t impact client consuming our services via Eureka.
Eureka Server does not have its own back-end and the service instances have to send heartbeats to server to keep their registrations up to date. Clients also have an in-memory cache of eureka, thus avoiding trip to server for every request.
There is concept of zones in Eureka Server stay tuned for updates on them !! ☺
Follow below Github repo to get code for EurekaServer, EurekaClient and EurkaConsumer
Eureka