Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "how to understand the technical selection of configuration center". In the operation process of actual cases, many people will encounter such difficulties. Next, let Xiaobian lead you to learn how to deal with these situations. I hope you can read carefully and learn something!

At present, in the construction of internal micro-service architecture infrastructure of the company, Spring Cloud technology is the main technology selection, which is also commonly known as "family bucket."

★ Because it has the various service components required in the microservice architecture system, such as service registration discovery (e.g. Spring Cloud Eureka, Zookeeper, Consul), API Gateway Routing Services (Spring Cloud Zuul), Client Load Balancer (Spring Cloud Ribbon, Zuul integrates Ribbon by default), Service Fault Tolerance Protection Spring Cloud Hystrix, Spring Cloud Bus, Spring Cloud Config, Spring Cloud Stream, Spring Cloud Sleuth. "

This article focuses on one of these components, the Distributed Configuration Center.

Spring Cloud Config Configuration Center Introduction & Architecture

Configuration center is one of the more important components in microservice architecture. Spring Cloud itself provides Spring Cloud Config distributed configuration center, which provides centralized external configuration support. It is divided into two parts: client and server.

The server is called a configuration center, which is an independent microservice application, which is used to connect the repository (such as Git, Svn) and provide an interface for obtaining configuration from the client; while the client is each microservice application, which obtains configuration content from the remote end by specifying the configuration center address, and loads configuration information into the application context when starting.

Because the configuration center implemented by Spring Cloud Config uses Git to store configuration information by default, version control management is also supported based on the characteristics of the Git repository itself.

After investigation of this component, the architecture based on message bus is mainly adopted, and the architecture diagram is shown as follows:

The configuration center architecture based on message bus needs to rely on external MQ components, such as Rabbit and Kafka to realize remote environment event change notification, and the client real-time configuration change can be realized based on Git Hook function.

At the same time, you can see on the rightmost side of the architecture diagram that there is a Self scheduling refresher. This is an extension I added in practice. The purpose is that when there is a problem with the dependent message component, if the Git repository configuration changes, some or all clients may not be able to obtain the latest configuration, which causes the client application configuration data to fail to achieve final consistency, thus causing online problems.

★ Self-scheduling refresher is a timed task. It is executed once every 5 minutes by default. If the local Git repository version is inconsistent with the remote Git repository version, the latest configuration will be obtained from the configuration center for loading, ensuring the final consistency of the configuration. "

After practical use, you will find that Spring Cloud Config is not very easy to use. If it is a small-scale project, it can be used without a problem, but it is not suitable for medium and large enterprise-level configuration management.

Therefore, after comparing the configuration centers of open source in the industry, I finally chose Apollo Configuration Center of Ctrip Open Source to solve the pain points of configuration management in microservice architecture and configuration management in other projects.

Here's a more intuitive comparison between Spring Cloud Config and Apollo Configuration Center:

Apollo VS Spring Cloud Config

Through the above comparison chart, it is found that Spring Cloud Config defects are quite large, such as the last high availability, Apollo configuration center client application will generate cache files locally after loading the configuration, even if all the services in the configuration center are suspended, only the configuration cannot be updated, but it does not affect your service startup.

And this Spring Cloud Config is not able to do, some people will say that we can add application configuration files under the application classpath as "bottom use", this first configuration will not automatically synchronize, and is not the function of Spring Cloud Config itself.

Another reason is that some self-developed configuration centers are also used in the current project, but they are not satisfactory. Some configuration centers only support xml format and cannot support KV format; some configuration centers are developed based on JMX, but only support attribute configuration push.

Therefore, after investigation and use of Apollo Configuration Center, it is found that this product is not only suitable for microservice configuration management scenarios, but also supports multiple configuration formats, such as xml, json, yml, and multi-language client access. It is also perfect in configuration service governance. It has supported 100,000 + instances in Ctrip, mature and stable!

Open Source Configuration Center Comparison

Here is a detailed comparison of open source configuration centers:

In the open source configuration centers mentioned above, the Apollo community is very active, constantly updating iterations.

Before Apollo appeared, Baidu open source disconf configuration center used more, disconf latest code update time is still 2 years ago, and compared with Apollo community activity has declined.

Apollo Configuration Center Introduction & Architecture

Apollo is a distributed configuration center developed by Ctrip Framework Department. It can centrally manage the configuration of different environments and clusters of applications. After configuration modification, it can be pushed to the application end in real time. It has standardized permissions, process governance and other characteristics, which is suitable for microservice configuration management scenarios.

The server side is based on Spring Boot and Spring Cloud development, which does not rely on external containers and is easy to deploy.

Java clients do not depend on any framework and can run on all Java runtime environments, with additional support for Spring/Spring Boot environments.

