Explain 4 kinds of common configuration center, compare their process and principle, whether interview or technical selection, are very helpful.

Previous selections:

• How to treat the programmer 35 career crisis?
• Java full set of learning materials (14W words), took half a year to sort out
• I spent three months writing the GO core manual for you
• Message queuing: From model selection to principle, this article takes you through everything
• Micro service gateway selection, please take my knee!
• How to choose the five registries? Interpret to you from principle!
• Liver ETCD for a month, from Raft principle to practice
• Much more! Much more! Much more! Triple strike!!

Hello everyone, I am Lou Zai! This is the fifth article I’ve written on “technology selection,” following message queues, registries, microservices Gateways, and RPC frameworks. This configuration Center is probably the last in a series that spans nearly a year, making it my longest.

After learning the registry, look at the configuration center piece, feel a lot easier, because a lot of knowledge principle is complementary to each other, the following is the article table of contents:

Configuration Center Foundation

Why use a configuration center?

• The configuration takes effect in real time: In the traditional static configuration mode, you can only modify a configuration and then re-publish the application. To achieve dynamic configuration, you can choose to use the database and access the database through periodic polling to sense configuration changes. Low polling frequency leads to a long delay in sensing configuration changes, while high polling frequency leads to a short delay in sensing configuration changes. However, when comparing loss performance, a compromise between real-time performance and performance is required. The configuration center manages dynamic configuration based on real-time performance and consistency.
• Configuration management process: A series of configuration management-related features, such as configuration permission control, gray release, version management, format verification, and security configuration, are not available in the configuration center.
• Distributed scenario: With the adoption of distributed development mode, the mutual reference between projects increases exponentially with the increasing number of services. Each time a new project is put into production or goes online, the configuration center governance needs to be referred to.

Configure center support functions

• Grayscale publishing: Grayscale publishing of configurations is an important function of the configuration center. When configuration changes have a great impact, verify whether the configuration changes meet expectations in some application instances and then push the configuration changes to all application instances.
• Permission management: Configuration changes and code changes are both changes to the application running logic. Important configuration changes often bring about the effect of nuclear bombs. The permission control and audit ability for configuration changes are also important functions of configuration center.
• Version management & Rollback: When configuration changes do not meet expectations, you need to roll back the configuration based on the release version.
• Configuration format verification: Application configuration data is usually stored in one configuration format in the configuration center, such as Properties, Json, and Yaml. Incorrect configuration formats may cause client configuration parsing failures and production faults. The configuration center verifies the configuration format to effectively prevent human error operations. Is the core function of the configuration center.
• Listen to queries: When troubleshooting problems or performing statistics, you need to know which application instances use a configuration and which configurations are used by an instance.
• Multiple environments: In actual production, the configuration center often involves multiple environments or clusters. During business development, the development environment and production environment can be separated, or multiple production environments can exist according to different business lines. The configuration center can support multiple environments through logical isolation if the interaction between the environments is small (the development environment affects the stability of the production environment).
• Multiple cluster: When the system has high requirements for stability and does not allow environments to affect each other, multiple environments need to be physically isolated in multiple clusters.

Common Configuration Center

Writing in the front

If any service that can be used as a distributed storage is used as a configuration center, there are too many options, such as Zookeeper and ETCD, so you need to explain them in advance.

In the article “Principle and Selection of Registry: As mentioned in Zookeeper, Eureka, Nacos, Consul and ETCD, Zookeeper and ETCD can store data and serve as a configuration center. For example, the microservice gateway of our company publishes its configuration to ETCD for each module of the gateway to call. For details, please refer to the article microservice Gateway: From comparison to selection, from Theory to Practice.

However, when we choose the configuration center, why not give priority to Zookeeper and ETCD? There are two reasons:

• There is no convenient UI management tool, and lack of authority, audit, gray release, audit mechanism, etc.
• On top of that, Zookeeper and ETCD are typically defined as service registries, leaving centralized configuration to specialized tools.

To sum up in plain English, professional people do professional things, he can not support a lot of functions. Why, you may ask, does your company use ETCD as its configuration center? Because we wrote a background, support permissions, gray release, version control and other functions.

Therefore, the following four configuration centers are mainly introduced, namely, Disconf, Spring Cloud Config, Apollo and Nacos.

Apollo

GitHub:github.com/apolloconfi…

Apollo (Apollo) is an open source configuration management center developed by Ctrip Framework Department, with standardized permissions, process governance and other features.

Apollo framework

Apollo’s framework is a bit complex, and if you leave aside service discovery issues in distributed microservices architecture, the simplest architecture of Apollo is shown below:

This contains the four core modules of the Apollo framework:

