Article Directory
background
In the monolithic architecture, we can write the configuration in the configuration file, but there is a disadvantage that every time the configuration is modified, the service needs to be restarted to take effect.
It can also be maintained when the application instance is relatively small. If there are hundreds or thousands of instances in the microservice architecture, all instances must be restarted every time the configuration is modified, which not only increases the instability of the system, but also increases the cost of maintenance.
So how can you modify the configuration without restarting the service? All this produces four basic demands:
Need to support dynamic configuration modification
How real-time the dynamic changes need to be
How to control and control the risk of change after the change is faster, such as grayscale, rollback, etc.
How to configure security for sensitive configurations
concept introduction
Configuration
During the system development process, some parameters and variables that need to be changed are usually separated from the code and managed independently, and exist in the form of independent configuration files. The purpose is to make static system artifacts or deliverables (such as WAR, JAR packages, etc.) better adapt to the actual physical operating environment.
Configuration management is generally included in the process of system deployment, and this step is completed by system administrators or operation and maintenance personnel. Configuration changes are one of the effective means to adjust the behavior of the system at runtime.
Configuration Management
In Nacos, all configuration-related activities such as storage, editing, deletion, grayscale management, historical version management, and change auditing of all configurations in the system are collectively referred to as configuration management.
Configuration Service
A service provider that provides dynamic configuration or metadata and configuration management during service or application running.
Configuration Items
A specific configurable parameter and its value range usually exist in the form of param-key = param-value.
For example, we often configure the log output level of the system (logLevel = INFO | WARN | ERROR) is a configuration item.
Configuration Set
A collection of related or unrelated configuration items is called a configuration set.
In the system, a configuration file is usually a configuration set, which includes the configuration of all aspects of the system. For example, a configuration set may include configuration items such as data source, thread pool, and log level.
Namespace
Used for tenant granular configuration isolation. The configuration of the same Group or Data ID can exist under different namespaces.
One of the common scenarios of Namespace is to distinguish and isolate the configuration of different environments, such as the isolation of resources (such as database configuration, current limit threshold, and downgrade switch) between the development and test environment and the production environment.
If no Namespace is specified, the public namespace is used by default
Configuration group (Group)
A set of configuration sets in Nacos is one of the configuration dimensions. Group configuration sets by a meaningful character string (such as experimental group and control group in ABTest), so as to distinguish configuration sets with the same Data ID.
When you create a configuration on Nacos, if you do not fill in the name of the configuration group, the name of the configuration group defaults to DEFAULT_GROUP.
Common scenarios for configuration grouping: Different applications or components use the same configuration items, such as database_url configuration and MQ_Topic configuration.
Configuration ID (Data ID)
The ID of a configuration set in Nacos. The configuration set ID is one of the dimensions for dividing configurations. Data IDs are often used to demarcate a system's configuration set.
A system or application can contain multiple configuration sets, and each configuration set can be identified by a meaningful name. The Data ID is guaranteed to be globally unique as much as possible. You can refer to the naming rules in Nacos Spring Cloud:
${
prefix}-${
spring.profiles.active}-${
file-extension}
Configuration Snapshot
The client SDK of Nacos will generate a snapshot of the configuration locally. When the client cannot connect to Nacos Server, the configuration snapshot can be used to display the overall disaster recovery capability of the system.
Configuration snapshots are similar to local commits in Git, and also similar to caches, which will be updated at appropriate times, but there is no concept of cache expiration.
Nacos configuration model
base model
- Nacos provides a visual console, which can publish, update, delete, grayscale, version management and other functions for the configuration.
- The SDK can provide functions such as publishing configuration, updating configuration, and monitoring configuration.
- The SDK monitors the configuration changes through the GRPC long connection, and the server side compares whether the MD5 configured on the client side is equal to the local MD5, and pushes configuration changes if they are not equal.
- The SDK will save a snapshot of the configuration, and get it locally when there is a problem with the server.
Configure the resource model
Namespace is designed for resource isolation. We can look at it from the following two perspectives when configuring resources:
- From the perspective of a single tenant, we need to configure multiple sets of environment configurations, and we can create Namespaces according to different environments. For example, in the development environment, test environment, and online environment, we create the corresponding Namespace (dev, test, prod), and Nacos will automatically generate the corresponding Namespace Id. If you want to configure the same configuration in the same environment, you can use Group to distinguish them. As shown below:
- From the perspective of multiple tenants, each tenant can have its own namespace. We can create a namespace for each user and assign corresponding permissions to the user, such as multiple tenants (zhangsan, lisi, wangwu), each tenant wants to have its own set of multi-environment configuration, that is, each Tenants want to configure multiple environments. Then you can create a Namespace (zhangsan, lisi, wangwu) for each tenant. The corresponding Namespace Id will also be generated. Then use Group to distinguish configurations for different environments. As shown below
Configuration Storage Model (ER Diagram)
Nacos storage configuration has several important tables:
config_info The main table for storing configuration information, which contains dataId, groupId, content, tenantId, encryptedDataKey and other data.
config_info_beta is the configuration information table of the gray scale test, and the stored content is basically similar to that of config_info. There is a beta _ips field for judging whether it is a grayscale ip when the client requests configuration.
config_tags_relation The tag table configured, if a tag is specified when publishing the configuration, then the associated information between the tag and the configuration will be stored in this table.
The his_config_info configuration history information table will record a piece of data when the configuration is released, updated, deleted, etc., which can be used for multi-version management and quick rollback.
