Distributed configuration center selection, why Apollo?

This is the third day of my participation in the August More text Challenge. For details, see: August More Text Challenge

Author: Tom brother wechat public account: Micro technology

Spring Boot is a major microservices framework with a mature community ecology. Market widely used, in order to facilitate everyone, organizing a spring-based boot used middleware introduction to quickly integrate series manual, involving the RPC, caching, message queues, depots table, registry, common open source components, such as distributed configuration about dozens of article, will open up in succession, the students are interested in, please attention & collection in advance

The general approach to configuration is to extract configuration information into XML, Properties files, and then bundle it with the application and publish it. If there are multiple environments, such as development, test, pre-delivery, and production, separate the environments by configuring separate files. However, applications must be republished every time configuration parameters are changed, which results in poor flexibility.

For example, Taobao holds the Double 11 event every year, which brings hundreds of billions of GMV, and the traffic is very large. In order to maintain the stability of the system, various drills, pressure tests, and thousands of mitigation plans are usually developed. If an emergency occurs, which switch should be turned on and corresponding emergency handling measures should be taken. If according to the above gameplay, every time to go a release process, a cluster of thousands of servers, released, half an hour is gone, how much money this loss.

Endowment loss does not calculate first, but your annual assessment 3.25 affirmation is did not have to run, year-end bonus bubble soup, win white rich beauty, walk on life peak… Brother wake up…

Like Dove, can we build silky Features that can dynamically sense configuration changes without going through the release process?

At this point we need a middleware framework, the Distributed Configuration Center.

Work for so many years, large and small, a variety of open source distributed configuration framework has the following:

1, the Apollo,

In May 2016, ctrip opened an open source configuration management center with standardized authority, process governance and other features.

2. Spring Cloud Config

Open source in September 2014, The Spring Cloud ecosystem component can be seamlessly integrated with the Spring Cloud architecture.

3, disconf

In July 2014, baidu’s open source configuration management center also has configuration management capability, but it is no longer maintained. The latest submission was two years ago.

4, Nacos

In June 2018, Ali’s open source configuration center can also do DNS and RPC service discovery.

5, Diamond,

Diamond from Taobao, open source address [github.com/takeseem/di…] has been maintained, here is not expanded.

The functions of the other four frames are compared. The table is larger and can be swiped left and right

Nacos configuration files support many formats, such as YAML, TEXT, JSON, XML, HTML, and Properties. Apollo only supports XML, TEXT, and Properties formats, and is not compatible with the common YAML configuration in Spring Boot. Although Nacos supports multi-format configuration files, it does not parse as well as Apollo, which supports fewer configuration formats but parses them so that each configuration looks intuitive and can be modified individually.

Apollo user management and permission management to do a good and comprehensive, suitable for the department or corporate level configuration center. Nacos is more concise, the permissions part is weak. Apollo has an active community — github’s last submission was on April 11, 2021 — and so many other companies are using it that the usual pits have been trampled.

Of course, Nacos, as a rising star and backed by Ali, has a very high market activity at present. You can choose according to your own situation. If it is safe, you can choose Apollo

Apollo is introduced

Apollo (Apollo) is a distributed configuration center developed by ctrip framework department. Apollo can centrally manage the configuration of different application environments and different clusters. The modified configuration can be pushed to the application end in real time.

Apollo includes two parts: server side and client side:

The server is developed based on Spring Boot and Spring Cloud, and can be run directly after packaging, without additional installation of application containers such as Tomcat.

The Java client does not depend on any framework, can run in all Java runtime environment, and Spring, Spring Boot environment also has good support.

Open source address: github.com/ctripcorp/a…

features

Apollo was designed to be a governing configuration publishing platform based on the specific nature of configuration, and currently offers the following features:

• Manage the configurations of different environments and clusters in a unified manner

• Configuration Changes Take Effect in Real time (Hot release)

• Version release management

• Gray released

• Permission management, release audit, operation audit

• Monitor client configuration information

• Provide Java and. Net native client

• Provide an open platform API

• The deployment of simple

Show me the code

External dependence:

Add the Apollo dependency to the pom.xml file:

<dependency> <groupId>com.ctrip.framework.apollo</groupId> <artifactId>apollo-client</artifactId> The < version > 1.4.0 < / version > < / dependency >Copy the code

Configuration file:

Configure Pulsar parameters in the application. Yaml configuration file as follows:

Apollo: meta: http://127.0.0.1:8080 bootstrap: Enabled: true App: ID: Spring-boot-Bulking-apolloCopy the code

Real-time dynamic awareness configuration change:

@Component public class ApolloConfig { private static final String USER_TIMEOUT = "user.timeout"; @PostConstruct public void init() { Config config = ConfigService.getAppConfig(); config.addChangeListener(changeEvent -> { ConfigChange configChange = changeEvent.getChange(USER_TIMEOUT); PropertyChangeType changeType = configChange.getChangeType(); if (PropertyChangeType.ADDED.equals(changeType) || PropertyChangeType.MODIFIED .equals(changeType)) { System.out.println(string.format (" dynamically refresh the new value. Key :%s, value :%s ", USER_TIMEOUT, configchange.getNewValue ())); } }, Sets.newHashSet(USER_TIMEOUT)); String userTimeoutValue = config.getProperty(USER_TIMEOUT, null); System.out.println(String. Format (" first pull. Key :%s, value :%s ", USER_TIMEOUT, userTimeoutValue); }}Copy the code

Management background

Console address:

http://localhost:8070/config.html?#/appid=spring-boot-bulking-apollo

The console changes the value of user.timeout several times, and the client system can receive the configuration change in real time.

First pull. Key :user.timeout, value: 1000 New value for dynamic refresh. Key :user.timeout, value: 500 New value for dynamic refresh. Key :user.timeout, value: 1000 New value for dynamic refresh. Key :user.timeout, value: 500 New value for dynamic refresh. Key :user.timeout, the value is 1000Copy the code

Demo code address

https://github.com/aalansehaiyang/spring-boot-bulking modules: spring - the boot - bulking - ApolloCopy the code