From f0e9cd474eddba652d6ca21cd0e24a13f4320176 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Mon, 23 Apr 2018 08:54:53 +0000 Subject: [PATCH] Sync docs from 1.4.x to gh-pages --- .../multi__service_discovery_eureka_clients.html | 6 +++--- 1.4.x/multi/multi_spring-cloud-netflix.html | 2 +- 1.4.x/single/spring-cloud-netflix.html | 8 ++++---- 1.4.x/spring-cloud-netflix.xml | 12 ++++++------ 4 files changed, 14 insertions(+), 14 deletions(-) diff --git a/1.4.x/multi/multi__service_discovery_eureka_clients.html b/1.4.x/multi/multi__service_discovery_eureka_clients.html index 8f28d242e..383afcc4f 100644 --- a/1.4.x/multi/multi__service_discovery_eureka_clients.html +++ b/1.4.x/multi/multi__service_discovery_eureka_clients.html @@ -99,12 +99,12 @@ traffic to application in state other then 'UP'.

application.yml.  healthcheck: enabled: true

[Warning]Warning

eureka.client.healthcheck.enabled=true should only be set in application.yml. Setting the value in bootstrap.yml will cause undesirable side effects like registering in eureka with an UNKNOWN status.

If you require more control over the health checks, you may consider -implementing your own com.netflix.appinfo.HealthCheckHandler.

1.7 Eureka Metadata for Instances and Clients

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.

1.7.1 Using Eureka on Cloudfoundry

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.

1.7 Eureka Metadata for Instances and Clients

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.

1.7.1 Using Eureka on Cloud Foundry

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).

1.7.2 Using Eureka on AWS

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).

1.7.2 Using Eureka on AWS

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.

1.8 Using the EurekaClient

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 @@ - Spring Cloud Netflix

Spring Cloud Netflix
   Next

Spring Cloud Netflix

Table of Contents

1. Service Discovery: Eureka Clients
1.1. How to Include Eureka Client
1.2. Registering with Eureka
1.3. Authenticating with the Eureka Server
1.4. Status Page and Health Indicator
1.5. Registering a Secure Application
1.6. Eureka’s Health Checks
1.7. Eureka Metadata for Instances and Clients
1.7.1. Using Eureka on Cloudfoundry
1.7.2. Using Eureka on AWS
1.7.3. Changing the Eureka Instance ID
1.8. Using the EurekaClient
1.8.1. EurekaClient without Jersey
1.9. Alternatives to the native Netflix EurekaClient
1.10. Why is it so Slow to Register a Service?
1.11. Zones
2. Service Discovery: Eureka Server
2.1. How to Include Eureka Server
2.2. How to Run a Eureka Server
2.3. High Availability, Zones and Regions
2.4. Standalone Mode
2.5. Peer Awareness
2.6. Prefer IP Address
3. Circuit Breaker: Hystrix Clients
3.1. How to Include Hystrix
3.2. Propagating the Security Context or using Spring Scopes
3.3. Health Indicator
3.4. Hystrix Metrics Stream
4. Circuit Breaker: Hystrix Dashboard
5. Hystrix Timeouts And Ribbon Clients
5.1. How to Include Hystrix Dashboard
5.2. Turbine
5.3. Turbine Stream
6. Client Side Load Balancer: Ribbon
6.1. How to Include Ribbon
6.2. Customizing the Ribbon Client
6.3. Customizing default for all Ribbon Clients
6.4. Customizing the Ribbon Client using properties
6.5. Using Ribbon with Eureka
6.6. Example: How to Use Ribbon Without Eureka
6.7. Example: Disable Eureka use in Ribbon
6.8. Using the Ribbon API Directly
6.9. Caching of Ribbon Configuration
6.10. How to Configure Hystrix thread pools
6.11. How to Provide a Key to Ribbon’s IRule
7. Declarative REST Client: Feign
7.1. How to Include Feign
7.2. Overriding Feign Defaults
7.3. Creating Feign Clients Manually
7.4. Feign Hystrix Support
7.5. Feign Hystrix Fallbacks
7.6. Feign and @Primary
7.7. Feign Inheritance Support
7.8. Feign request/response compression
7.9. Feign logging
8. External Configuration: Archaius
9. Router and Filter: Zuul
9.1. How to Include Zuul
9.2. Embedded Zuul Reverse Proxy
9.3. Zuul Http Client
9.4. Cookies and Sensitive Headers
9.5. Ignored Headers
9.6. Management Endpoints
9.6.1. Routes Endpoint
9.6.2. Filters Endpoint
9.7. Strangulation Patterns and Local Forwards
9.8. Uploading Files through Zuul
9.9. Query String Encoding
9.10. Plain Embedded Zuul
9.11. Disable Zuul Filters
9.12. Providing Hystrix Fallbacks For Routes
9.13. Zuul Timeouts
9.13.1. Service Discovery Configuration
9.13.2. URL Configuration
9.14. Rewriting Location header
9.15. Zuul Developer Guide
9.15.1. The Zuul Servlet
9.15.2. Zuul RequestContext
9.15.3. @EnableZuulProxy vs. @EnableZuulServer
9.15.4. @EnableZuulServer Filters
9.15.5. @EnableZuulProxy Filters
9.15.6. Custom Zuul Filter examples
9.15.7. How to Write a Pre Filter
9.15.8. How to Write a Route Filter
9.15.9. How to Write a Post Filter
9.15.10. How Zuul Errors Work
9.15.11. Zuul Eager Application Context Loading
10. Polyglot support with Sidecar
11. RxJava with Spring MVC
12. Metrics: Spectator, Servo, and Atlas
12.1. Dimensional vs. Hierarchical Metrics
12.2. Default Metrics Collection
12.3. Metrics Collection: Spectator
12.3.1. Spectator Counter
12.3.2. Spectator Timer
12.3.3. Spectator Gauge
12.3.4. Spectator Distribution Summaries
12.4. Metrics Collection: Servo
12.4.1. Creating Servo Monitors
12.5. Metrics Backend: Atlas
12.5.1. Global tags
12.5.2. Using Atlas
12.6. Retrying Failed Requests
12.6.1. BackOff Policies
12.6.2. Configuration
12.6.3. Zuul
13. HTTP Clients
   Next
   
