The Config component

Config is also called unified Configuration Center. As the name implies, it is unified configuration management. The benefits of unified configuration management are as follows: When service applications are deployed in a large-scale cluster in the future, the configurations of the same services are the same. If you modify the configurations in a unified manner, you do not need to manually maintain each service.

Config service center development

1. The configuration

  1. Create a separate Config module.

  2. Register the module into a service registry (in this article, Consul is the registry).

  3. Modules introduce dependencies

    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>
Copy the code

  4. Module start class adds annotations

    @SpringBootApplication
// Enable the configuration center service
@EnableConfigServer
public class ConfigApplication {

    public static void main(String[] args) { SpringApplication.run(ConfigApplication.class, args); }}Copy the code

  5. Create the configuration center remote repository on GithHub

  6. Get warehouse address

  7. Configure the Github repository address in the module

    spring:
  application:
    name: config
  cloud:
    # consul configuration
    consul:
      .
    # config configuration
    config:
      server:
        git:
          uri: https://github.com/AydenBryan/config-springcloud-demo.git
          If it is a private warehouse, it needs to be configured
          # username:
          # password:
Copy the code

  8. Create a configuration file in the Github remote repository

  1. Pull configuration files from remote repositories locally (three ways)

    Properties http://module IP: module port/products-xxx.yml http://module IP: module port/products-xxx.jsonCopy the code

  2. View pull configuration file details (as needed)

    http://module IP: module port/products/ XXX http://module IP: module port/products/dev http://module IP: module port/products/prodCopy the code

Note:

  1. When creating a repository on Github, you’ll be asked to choose between Public and Private. Public is a Public warehouse and Private is a Private warehouse. Generally, private warehouses are used by companies. Private warehouses can only be accessed by the user name and password assigned to you by the company, which is of high security, but you need to pay to use them. So this article uses the open repository as the configuration central repository.

  2. Username and password also need to be configured in the application.yml file if the private repository used is the remote repository for the configuration center.

  3. The configuration file type stored by the remote repository: Properties, YML.

  4. When the configuration center pulls the configuration file of the remote repository, the file type can be automatically changed according to the suffix of the configuration file in the pull request. However, file types can only be toggled between Properties, YML, and JSON.

  5. In the pull request, if you write

    http://module IP address: module port/products.propertiesCopy the code

    The products configuration file cannot be pulled. Because the Config registry has a specified format for the configuration file name in the pull request. This format refers to the principle of splitting and merging configuration files. In real project development, a service runs in multiple environments, such as dev, PROD, test, and so on. The configuration files of the service are different in each environment. The common configuration files are the same. However, each environment has its own special configuration. Therefore, a management scheme for configuration file decomposition and merge was derived.

    For example, the products service, products.yml is the common configuration of the service in different environments, products-dev.yml is the special configuration of the service in the development environment, and products-prod.yml is the special configuration of the service in the production environment. This management approach is also supported in the Config component, so for a service, we might create a common configuration file for that service and a special configuration file for each environment in the Github remote repository.

    If all three files exist, then the pull request is written to

    http://module IP: module port/products-xxx.propertiesCopy the code

    If products-xxx does not match any of the files in the remote repository, the products.yml file is pulled. If the pull request says

    http://module IP: module port/products-dev.propertiesCopy the code

    Yml and products-dev. Yml will be pulled down. If the pull request says

    http://module IP: module port/products-prod.propertiesCopy the code

    Yml and products-prod. Yml will be pulled down.

    This pull rule greatly reduces configuration redundancy in configuration files.

2. Specify the location of the local warehouse

  1. Create the localConfig folder in the project resources directory and copy the absolute path.

  2. The configuration application. Yml

    # config configuration
    config:
      server:
        git:
          uri: https://gitee.com/aydenbryan/config-springcloud-demo.git
          # Local warehouse location
          basedir: G:\Project\springcloud\springcloud-demo-HoxtonSR6\config\src\main\resources\localconfig
Copy the code

