terça-feira, 16 de agosto de 2016

Spring Cloud Netflix - How works Service Registration and Discovery

Spring Cloud has a full stack for micro services. The main objective of the spring cloud is to provide a complete integration between Spring Boot and Netflix OSS project, where simple annotation is possible 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 will talk about service discovery, showing the concept and how it is possible with a few annotation have the default working on a project with Spring Boot.
Service Discovery is one of the key tenets of micro service 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 would be if the service tell 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.


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 application in state other then 'UP'.

Server code:

Client 1 code:

                         defaultZone is the Eureka service address

Tomcat port to client 1

Client 2 code:

The same of the client 1 but in other port

        Tomcat port to client 2


1.The first step is run server:

Will be available on http://localhost:8761 and will be showed some information’s and a screen with the instances available.
2.The second step is run client, this client will be registered in the server:

Now in the server is possible see the instance registered:

3.The third step is run the second client:

Now in the server is possible see the new instance registered:

all instances already registered:

In this links is possible see some information about instances:

Health information image:

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


Nenhum comentário:

Postar um comentário

Observação: somente um membro deste blog pode postar um comentário.