A configuration management system for microservice architecture
By deploying configuration clients and system call interceptors in the operating system kernel space, combined with a dynamic binding rule base and an immutable audit chain, the problems of configuration activation delay and compliance in microservice architecture are solved, achieving zero-latency configuration activation and high-reliability auditing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUANGDONG GUOSHI TECHNOLOGY CO LTD
- Filing Date
- 2026-04-02
- Publication Date
- 2026-06-30
AI Technical Summary
Existing configuration management systems in microservice architectures suffer from problems such as delayed configuration activation, difficulty in accurately assessing the scope of impact of configuration changes, easy tampering or loss of configuration change operation records, and inability to meet the auditing requirements of high compliance scenarios.
It employs components such as a configuration storage center, a policy engine server, a configuration client, and a system call interceptor. By deploying the configuration client in the operating system kernel space, the system call interceptor enables configurations to take effect in real time with zero restart. Combined with a dynamic binding rule base and an immutable audit chain module, it achieves fine-grained configuration management and immutable auditing.
It achieves zero-latency activation of configuration changes, fine-grained dynamic binding, and end-to-end immutable auditing, meeting the high reliability and high compliance requirements of microservice architecture, reducing service jitter, and improving the security and audit credibility of configuration management.
Smart Images
Figure CN122309197A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of packaging equipment technology, and more specifically, to a configuration management system oriented towards a microservices architecture. Background Technology
[0002] With the widespread adoption of microservice architecture, configuration management has become a core component for ensuring system elasticity, stability, and operational efficiency. Microservice architecture typically includes hundreds or thousands of independently deployed service instances, each of which needs to dynamically obtain configuration information such as database connection parameters, business switches, and rate limiting thresholds. The core issues of configuration management systems are: how to enable rapid implementation of configuration changes, how to ensure the security of configuration changes, and how to quickly recover from configuration anomalies. In existing technologies, mainstream configuration management solutions include Spring Cloud Config, Apollo, and Nacos. These systems typically use client-side pull or server-side push models for configuration distribution. However, the aforementioned existing technologies have the following drawbacks: Configuration changes are delayed. In the traditional pull mode, the client periodically retrieves configurations from the configuration center, and the changes take effect based on the heartbeat cycle. In the push mode, although the client can be notified in real time, the client still needs to trigger an application context refresh, which may cause thread blocking and some request failures, making it impossible to achieve true zero-latency hot reloading. At the same time, in complex microservice scenarios with multiple tenants, multiple environments, and multiple versions, the impact of configuration changes is difficult to assess accurately. Existing systems typically only support coarse-grained binding based on application names, and cannot achieve fine-grained configuration distribution based on dynamic conditions such as instance tags, regions, and canary versions. In addition, the operation records of configuration changes are mostly traditional logs, which are easily tampered with or lost, making it difficult to meet the auditing requirements of high compliance scenarios such as finance and government. In summary, existing technologies require a configuration management system that can achieve zero-delay activation of configuration changes, fine-grained dynamic binding, end-to-end immutable auditing, and intelligent automatic rollback. Summary of the Invention
[0003] In view of the shortcomings of the existing technology, the purpose of this invention is to provide a configuration management system for microservice architecture to solve the problems existing in the background technology.
[0004] The above-mentioned technical objective of this invention is achieved through the following technical solution: a configuration management system for microservice architecture, comprising: Configure the storage center to store configuration data and maintain multi-version information and environment isolation information of the configuration data; The strategy engine server is connected to the configuration storage center and is used to receive configuration change requests, parse the service tag rules in the configuration change requests, calculate the set of affected microservice instances based on the dynamic binding rule base, and generate a set of configuration change instructions containing configuration data and target instance identifiers. The configuration client is deployed in the operating system kernel state of the computing node where the microservice instance is located. It communicates with the policy engine server to receive the configuration change instruction set, write the configuration data in binary compact format to the shared memory mapping table associated with the microservice instance, and update the metadata version number. A system call interceptor, integrated into the configuration client, is used to intercept and return the configuration data to the process when the process of the microservice instance initiates a configuration read system call, by matching the corresponding configuration data in the shared memory mapping table according to the process identifier of the process, thereby achieving real-time configuration with zero restart.
[0005] Optionally, the strategy engine server includes: a dynamically bound rule base for storing user-defined strategy expressions, wherein the strategy expressions include one or more matching conditions among service name, namespace, instance tag, regional information, and grayscale version; The service topology acquisition module is used to obtain metadata information of microservice instances from the service registry in real time and parse the strategy expression into a specific list of instances; A configuration instruction generator is used to bind configuration data with the instance list and generate the configuration change instruction set.
[0006] Optionally, the configuration client includes: A shared memory manager is used to allocate shared memory regions in the kernel mode of the compute node, establish a mapping relationship between the shared memory regions and microservice instance processes, and provide at least one configuration snapshot version for each microservice instance; The kernel-mode communication proxy is used to communicate bidirectionally with the policy engine server through a high-speed channel, receive configuration change instructions, and return confirmation status.
[0007] Optionally, the system call interceptor is implemented based on extended Berkeley packet filtering technology, including: eBPF hooks are attached to the configuration reading system call entry point of the microservice instance process; The eBPF mapping table, associated with the shared memory mapping table, is used to quickly look up the configuration data corresponding to the process in kernel mode. The eBPF hook program is configured to be triggered when the process initiates a system call, read the latest configuration data in the eBPF mapping table, overwrite the return result of the system call, and then return it to the user-space process.
[0008] Optionally, it also includes: an immutable audit chain module, which is connected to the strategy engine server and the configuration client, and is used to record the metadata of each configuration change event in an append-only manner to the distributed immutable storage; The metadata includes the configuration hash value before the change, the configuration hash value after the change, the operator's identity identifier, the operation timestamp, the list of affected instances determined by the policy engine server, the configuration change instruction set fingerprint, and the effective confirmation information from the configuration client.
[0009] Optionally, the immutable audit chain module is implemented based on blockchain technology or distributed ledger technology. The metadata is written into the blockchain node as transaction content, thereby forming an immutable audit trail and providing an audit query interface based on time range and instance identifier.
[0010] Optional, also includes: An intelligent rollback controller, connected to the policy engine server, the configuration client, and the monitoring system respectively, includes: The metrics collection unit is used to acquire real-time key metrics data of microservice instances before and after configuration changes. These key metrics include query rate per second, error rate, and average response latency. The anomaly detection engine is used to start a sliding time window after a configuration change event occurs, compare the current metrics with the historical baseline, and determine the configuration change anomaly when the error rate exceeds a preset threshold or the response delay exceeds a preset multiple. The rollback execution unit is used to automatically send a rollback instruction to the policy engine server or directly to the configuration client when the anomaly detection engine determines an anomaly. The rollback instruction contains the configuration data of the previous version or the version number of the previous version, so as to revert the configuration data in the shared memory mapping table to the state before the change.
[0011] Optionally, the configuration storage center includes: A multi-version repository is used to store each historical version of configuration data, supporting version comparison and version backtracking; The environment isolation module is used to physically or logically isolate configuration data according to development environment, testing environment, pre-release environment, and production environment. The service tag mapping table is used to store the association between configuration data and service tag rules, which can be dynamically queried by the policy engine server when the configuration changes.
[0012] Optionally, the configuration storage center includes: A multi-version repository is used to store each historical version of configuration data, supporting version comparison and version backtracking; The environment isolation module is used to physically or logically isolate configuration data according to development environment, testing environment, pre-release environment, and production environment. The service tag mapping table is used to store the association between configuration data and service tag rules, which can be dynamically queried by the policy engine server when the configuration changes.
[0013] A configuration management method for a microservice architecture-oriented configuration management system, based on the above, includes the following steps: Step S1: Configure the storage center to receive and store configuration data, and maintain the environment isolation and multi-version information of the configuration data; Step S2: The strategy engine server receives the configuration change request, parses the service tag rules carried in the configuration change request, and calculates the set of affected microservice instances based on the dynamic binding rule base; Step S3: The strategy engine server generates a configuration change instruction set, binds the configuration data with the microservice instance set, and sends it to the configuration client deployed in the kernel state of the operating system of the computing node where the microservice instance is located; Step S4: The configuration client writes the configuration data to the shared memory mapping table and updates the metadata version number; Step S5: The system call interceptor intercepts the configuration read system call initiated by the process of the microservice instance, matches it with the shared memory mapping table based on the process identifier, and returns the latest configuration data to the process; Step S6: The immutable audit chain module writes the metadata of the configuration change event into the distributed immutable storage to form an audit record; Step S7: The intelligent rollback controller collects runtime metrics of the microservice instance in real time. When it detects that the metrics exceed a preset abnormal threshold within a preset time window after the configuration change, it automatically triggers a rollback operation and instructs the configuration client to restore the previous version configuration data in the shared memory mapping table.
[0014] In summary, the present invention has the following beneficial effects: 1. By deploying the configuration client in the operating system kernel space, and using system call interceptors to intercept and inject configurations in real time when the microservice process reads the configuration, configuration hot reloading can be achieved without restarting the service instance, triggering application context refresh, or modifying application code after configuration changes. Compared with existing technologies that rely on heartbeat retrieval or the / refresh interface, this reduces the delay in configuration taking effect and eliminates service jitter caused by configuration changes.
[0015] 2. By introducing a dynamic binding rule base through the strategy engine server, it supports strategy expressions based on multiple dimensions such as service name, namespace, instance tag, region information, and canary release. The strategy engine can accurately calculate the set of affected microservice instances based on the real-time topology of the service registry, enabling fine-grained configuration distribution. Compared with existing technologies that only support application-level coarse-grained binding, it supports flexible configuration management in complex scenarios such as canary release, A / B testing, and multi-region deployment.
[0016] 3. By introducing an immutable audit chain module, metadata such as the operator, timestamp, hash values before and after the change, list of affected instances, and confirmation information for each configuration change are recorded in distributed immutable storage (preferably blockchain or distributed ledger). This audit record is tamper-proof, traceable, and verifiable, meeting the stringent requirements for operational auditing in highly compliant scenarios such as finance and government. Compared to existing auditing methods based on traditional logs, this improves the credibility of audit data. Attached Figure Description
[0017] Figure 1 This is a schematic diagram of the system flow logic of the present invention; Figure 2 This is a schematic diagram of the method steps of the present invention. Detailed Implementation
[0018] To make the objectives, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Several embodiments of the present invention are shown in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein.
[0019] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances. The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature.
[0020] In this invention, unless otherwise expressly specified and limited, "above" or "below" a second feature can include direct contact between the first and second features, or contact between the first and second features through another feature between them. Furthermore, "above," "over," and "on top" of a second feature includes the first feature being directly above or diagonally above the second feature, or simply indicates that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" of a second feature includes the first feature being directly below or diagonally below the second feature, or simply indicates that the first feature is at a lower horizontal level than the second feature. The terms "vertical," "horizontal," "left," "right," "above," "below," and similar expressions are for illustrative purposes only and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed or operated in a specific orientation, and therefore should not be construed as limiting the invention.
[0021] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0022] This invention provides a configuration management system for microservice architectures, such as... Figure 1 As shown, it includes a configuration storage center, a policy engine server, a configuration client, a system call interceptor, an immutable audit chain module, and a smart rollback controller.
[0023] The configuration storage center is used to store configuration data and maintain multi-version information and environment isolation information of the configuration data. In this embodiment, the configuration storage center uses a distributed database as the underlying storage and supports horizontal scaling. The configuration data is stored in key-value pairs, and each configuration item is associated with metadata such as version number, environment identifier, creation time, and modification time. The configuration storage center further includes a multi-version repository, an environment isolation module, and a service tag mapping table. The multi-version repository stores each historical version of the configuration data and supports version comparison and version backtracking functions. The environment isolation module physically or logically isolates the configuration data according to the development environment, testing environment, pre-release environment, and production environment. The service tag mapping table stores the association between the configuration data and the service tag rules, which can be dynamically queried by the policy engine server when the configuration changes.
[0024] The strategy engine server connects to the configuration storage center to receive configuration change requests, parse the service tag rules in the configuration change requests, calculate the set of affected microservice instances based on the dynamic binding rule base, and generate a set of configuration change instructions containing configuration data and target instance identifiers. The strategy engine server adopts an event-driven architecture. When a configuration change request arrives, it triggers the binding calculation process. The strategy engine server further includes a dynamic binding rule base, a service topology acquisition module, and a configuration instruction generator. The dynamic binding rule base stores user-defined strategy expressions, which include one or more matching conditions such as service name, namespace, instance tag, region information, and grayscale version. The service topology acquisition module obtains the metadata information of microservice instances from the service registry in real time and parses the strategy expressions into a specific instance list. The configuration instruction generator binds the configuration data with the instance list to generate a configuration change instruction set.
[0025] The configuration client is deployed in the operating system kernel space of the compute node where the microservice instance is located. It communicates with the policy engine server to receive configuration change instruction sets, write configuration data in binary compact format to the shared memory mapping table associated with the microservice instance, and update the metadata version number. The configuration client is loaded into the operating system as a kernel module. Only one configuration client instance needs to be deployed on each compute node to serve all microservice containers or processes on that node. The configuration client further includes a shared memory manager and a kernel-mode communication agent. The shared memory manager allocates a shared memory region in the kernel mode of the compute node, establishes a mapping relationship between the shared memory region and the microservice instance process, and provides at least one configuration snapshot version for each microservice instance. The kernel-mode communication agent communicates bidirectionally with the policy engine server through a high-speed channel, receives configuration change commands, and returns confirmation status.
[0026] The system call interceptor is integrated into the configuration client. When a process of a microservice instance initiates a configuration read system call, it matches the corresponding configuration data in the shared memory mapping table based on the process identifier of the process, intercepts the call, and returns the configuration data to the process, thereby achieving real-time configuration with zero restart.
[0027] The immutable audit chain module connects to the policy engine server and configuration client to record the metadata of each configuration change event in an append-only manner to the distributed immutable storage. The metadata includes the configuration hash value before the change, the configuration hash value after the change, the operator's identity, the operation timestamp, the list of affected instances determined by the policy engine server, the configuration change instruction set fingerprint, and the effective confirmation information from the configuration client.
[0028] The intelligent rollback controller connects to the policy engine server, configuration client, and monitoring system, and includes a metric collection unit, an anomaly detection engine, and a rollback execution unit. The metric collection unit acquires real-time key performance indicators (KPIs) of the microservice instance before and after configuration changes. These KPIs include queries per second (QPS), error rate, and average response latency. The anomaly detection engine starts a sliding time window after a configuration change event occurs, comparing the current metrics with historical baselines. When the error rate exceeds a preset threshold or the response latency exceeds a preset multiple, it is determined that the configuration change is abnormal. When the anomaly detection engine determines an anomaly, the rollback execution unit automatically sends a rollback command to the policy engine server or directly to the configuration client. The rollback command includes the configuration data of the previous version or the version number of the previous version, so that the configuration data in the shared memory mapping table is rolled back to the state before the change.
[0029] In the specific second embodiment, this embodiment details the implementation of configuring the client and the system call interceptor; The configuration client is deployed as a kernel module and loaded when the operating system starts. The shared memory manager creates a contiguous memory region in the system kernel as a shared memory pool. When a new microservice instance starts on a compute node, the shared memory manager allocates an independent shared memory region for it based on the instance's process identifier (PID) and establishes a mapping relationship between the PID and the shared memory address. Each microservice instance's corresponding shared memory region stores a configuration snapshot, which contains the complete configuration data and the corresponding version number.
[0030] The shared memory manager uses reference counting to manage the allocation and release of shared memory. When a microservice instance terminates, the shared memory manager detects the process exit event and automatically releases the corresponding shared memory region to prevent memory leaks.
[0031] A long-lived connection channel based on Unix Domain Socket or TCP is established between the kernel-mode communication agent and the policy engine server. When the policy engine server issues a configuration change instruction set, the kernel-mode communication agent receives the instruction, parses it, and calls the interface provided by the shared memory manager to write the configuration data into the shared memory area corresponding to the target microservice instance in binary compact format, and updates the version number field of that area. After the writing is completed, the kernel-mode communication agent returns a confirmation status to the policy engine server, including whether the writing was successful, the target instance PID, the new version number, and other information.
[0032] The system call interceptor is implemented based on eBPF technology. More specifically, it attaches an eBPF hook program at the configuration reading system call entry point of the microservice instance process. The configuration reading system calls include, but are not limited to, getenv (read environment variables), open (open configuration file), and read (read file content). The eBPF hook program is attached to the kernel function entry point using eBPF's kprobe or tracepoint mechanism.
[0033] The eBPF mapping table is associated with the shared memory mapping table 303. Its key is the process's PID, and its value is a pointer to a shared memory region. When the eBPF hook program 401 is triggered, it executes the following logic: obtains the PID of the current process; searches for the shared memory region pointer corresponding to the PID in the eBPF mapping table 402; if the corresponding entry is found, reads the configuration data from the shared memory region; modifies the return value of the system call, overwriting the original return value with the read configuration data; and returns control to the user-mode process.
[0034] Since the entire process is completed in kernel mode and does not involve changes in the state of user-mode processes, the microservice process is completely unaware that the configuration data has been dynamically replaced, achieving zero-intrusion and zero-restart configuration hot reloading.
[0035] Furthermore, the system call interceptor also supports a configuration whitelist mechanism, which can intercept only configuration read requests for specified paths or names, thus avoiding performance impact on all system calls.
[0036] In specific implementation three, this embodiment illustrates the specific implementation method of the immutable audit chain module. The immutable audit chain module is preferably implemented using blockchain technology, constructing a consortium blockchain network, which is jointly maintained by multiple audit nodes, and each configuration change event corresponds to a transaction; Once the strategy engine server completes the generation of the configuration change instruction set, it immediately encapsulates the aforementioned metadata into a transaction and broadcasts it to the blockchain network. After the blockchain nodes verify the transaction through consensus, they package it into a new block. Each block contains the hash value of the previous block, forming a chain structure. Any modification to historical transactions will destroy the integrity of the hash chain, thereby achieving immutability. The audit query interface supports two query modes: based on time range (e.g., querying change events within the last 24 hours) and instance identifier (e.g., querying all relevant changes for a specific microservice instance). The query results return complete transaction information, and auditors can verify the authenticity of the configuration data by recalculating the configuration hash value and comparing it with the hash value recorded on the chain. As an alternative, the immutable audit chain module can also be implemented using distributed ledger technology (such as the linear read feature of etcd combined with timed snapshots), but the blockchain solution has superior characteristics in terms of tamper resistance and decentralization.
[0037] In specific implementation four, this embodiment details the workflow of the intelligent rollback controller. The intelligent rollback controller 600 is deployed as an independent microservice and interfaces with the monitoring system through a service mesh or API gateway. The metric collection unit 601 adopts a streaming processing framework to consume the metric data stream pushed by the monitoring system in real time. For each microservice instance, the metric collection unit 601 maintains a time-series buffer to store key metric data such as QPS, error rate, and average response latency over a recent period.
[0038] The anomaly detection engine maintains a configuration change event log table, recording the event ID, timestamp, and list of affected instances for each configuration change. When a configuration change event occurs, the anomaly detection engine creates a detection task for that event and starts a sliding time window (default configuration is 2 to 5 minutes after the change). The detection task executes the following logic: Obtain baseline data of the affected instances from the indicator collection unit within the first preset time period (default 10 minutes) before the change; Obtain real-time indicator data of the affected instances within the second preset time period (default 5 minutes) after the change from the indicator collection unit; Calculate the magnitude of change of the modified indicator relative to the baseline; If the error rate increases by more than the first preset threshold (e.g., 5 percentage points) and the response latency increases by more than the second preset threshold (e.g., more than 100% of the baseline), it is determined to be an abnormal configuration change. If only a single instance experiences an anomaly, the gray-scale rollback unit is activated to perform a rollback only on that instance, creating an A / B comparison to verify whether the anomaly was indeed caused by the configuration change. After receiving the exception determination result, the rollback execution unit performs a rollback operation. The rollback command can be issued in two ways: first, by sending a rollback request to the policy engine server, which then regenerates and issues the configuration change command set of the previous version; second, by directly issuing the rollback command to the configuration client, carrying the previous version number or the complete configuration data of the previous version. The second method is preferred to reduce rollback latency. After receiving the rollback command, the configuration client atomically replaces the configuration data in the target shared memory area with the previous version's configuration data through the shared memory manager. The atomic replacement is achieved through memory locks or RCU mechanisms to ensure that no part of the data is read as a mixture of old and new data during the replacement process. After the rollback is completed, the rollback execution unit submits the rollback event as a new configuration change event to the immutable audit chain module, forming a complete change rollback audit record.
[0039] In specific implementation four, this embodiment provides a configuration management method for microservice architecture, including the following steps: Step S1: Configure data storage and initialization. Configure the storage center to receive configuration data and store it in isolation according to the environment identifier. When storing each configuration item, a version number is automatically generated, and the initial version is recorded in the multi-version repository. When the service tag mapping table is initialized, the association relationship between the configuration data and the service tag rules is loaded. Step S2: Configuration change request processing. The strategy engine server receives the configuration change request, which carries the changed configuration key-value pairs, the target service tag rule, and the operator's identity information. The strategy engine server parses the service tag rule, calls the dynamic binding rule library to verify the correctness of the rule syntax, and then calls the service topology collection module to obtain a list of all service instances that match the rule from the service registry center. Step S3: Configuration change instruction generation and distribution. The policy engine server binds the configuration data with the instance list to generate a configuration change instruction set. The configuration change instruction set is encapsulated in a binary serialization format or similar, containing configuration key-value pairs, a list of target instance PIDs, version numbers, timestamps, and other information. The configuration change instruction set is distributed to the configuration clients of the compute nodes where each target instance resides via a high-speed channel. Step S4: Kernel-mode configuration injection. The kernel-mode communication agent of the configuration client receives the instruction, parses it, calls the shared memory manager, writes the configuration data into the shared memory region corresponding to each target instance, and updates the version number of the region. After writing is completed, the kernel-mode communication agent returns confirmation information to the policy engine server. Step S5: The configuration takes effect in real time. When the microservice instance process executes the configuration read system call, the eBPF hook program of the system call interceptor is triggered. The eBPF hook program obtains the current process PID, looks up the corresponding shared memory region in the eBPF mapping table, reads the latest configuration data, modifies the system call return value, and returns the configuration data to the user-space process. The microservice process obtains the latest configuration without any restart or refresh operation. Step S6: Write the audit record. The immutable audit chain module encapsulates the metadata of this configuration change, including the hash values before and after the change, the operator, the timestamp, the list of affected instances, the instruction set fingerprint, and the effective confirmation information, into a transaction and submits it to the blockchain network to form an immutable audit record. Step S7: Intelligent Monitoring and Automatic Rollback. The intelligent rollback controller collects key performance indicators (KPIs) of affected instances in real time. If the error rate or response latency exceeds a preset threshold within a preset time window after a configuration change, it is automatically determined to be an abnormal configuration change and triggers a rollback operation. The rollback command is sent to the configuration client, restoring the configuration data in shared memory to the previous version, and the rollback event is written to the audit chain.
[0040] In the specific implementation process, the configuration management system provided by this invention is used for microservice operation and maintenance. The operation and maintenance team plans to adjust the database connection pool timeout of the order service from 5 seconds to 1 second to improve the system throughput. Due to the high risk of this change, the operation and maintenance personnel only want to conduct gray-scale verification on the order service instance first. The operations and maintenance personnel enter the configuration change in the console of the policy engine server: the configuration key db.timeout is changed from 5 seconds to 1 second, and the service label rule is ServiceName=OrderService AND Region=HZ; the policy engine server automatically obtains the list of order service instances (a total of 10 instances) from the registry center, generates the configuration change instruction set and sends it to the host machine where these instances are located; The configuration client on the host machine receives the instruction and writes the configuration data to the shared memory area corresponding to each order service instance process. When the order service process processes subsequent requests, it reads the database connection parameters through a system call, which is intercepted by the eBPF hook program, returning a new timeout value of 1 second. The entire configuration taking effect process takes less than 1 millisecond and does not require restarting any instances.
[0041] After the configuration change was completed, the intelligent rollback controller began monitoring the key performance indicators (KPIs) of these 10 instances. Approximately 30 seconds later, the anomaly detection engine 602 detected that the error rate of two of the instances had increased from 0.1% to 8%, and the response latency had increased from 50ms to 200ms, indicating an anomaly in the configuration change. The rollback execution unit 603 automatically issued rollback commands to these two anomaly instances, restoring their configuration to 5 seconds. After the rollback, the KPIs of these two instances returned to normal, and the remaining eight instances continued to run with the new configuration.
[0042] The entire configuration change and automatic rollback process is completed within 1 minute. Operations personnel only need to focus on the gray-scale verification results and do not need to manually handle the fault. At the same time, the immutable audit chain module records the complete information of this change, including the operator, hash values before and after the change, a list of affected instances, and a detailed record of the rollback event, which can be used for subsequent compliance audits.
[0043] This invention provides a configuration management system for microservice architectures. By deploying the configuration client in the operating system kernel space, it utilizes a system call interceptor to intercept and inject configurations in real time when microservice processes read configurations. Configuration changes can be hot-loaded without restarting service instances, triggering application context refreshes, or modifying application code. Compared to existing solutions relying on heartbeat retrieval or the / refresh interface, this reduces configuration activation latency and eliminates service jitter caused by configuration changes. The policy engine server introduces a dynamically bound rule base, supporting policy expressions based on multiple dimensions such as service name, namespace, instance tag, region information, and grayscale versions. The engine can accurately calculate the set of affected microservice instances based on the real-time topology of the service registry, enabling fine-grained configuration distribution. Compared to existing technologies that only support application-level coarse-grained binding, it supports flexible configuration management in complex scenarios such as canary releases, A / B testing, and multi-region deployments. By introducing an immutable audit chain module, metadata such as the operator of each configuration change, timestamp, hash values before and after the change, list of affected instances, and confirmation information are recorded in distributed immutable storage (preferably blockchain or distributed ledger). This audit record has the characteristics of being tamper-proof, traceable, and verifiable, which can meet the strict requirements of operation auditing in high-compliance scenarios such as finance and government. Compared to existing auditing methods based on traditional logs, it improves the credibility of audit data.
[0044] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.
Claims
1. A configuration management system for microservice architecture, characterized in that, include: Configure the storage center to store configuration data and maintain multi-version information and environment isolation information of the configuration data; The strategy engine server is connected to the configuration storage center and is used to receive configuration change requests, parse the service tag rules in the configuration change requests, calculate the set of affected microservice instances based on the dynamic binding rule base, and generate a set of configuration change instructions containing configuration data and target instance identifiers. The configuration client is deployed in the operating system kernel state of the computing node where the microservice instance is located. It communicates with the policy engine server to receive the configuration change instruction set, write the configuration data in binary compact format to the shared memory mapping table associated with the microservice instance, and update the metadata version number. A system call interceptor, integrated into the configuration client, is used to intercept and return the configuration data to the process when the process of the microservice instance initiates a configuration read system call, by matching the corresponding configuration data in the shared memory mapping table according to the process identifier of the process, thereby achieving real-time configuration with zero restart.
2. The configuration management system for microservice architecture according to claim 1, characterized in that, The strategy engine server includes: a dynamic binding rule base for storing user-defined strategy expressions, wherein the strategy expressions include one or more matching conditions among service name, namespace, instance tag, region information, and grayscale version; The service topology acquisition module is used to obtain metadata information of microservice instances from the service registry in real time and parse the strategy expression into a specific list of instances; A configuration instruction generator is used to bind configuration data with the instance list and generate the configuration change instruction set.
3. A configuration management system for microservice architecture according to claim 1, characterized in that, The configuration client includes: A shared memory manager is used to allocate shared memory regions in the kernel mode of the compute node, establish a mapping relationship between the shared memory regions and microservice instance processes, and provide at least one configuration snapshot version for each microservice instance; The kernel-mode communication proxy is used to communicate bidirectionally with the policy engine server through a high-speed channel, receive configuration change instructions, and return confirmation status.
4. A configuration management system for microservice architecture according to claim 1, characterized in that, The system call interceptor is implemented based on extended Berkeley packet filtering technology and includes: eBPF hooks are attached to the configuration reading system call entry point of the microservice instance process; The eBPF mapping table, associated with the shared memory mapping table, is used to quickly look up the configuration data corresponding to the process in kernel mode. The eBPF hook program is configured to be triggered when the process initiates a system call, read the latest configuration data in the eBPF mapping table, overwrite the return result of the system call, and then return it to the user-space process.
5. A configuration management system for microservice architecture according to claim 1, characterized in that, Also includes: The immutable audit chain module, connected to the strategy engine server and the configuration client, is used to record the metadata of each configuration change event in an append-only manner to the distributed immutable storage. The metadata includes the configuration hash value before the change, the configuration hash value after the change, the operator's identity identifier, the operation timestamp, the list of affected instances determined by the policy engine server, the configuration change instruction set fingerprint, and the effective confirmation information from the configuration client.
6. A configuration management system for microservice architecture according to claim 5, characterized in that, The immutable audit chain module is implemented based on blockchain technology or distributed ledger technology. The metadata is written into the blockchain node as transaction content, thereby forming an immutable audit trail and providing an audit query interface based on time range and instance identifier.
7. A configuration management system for microservice architecture according to claim 1, characterized in that, Also includes: An intelligent rollback controller, connected to the policy engine server, the configuration client, and the monitoring system respectively, includes: The metrics collection unit is used to acquire real-time key metrics data of microservice instances before and after configuration changes. These key metrics include query rate per second, error rate, and average response latency. The anomaly detection engine is used to start a sliding time window after a configuration change event occurs, compare the current metrics with the historical baseline, and determine the configuration change anomaly when the error rate exceeds a preset threshold or the response delay exceeds a preset multiple. The rollback execution unit is used to automatically send a rollback instruction to the policy engine server or directly to the configuration client when the anomaly detection engine determines an anomaly. The rollback instruction contains the configuration data of the previous version or the version number of the previous version, so as to revert the configuration data in the shared memory mapping table to the state before the change.
8. A configuration management system for microservice architecture according to claim 7, characterized in that, The configuration storage center includes: A multi-version repository is used to store each historical version of configuration data, supporting version comparison and version backtracking; The environment isolation module is used to physically or logically isolate configuration data according to development environment, testing environment, pre-release environment, and production environment. The service tag mapping table is used to store the association between configuration data and service tag rules, which can be dynamically queried by the policy engine server when the configuration changes.
9. A configuration management system for microservice architecture according to claim 1, characterized in that, The configuration storage center includes: A multi-version repository is used to store each historical version of configuration data, supporting version comparison and version backtracking; The environment isolation module is used to physically or logically isolate configuration data according to development environment, testing environment, pre-release environment, and production environment. The service tag mapping table is used to store the association between configuration data and service tag rules, which can be dynamically queried by the policy engine server when the configuration changes.
10. A configuration management method for a configuration management system based on any one of claims 1-9 for a microservice architecture, characterized in that, Includes the following steps: Step S1: Configure the storage center to receive and store configuration data, and maintain the environment isolation and multi-version information of the configuration data; Step S2: The strategy engine server receives the configuration change request, parses the service tag rules carried in the configuration change request, and calculates the set of affected microservice instances based on the dynamic binding rule base; Step S3: The strategy engine server generates a configuration change instruction set, binds the configuration data with the microservice instance set, and sends it to the configuration client deployed in the kernel state of the operating system of the computing node where the microservice instance is located; Step S4: The configuration client writes the configuration data to the shared memory mapping table and updates the metadata version number; Step S5: The system call interceptor intercepts the configuration read system call initiated by the process of the microservice instance, matches it with the shared memory mapping table based on the process identifier, and returns the latest configuration data to the process; Step S6: The immutable audit chain module writes the metadata of the configuration change event into the distributed immutable storage to form an audit record; Step S7: The intelligent rollback controller collects runtime metrics of the microservice instance in real time. When it detects that the metrics exceed a preset abnormal threshold within a preset time window after the configuration change, it automatically triggers a rollback operation and instructs the configuration client to restore the previous version configuration data in the shared memory mapping table.