Note:

  1. localconfigThe folder must be a local repositoryAn empty folderOtherwise, the local repository will be forcibly emptied the first time the configuration file is fetched from the remote repository to the local repository.

3. Specify branch fetching

When there is more than one branch in the repository, you can grab the configuration file under the specified branch.

  1. If there is no branch, create one

  2. The configuration application. Yml

    # config configuration
    config:
      server:
        git:
          uri: https://gitee.com/aydenbryan/config-springcloud-demo.git
          # select branch
          default-label: dev
Copy the code

Note:

  1. On Github, inmainCreate a new branch under the branch,mainThe branch copies everything into the new branch.
  2. If the specified branch is not configured, the default branch ismain.

Config client development

The purpose of this example is to configure the Products service in the project as the Config client.

  1. Introduction of depend on

    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>
Copy the code

  2. Create a common configuration on Github to store the products.yml service in different environments

  3. Create a special configuration on Github to store the products-prod.yml service in a production environment

  4. Create products-dev. Yml on Github to store the special configuration of the service in the development environment

  5. Configure the bootstrap. Yml

    spring:
  cloud:
    config:
      discovery:
        Enable configuration center lookup
        enabled: true
        Configure the service name of the center
        service-id: config
      # select branch
      label: main
      # Specify the configuration file
      name: products
      # specify the context for the configuration file
      profile: dev
Copy the code

Note:

  1. All Config clients need to change application.yml to bootstrap.yml. For each Config client, part of the configuration needs to be pulled from the configuration center and part needs to be configured locally. Some configurations in the configuration center can be found in the configuration center only after local configuration.

    If the application. Yml configuration is used, application. Yml is loaded when the service is started. When the service is started, the service does not wait for the part of the configuration that is pulled from the configuration center. When the service is started, an error is reported if the configuration is missing.

    If the bootstrap.yml configuration is used, bootstrap.yml is loaded when the service is prestarted. When the service starts, the part of the configuration center has been pulled to the service and started normally.

  2. Because application.yml was originally used for local configuration, and because the project service startup requires an application name, you need to leave spring.application.name configured in local application.yml. Now, with bootstrap.yml being used for local configuration, the application name is loaded into the service from the configuration center when the project is pre-started, so you can configure spring.application.name in a remote repository.

Refreshing configuration Files

1.

After the configuration file in the Github remote repository is modified, the configuration file of each service client cannot be refreshed automatically. As a result, the related code that uses the configuration file parameters cannot be refreshed. The update can be made only after the service is restarted and the configuration center is re-accessed so that the configuration center can pull the configuration file from the remote repository again.

However, in a production environment, microservices can be numerous. It is not possible to restart all services after each change in the remote configuration. In this case, you need to enable the modified service to refresh the modified configurations on the remote device. In this way, the modified service does not take effect every time you restart the service, further improving the maintenance efficiency of the microservice system. There are also two strategies available in Spring Cloud: manual configuration refresh and automatic configuration refresh.

2. Manually refresh the configuration

  1. The Config client enables all Web endpoints (including those for remote configuration file refreshes)

    management:
  endpoints:
    web:
      exposure:
        include: "*"
Copy the code

  2. Configuration annotations enable the area code to be refreshed as the configuration file is refreshed

    @RestController
// The implementation code is refreshed as the configuration file is refreshed
@RefreshScope
public class TestController {

    // Get the content from the configuration file
    @Value("${name}")
    private String name;

    /** * Tests whether the remote configuration is refreshed *@returnPort information */
    @GetMapping("/config/testName")
    public String testName(a) {
        return "The name is:"+ name; }}Copy the code

  3. Manually sending a POST request invokes the refresh configuration interface

    Curl -x POST http:// service IP address: service port/actuator/refreshCopy the code

Note:

  1. Manual configuration refreshes only the configuration file of a service port, but not cluster services. Generally, o&M will write a script and automatically execute multiple scriptscrulTo refresh the cluster service. To easily refresh the configuration files of all ports in a cluster, you need to combineThe message busAutomatically refresh the configuration.