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.
![]() | Note |
|---|---|
The use of |
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 relies on a Registration bean in the Spring Application Context. Calling /service-registry via a GET will return the status of the Registration. A POST to the same endpoint with a JSON body will change the status of the current Registration to the new value. The JSON body has to include the status field with the preferred value. Please see the documentation of the ServiceRegistry implementation you are using for the allowed values for updating the status and the values returned for the status. For instance, Eureka’s supported statuses are UP, DOWN, OUT_OF_SERVICE and UNKNOWN.
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.
WebClient can be automatically configured to use the LoadBalancerClient. To create a load balanced WebClient create a WebClient.Builder @Bean and use the @LoadBalanced qualifier.
@Configuration public class MyConfiguration { @Bean @LoadBalanced public WebClient.Builder loadBalancedWebClientBuilder() { return WebClient.builder(); } } public class MyClass { @Autowired private WebClient.Builder webClientBuilder; public Mono<String> doOtherStuff() { return webClientBuilder.build().get().uri("http://stores/stores") .retrieve().bodyToMono(String.class); } }
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.
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.
If you would like to implement a BackOffPolicy in your retries you will need to
create a bean of type LoadBalancedBackOffPolicyFactory, and return the BackOffPolicy
you would like to use for a given service.
@Configuration public class MyConfiguration { @Bean LoadBalancedBackOffPolicyFactory backOffPolciyFactory() { return new LoadBalancedBackOffPolicyFactory() { @Override public BackOffPolicy createBackOffPolicy(String service) { return new ExponentialBackOffPolicy(); } }; } }
![]() | Note |
|---|---|
|
If you want to add one or more RetryListener to your retry you will need to
create a bean of type LoadBalancedRetryListenerFactory and return the RetryListener array
you would like to use for a given service.
@Configuration public class MyConfiguration { @Bean LoadBalancedRetryListenerFactory retryListenerFactory() { return new LoadBalancedRetryListenerFactory() { @Override public RetryListener[] createRetryListeners(String service) { return new RetryListener[]{new RetryListener() { @Override public <T, E extends Throwable> boolean open(RetryContext context, RetryCallback<T, E> callback) { //TODO Do you business... return true; } @Override public <T, E extends Throwable> void close(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) { //TODO Do you business... } @Override public <T, E extends Throwable> void onError(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) { //TODO Do you business... } }}; } }; } }
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 |
WebClient can be configured to use the LoadBalancerClient. A `LoadBalancerExchangeFilterFunction is auto-configured if spring-webflux is on the classpath.
public class MyClass { @Autowired private LoadBalancerExchangeFilterFunction lbFunction; public Mono<String> doOtherStuff() { return WebClient.builder().baseUrl("http://stores") .filter(lbFunction) .build() .get() .uri("/stores") .retrieve() .bodyToMono(String.class); } }
The URI needs to use a virtual host name (ie. service name, not a host name).
The LoadBalancerClient is used to create a full physical address.
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. In addition, if you provide a bean of type HttpClientBuilder and/or OkHttpClient.Builder,
the default factories will use these builders as the basis for the builders returned to 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.
A /features actuator endpoint is provided by Commons. This endpoint returns features available on the classpath and if they are enabled or not. The information returned includes the feature type, name, version and vendor.
There are two types of 'features': abstract and named.
Abstract features are features where an interface or abstract class is defined that an implementation creates, such as DiscoveryClient, LoadBalancerClient or LockService. The abstract class or interface is used to find a bean of that type in the context. The version displayed is bean.getClass().getPackage().getImplementationVersion().
Named features are features that don’t have a particular class they implement, such as "Circuit Breaker", "API Gateway", "Spring Cloud Bus", etc… These features require a name and a bean type.
Any module can declare any number of HasFeature beans. Some examples:
@Bean public HasFeatures commonsFeatures() { return HasFeatures.abstractFeatures(DiscoveryClient.class, LoadBalancerClient.class); } @Bean public HasFeatures consulFeatures() { return HasFeatures.namedFeatures( new NamedFeature("Spring Cloud Bus", ConsulBusAutoConfiguration.class), new NamedFeature("Circuit Breaker", HystrixCommandAspect.class)); } @Bean HasFeatures localFeatures() { return HasFeatures.builder() .abstractFeature(Foo.class) .namedFeature(new NamedFeature("Bar Feature", Bar.class)) .abstractFeature(Baz.class) .build(); }
Each of these beans should go in an appropriately guarded @Configuration.