SpringCloud Netflix Eureka Kullanımı

Giriş

Eureka iki kısımdan oluşur

1. Sunucu

2. İstemci

Eureka Sunucusu

Eureka kullanabilmek için bir tane Eureka sunucusu başlatmak gerekir. Bunun için @EnableEurekaServer anotasyonu kullanılır

Eureka İstemcisi

İstemcilerin bu sunucuyu kullanabilmesi için @EnableEurekaClient anotasyonu kullanılır.  Bu anotasyon aslında mecburi değil. Açıklaması şöyle

Then we need to annotate a @Configuration with either @EnableDiscoveryClient or @EnableEurekaClient – note that this annotation is optional if we have the spring-cloud-starter-netflix-eureka-client dependency on the classpath.

Health Monitoring

Kullanılabilecek iki tane yöntem var. Açıklaması şöyle

Learnt Monitoring for the approach where servers send keep-alive requests to clients in order to learn whether they are healthy; 

Taught Monitoring for the approach where clients send heartbeats to servers in order to educate the server on their health status.

Eureka'ya kayıtlı istemci durumunu heartbeat mesajı ile kendisi bildirir. Yani Eurekea Taught Monitoring yöntemini kullanır. 

Eurekea sunucusu ile istemciyi kontrol etmez ama Learnt Monitoring için gerekli URL'yi sağlar. Şeklen şöyle

Heartbeat URL

Eureka sunucusu heartbeat için şu URL'yi dinler

PUT /eureka/apps/{app-id}/{instance-id}?status={status}

Açıklaması şöyle

I’ve omitted a few other query parameters for clarity. {instance-id} takes the form of hostname:app-id:port where it identifies a unique Eureka client instance. Eureka server recognizes a few statuses — UP, DOWN, STARTING, OUT_OF_SERVICE and UNKNOWN.

Örnek bir hearbeat şöyle

PUT /eureka/apps/ORDER-SERVICE/localhost:order-service:8886?status=UP

Açıklaması şöyle. Yani istemci henüz Eureka sunucusuna kayıt olmadıysa, 404 gönderilir ve heartbeat mesajı kabul edilmez. Önce kayıt olması istenir

Upon receiving a heartbeat request from a client instance, Eureka server renews the lease of that instance. If it’s the very first heartbeat from a given client, Eureka server responds with a 404 and right after that the client will send a registration request.

Sorgulama URL'si

Sorgulama için URL şöyle

PUT    /eureka/apps/{app-id}/

Örnek

Şöyle yaparız

GET /eureka/apps/ORDER-SERVICE
<application>
  <name>ORDER-SERVICE</name>
  <instance>
    <instanceId>localhost:order-service:8886</instanceId>
    <ipAddr>192.168.1.6</ipAddr>
    <port>8886</port>
    <status>UP</status>
    <overriddenstatus>UP</overriddenstatus>
    <healthCheckUrl>http://localhost:8886/health</healthCheckUrl>
    ...
    ...
  </instance>
</application>

Cevap'taki alanlar için açıklama şöyle

The response has three important health-related information — status, overriddenstatus and healthCheckUrl.

status is the health status as published by the Eureka instance itself.

overriddenstatus is the enforced health status manually or by tools. The PUT /eureka/apps/{app-id}/instance-id}/status?value={status} operation is used to override the status published by Eureka instance and once invoked both status will also be changed to the overriddenstatus.

healthCheckUrl is the endpoint which the client exposes to GET its health status

Örnek - Ribbon

Bu bilgiyi sorgulayan ve kullanan Ribbon için açıklama şöyle

This information can be leveraged by tools for various purposes.

Client-side load balancers like Ribbon to make load balancing decisions

Ribbon reads the status attribute and considers only the instances with UP status for load balancing. Ribbon, however, does not invoke the healthCheckUrl but relies on published instance status available in the registry.

Şeklen şöyle

Örnek - Asgard

Bu bilgiyi sorgulayan ve kullanan Asgard için açıklama şöyle

Deployment tools like Asgard to make deployment decisions
During rolling deployments, Asgard first deploys one instance of the new version of a microservice and waits till that instance is transitioned to UP status - before deploying rest of the instances (as a risk mitigation strategy). However, rather than relying on instance status available in the Eureka server registry (i.e. the status attribute), Asgard learns instance status by invoking its healthCheckUrl. It could be because the value of status attribute can be stale (since it’s dependent on a few factors as described in the next section) but live health status is important in this case in order to avoid deployment delays.

Şeklen şöyle

Accuracy of health status