• ConfigService: provides a configuration fetch interface and a configuration push interface for the Apollo client.
• AdminService: provides configuration management interface, provides configuration modification publishing interface, and serves the management Portal.
• Client: Obtains the ConfigService service list using MetaServer and invoks the ConfigService in SLB mode.
• Portal: obtain the Service list of AdminService by using MetaServer and invoke AdminService in SLB mode.

Call flow:

1. ConfigService is an independent microservice for clients to obtain configurations.
2. The Client maintains a long connection with the ConfigService. In push and pull mode, real-time configuration updates are implemented to ensure that configuration updates are not lost.
3. AdminService is an independent microservice that serves the Portal for configuration management. Portal invokes AdminService for configuration management and publishing.
4. ConfigService and AdminService share ConfigDB, which stores configuration information about a project in a certain environment. In each environment ConfigService/AdminService ConfigDB three (DEV/FAT/UAT/PRO) to be deployed in a.
5. Protal has a separate PortalDB that holds metadata information about user permissions, projects, and configurations. Protal requires only one deployment and can manage multiple environments.

Together with service discovery in distributed microservices architecture, the real Apollo framework is as follows:

If you know about RPC and registries, this picture is not hard to understand:

• Eureka is used for registries, AP principles, so the list of machines for Config Service and Admin Service is registered in Eureka.
• The Client and Portal need to obtain the list of machines in the registry, but since Eureka only supports Java clients, a Meta Server is created to expose Eureka’s service discovery interface in the form of HTTP interface.
• Since Meta Server is clustered, NginxLB is required to find Meta Server machines.

NginxLB + Meta Server is designed to find the Eureka machine list configuration, and the Client and Portal can call the machine list configuration.

I have said enough clear, if you still do not understand, read this article “micro service architecture ~ Ctrip Apollo configuration center architecture analysis”

Apollo features

• Centrally manage configurations in different environments and clusters:
  • Apollo provides a unified interface to centrally manage configurations of different environments, clusters, and namespaces.
  • The same piece of code deployed in different clusters can have different configurations, such as zK addresses, etc.
  • Namespaces allow multiple applications to share the same configuration and overwrite the shared configuration.
• Configuration changes take effect in real time (hot release) : After the user changes the configuration in Apollo and publishes it, the client can receive the latest configuration in real time (1 second) and notify the application.
• Version release management + grayscale release
• Permission management, release audit, and operation audit: Applications and configurations are managed by a complete permission management mechanism. Configuration management is also divided into editing and publishing to reduce human errors. All operations have audit logs, so problems can be easily traced.
• Client configuration information monitoring: You can easily see which instances the configuration is being used on the interface.
• Provides Java and. Net native client:
  • Java and. Net native client, easy application integration.
  • Support Spring Placeholder, Annotation and Spring Boot ConfigurationProperties for easy application.
  • Provides Http interfaces, non-Java and. Net applications are also easy to use.
• Provide open platform apis:
  • Apollo itself provides a comprehensive unified configuration management interface, supporting multi-environment, multi-data center configuration management, rights, process management, and other features.
  • For versatility, Apollo doesn’t limit configuration changes too much, as long as it conforms to the basic format.
  • For some users, the configuration may have a complex format, and the input values may need to be verified before being saved, such as checking for database, username, and password matches. For these applications, Apollo allows applications to modify and publish configurations at Apollo through an open interface, with complete authorization and permission controls.

Finally, through the background interface, intuitive experience:

Disconf

GitHub:github.com/knightliao/…

In July 2014, Baidu opened the open source configuration management center, which also has the configuration management ability, but currently does not maintain, the last submission is two years ago.

Disconf framework

Disconf is a unified distributed configuration solution based on ZooKeeper. It manages configuration information through Disconf-Web and creates a node on ZooKeeper based on the configured key. After the disconf-client starts, it pulls the required configuration information and listens to the Zookeeper node. Updating the configuration information on the Web UI triggers the status change of the ZK node. The client can detect the change in real time and pull the latest configuration information from the Web UI.

Here I would like to make a joke, the official Disconf document drawing is really ugly ah, the key is very unclear, can not be well maintained?

Disconf characteristics

• Supports distributed configuration (configuration items and configuration files) management:
  • Unified configuration and publishing
  • Unified configuration publishing and updating (cloud storage and publishing) : Users can publish and update configurations on the cloud system in a unified manner.
  • Configuration update automation: When a user updates a configuration on the platform, the system using the configuration automatically detects the situation and applies the new configuration. In particular, if the user defines a callback function class for this configuration, this function class is called automatically.
• Configure heterogeneous system management:
  • Unified deployment of heterogeneous packages: A heterogeneous system refers to a situation where multiple deployment packages (JAR or WAR) are required due to different configurations when multiple instances of a system are deployed (the same below). After Disconf is used, only one deployment package is required for heterogeneous system deployment, and configurations of different instances are automatically allocated. In particular, as deployment virtualization (such as JPAAS, SAE, BAE) is increasingly used in the industry, the same system will use the same deployment package, and Disconf is a natural fit. Heterogeneous active/Standby switchover: If a heterogeneous system has active and standby nodes, the standby node automatically obtains the host configuration and becomes the host when the host hangs up.
  • Context sharing tool: In a heterogeneous system, Context sharing may be required during active/standby switchover. You can use the Context sharing tool to share the active and standby Context.