Native support Java and. Net clients, but also support other language clients, currently supports Go, PHP, Python, NodeJS, C++.

Main functional characteristics:

Unified management of configurations in different environments and clusters

Configuration changes take effect in real time (hot release)

Release Management

releasing services on a server in stages

Permission management, release audit, operation audit

Client Configuration Information Monitoring

Java and. Net native clients available

Open Platform API

Simple deployment with few dependencies

Apollo overall architecture design:

Description of each component:

Apollo HA High Availability Design:

Apollo Client Architecture:

Client Architecture Principle:

1. push-pull combination

The client maintains a long connection with the configuration center and configures real-time push.

Timed pull configuration (default 5 minutes)

2. Local cache

Configuration cache in memory

Locally cache a profile

3. application

Get the latest configuration via Apollo client

Subscribe to configuration update notifications

Apollo core concepts:

application

Each app needs a unique ID-- appId

environment

Apollo client obtains corresponding configuration through different environments

cluster

Different instances of an application can be grouped, and different clusters can have different configurations.

For example, Beijing computer room and Tianjin computer room can have different kafka or zk address configuration.

namespace

Groups of different configurations under an application, different namespaces are similar to different files.

Such as: database configuration, RPC configuration, etc. Support for inheriting configurations from common components.

disposition division

Private: can only be obtained by the application to which it belongs

Public type: Must be globally unique. Usage scenarios: shared configuration at department/team level, middleware client configuration.

Association type (inheritance type): private inherits public configuration and overrides; customize public component configuration scenarios.

Item

Default and public configurations use properties format; private configurations support properties/json/xml/yaml/yml format.

Location: app+cluster+namespace+item_key

rights management

The system administrator has all the privileges.

Creators can create projects on their behalf, and the responsible person is the project administrator by default. Generally, creator = responsible person

Project administrators can create clusters, Namespace, manage projects and Namespace permissions

Edit permission can only be edited, not published

Cloth permission can only be published, not edited

Ordinary users can search and view all project configurations, but do not have relevant operation permissions.

Apollo configuration used and extended

With Apollo Configuration Center, further feature development extensions were made to access corporate SSO and email notification access.

In the Spring Cloud Config microservice architecture, if you used Spring Cloud Config before, you can also migrate to Apollo Configuration Center smoothly in the following ways.

The Spring Cloud microservices project introduces the following dependencies in pom.xml:

com.letv.micro.apollo micro-apollo-spring-boot-starter 1.0-SNAPSHOT

The source code reference Github:

★ https://github.com/david1228/micro-apollo-spring-boot-starter"

It needs to be compiled into jar packages for use.

This jar package further encapsulates the Spring Cloud configuration refresh mechanism integration Apollo client. The main functions are as follows:

1. After the Apollo configuration center publishes the configuration, the microservice application client listens for configuration changes, including default configuration and public configuration, and completes the configuration refresh of the application environment context through the refresh() method in ContextRefresh.

2. Support dynamic configuration changes to log levels and log path files. [Apollo Client does not support log level and log path file changes well because the LoggingApplicationListener load priority of logs is high and Apollo configuration loads late.]

The above jar package has been uploaded to the company's Maven private server. For specific configuration examples, please refer to "4.Apollo Configuration Center Usage Examples"

With the introduction of micro-apollo-spring-boot-starter, the spring-cloud-stater-config dependency can be removed from pom.xml.

Apollo Configuration Center common configuration naming conventions:

Common configuration is recommended to be placed uniformly in the newly created project, where the configuration of Spring Cloud-related common components, such as Eureka, Zipkin, Stream, etc., is stored. For example, the Eureka address may be shared by multiple microservice applications, so as to facilitate unified configuration management in the project.

When creating a project, select a department such as microservices public platform (dpms)

After each microservice application project is created, you can add Namespace and select Associated Public Configuration.

Common configuration naming rules: {department prefix}.application or {department prefix}.application-{specific subdivision configuration}

After the Apollo configuration is released, if the Spring Cloud configuration is to be dynamically loaded, the public configuration name must start with the application keyword, and configuration changes will be monitored for such named namespaces in the above dependent jar package.

For example:

dpms.application-eureka Store eureka-related configuration

or dpms.application-zipkin stores zipkin-dependent configurations

or dpms.application stores all of Spring Cloud's common dependencies

Common configuration items used by default after other microservices are associated with common configurations.

You can also override all parameters of the public configuration, and then get the configuration in this project first. This feature can be visually displayed in Apolo's public configuration interface.

The above is some introduction to why you should choose Apollo Configuration Center. I believe that you may also encounter similar configuration management problems or pain points in your project. It is strongly recommended to use Apollo Configuration Center as your configuration management basic service.

"How to understand the configuration center technology selection" content is introduced here, thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.