Netflix Eureka Server

In a typical microservice architecture we have many small applications deployed separately and they often need to communicate with each other.

Problem in this type of architecture is how the client service finds all of its end services. We normally hardcode the hostname/port in some property file,which is not a best practice. 

There could be any number of microservices, and it's time and resource-consuming to hard-code when there's an uncertain amount of them, and when their locations may change.

Discovery implies a mechanism where:

• Services have no prior knowledge about the physical location of other Service Instances
• Services advertise their existence and disappearance
• Services are able to find instances of another Service based on advertised metadata
• Instance failures are detected and they become invalid discovery results

Service Discovery is not a single point of failure by itself.

To solve this issue, we need a tool that will monitor and maintain the registry of all the microservices in the ecosystem.

Netflix Eureka:

Netflix to provide a solution to the above problem. It consists of the Eureka Server and Eureka clients. Eureka Server is itself a microservice to which all other microservices registers. Eureka Clients are the independent microservices.

The actual routing is done at runtime along with equally distributing the load among the end services.

There are other service discovery clients like Consul,Zookeeper,etcd,Cloudfoundry..etc.

High Availability in Eureka:

Netflix Eureka is built for High Availability. In CAP Theorem terms, it favors Availability over Consistency.

Focus is on ensuring Services can find each other in unplanned scenarios like network partitions or Server crashes.

High Availability is achieved at two levels:

• Server Cluster :Production setup includes a cluster of Eureka Servers,
• Client Side Caching.

Client Side Caching:

One of the best Eureka features is Client Side Caching. The Client pulls regularly discovery information from the registry and caches it locally. 

It basically has the same view on the system as the Server. In case all Servers go down or the Client is isolated from the Server by a network partition, it can still behave properly until its cache becomes obsolete.

Note:Clients retrieve and cache the registry information from the Eureka Server. In case all Servers crash, the Client still holds the last healthy snapshot of the registry.