• Annotated programming, minimalist use: We are looking for a minimalist, user-friendly programming experience. With simple annotation + extremely simple code writing, complex configuration can be distributed.
• The Spring programming environment is required.
• You can host any type of configuration file.
• Provides a good Web management function, it is very convenient to see which instances of configuration are used.

Spring Cloud Config

GitHub:github.com/spring-clou…

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

How Spring Cloud Config works

Application Architecture Diagram:

Workflow:

• Before deploying the environment, you need to push configuration information to the configuration repository.
• After the configuration server is started, the configuration information is pulled and synchronized to the local repository.
• The configuration server provides REST interfaces externally, and all other configuration clients pull corresponding configurations according to the {application}/{profile}/{label} information configured in spring.cloud.config. The configuration repository supports a variety of sources, such as Git, SVN, JDBC databases, and local file systems.
• Other applications start and pull the configuration from the configuration server. (The configuration center also supports dynamic refreshing of configuration information without the need to restart the application. The spring-cloud-config-monitor monitoring module contains /monitor refreshing API, and Webhook calls this endpoint API to achieve dynamic refreshing effect.)

Spring Cloud Config features

• Provide configured server and client support;
• Centrally manage application configurations in a distributed environment.
• Seamlessly integrate with Spring applications based on the Spring environment;
• Can be used to develop programs in any language, for its management and provide configuration information;
• The default implementation is based on git repositories for version management.

Nacos

IO /zh-cn/docs/…

Nacos is dedicated to helping you discover, configure, and manage microservices. Nacos provides an easy-to-use feature set that helps you quickly implement dynamic service discovery, service configuration, service metadata, and traffic management.

Nacos helps you build, deliver, and manage microservices platforms more agile and easily. Nacos is the service infrastructure for building modern “service” centric application architectures (e.g., microservices paradigm, cloud native paradigm).

Main features of Nacos

Service discovery and service health Monitoring:

• Nacos supports DNs-based and RPC-based service discovery. After a Service provider registers a Service using a native SDK, OpenAPI, or a separate Agent TODO, Service consumers can use DNS TODO or HTTP&API to find and discover services.
• Nacos provides real-time health checks on services to prevent requests from being sent to unhealthy hosts or service instances. Nacos supports health checks at the transport layer (PING or TCP) and the application layer (e.g. HTTP, MySQL, user-defined). Nacos provides two health check modes: Agent report mode and server active check mode for complex cloud environments and network topologies, such as VPCS and edge networks. Nacos also provides a unified health check dashboard to help you manage service availability and traffic based on health status.

Dynamically configuring services:

• Dynamically configured services allow you to manage application configuration and service configuration for all environments in a centralized, external, and dynamic manner.
• Dynamic configuration eliminates the need to redeploy applications and services when configuration changes, making configuration management more efficient and agile.
• Centralized configuration management makes it easier to implement stateless services and make it easier for services to scale flexibly on demand.
• Nacos provides an easy-to-use UI (sample console Demo) to help you manage the configuration of all your services and applications. Nacos also provides a number of out-of-the-box configuration management features including configuration version tracking, Canary publishing, one-click rollback configuration, and client configuration update status tracking to help you more securely manage configuration changes and reduce the risks associated with configuration changes in a production environment.

Dynamic DNS service:

• The dynamic DNS service supports weighted routing, enabling you to implement load balancing at the middle layer, flexible routing policies, traffic control, and simple DNS resolution services on the data center Intranet. Dynamic DNS services also make it easier for you to implement DNS protocol-based service discovery to help eliminate the risk of coupling to vendor-proprietary service discovery apis.
• Nacos provides some simple DNS APIs TODO to help you manage your service’s associated domain name and available IP:PORT list.

Here’s a section:

• Nacos is ali open source and supports DNS and RPC-based service discovery.
• Nacos registry support CP also support AP, for it is just a command switch, play with it, also support various registries to migrate to Nacos, anyway, in a word, you want it it has.
• In addition to service registration discovery, Nacos also supports dynamic configuration of services. In a word, Nacos = Spring Cloud registry + Spring Cloud configuration Center.

Configuration center comparison and selection

Since Disconf is no longer maintained, let’s compare Spring Cloud Config, Apollo, and Nacos.

Configuration Center Comparison