Açıklaması şöyle. Yani Eureka her zaman en son sonucu vermeyebilir. Biraz gecikme olabilir.

The Eureka server registry (hence the health status) is not always accurate due to the following reasons.

AP in CAP

Eureka is a highly available system in terms of CAP theorem, the information in the registry may not be consistent between Eureka servers in the cluster — during a network partition.

Server response cache

Eureka servers maintain a response cache which is updated in every 30 seconds by default. Therefore an instance which is actually DOWN may appear to be UP in the GET /eureka/apps/{app-id}/ response.

Scheduled heartbeats

Since the Eureka clients send heartbeats in every 30 seconds by default, health status changes between the heartbeats are not reflected in the Eureka server registry.

Self preservation

Eureka servers stop expiring clients from the registry when they do not receive heartbeats beyond a certain threshold which in turn makes the registry inaccurate.

Therefore the clients should follow proper failover mechanisms to complement this inaccuracy.

Manual İşlem İçin Diğer URL'ler

Bunlar şöyle

PUT    /eureka/apps/{app-id}/{instance-id}/status?value={status}
DELETE /eureka/apps/{app-id}/{instance-id}/status

PUT İle Manual İşlem

Açıklaması şöyle

The overriding operation (i.e. the PUT operation above) is used to take otherwise a healthy instance OUT_OF_SERVICE manually or by administration tools such as Asgard, in order to temporarily disallow traffic to some instance.

Örnek şöyle yaparız

PUT /eureka/apps/ORDER-SERVICE/localhost:order-service:8886/status?value=OUT_OF_SERVICE

Açıklaması şöyle

This will be useful for red black deployments where you run older and newer versions of a microservice for some period of time (in order to easily rollback to an older version if the new version is unstable). Once the deployment of the new version is completed and the new version has started serving requests, instances of the older version can be taken OUT_OF_SERVICE (without bringing them down) so that they will just stop serving requests.

DELETE İle Manual İşlem

Şöyle yaparız

DELETE /eureka/apps/ORDER-SERVICE/localhost:order-service:8886/status

HealthCheckHandler Arayüzü

Açıklaması şöyle

Eureka clients (or servers) never invoke the /health endpoint to determine the health status of an instance. Health status of a Eureka instance is determined by a HealthCheckHandler implementation. The default HealthCheckHandler always announces that the application is in UP state as long as the application is running.

Eureka allows custom HealthCheckHandlers to be plugged-in through the EurekaClient#registerHealthCheck() API. Spring Cloud leverages this extension point to register a new handler, EurekaHealthCheckHandler, if the following property is set.

eureka.client.healthcheck.enabled=true

EurekaHealthCheckHandler 

Açıklaması şöyle

The EurekaHealthCheckHandler works by aggregating health status from multiple health indicators such as;

- DiskSpaceHealthIndicator

- RefreshScopeHealthIndicator

- HystrixHealthIndicator

and mapping the aggregated status into one of Eureka supported statuses. This status will then be propagated to Eureka server through heartbeats.

application.properties

eureka.instance.health-check-url Alanı

Spring sayfasındaki açıklama şöyle

Gets the absolute health check page URL for this instance. The users can provide the healthCheckUrlPath if the health check page resides in the same instance talking to eureka, else in the cases where the instance is a proxy for some other server, users can provide the full URL. If the full URL is provided it takes precedence.

Daha anlaşılır bir açıklama şöyle. Yani Eureka istemcisi, sunucuya kayıt olurken bir URL vermek zorunda. Bu URL'nin ne olacağına health-check-url ve health-check-url-path alanlarına bakarak karakr veriyor. Eğer bu alanlara değer vermezsek /health kullanılıyor. 

Eureka clients POST a healthCheckUrl in the payload when they are registering themselves with the server. The value of the healthCheckUrl is calculated from the following instance

 properties.

eureka.instance.health-check-url=...
eureka.instance.health-check-url-path=...

The default value of the health-check-url-path is /health which is the spring-boot’s default health actuator endpoint that will be ignored if a heath-check-url property is set.

Örnek - custom path

Şöyle yaparız

endpoints.health.path=/new-heath

# configure either a relative path
eureka.instance.health-check-url-path=${endpoints.health.path}

# or an absolute path
eureka.instance.health-check-url=http://${eureka.hostname}:${server.port}/${endpoints.health.path}

Örnek - custom path

Şöyle yaparız

management.context-path=/admin

# configure either a relative path
eureka.instance.health-check-url-path=${management.context-path}/health

# or an absolute path
eureka.instance.health-check-url=http://${eureka.hostname}:${server.port}/${management.context-path}/health