\ No newline at end of file + Spring Cloud Netflix
Spring Cloud Netflix
   Next

Spring Cloud Netflix

Table of Contents

1. Service Discovery: Eureka Clients
1.1. How to Include Eureka Client
1.2. Registering with Eureka
1.3. Authenticating with the Eureka Server
1.4. Status Page and Health Indicator
1.5. Registering a Secure Application
1.6. Eureka’s Health Checks
1.7. Eureka Metadata for Instances and Clients
1.7.1. Using Eureka on Cloud Foundry
1.7.2. Using Eureka on AWS
1.7.3. Changing the Eureka Instance ID
1.8. Using the EurekaClient
1.8.1. EurekaClient without Jersey
1.9. Alternatives to the native Netflix EurekaClient
1.10. Why is it so Slow to Register a Service?
1.11. Zones
2. Service Discovery: Eureka Server
2.1. How to Include Eureka Server
2.2. How to Run a Eureka Server
2.3. High Availability, Zones and Regions
2.4. Standalone Mode
2.5. Peer Awareness
2.6. Prefer IP Address
3. Circuit Breaker: Hystrix Clients
3.1. How to Include Hystrix
3.2. Propagating the Security Context or using Spring Scopes
3.3. Health Indicator
3.4. Hystrix Metrics Stream
4. Circuit Breaker: Hystrix Dashboard
5. Hystrix Timeouts And Ribbon Clients
5.1. How to Include Hystrix Dashboard
5.2. Turbine
5.3. Turbine Stream
6. Client Side Load Balancer: Ribbon
6.1. How to Include Ribbon
6.2. Customizing the Ribbon Client
6.3. Customizing default for all Ribbon Clients
6.4. Customizing the Ribbon Client using properties
6.5. Using Ribbon with Eureka
6.6. Example: How to Use Ribbon Without Eureka
6.7. Example: Disable Eureka use in Ribbon
6.8. Using the Ribbon API Directly
6.9. Caching of Ribbon Configuration
6.10. How to Configure Hystrix thread pools
6.11. How to Provide a Key to Ribbon’s IRule
7. Declarative REST Client: Feign
7.1. How to Include Feign
7.2. Overriding Feign Defaults
7.3. Creating Feign Clients Manually
7.4. Feign Hystrix Support
7.5. Feign Hystrix Fallbacks
7.6. Feign and @Primary
7.7. Feign Inheritance Support
7.8. Feign request/response compression
7.9. Feign logging
8. External Configuration: Archaius
9. Router and Filter: Zuul
9.1. How to Include Zuul
9.2. Embedded Zuul Reverse Proxy
9.3. Zuul Http Client
9.4. Cookies and Sensitive Headers
9.5. Ignored Headers
9.6. Management Endpoints
9.6.1. Routes Endpoint
9.6.2. Filters Endpoint
9.7. Strangulation Patterns and Local Forwards
9.8. Uploading Files through Zuul
9.9. Query String Encoding
9.10. Plain Embedded Zuul
9.11. Disable Zuul Filters
9.12. Providing Hystrix Fallbacks For Routes
9.13. Zuul Timeouts
9.13.1. Service Discovery Configuration
9.13.2. URL Configuration
9.14. Rewriting Location header
9.15. Zuul Developer Guide
9.15.1. The Zuul Servlet
9.15.2. Zuul RequestContext
9.15.3. @EnableZuulProxy vs. @EnableZuulServer
9.15.4. @EnableZuulServer Filters
9.15.5. @EnableZuulProxy Filters
9.15.6. Custom Zuul Filter examples
9.15.7. How to Write a Pre Filter
9.15.8. How to Write a Route Filter
9.15.9. How to Write a Post Filter
9.15.10. How Zuul Errors Work
9.15.11. Zuul Eager Application Context Loading
10. Polyglot support with Sidecar
11. RxJava with Spring MVC
12. Metrics: Spectator, Servo, and Atlas
12.1. Dimensional vs. Hierarchical Metrics
12.2. Default Metrics Collection
12.3. Metrics Collection: Spectator
12.3.1. Spectator Counter
12.3.2. Spectator Timer
12.3.3. Spectator Gauge
12.3.4. Spectator Distribution Summaries
12.4. Metrics Collection: Servo
12.4.1. Creating Servo Monitors
12.5. Metrics Backend: Atlas
12.5.1. Global tags
12.5.2. Using Atlas
12.6. Retrying Failed Requests
12.6.1. BackOff Policies
12.6.2. Configuration
12.6.3. Zuul
13. HTTP Clients
   Next
   
