@Configuration
+@Configuration
@ComponentScan
@EnableAutoConfiguration
@EnableEurekaClient
@@ -1228,16 +1234,23 @@ public class Application {
(i.e. utterly normal Spring Boot app). Configuration is required to locate the Eureka server. Example:
eureka:
+eureka:
client:
serviceUrl:
- defaultZone: http://localhost:8761/eureka/The default application name, virtual host and non-secure port are taken from the Environment is
-${spring.application.name}, ${spring.application.name}.mydomain.net and ${server.port} respectively.
where "defaultZone" is a magic string fallback value that provides the +service URL for any client that doesn’t express a preference +(i.e. it’s a useful default).
+The default application name (service ID), virtual host and non-secure
+port, taken from the Environment, are ${spring.application.name},
+${spring.application.name} and ${server.port} respectively.
@EnableEurekaClient makes the app into both a Eureka "instance"
@@ -1276,7 +1289,7 @@ assumptions about the lease renewal period.
@Configuration
+@Configuration
@EnableAutoConfiguration
@EnableEurekaServer
public class Application {
@@ -1346,6 +1359,103 @@ springBoot {
The Eureka server does not have a backend store, but the service +instances in the registry all have to send heartbeats to keep their +resistrations up to date (so this can be done in memory). Clients also +have an in-memory cache of eureka registrations (so they don’t have to +go to the registry for every single request to a service).
+By default every Eureka server is also a Eureka client and requires +(at least one) service URL to locate a peer. If you don’t provide it +the service will run and work, but it will shower your logs with a lot +of noise about not being able to register with the peer.
+The combination of the two caches (client and server) and the +heartbeats make a standalone Eureka server fairly resilient to +failure, as long as there is some sort of monitor or elastic runtime +keeping it alive (e.g. Cloud Foundry). In standalone mode, you might +prefer to switch off the client side behaviour, so it doesn’t keep +trying and failing to reach its peers. Example:
+server:
+ port: 8761
+
+eureka:
+ instance:
+ hostname: localhost
+ client:
+ registerWithEureka: false
+ fetchRegistry: false
+ serviceUrl:
+ defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
+Notice that the serviceUrl is pointing to the same host as the local
+instance.
Eureka can be made even more resilient and available by running
+multiple instances and asking them to register with each other. In
+fact, this is the default behaviour, so all you need to do to make it
+work is add a valid serviceUrl to a peer, e.g.
--- +spring: + profiles: peer1 +eureka: + instance: + hostname: peer1 + client: + serviceUrl: + defaultZone: http://peer2/eureka/ + +--- +spring: + profiles: peer2 +eureka: + instance: + hostname: peer2 + client: + serviceUrl: + defaultZone: http://peer1/eureka/+
In this example we have a YAML file that can be used to run the same
+server on 2 hosts (peer1 and peer2), by running it in different
+Spring profiles. You could use this configuration to test the peer
+awareness on a single host (there’s not much value in doing that in
+production) by manipulating /etc/hosts to resolve the host names. In
+fact, the eureka.instance.hostname is not needed if you are running
+on a machine that knows its own hostname (it is looked up using
+java.net.InetAddress by default).
You can add multiple peers to a system, and as long as they are all +connected to each other by at least one edge, they will synchronize +the registrations amongst themselves. If the peers are physically +separated (inside a data centre or between multiple data centres) then +the system can in principle survive split-brain type failures.
+@Configuration
+@Configuration
@EnableAutoConfiguration
@EnableHystrix
public class Application {
@@ -1399,7 +1509,7 @@ public class StoreIntegration {
public Object defaultStores(Map<String, Object> parameters) {
return /* something useful */;
}
-}@Configuration
+@Configuration
@ComponentScan
@EnableAutoConfiguration
@EnableEurekaClient
@@ -1463,12 +1573,10 @@ public class Application extends FeignConfigurer {
}
StoreClient.java
-public interface StoreClient {
+public interface StoreClient {
@RequestMapping(method = RequestMethod.GET, value = "/stores")
Stores getStores();
@@ -1487,7 +1595,7 @@ public class Application extends FeignConfigurer {
public class MyClass {
+public class MyClass {
@Autowired
private LoadBalancerClient loadBalancer;
@@ -1504,7 +1612,7 @@ public class Application extends FeignConfigurer {
public class MyClass {
+public class MyClass {
@Autowired
private RestTemplate restTemplate;
@@ -1903,7 +2011,7 @@ and puts it in a request header for the downstream requests.