• Gray released:
  • Spring Cloud Config supports specifying the machine whose configuration is to be updated via the destination parameter of the /bus/ Refresh endpoint, but the process is not automated or systematic.
  • Apollo can specify the IP of the publishing machine directly from the console with a point of grayscale publishing, followed by full publishing in a more systematic way. Nacos is currently released to version 0.9 and does not support grayscale distribution.
• Rights management:
  • Spring Cloud Config relies on Git’s permission management ability. GitHub’s permission control can be divided into Admin, Write and Read permission, and the permission management is relatively complete.
  • Apollo manages configuration permissions by project dimensions, and an owner of a project can authorize other users to publish configured changes.
  • Nacos does not currently have permission management capabilities.
• Version management & rollback:
  • Spring Cloud Config, Apollo, and Nacos all have configuration versioning and rollback capabilities that allow you to view and roll back configuration changes from the console.
  • Spring Cloud Config is easier to version with Git.
• Configuration format verification:
  • Spring Cloud Config uses Git and currently does not support format verification. The correctness of the format depends on the developer himself.
  • Both Apollo and Nacos verify the correctness of the configuration format to prevent human error.
• Listening to the query:
  • Spring Cloud Config uses Spring Cloud Bus to push configuration changes. Spring Cloud Bus is compatible with RabbitMQ and Kafka, and supports query of subscription relationship between Topic and Consumer.
  • Apollo can view a list of instances of listening configurations through the grayscale instance list, but the configuration of instance listening (which Apollo calls a namespace) is not currently displayed.
  • Nacos can view instances of listening configurations as well as instance listening configurations.
  • Basically, all three products have the ability to listen to queries, and Nacos was relatively simple and easier to use in our own use.
• Many environmental:
  • Spring Cloud Config supports Profile isolation for multiple environments. By configuring multiple Profile profiles on Git, you can specify profiles to access the corresponding profiles when the client starts.
  • Apollo also supports multiple environments, specifying the environment in which the configuration is created on the console, and specifying the JVM parameter ENV at startup to access the configuration file for that environment.
  • Nacos supports multiple environments through namespaces, where the configuration of each namespace is isolated from the other. Clients can achieve logical isolation by specifying the namespace they want to access.
• Multiple clusters:
  • Spring Cloud Config can be physically isolated by setting up multiple Config servers and Git using multiple repositories of the same Git.
  • Apollo can build multiple clusters. Apollo’s console and data update push service are deployed separately, so one console can manage multiple clusters.
  • The Nacos console and back-end configuration services are deployed together and can be switched between different domain names to support multiple clusters.
• Configuring Real-time Push:
  • Both Nacos and Apollo configuration push are based on HTTP long polling. The client establishes an HTTP long connection with the configuration center, which pushes the configuration to the client when the configuration changes.
  • Spring Cloud Config natively does not support real-time push of configuration and relies on Git’s WebHook, Spring Cloud Bus, and client/Bus/Refresh endpoints.
  • Nacos and Apollo are relatively simple and efficient in configuring real-time push links. The configuration push of Spring Cloud Config is introduced into Spring Cloud Bus, which has a long and complicated link.
• Multilingual support:
  • Spring Cloud serves the Java ecosystem. At first, it is only for Java microservice applications. For non-Java microservice calls, Sidecar provides HTTP APIS, but dynamic configuration is not well supported.
  • Apollo already supports multiple languages and provides an Open API. For other unsupported languages, Apollo has relatively low access costs.
  • Nacos supports major languages such as Java, Go, Python, Nodejs, PHP, etc. It also provides an Open API.
• The performance comparison:
  • Nacos has the highest read and write performance, followed by Apollo. Spring Cloud Config’s Git dependency scenario is not suitable for open large-scale automated o&M apis.

Configuration center selection

In summary:

• Apollo and Nacos have a broader ecosystem than Spring Cloud Config and do a better job of configuration management processes.
• Apollo is more comprehensive in configuration management than Nacos, but it’s also a bit more cumbersome to use.
• Apollo is difficult to contain. Nacos has an official website image that can be deployed directly, and overall, Nacos is more KISS compliant than Apollo.
• Nacos is relatively simple to use and is better suited for large-scale scenarios with high performance requirements.

In addition, Nacos not only provides the function of configuration center, but also provides the function of dynamic service discovery, service sharing and management, which reduces the difficulty in the process of service transformation.

However, for the selection of an open source project, in addition to the above aspects, human input on the project (iteration progress, document integrity), community activity (number of issues and solution speed, Contributor number, community communication frequency, etc.), community standard degree (disclaimer, security instructions, etc.), That’s probably what users are paying more attention to.

For more information on selection, please refer to the article “How to choose Nacos, Apollo and Config configuration center? These 10 dimensions tell you!” Many knowledge points in this article also come from this article.

It is better to have no books than to have no books. Because of my limited ability, it is hard to avoid omissions and mistakes. If you find bugs or have better suggestions, you are welcome to criticize and correct.