anchor.diff:  
   [TIP]
   ====
  -Don't use the `DiscoveryClient` in `@PostConstruct` 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
  -higher phase.
  +Don't use the `DiscoveryClient` in `@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 higher phase.
   ====
   
   === Alternatives to the DiscoveryClient
  
positive.code: used in some scenarios to decide whether to send requests to your
  application, so it's helpful if they are accurate.
  
  === Making the Eureka Instance ID Unique
  
  By default a eureka instance is registered with an ID that is equal to its host name (i.e. only one service per host). Using Spring Cloud you can override this by providing a unique identifier in `eureka.instance.metadataMap.instanceId`. For example:
  
  
negative.code:       instanceId: ${spring.application.name}:${spring.application.instance_id:${random.value}}
  ----
  
  With this meatdata, and multiple service instances deployed on
  localhost, the random value will kick in there to make the instance
  unique. In Cloudfoundry the `spring.application.instance_id` will be
  populated automatically in a Spring Boot Actuator application, so the
  random value will not be needed.
  
  === Using the DiscoveryClient
  
  Once you have an app that is `@EnableEurekaClient` you can use it to
  