\ No newline at end of file diff --git a/1.4.x/single/spring-cloud-netflix.html b/1.4.x/single/spring-cloud-netflix.html index e05c5bfe4..00fb14d09 100644 --- a/1.4.x/single/spring-cloud-netflix.html +++ b/1.4.x/single/spring-cloud-netflix.html @@ -1,6 +1,6 @@ - Spring Cloud Netflix

Spring Cloud Netflix

Table of Contents

1. Service Discovery: Eureka Clients
1.1. How to Include Eureka Client
1.2. Registering with Eureka
1.3. Authenticating with the Eureka Server
1.4. Status Page and Health Indicator
1.5. Registering a Secure Application
1.6. Eureka’s Health Checks
1.7. Eureka Metadata for Instances and Clients
1.7.1. Using Eureka on Cloudfoundry
1.7.2. Using Eureka on AWS
1.7.3. Changing the Eureka Instance ID
1.8. Using the EurekaClient
1.8.1. EurekaClient without Jersey
1.9. Alternatives to the native Netflix EurekaClient
1.10. Why is it so Slow to Register a Service?
1.11. Zones
2. Service Discovery: Eureka Server
2.1. How to Include Eureka Server
2.2. How to Run a Eureka Server
2.3. High Availability, Zones and Regions
2.4. Standalone Mode
2.5. Peer Awareness
2.6. Prefer IP Address
3. Circuit Breaker: Hystrix Clients
3.1. How to Include Hystrix
3.2. Propagating the Security Context or using Spring Scopes
3.3. Health Indicator
3.4. Hystrix Metrics Stream
4. Circuit Breaker: Hystrix Dashboard
5. Hystrix Timeouts And Ribbon Clients
5.1. How to Include Hystrix Dashboard
5.2. Turbine
5.3. Turbine Stream
6. Client Side Load Balancer: Ribbon
6.1. How to Include Ribbon
6.2. Customizing the Ribbon Client
6.3. Customizing default for all Ribbon Clients
6.4. Customizing the Ribbon Client using properties
6.5. Using Ribbon with Eureka
6.6. Example: How to Use Ribbon Without Eureka
6.7. Example: Disable Eureka use in Ribbon
6.8. Using the Ribbon API Directly
6.9. Caching of Ribbon Configuration
6.10. How to Configure Hystrix thread pools
6.11. How to Provide a Key to Ribbon’s IRule
7. Declarative REST Client: Feign
7.1. How to Include Feign
7.2. Overriding Feign Defaults
7.3. Creating Feign Clients Manually
7.4. Feign Hystrix Support
7.5. Feign Hystrix Fallbacks
7.6. Feign and @Primary
7.7. Feign Inheritance Support
7.8. Feign request/response compression
7.9. Feign logging
8. External Configuration: Archaius
9. Router and Filter: Zuul
9.1. How to Include Zuul
9.2. Embedded Zuul Reverse Proxy
9.3. Zuul Http Client
9.4. Cookies and Sensitive Headers
9.5. Ignored Headers
9.6. Management Endpoints
9.6.1. Routes Endpoint
9.6.2. Filters Endpoint
9.7. Strangulation Patterns and Local Forwards
9.8. Uploading Files through Zuul
9.9. Query String Encoding
9.10. Plain Embedded Zuul
9.11. Disable Zuul Filters
9.12. Providing Hystrix Fallbacks For Routes
9.13. Zuul Timeouts
9.13.1. Service Discovery Configuration
9.13.2. URL Configuration
9.14. Rewriting Location header
9.15. Zuul Developer Guide
9.15.1. The Zuul Servlet
9.15.2. Zuul RequestContext
9.15.3. @EnableZuulProxy vs. @EnableZuulServer
9.15.4. @EnableZuulServer Filters
9.15.5. @EnableZuulProxy Filters
9.15.6. Custom Zuul Filter examples
9.15.7. How to Write a Pre Filter
9.15.8. How to Write a Route Filter
9.15.9. How to Write a Post Filter
9.15.10. How Zuul Errors Work
9.15.11. Zuul Eager Application Context Loading
10. Polyglot support with Sidecar
11. RxJava with Spring MVC
12. Metrics: Spectator, Servo, and Atlas
12.1. Dimensional vs. Hierarchical Metrics
12.2. Default Metrics Collection
12.3. Metrics Collection: Spectator
12.3.1. Spectator Counter
12.3.2. Spectator Timer
12.3.3. Spectator Gauge
12.3.4. Spectator Distribution Summaries
12.4. Metrics Collection: Servo
12.4.1. Creating Servo Monitors
12.5. Metrics Backend: Atlas
12.5.1. Global tags
12.5.2. Using Atlas
12.6. Retrying Failed Requests
12.6.1. BackOff Policies
12.6.2. Configuration
12.6.3. Zuul
13. HTTP Clients

