Spring Cloud Netflix: How Service Registration and Discovery Work

Spring Cloud has a full stack for microservices. The main objective of Spring Cloud is to provide a complete integration between Spring Boot and the Netflix OSS project, where simple annotation allows you to have some components used by Netflix running in your environment

Some pattern provided by Netflix OSS that Spring Cloud provides: 

• Service Discovery (Eureka).
• Circuit Breaker (Hystrix).
• Intelligent Routing (Zuul).
• Client Side Load Balancing (Ribbon).

In this post, we will talk about service discovery, display the concept, and show how it is possible to, with a few annotations, to have the default working on a project with Spring Boot.

Service Discovery is one of the key tenets of microservice-based architecture. Trying to hand-configure each client or some form of convention can be very difficult to do and can be very brittle. Eureka is the Netflix Service Discovery Server and Client. The server can be configured and deployed to be highly available, with each server replicating state about the registered services to the others.

Why Use Service Discovery?

Let's imagine we have many services dynamically distributed on the network, where instances of services dynamically change because of auto-scaling, failures, upgrades, and we have no control of IP addresses, the name of the instance. In this situation, the simplest solution would be if the service tells the server or other services where it is and if it is available.

This is how the discovery service works, the service entered in the network and register on a server to make it available for the use of some other service. The pattern that will be addressed in this post will be The Server-Side Pattern Discovery.

Where customers know where the server is and send to the server that is available.

Registering

When a client registers with Eureka, it provides meta-data about itself ,such as host and port, health indicator URL, home page, etc. Eureka receives heartbeat messages from each instance belonging to a service. If the heartbeat fails over a configurable timetable, the instance is normally removed from the registry.

Status Page and Health Indicator

The network location of a service instance is registered with the service registry when it starts up. It is removed from the service registry when the instance terminates. The service instance’s registration is typically refreshed periodically using a heartbeat mechanism.

Eureka’s Health Checks

By default, Eureka uses the client heartbeat to determine if a client is up. Unless specified otherwise the Discovery Client will not propagate the current health check status of the application per the Spring Boot Actuator. Which means that after successful registration Eureka will always announce that the application is in 'UP' state. Enabling Eureka health checks can alter this behavior, which results in propagating application status to Eureka. As a consequence, every other application won’t be sending traffic to the application in state other than 'UP'.

Server Code

Client 1 Code

The default zone is the Eureka service address:

Tomcat port to client 1

Client 2 Code

The same as Client 1 but in another port:

Steps to Run

1. Run the Server

It will be available on http://localhost:8761 and will show some information and a screen with the instances available.

2. Run Client 1

Now, in the server, it is possible to see the instance registered: 

3. Run Client 2

Now, in the server, it is possible to see the new instance registered:

All registered instances:  

Health information image:  

My Sandbox with the samples above.

With few lines of code and annotation, is possible have all benefits of service discovery with spring boot and eureka.