SpringCloud How to Extract Common Configuration

SpringCloud Extract Common Configuration

When developing micro-service projects, There are usually many services, The configuration center is used to manage the configuration of these services, But some services may have the same configuration, Such as data source configuration, eureka server Registry Address Configuration, actuator open port configuration, etc., Many services are needed. If each service writes one such identical configuration, there are more than one service, which is quite troublesome. If you want to change a database or registry, every service has to be changed, which is very troublesome. Therefore, you need to extract these public configurations and put them in public configuration files, and these services can reference these configurations.

The configuration file of the original service might look like this:

spring:
  application:
    name: eureka-client
  cloud:
    config:
      uri: http://localhost:8888  # Configuration center address 
      label: master
      profile: dev

At this time, the service will go to config by default to find the configuration file named eureka-client-dev. yml. This configuration file may have the eureka server address, Data source configuration, redis configuration, etc., And the configuration file of another service may have these same configurations, You can then extract these same configurations, Put it into multiple configuration files, and let the service read these configuration files. For example, there may be base-dev. yml to put the configuration common to each service, datasource-dev. yml to store the data source configuration, and eureka-client-dev. yml is the unique configuration of this service. These configuration files are all in config server, then the configuration files in the service project can be changed as follows:

spring:
  application:
    name: eureka-client
  cloud:
    config:
      uri: http://localhost:8888  # Configuration center address 
      label: master
      profile: dev
      name: eureka-client,base,datasource

In this way, eureka-client services will go to the configuration center to read these three configuration files. If necessary, other services can directly add file names to spring. cloud. config. name attributes in their own configuration instead of writing the same configuration.

Solution of SpringCloud config Multi-service Sharing Common Configuration

Problem description

Our company's project is a micro-service developed based on SpringCloud, which uses Spring-Cloud-Config as the configuration center of micro-service system 1, and can manage the configuration of each service scattered in the system 1.

Although the configuration center manages the configuration files of each application in a unified way, some public configurations involved, such as database connection, redis connection, ftp connection, etc., are still scattered in the configuration files of each application and have not been extracted. We need to modify them dynamically according to different environments, which is very difficult to maintain. As a result, every time it involves modifying these public configurations, it is very old-fashioned.

Therefore, I thought of using the public file method, and now I briefly explain how to configure it under 1. (The following examples Spring-Cloud-Config-Server are all configured locally).

After consulting the information on the Internet, most of them are configured by Method 1, so I provided a Method 2 configuration, which may make your eyes shine, and then leave your thoughts. If you choose, which method will you choose?

Method 1:

First, create a common configuration file common. yml in the config/directory of the configuration center, and then configure multiple configuration file names here spring. cloud. config. name in the bootstrap. yml file under each application.

For example:

service-bootstap. yml for a client:

spring:
  cloud:
    config:
      name: service-a, common

bootstap. yml for service-b client:

spring:
  cloud:
    config:
      name: service-b, common

Method 2: (Recommended)

We still remember how to pull away from the public configuration when springboot was used as a single unit. The answer is to use spring. profiles. include to reference other public profiles. And its file name has a characteristic, that is, it must be the configuration file at the beginning of application.

We will also wonder if the configuration like spring-cloud-config is centralized, will this configuration take effect?

For example:

First, we create the application-common-dev. yml configuration file in the config/directory

Then modify the configuration files of service-a and service-b under the config/directory, respectively, to configure as follows:

service-a-dev. yml for service-a client

spring:
  application:
    name: service-a
  # Common profile 
  profiles:
    include: common-dev

service-b-dev. yml for service-b client

spring:
  application:
    name: service-b
  # Common profile 
  profiles:
    include: common-dev

Start each service separately, and you can see that the service started successfully.

So, which of these two ways is better?

Method 1:

Disadvantages: If there is a new public configuration file, you need to go to bootstrap. yml of each service to modify 1. And you need to republish the jar package.

Method 2:

Advantages: The configuration can be externalized, and the configuration file can be modified without the need to publish the jar package separately.