1.4.5.BUILD-SNAPSHOT

This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration + Spring Cloud Netflix

Spring Cloud Netflix

Table of Contents

1. Service Discovery: Eureka Clients
1.1. How to Include Eureka Client
1.2. Registering with Eureka
1.3. Authenticating with the Eureka Server
1.4. Status Page and Health Indicator
1.5. Registering a Secure Application
1.6. Eureka’s Health Checks
1.7. Eureka Metadata for Instances and Clients
1.7.1. Using Eureka on Cloud Foundry
1.7.2. Using Eureka on AWS
1.7.3. Changing the Eureka Instance ID
1.8. Using the EurekaClient
1.8.1. EurekaClient without Jersey
1.9. Alternatives to the native Netflix EurekaClient
1.10. Why is it so Slow to Register a Service?
1.11. Zones
2. Service Discovery: Eureka Server
2.1. How to Include Eureka Server
2.2. How to Run a Eureka Server
2.3. High Availability, Zones and Regions
2.4. Standalone Mode
2.5. Peer Awareness
2.6. Prefer IP Address
3. Circuit Breaker: Hystrix Clients
3.1. How to Include Hystrix
3.2. Propagating the Security Context or using Spring Scopes
3.3. Health Indicator
3.4. Hystrix Metrics Stream
4. Circuit Breaker: Hystrix Dashboard
5. Hystrix Timeouts And Ribbon Clients
5.1. How to Include Hystrix Dashboard
5.2. Turbine
5.3. Turbine Stream
6. Client Side Load Balancer: Ribbon
6.1. How to Include Ribbon
6.2. Customizing the Ribbon Client
6.3. Customizing default for all Ribbon Clients
6.4. Customizing the Ribbon Client using properties
6.5. Using Ribbon with Eureka
6.6. Example: How to Use Ribbon Without Eureka
6.7. Example: Disable Eureka use in Ribbon
6.8. Using the Ribbon API Directly
6.9. Caching of Ribbon Configuration
6.10. How to Configure Hystrix thread pools
6.11. How to Provide a Key to Ribbon’s IRule
7. Declarative REST Client: Feign
7.1. How to Include Feign
7.2. Overriding Feign Defaults
7.3. Creating Feign Clients Manually
7.4. Feign Hystrix Support
7.5. Feign Hystrix Fallbacks
7.6. Feign and @Primary
7.7. Feign Inheritance Support
7.8. Feign request/response compression
7.9. Feign logging
8. External Configuration: Archaius
9. Router and Filter: Zuul
9.1. How to Include Zuul
9.2. Embedded Zuul Reverse Proxy
9.3. Zuul Http Client
9.4. Cookies and Sensitive Headers
9.5. Ignored Headers
9.6. Management Endpoints
9.6.1. Routes Endpoint
9.6.2. Filters Endpoint
9.7. Strangulation Patterns and Local Forwards
9.8. Uploading Files through Zuul
9.9. Query String Encoding
9.10. Plain Embedded Zuul
9.11. Disable Zuul Filters
9.12. Providing Hystrix Fallbacks For Routes
9.13. Zuul Timeouts
9.13.1. Service Discovery Configuration
9.13.2. URL Configuration
9.14. Rewriting Location header
9.15. Zuul Developer Guide
9.15.1. The Zuul Servlet
9.15.2. Zuul RequestContext
9.15.3. @EnableZuulProxy vs. @EnableZuulServer
9.15.4. @EnableZuulServer Filters
9.15.5. @EnableZuulProxy Filters
9.15.6. Custom Zuul Filter examples
9.15.7. How to Write a Pre Filter
9.15.8. How to Write a Route Filter
9.15.9. How to Write a Post Filter
9.15.10. How Zuul Errors Work
9.15.11. Zuul Eager Application Context Loading
10. Polyglot support with Sidecar
11. RxJava with Spring MVC
12. Metrics: Spectator, Servo, and Atlas
12.1. Dimensional vs. Hierarchical Metrics
12.2. Default Metrics Collection
12.3. Metrics Collection: Spectator
12.3.1. Spectator Counter
12.3.2. Spectator Timer
12.3.3. Spectator Gauge
12.3.4. Spectator Distribution Summaries
12.4. Metrics Collection: Servo
12.4.1. Creating Servo Monitors
12.5. Metrics Backend: Atlas
12.5.1. Global tags
12.5.2. Using Atlas
12.6. Retrying Failed Requests
12.6.1. BackOff Policies
12.6.2. Configuration
12.6.3. Zuul
13. HTTP Clients

