Nacos provides us with a very useful configuration center function and comes with a console, but every time the configuration is updated, the value of the entire configuration item needs to be modified, which is very inconvenient.
How to use the Nacos configuration center more conveniently, elegantly and safely is very important. In this article, I will introduce a way to use the configuration center through plug-in adaptation, which is as simple as operating KV key-value pairs.
Problems with existing pages
Let's take a look at the possible problems with the existing configuration management page of Nacos. For example, I have a configuration item as shown in the following figure:
If users are allowed to manage these configurations directly in nacos, users will be very troubled for the following reasons:
1. For non-technical personnel, system-related configuration items such as jdbc.url, they do not need to care, nor should they manage these configuration items, it will be very dangerous to directly expose them to them
2. Some configuration items cannot be judged from the name of the key only, because they do not explain themselves so well. For example, the time.diff in the above configuration is very confusing.
3. Configuration modification should be minimized. If all configuration items are exposed, users may accidentally delete one of the configuration items during modification, which will have catastrophic consequences
4. Depending on the division of permissions, configuration items should be isolated from data permissions. Different people should only see the configuration items that they can modify, not all configuration items.
a friendlier page
Suppose we have a more friendly operation page as shown below, then operation will be easier:
By dividing the content of an entire configuration item into smaller configuration items, and adding a description to each configuration item, is it better to operate on such a page than to operate directly on the Nacos console? What about convenience, friendliness and safety?
Design ideas
In order to achieve such a function, we can build an adaptation layer on the basis of the original configuration center, and provide external query and modification services for configuration items in the form of plug-ins.
The main architecture is shown in the following figure:
The whole process is divided into three parts:
1. Nacos client long polling server configuration information
2. The adaptation layer obtains the complete configuration information from the Nacos client and splits it into smaller configuration items
3. Update a certain configuration item from the adaptation layer, and then reassemble all the small configuration items into a complete configuration item to update the content to the server through the Nacos client
The Config Unit in the figure above is the smallest configuration unit we need to care about. Through this configuration unit, we can specify attributes such as "description" for each configuration item.
What properties does a hive need to have
We can freely design the properties in the hive, and according to the business scenario we can design the following properties for the hive:
- desc: This attribute is mainly used to describe the configuration item
- type: identifies the value type of the configuration item, which can be defined by an enumeration
- readOnly: Identifies whether the configuration item is read-only, if it is read-only, modification is not allowed
- grade: Specifies the danger level of the configuration item, mainly for data permission isolation
Through these attributes, the complete configuration items in Nacos can be split into small configuration units, and the configuration unit can be understood as the metadata of the configuration item. These metadata can be saved in the database or in the configuration file or even in Nacos. , as long as each configuration item can correspond to a configuration unit.
What capabilities does the plugin need
In fact, the adaptation layer only needs to provide the function of querying and updating configuration items. The query is divided into a query list and a single configuration item. The specific interface definition is shown in the following figure:
View several effects
Let's take a look at the effect below. The specific implementation process is not described in detail here. The complete implementation code is at the end of the article.
get configuration list
Query all configuration items with grade less than or equal to 5:
Query all configuration items whose grade is less than or equal to 2:
On the one hand, the grade here can be used to isolate data permissions, and it can also be used as a basis for the front end to display the "dangerous" level. The higher the grade value, the more dangerous the configuration item is, and special attention should be paid when modifying it.
Query a single configuration item
Query a single configuration item by key:
When we need to get the value of a configuration item in our system, we can call this interface.
Update configuration items
Update a non-existing configuration item:
Update a configuration item, but the permission is not enough, the submitted grade is lower than the grade of the configuration item:
Update a configuration item, but the configuration item is read-only:
A configuration item was updated, but an incorrect value type was specified:
Correctly update a configuration item:
View values in Nacos
After updating the configuration information through the adaptation layer, let's check whether the configuration items in Nacos have changed, as shown in the following figure:
It can be found that the value of this configuration item in the Nacos server has been updated.
Use in real environment
To use this plugin in a practical environment, the following issues need to be addressed:
1. Hive
First, we need to correspond to a configuration unit for each configuration item in Nacos, specify various attributes for them, and then persist the configuration unit to the database or configuration file, so that the plug-in can obtain the list of configuration units.
2. Permission isolation
All hives need to be classified, i.e. maintain grades for them, and segregate data permissions in your system according to the permission model, for example:
Ordinary user roles can view and modify configuration items with grade <= 2;
The administrator role can view and modify configuration items with grade<= 5;
The super administrator role can view and modify all configuration items.
However, if it is transmitted in plain text through grade, it is likely to forge the request after the message is captured by others, so it is best to integrate the data permission with the permission module of the system.
full code
At present, I have implemented the function of this plug-in. If you need the complete code, you can reply to the "Configuration Center Plug-in" in the official account to get it. If you don't need it, just ignore this paragraph.
Houyi is code-by-code, focusing on original sharing, describing the source code and principles with easy-to-understand pictures and texts
