Microservice ServiceComb example to explain the selection and connection of microservice configuration center

Author Li Bo

Configuration Center

Various configuration items are often used in project code. For example, the following code is obtained from system environment variables prop:

String prop = System.getProperty(myProperty);
int x = DEFAULT_VALUE;
try {
    x = Integer.parseInt(prop);
} catch (NumberFormatException e) {
    // handle format issues
}
myMethod(x);

Similar to the method of using environment variables or files such as propertiesand xmlfiles to pass in the configuration to control the performance of the application is widely used in the development process. This can decouple the external configuration from the business code. If there is a change, you only need to modify the configuration parameters without recompiling. Build the project. However, this way of putting configuration and code together may reveal private information (such as passwords), because the code may be public. For security reasons, the separation management method of configuration and code has become widely used. Common methods such as putting The configuration is placed on the CI server into the application package through the packaging script, or directly placed in a specific directory of the server running the application, or stored in the database. This approach is simple and effective in traditional monolithic applications, but it also brings some new challenges:

When the configuration changes frequently, the application needs to be packaged and deployed frequently
Different configuration items in different environments need to be managed separately (such as test environment and production environment)
Although the private information in the configuration item is avoided from being leaked with the code disclosure, it will still be packaged into the application package

In addition, facing the explosive growth of microservices in the number of applications and servers brings new difficulties

Complex business corresponds to a large number of configuration items
Configuration items may conflict in different services
When modifying the application configuration deployed in the cluster, you need to modify the application configuration on each machine at one time

In this context, a centralized configuration service, that is, a configuration center, came into being. Simply put, a configuration center is a basic service component that manages various application configurations in a unified manner. A qualified configuration center needs to meet:

Configuration items are easy to read and modify
Adding new configurations is straightforward
Supports review of configuration changes to control risks
Can view the history of configuration modifications
Different deployment environments support isolation

The current mainstream configuration centers in the open source community include spring-cloud-config, ctrip apollo, disconf, etc. The following table is a comparison of their functional characteristics, technical route, usability and ease of use [3] for reference.

	spring-cloud-config	ctrip apollo	disconf
Static configuration management	file based	support	support
Dynamic Configuration Management	support	support	support
Unified management	None, requires github	support	support
Multi-dimensional management	None, requires github	support	support
local configuration cache	without	support	support
Configuration effective time	Restart or manual refresh to take effect	real time	real time
Configuration update push	Manual trigger	support	support
Configure timing pull	without	support	Depends on event driven
Authorization, Audit, Review	None, requires github	support	without
Configure version management	git for version management	Release history and rollback buttons are provided on the interface	Operations are recorded in the database, no query interface
Instance configuration monitoring	Need to combine spring admin	support	support
grayscale release	not support	support	Partial updates are not supported
Alarm notification	not support	Support, email alert	Support, email alert
Multi-Data Center Deployment	support	support	support
configuration interface	None, via git	Unified interface	Unified interface

After comprehensive comparison, ServiceComb chose Apollo[4] as the configuration center for docking. Apollo is a distributed configuration center developed by Ctrip's framework department and contributed to the open source community, with nearly 100 active contributors. The latest version of ServiceComb Java Chassis has realized support for Apollo. Users can use the configuration center combined with Archaius integrated in Chassis to achieve centralized management and dynamic modification of configuration items without restarting or redeploying applications. Based on ServiceComb's excellent plug-in design, users can easily connect to other open source or self-developed configuration centers.

Introduction

Start the Apollo service

Start apollo service

Apollo service can be started through docker or binary. For the method, please refer to the official website document [5]. It is recommended to use docker to start.

git clone https://github.com/lijasonvip/apollo-image-for-servicecomb.git
cd apollo-image-for-servicecomb && docker-compose up

After it appears apollo-quick-start | Portal started. You can visit http://localhost:8070 now!, it means that Apollo has been successfully started, and the browser http://localhost:8070can access portalthe service. The default login account is apollo/admin.

Create an app

After logging in, click Create Project, fill in the application name, and select the default for others. After creating an application, you need to enter the application and click Publish to take effect.

Produce TOKEN

After the application is released, we need to obtain a TOKEN, http://localhost:8070/open/manage.htmlfill in the application ID and application name just created on the page, select the project and department information, and click Create to generate a TOKEN, save this TOKEN and configure it in the configuration file of the Chassis application.

import dependencies

Introduce dependencies in the pom file of the Chassis application config-apollo:

 <dependency>
       <groupId>org.apache.servicecomb</groupId>
       <artifactId>config-apollo</artifactId>
 </dependency>

add configuration

microservice.yamlAdd the following configuration to the configuration file of the Chassis application :

   apollo:
     config:
       serverUri: http://127.0.0.1:8070
       serviceName: provider-id				#创建应用时的AppID
       env: DEV
       clusters: default
       namespace: application
       token: de3c5b2e6d8535b96
       refreshInterval: 10

So far, the simple 4-step application has been successfully connected to the Apollo configuration center. After starting the application, you can perform service management on the Apollo page through operations such as adding, updating, and rolling back configuration items! Demo reference [6].

Docking configuration center

Chassis dynamic configuration is based on Netflix's Archaius implementation [7], Archaius extended data source method reference document [8] and demo [9], Chassis extends PolledConfigurationSourceand according to [8], and AbstractPollingScheduleruses the SPI mechanism to find the implementation class of the Source interface at startup.

To connect to a new configuration center, you only need to extend the implementation ConfigCenterConfigurationSourceinterface, implement initthe method, initimplement the connection configuration center in the method, and refresh the logic of the configuration item. Please refer to [10] for the specific code.

Design configuration items

When connected to the new configuration center, you can design new configuration parameters, define new tool classes to obtain these parameters, and specify default values, and refer to the processing ApolloConfigof new apollo.config.serverUriparameters by the class

Extend the Source interface

The init function implements the logic of obtaining the configuration items of the configuration center at fixed time intervals or in real time. ApolloClientThe middle refreshApolloConfigfunction starts a regularly executed thread to refresh the configuration item:

  public void refreshApolloConfig() {
    EXECUTOR
        .scheduleWithFixedDelay(new ConfigRefresh(serviceUri), 
                                firstRefreshInterval, 
                                refreshInterval, 
                                TimeUnit.SECONDS);
  }

ConfigRefreshThe middle of the thread runwill obtain the latest configuration items from the Apollo configuration center and compare and analyze the new, modified and deleted configuration parameters with the previous configuration items, and then perform the corresponding update operations. Modifications and updates to configuration items are based on Archaius to WatchedUpdateListenerachieve dynamic update of in-app parameters.

Join the ServiceComb community

ServiceComb is currently incubating in the Apache Foundation. Developers and users are sincerely welcome to participate in community discussions and contributions. The methods of joining the community include subscribing to the mailing list, following the WeChat public account, and joining the community WeChat group. For details, please refer to [1].

Scan the QR code below to add ServiceComb assistant and follow the community account.

ServiceComb assistant