![[Warning]](images/warning.png) | Warning |
|---|---|
|
application.yml. healthcheck: enabled: true
| Warning |
|---|---|
|
If you require more control over the health checks, you may consider
-implementing your own com.netflix.appinfo.HealthCheckHandler.
It’s 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 things like hostname, IP address, port numbers, 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 will be accessible in the remote clients, but in general will not change the behaviour of the client, unless it is made aware of the meaning of the metadata. There are a couple of special cases described below where Spring Cloud already assigns meaning to the metadata map.
Cloudfoundry has a global router so that all instances of the same app have the same hostname (it’s the same in other PaaS solutions with a similar architecture). This isn’t necessarily a barrier to using Eureka, but 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 you can distinguish between the instances on the client (e.g. in a custom load balancer). By default, the eureka.instance.instanceId is vcap.application.instance_id. For example:
application.yml.
+implementing your own com.netflix.appinfo.HealthCheckHandler.
It’s 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 things like hostname, IP address, port numbers, 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 will be accessible in the remote clients, but in general will not change the behaviour of the client, unless it is made aware of the meaning of the metadata. There are a couple of special cases described below 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 (it’s the same in other PaaS solutions with a similar architecture). This isn’t necessarily a barrier to using Eureka, but 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 you can distinguish between the instances on the client (e.g. in a custom load balancer). By default, the eureka.instance.instanceId is vcap.application.instance_id. For example:
application.yml.
eureka:
instance:
hostname: ${vcap.application.uris[0]}
nonSecurePort: 80-
Depending on the way the security rules are set up in your Cloudfoundry 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).
If the application is planned to be deployed to an AWS cloud, then the Eureka instance will have to be configured to be AWS aware and this can be done by customizing the EurekaInstanceConfigBean the following way:
@Bean +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).
If the application is planned to be deployed to an AWS cloud, then the Eureka instance will have to be configured to be AWS aware and this can be done by customizing the EurekaInstanceConfigBean the following way:
@Bean
@Profile("!default")
public EurekaInstanceConfigBean eurekaInstanceConfig(InetUtils inetUtils) {
EurekaInstanceConfigBean b = new EurekaInstanceConfigBean(inetUtils);
@@ -117,7 +117,7 @@ implementing your own com.netflix.appinfo.HealthCheckHandl
instanceId: ${spring.application.name}:${vcap.application.instance_id:${spring.application.instance_id:${random.value}}}
With this metadata, and multiple service instances deployed on
localhost, the random value will kick in there to make the instance
-unique. In Cloudfoundry the vcap.application.instance_id will be
+unique. In Cloud Foundry the vcap.application.instance_id will be
populated automatically in a Spring Boot application, so the
random value will not be needed.
Once you have an app that is a discovery client you can use it to discover service instances from the Eureka Server. One way to do that is to use the native diff --git a/1.4.x/multi/multi_spring-cloud-netflix.html b/1.4.x/multi/multi_spring-cloud-netflix.html index a21739c22..1c0b7906d 100644 --- a/1.4.x/multi/multi_spring-cloud-netflix.html +++ b/1.4.x/multi/multi_spring-cloud-netflix.html @@ -1,3 +1,3 @@
-Table of Contents
IRuleLocation header@EnableZuulProxy vs. @EnableZuulServer@EnableZuulServer Filters@EnableZuulProxy FiltersTable of Contents
IRuleLocation header@EnableZuulProxy vs. @EnableZuulServer@EnableZuulServer Filters@EnableZuulProxy Filters