Spring Cloud Consul配置Spring Cloud Config

Question

I'm having a real tough time with this one. We want to use Spring Cloud Consul for service discovery and my colleges are pushing the idea to use Spring Cloud Consul Config over Spring Cloud Config, which I have already previously implemented for a related project. The thing is, Spring Cloud Config works great and has a seamless out-of-the-box version control conduit (git) for a dynamic centralized management of properties. In order to support this same functionality in Spring Cloud Consul Config it seems would require re-inventing the wheel already baked into Spring Cloud Config.

Does anyone have experience using both? Would it make sense to use both together? That is, have Spring Cloud Config Client pointing to a Spring Cloud Config Server for the more "static" environment properties (things that vary between dev, qa, stage, production both otherwise static) and Spring Cloud Consul Config for pure dynamic properties like service discovery?

Someone please correct me if I am wrong but from my understanding what I will need to do in order to support dynamic version control for "static" properties using Spring Cloud Consul Config, I would need some kind of conduit between say git and the physical "/config" directory of the running instance of each Spring Cloud Consul Config application instance :/

Answer 1

tl;dr: I use spring cloud config and spring cloud consul but not spring cloud consul config.

I did not use spring cloud consul config specifically since I am not using consul config, but I am using a spring cloud config server that register itself in consul and I have other microservices accessing the spring cloud config server through consul for service discovery. Both server and client uses spring cloud consul to register and discover the config server. And the config server and config clients both uses spring cloud config.

Here is my setup:

Spring Cloud Config Server

Dependencies:

org.springframework.cloud:spring-cloud-config-server
org.springframework.cloud:spring-cloud-starter-consul-discovery
org.springframework.boot:spring-boot-starter-actuator

bootstrap.properties:

spring.application.name=config-server
spring.cloud.consul.host=CONSUL_HOSTNAME
spring.cloud.consul.port=CONSUL_PORT

application.properties:

spring.cloud.config.server.git.uri=GIT_REPO_URL
spring.cloud.config.server.git.username=GIT_REPO_USERNAME
spring.cloud.config.server.git.password=GIT_REPO_PASSWORD

Application.java:

@SpringBootApplication
@EnableConfigServer
@EnableDiscoveryClient
public class Application
{
    public static void main(String[] args)
    {
        SpringApplication.run(Application.class);
    }
}

Spring Cloud Client Application

Dependencies:

org.springframework.cloud:spring-cloud-starter-config
org.springframework.cloud:spring-cloud-starter-consul-discovery
org.springframework.boot:spring-boot-starter-web
org.springframework.boot:spring-boot-starter-actuator

bootstrap.properties:

spring.application.name=client-app-name
spring.cloud.consul.host=CONSUL_HOSTNAME
spring.cloud.consul.port=CONSUL_PORT
spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.serviceId=config-server

Application.java:

@SpringBootApplication
@EnableDiscoveryClient
public class Application
{
    public static void main(String[] args)
    {
        SpringApplication.run(Application.class);
    }
}

Answer 2

So far as I understand, in case of configuration management, in compare with spring cloud config, Consul(with git2Consul) provides solution of data exchanging across multiple datacenter and failover of nodes.

For single datacenter use, spring cloud config (with simple failover solution, eg LVS, master/slave, rsync mechanism etc) is enough.

For service discovery, Consul has health check mechanism and can enable automatic switch of routings. In spring cloud config, extra work needs to be done to implement semi-automatic discovery.