1.4.5.BUILD-SNAPSHOT

This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your application and build large distributed systems with battle-tested Netflix components. The @@ -104,12 +104,12 @@ traffic to application in state other then 'UP'.

application.yml.  healthcheck: enabled: true

[Warning]Warning

eureka.client.healthcheck.enabled=true should only be set in application.yml. Setting the value in bootstrap.yml will cause undesirable side effects like registering in eureka with an UNKNOWN status.

If you require more control over the health checks, you may consider -implementing your own com.netflix.appinfo.HealthCheckHandler.

1.7 Eureka Metadata for Instances and Clients

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.

1.7.1 Using Eureka on Cloudfoundry

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.

1.7 Eureka Metadata for Instances and Clients

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.

1.7.1 Using Eureka on Cloud Foundry

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).

1.7.2 Using Eureka on AWS

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).

1.7.2 Using Eureka on AWS

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);
@@ -122,7 +122,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.

1.8 Using the EurekaClient

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/spring-cloud-netflix.xml b/1.4.x/spring-cloud-netflix.xml index cf21e616e..2cc3c2dc8 100644 --- a/1.4.x/spring-cloud-netflix.xml +++ b/1.4.x/spring-cloud-netflix.xml @@ -4,7 +4,7 @@ Spring Cloud Netflix -2018-04-13 +2018-04-23 @@ -182,9 +182,9 @@ implementing your own com.netflix.appinfo.HealthCheckHandler.

Eureka Metadata for Instances and Clients 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. -
-Using Eureka on Cloudfoundry -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: +
+Using Eureka on Cloud Foundry +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 @@ -194,7 +194,7 @@ implementing your own com.netflix.appinfo.HealthCheckHandler. 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). +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).
Using Eureka on AWS @@ -222,7 +222,7 @@ public EurekaInstanceConfigBean eurekaInstanceConfig(InetUtils inetUtils) { 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.