In spring cloud v1.1, I can use @EnableDiscoveryClient
and @EnableEurekaClient
to register a spring cloud app to both Eureka and Consul properly, because I want to use circuit breakers of Eureka/Zuul and key-value configurations of consul. But when using spring cloud v1.2.1, for the same code, I got the following exception:
***************************
APPLICATION FAILED TO START
***************************
Description:
Parameter 0 of method serviceRegistryEndpoint in org.springframework.cloud.client.serviceregistry.ServiceRegistryAutoConfiguration$ServiceRegistryEndpointConfiguration required a single bean, but 2 were found:
- eurekaServiceRegistry: defined by method 'eurekaServiceRegistry' in class path resource [org/springframework/cloud/netflix/eureka/EurekaClientAutoConfiguration.class]
- consulServiceRegistry: defined by method 'consulServiceRegistry' in class path resource [org/springframework/cloud/consul/serviceregistry/ConsulServiceRegistryAutoConfiguration.class]
Action:
Consider marking one of the beans as @Primary, updating the consumer to accept multiple beans, or using @Qualifier to identify the bean that should be consumed
I found the class of org.springframework.cloud.client.serviceregistry.ServiceRegistryAutoConfiguration
is a new class from spring cloud v1.2.0, and its purpose is
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).
So, does it mean using spring cloud v1.2, I could register the app to only consul but could use key-value configurations and circuit breakers?
I just did it.
The key is exclude default auto configurations in
application.yml
like this:spring.autoconfigure.exclude: - org.springframework.cloud.client.serviceregistry.ServiceRegistryAutoConfiguration - org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration
Then you can write your own implementations or just ignore those beans.
see: https://github.com/cloud-ready/spring-cloud-service-discovery/tree/develop/spring-cloud-multi-registration for details.
Would it also not be possible to explicitly use the
ServiceRegistry
interface implementations from each package (eg. see EurekaRegistry) and explicitly register: