Patterns such as service discovery, load balancing and circuit breakers lend themselves to a common abstraction layer that can be consumed by all Spring Cloud clients, independent of the implementation (e.g. discovery via Eureka or Consul).
Commons provides the @EnableDiscoveryClient
annotation. This looks for implementations of the DiscoveryClient
interface via META-INF/spring.factories
. Implementations of Discovery Client will add a configuration class to spring.factories
under the org.springframework.cloud.client.discovery.EnableDiscoveryClient
key. Examples of DiscoveryClient
implementations: are Spring Cloud Netflix Eureka, Spring Cloud Consul Discovery and Spring Cloud Zookeeper Discovery.
By default, implementations of DiscoveryClient
will auto-register the local Spring Boot server with the remote discovery server. This can be disabled by setting autoRegister=false
in @EnableDiscoveryClient
.
Commons creates a Spring Boot HealthIndicator
that DiscoveryClient
implementations can participate in by implementing DiscoveryHealthIndicator
. To disable the composite HealthIndicator
set spring.cloud.discovery.client.composite-indicator.enabled=false
. A generic HealthIndicator
based on DiscoveryClient
is auto-configured (DiscoveryClientHealthIndicator). To disable it, set `spring.cloud.discovery.client.health-indicator.enabled=false
. To disable the description field of the DiscoveryClientHealthIndicator
set spring.cloud.discovery.client.health-indicator.include-description=false
, otherwise it can bubble up as the description
of the rolled up HealthIndicator
.
Commons now provides a ServiceRegistry
interface which provides methods like register(Registration)
and deregister(Registration)
which allow you to provide custom registered services. Registration
is a marker interface.
@Configuration @EnableDiscoveryClient(autoRegister=false) public class MyConfiguration { private ServiceRegistry registry; public MyConfiguration(ServiceRegistry registry) { this.registry = registry; } // called via some external process, such as an event or a custom actuator endpoint public void register() { Registration registration = constructRegistration(); this.registry.register(registration); } }
Each ServiceRegistry
implementation has its own Registry
implementation.
By default, the ServiceRegistry
implementation will auto-register the running service. To disable that behavior, there are two methods. You can set @EnableDiscoveryClient(autoRegister=false)
to permanently disable auto-registration. You can also set spring.cloud.service-registry.auto-registration.enabled=false
to disable the behavior via configuration.
A /service-registry
actuator endpoint is provided by Commons. This endpoint relys on a Registration
bean in the Spring Application Context. Calling /service-registry/instance-status
via a GET will return the status of the Registration
. A POST to the same endpoint with a String
body will change the status of the current Registration
to the new value. Please see the documentation of the ServiceRegistry
implementation you are using for the allowed values for updating the status and the values retured for the status.
RestTemplate
can be automatically configured to use ribbon. To create a load balanced RestTemplate
create a RestTemplate
@Bean
and use the @LoadBalanced
qualifier.
Warning | |
---|---|
A |
@Configuration public class MyConfiguration { @LoadBalanced @Bean RestTemplate restTemplate() { return new RestTemplate(); } } public class MyClass { @Autowired private RestTemplate restTemplate; public String doOtherStuff() { String results = restTemplate.getForObject("http://stores/stores", String.class); return results; } }
The URI needs to use a virtual host name (ie. service name, not a host name).
The Ribbon client is used to create a full physical address. See
RibbonAutoConfiguration
for details of how the RestTemplate
is set up.
A load balanced RestTemplate
can be configured to retry failed requests.
By default this logic is disabled, you can enable it by adding Spring Retry to your application’s classpath. The load balanced RestTemplate
will
honor some of the Ribbon configuration values related to retrying failed requests. If
you would like to disable the retry logic with Spring Retry on the classpath
you can set spring.cloud.loadbalancer.retry.enabled=false
.
The properties you can use are client.ribbon.MaxAutoRetries
,
client.ribbon.MaxAutoRetriesNextServer
, and client.ribbon.OkToRetryOnAllOperations
.
See the Ribbon documentation
for a description of what there properties do.
Note | |
---|---|
|
If you want a RestTemplate
that is not load balanced, create a RestTemplate
bean and inject it as normal. To access the load balanced RestTemplate
use
the @LoadBalanced
qualifier when you create your @Bean
.
Important | |
---|---|
Notice the |
@Configuration public class MyConfiguration { @LoadBalanced @Bean RestTemplate loadBalanced() { return new RestTemplate(); } @Primary @Bean RestTemplate restTemplate() { return new RestTemplate(); } } public class MyClass { @Autowired private RestTemplate restTemplate; @Autowired @LoadBalanced private RestTemplate loadBalanced; public String doOtherStuff() { return loadBalanced.getForObject("http://stores/stores", String.class); } public String doStuff() { return restTemplate.getForObject("http://example.com", String.class); } }
Tip | |
---|---|
If you see errors like |
Sometimes it is useful to ignore certain named network interfaces so they can be excluded from Service Discovery registration (eg. running in a Docker container). A list of regular expressions can be set that will cause the desired network interfaces to be ignored. The following configuration will ignore the "docker0" interface and all interfaces that start with "veth".
application.yml.
spring: cloud: inetutils: ignoredInterfaces: - docker0 - veth.*
You can also force to use only specified network addresses using list of regular expressions:
application.yml.
spring: cloud: inetutils: preferredNetworks: - 192.168 - 10.0
You can also force to use only site local addresses. See Inet4Address.html.isSiteLocalAddress() for more details what is site local address.
application.yml.
spring: cloud: inetutils: useOnlySiteLocalInterfaces: true
Spring Cloud Commons provides beans for creating both Apache HTTP clients (ApacheHttpClientFactory
)
as well as OK HTTP clients (OkHttpClientFactory
). The OkHttpClientFactory
bean will only be created
if the OK HTTP jar is on the classpath. In addition, Spring Cloud Commons provides beans for creating
the connection managers used by both clients, ApacheHttpClientConnectionManagerFactory
for the Apache
HTTP client and OkHttpClientConnectionPoolFactory
for the OK HTTP client. You can provide
your own implementation of these beans if you would like to customize how the HTTP clients are created
in downstream projects. You can also disable the creation of these beans by setting
spring.cloud.httpclientfactories.apache.enabled
or spring.cloud.httpclientfactories.ok.enabled
to
false
.