Pal Pal Dil Ke Paas Netflix

[Alexandrin Chaples]

Thisgroup is for software engineers interested in using and contributing to Netflix Open Source Platform components. Netflix has open sourced many components of our Global PaaS that provide best practices on creating and running highly available services in the Cloud. Full set of NetflixOSS components is at ://netflix.github.io

Service Discovery is one of the key tenets of a microservice-based architecture.Trying to hand-configure each client or some form of convention can be difficult to do and can be 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.

To include the Eureka Client in your project, use the starter with a group ID of org.springframework.cloud and an artifact ID of spring-cloud-starter-netflix-eureka-client.See the Spring Cloud Project page for details on setting up your build system with the current Spring Cloud Release Train.

Note that the preceding example shows a normal Spring Boot application.By having spring-cloud-starter-netflix-eureka-client on the classpath, your application automatically registers with the Eureka Server. Configuration is required to locate the Eureka server, as shown in the following example:

HTTP basic authentication is automatically added to your eureka client if one of the eureka.client.serviceUrl.defaultZone URLs has credentials embedded in it (curl style, as follows: :password@localhost:8761/eureka).For more complex needs, you can create a @Bean of type DiscoveryClientOptionalArgs and inject ClientFilter instances into it, all of which is applied to the calls from the client to the server.

The status page and health indicators for a Eureka instance default to /info and /health respectively, which are the default locations of useful endpoints in a Spring Boot Actuator application.You need to change these, even for an Actuator application if you use a non-default context path or servlet path (such as server.servletPath=/custom). The following example shows the default values for the two settings:

Doing so makes Eureka publish instance information that shows an explicit preference for secure communication.The Spring Cloud DiscoveryClient always returns a URI starting with https for a service configured this way.Similarly, when a service is configured this way, the Eureka (native) instance information has a secure health check URL.

Because of the way Eureka works internally, it still publishes a non-secure URL for the status and home pages unless you also override those explicitly.You can use placeholders to configure the eureka instance URLs, as shown in the following example:

By default, Eureka uses the client heartbeat to determine if a client is up.Unless specified otherwise, the Discovery Client does not propagate the current health check status of the application, per the Spring Boot Actuator.Consequently, after successful registration, Eureka always announces that the application is in 'UP' state. This behavior can be altered by enabling Eureka health checks, which results in propagating application status to Eureka.As a consequence, every other application does not send traffic to applications in states other then 'UP'.The following example shows how to enable health checks for the client:

It is worth spending a bit of time understanding how the Eureka metadata works, so you can use it in a way that makes sense in your platform.There is standard metadata for information such as hostname, IP address, port numbers, the status page, and health check.These are published in the service registry and used by clients to contact the services in a straightforward way.Additional metadata can be added to the instance registration in the eureka.instance.metadataMap, and this metadata is accessible in the remote clients.In general, additional metadata does not change the behavior of the client, unless the client is made aware of the meaning of the metadata.There are a couple of special cases, described later in this document, where Spring Cloud already assigns meaning to the metadata map.

Cloud Foundry has a global router so that all instances of the same app have the same hostname (other PaaS solutions with a similar architecture have the same arrangement).This is not necessarily a barrier to using Eureka.However, if you use the router (recommended or even mandatory, depending on the way your platform was set up), you need to explicitly set the hostname and port numbers (secure or non-secure) so that they use the router.You might also want to use instance metadata so that you can distinguish between the instances on the client (for example, in a custom load balancer).By default, the eureka.instance.instanceId is vcap.application.instance_id, as shown in the following example:

Depending on the way the security rules are set up in your Cloud Foundry instance, you might be able to register and use the IP address of the host VM for direct service-to-service calls.This feature is not yet available on Pivotal Web Services (PWS).

A vanilla Netflix Eureka instance is registered with an ID that is equal to its host name (that is, there is only one service per host).Spring Cloud Eureka provides a sensible default, which is defined as follows:

With the metadata shown in the preceding example and multiple service instances deployed on localhost, the random value is inserted there to make the instance unique.In Cloud Foundry, the vcap.application.instance_id is populated automatically in a Spring Boot application, so the random value is not needed.

Once you have an application that is a discovery client, you can use it to discover service instances from the Eureka Server.One way to do so is to use the native com.netflix.discovery.EurekaClient (as opposed to the Spring Cloud DiscoveryClient), as shown in the following example:

Do not use the EurekaClient in a @PostConstruct method or in a @Scheduled method (or anywhere where the ApplicationContext might not be started yet).It is initialized in a SmartLifecycle (with phase=0), so the earliest you can rely on it being available is in another SmartLifecycle with a higher phase.

By default, EurekaClient uses Jersey for HTTP communication.If you wish to avoid dependencies from Jersey, you can exclude it from your dependencies.Spring Cloud auto-configures a transport client based on Spring RestTemplate.The following example shows Jersey being excluded:

You need not use the raw Netflix EurekaClient.Also, it is usually more convenient to use it behind a wrapper of some sort.Spring Cloud has support for Feign (a REST client builder) and Spring RestTemplate through the logical Eureka service identifiers (VIPs) instead of physical URLs.To configure Ribbon with a fixed list of physical servers, you can set .ribbon.listOfServers to a comma-separated list of physical addresses (or hostnames), where is the ID of the client.

If you have deployed Eureka clients to multiple zones, you may prefer that those clients use services within the same zone before trying services in another zone.To set that up, you need to configure your Eureka clients correctly.

Next, you need to tell Eureka which zone your service is in.You can do so by using the metadataMap property.For example, if service 1 is deployed to both zone 1 and zone 2, you need to set the following Eureka properties in service 1:

3a8082e126