A configuration health check management system and method based on dynamic detection

Abstract

The application provides a configuration health check management system and method based on dynamic detection, relates to the technical field of data processing, and comprises an extraction module, a verification module and an analysis module.The extraction module is used for receiving an update request of a target configuration item in a configuration center and extracting a new parameter value of the configuration item.The verification module is used for dynamically constructing an isolated test environment based on the new parameter value, loading the new parameter value into the isolated test environment, executing a set of predefined basic health probes, and obtaining a primary verification result.The analysis module is used for, when the primary verification result is passed, analyzing a configuration item group that is indirectly associated with the target configuration item according to a dependency topological relationship among microservices, and generating a set of associated configuration item groups.The application extends the configuration verification range, constructs an isolated test environment, locates a configuration impact key node, automatically optimizes and corrects parameters, and guarantees release safety, realizes full-process controllability of microservice configuration changes, avoids chain risks, reduces operation and maintenance costs, and guarantees stable operation of a microservice architecture.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a configuration health check management system and method based on dynamic detection. Background Technology

[0002] In a microservice architecture, application configurations are typically managed centrally by a configuration center. Existing configuration management systems, when performing health checks, usually focus on basic validations of individual configuration items, such as format checks, numerical range validations, or functional probing of their directly associated microservice environments. However, this approach may struggle to effectively address the indirect impacts between configuration items through microservice dependency chains.

[0003] For example, in an e-commerce system, when updating a "concurrency thread count" configuration in the "Inventory Service," the existing system can verify whether this configuration can be loaded and run normally within the Inventory Service itself. However, due to the call relationships between microservices, this configuration change may indirectly affect the processing logic of the downstream "Order Service," which depends on the "Inventory Service," potentially causing new timeouts or queuing issues in the Order Service. This indirect risk caused by configuration dependency chains may be difficult to fully identify before release if the inspection mechanism only focuses on directly related configuration items. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a configuration health check management system and method based on dynamic detection, which can locate key turning points where configuration changes have a significant impact on business flow and provide data support for configuration optimization.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] Firstly, a configuration-based health check management system based on dynamic detection includes:

[0007] The extraction module is used to receive update requests for target configuration items in the configuration center and extract the new parameter values ​​of the configuration items.

[0008] The verification module is used to dynamically build an isolated test environment based on new parameter values, load the new parameter values ​​into the isolated test environment, execute a predefined set of basic health probes, and obtain preliminary verification results.

[0009] The parsing module is used to parse the configuration item group that is indirectly related to the target configuration item based on the dependency topology relationship between microservices when the initial verification result is passed, and generate a set of associated configuration item groups.

[0010] The calculation module is used to construct a virtual configuration topology space based on the set of associated configuration items, and select three key configuration nodes in the virtual configuration topology space to determine a circular detection area; based on the circular detection area, four verification nodes are selected on the circumference and two verification nodes are located in the outer area of ​​the circle. The external detection boundary is constructed by calculating the tangents from the outer nodes to the circle, forming a circular verification path.

[0011] The identification module is used to perform business flow simulation detection in an isolated test environment based on the circular verification path, obtain path execution data, and identify key turning points by analyzing the curvature change features in the path execution data, and generate configuration adjustment parameters.

[0012] The optimization module is used to adjust parameters based on configuration, optimize and correct new parameter values, and complete the release to the corresponding microservice when the corrected parameters pass the final health check; otherwise, the release process is blocked and the system is rolled back to a previous healthy version.

[0013] Secondly, a configuration-based health check management method based on dynamic detection includes:

[0014] Step 1: Receive the update request for the target configuration item in the configuration center and extract the new parameter value of the configuration item;

[0015] Step 2 is used to dynamically construct an isolated test environment based on the new parameter values, load the new parameter values ​​into the isolated test environment, execute a predefined basic health probe set, and obtain preliminary verification results;

[0016] Step 3: When the initial verification result is passed, based on the dependency topology between microservices, parse the configuration item group that is indirectly related to the target configuration item and generate a set of related configuration item groups;

[0017] Step 4: Based on the set of associated configuration items, construct a virtual configuration topology space, and select three key configuration nodes in the virtual configuration topology space to determine the circular detection area; based on the circular detection area, select four verification nodes located on the circumference and two verification nodes located outside the circle, and construct the external detection boundary by calculating the tangents from the outside nodes to the circle to form a circular verification path;

[0018] Step 5: Based on the circular verification path, perform business flow simulation detection in the isolated test environment to obtain path execution data, and identify key turning points by analyzing the curvature change features in the path execution data to generate configuration adjustment parameters;

[0019] Step 6: Adjust the parameters based on the configuration, optimize and correct the new parameter values. When the corrected parameters pass the final health check, complete the release to the corresponding microservice; otherwise, block the release process and revert to the historical healthy version.

[0020] Thirdly, a computer-readable storage medium storing a program that, when executed by a processor, implements the system.

[0021] The above-described solution of the present invention has at least the following beneficial effects:

[0022] By deeply mining the dependency topology relationships between microservices, the verification scope is extended to configuration item groups indirectly associated with the target configuration item. This effectively avoids the potential risks of configuration changes being propagated through the service call chain, preventing downstream services from experiencing functional abnormalities or operational failures due to upstream configuration adjustments. Secondly, the dynamically constructed isolated test environment achieves complete isolation between configuration verification and the production environment. This isolation mechanism ensures that various business flow simulations and health probe executions during testing do not interfere with the stable operation of production services. Furthermore, by deploying a runtime framework and dependent components consistent with the production environment, the verification results are more valuable, reducing the occurrence of tests passing but production failures. Thirdly, the constructed virtual configuration topology space and circular verification path, combined with the curvature change analysis of path execution data by the identification module, can pinpoint key turning points where configuration changes significantly impact business flows, providing a basis for... Configuration optimization provides data support, avoiding the subjectivity and lag of relying on human experience in inspections. Simultaneously, the system can generate configuration adjustment parameters based on identified key inflection points, automatically optimizing and correcting new parameter values. Release operations are only performed when the corrected parameters pass a final health check encompassing multiple scenarios. If the check fails, the release process is immediately halted, and the system automatically reverts to a historical healthy version, reducing the probability of unqualified configurations entering the production environment and shortening fault recovery time. Furthermore, from receiving configuration update requests, building test environments, and resolving dependencies, to verification, parameter optimization, and release control, each step is completed automatically and collaboratively by system modules. This reduces the tedious operations and error risks associated with manual intervention, lowers operational costs, and achieves traceability and controllability throughout the entire configuration change lifecycle, providing a solid guarantee for the stable operation of the microservice architecture. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of a configuration health check management system based on dynamic detection, provided by an embodiment of the present invention.

[0024] Figure 2 This is a flowchart illustrating a configuration health check management method based on dynamic detection, provided by an embodiment of the present invention. Detailed Implementation

[0025] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0026] like Figure 1 As shown, an embodiment of the present invention proposes a configuration health check management system based on dynamic detection, comprising:

[0027] The extraction module is used to receive update requests for target configuration items in the configuration center and extract the new parameter values ​​of the configuration items.

[0028] The verification module is used to dynamically build an isolated test environment based on new parameter values, load the new parameter values ​​into the isolated test environment, execute a predefined set of basic health probes, and obtain preliminary verification results.

[0029] The parsing module is used to parse the configuration item group that is indirectly related to the target configuration item based on the dependency topology relationship between microservices when the initial verification result is passed, and generate a set of associated configuration item groups.

[0030] The calculation module is used to construct a virtual configuration topology space based on the set of associated configuration items, and select three key configuration nodes in the virtual configuration topology space to determine a circular detection area; based on the circular detection area, four verification nodes are selected on the circumference and two verification nodes are located in the outer area of ​​the circle. The external detection boundary is constructed by calculating the tangents from the outer nodes to the circle, forming a circular verification path.

[0031] The identification module is used to perform business flow simulation detection in an isolated test environment based on the circular verification path, obtain path execution data, and identify key turning points by analyzing the curvature change features in the path execution data, and generate configuration adjustment parameters.

[0032] The optimization module is used to adjust parameters based on configuration, optimize and correct new parameter values, and complete the release to the corresponding microservice when the corrected parameters pass the final health check; otherwise, the release process is blocked and the system is rolled back to a previous healthy version.

[0033] In this embodiment of the invention, by deeply mining the dependency topology relationships between microservices, the verification scope is extended to configuration item groups indirectly associated with the target configuration item. This effectively avoids the potential risks of configuration changes being passed through the service call chain, preventing downstream services from experiencing functional abnormalities or operational failures due to upstream configuration adjustments. Secondly, the dynamically constructed isolated test environment achieves complete isolation between configuration verification and the production environment. This isolation mechanism ensures that various business flow simulations and health probe executions during testing do not interfere with the stable operation of production services. Furthermore, by deploying a runtime framework and dependent components consistent with the production environment, the verification results are more valuable, reducing the occurrence of tests passing but production failures. Moreover, the constructed virtual configuration topology space and circular verification path, combined with the curvature change analysis of path execution data by the identification module, can pinpoint the key factors that significantly impact business flows due to configuration changes. The inflection point provides data support for configuration optimization, avoiding the subjectivity and lag of relying on human experience in the inspection process. At the same time, the system can generate configuration adjustment parameters based on the identified key inflection points, automatically complete the optimization and correction of the new parameter values, and only perform the release operation when the corrected parameters pass the final health check that includes multiple scenarios. If the check fails, the release process is immediately blocked and automatically rolled back to the historical healthy version, reducing the probability of unqualified configurations entering the production environment and shortening the fault recovery time. In addition, from receiving configuration update requests, building test environments, resolving dependencies, to verification and detection, parameter optimization and release control, each link is completed automatically by system modules in a collaborative manner, reducing the tedious operation and error risk of manual intervention, reducing operation and maintenance costs, and realizing the traceability and controllability of the entire lifecycle of configuration changes, providing a solid guarantee for the stable operation of microservice architecture.

[0034] In a preferred embodiment of the present invention, receiving an update request for a target configuration item in the configuration center and extracting the new parameter value of the configuration item includes:

[0035] The system receives configuration change notifications pushed by the configuration center, parses the notifications to obtain the identifier information of the target configuration item, specifically including: when a configuration administrator completes parameter modification of the target configuration item in the configuration center and submits a release request, the configuration center's message push function will immediately trigger the generation process of the configuration change notification; the system pre-establishes a stable communication link with the configuration center via a long connection, and subscribes to the global configuration change message topic of the configuration center to ensure that it can capture various configuration change-related notification information in real time; after receiving the configuration change notification pushed by the configuration center, the system first performs a format validation operation on the notification data. During the validation, it first verifies the basic metadata such as the message version number, timestamp, and message signature in the notification header. After confirming the completeness and absence of any missing information, the system then disassembles the notification body layer by layer according to preset structured parsing rules. The notification body uses a hierarchical data structure to store information. The system first locates the change type field, confirms that the change attribute is a configuration item modification, and then focuses on the target configuration item identifier field. This identifier field contains multiple levels of content. The system first parses out the microservice identifier to which the target configuration item belongs, then parses the configuration category identifier under that microservice, such as database connection configuration, cache service configuration, external interface configuration, etc., and finally parses out the unique code of the configuration item. Through the combination of these three layers of information—microservice identifier, configuration category identifier, and configuration item unique code—the system completely locks out the identifier information of the target configuration item. During the parsing process, if any layer of identifier information is found to be missing, has misaligned characters, or has other format errors, the system will immediately trigger an exception alarm and terminate all subsequent processes to ensure the accuracy of the identifier information from the source.

[0036] Based on the identification information, the system extracts the corresponding new parameter values ​​from the storage component of the configuration center. Specifically, after obtaining the complete identification information, the system first constructs a query index for the storage component of the configuration center. The storage component adopts a hierarchical storage structure of microservice identifier, configuration category identifier, and configuration item unique code. The system concatenates the parsed three-layer identification information in the order of this structure to generate an index key that conforms to the query rules of the storage component. Subsequently, the system sends a parameter query request carrying the index key to the storage component of the configuration center. The request also includes a parameter version verification value. The version verification value is calculated by first counting the character length of the microservice identifier, the character length of the configuration category identifier, and the character length of the configuration item unique code, adding these three length values ​​together, and then multiplying the sum by a preset basic verification coefficient of 2. The final result is the version verification value for this query, which is used to verify the validity of the data in the storage component.

[0037] Upon receiving a query request, the storage component first performs a dual verification process. The first step is index key format verification. Based on the storage component's preset rules, it checks whether the index key conforms to the hierarchical structure of microservice identifier, configuration category identifier, and configuration item unique code, confirming that the separators between each level of identifier are used correctly and that there are no extra characters or missing fields. The second step is version checksum matching verification. Here, matching is judged by complete numerical consistency. The storage component extracts each level of identifier from the index key in the request, calculates the character length of the microservice identifier, configuration category identifier, and configuration item unique code, and then... The three values ​​are added together and multiplied by a preset base verification coefficient of 2 to obtain a real-time calculated version verification value. This value is then compared with the version verification value carried in the request. If the two values ​​are completely equal, the matching degree is considered satisfactory. Only after both verifications pass can subsequent operations proceed. After verification, the storage component locates the target configuration item's storage directory layer by layer according to the hierarchical structure of the index key. It then reads the parameter record marked as the latest version in that directory. After receiving the parameter data returned by the storage component, the system immediately initiates parameter integrity verification, checking the field values ​​sequentially according to the field order defined in the parameter definition. The strings are concatenated into a continuous string, and then hashed using the SHA-256 algorithm to generate a 256-bit hash value. This hash value is then compared bit-by-bit with the pre-associated hash verification value of the parameter in the storage component. If all bits match, the parameter data is confirmed to be intact and undamaged. If the new parameter value of the target configuration item is of a composite type, i.e., containing multiple sub-parameters, the system will split it into individual sub-parameters according to the business function division rules, and obtain the association weight of each sub-parameter through weighted calculation. Specifically, the calculation method is the sum of the sub-parameter's call frequency weight and its business impact weight, where the call frequency weight... The sub-parameter's weight is calculated by dividing the actual number of calls to that sub-parameter by the total number of calls to its associated configuration item, with the result rounded to two decimal places. The business impact weight is a fixed value preset based on the sub-parameter's business importance, determined by its support for core business processes. Sub-parameters supporting core business processes (such as transaction payments and data storage) have a preset business impact weight of 0.6; anomalies in these sub-parameters will directly cause main business interruptions. Auxiliary, non-core sub-parameters (such as log output formats and non-critical interface timeout settings) have a preset business impact weight of 0.3; fluctuations in these weights will not have a decisive impact on the main business process. The combined weight of each sub-parameter is obtained by adding the two weights, with the result rounded to two decimal places. After all parameter verification and weight calculation are completed, the system stores the complete and multi-validated new parameter values ​​in a local temporary cache. The cache space is set to an independent partition to avoid confusion with other business data.

[0038] This embodiment, through preset communication links and structured parsing rules, combined with multi-level identification information verification, avoids deviations in target configuration item location caused by notification loss or identification parsing errors, ensuring that the configuration items that need to be updated can be locked; by constructing a hierarchical query index, version verification, and hash integrity verification, it eliminates the possibility of extracting invalid, expired, or incomplete parameter values; the entire process of notification reception, parsing, and parameter extraction is completed through an automated workflow, reducing the number of manual intervention steps, lowering the risk of human error, and shortening the response time from configuration change triggering to parameter extraction.

[0039] In a preferred embodiment of the present invention, an isolated test environment is dynamically constructed based on new parameter values, and the new parameter values ​​are loaded into the isolated test environment. A predefined set of basic health probes is then executed to obtain preliminary verification results, including:

[0040] Based on the configuration type and associated service characteristics of the new parameter values, independent test container instances are created. Specifically, this includes: first, classifying and identifying the configuration types of the new parameter values, including database connection configuration, cache service configuration, external interface configuration, and business logic parameter configuration, etc. Different types correspond to different resource consumption characteristics. Simultaneously, associated service characteristics are extracted, with core characteristics including the service's business level (core business / non-core business), average concurrent processing volume, and resource dependency strength (e.g., whether it relies on GPU acceleration or large memory). Based on these two types of information, the resource configuration specifications of the test container are determined. The calculation logic is as follows: the container's basic CPU core count is set to 1, dynamically adjusted according to the associated service concurrency level. The concurrency level is divided into low (below 1000 requests / minute), medium (...), and high (...) concurrency levels based on the peak number of requests processed by the business. The concurrency levels are divided into three levels: 1000 to 5000 times / minute and high (above 5000 times / minute), with corresponding adjustment coefficients of 0.5, 1, and 2, respectively. The final number of CPU cores = base number of cores + concurrency level adjustment coefficient. The memory configuration is based on the daily memory usage of the associated service in the production environment, multiplied by a redundancy coefficient of 1.2 to ensure sufficient resources and no lag during testing. For example, if the new parameter is the cache configuration of the core transaction service, the concurrency level of the associated service is high, and the daily memory usage in the production environment is 4GB, then the container CPU cores = 1 + 2 = 3 cores, and the memory = 4 × 1.2 = 4.8GB. After determining the specifications, an independent instance is automatically created through the container orchestration tool, and a dedicated network address and isolated storage space are allocated to the container to avoid resource competition with other test tasks or the production environment.

[0041] Deploy the same version of the runtime framework and dependent components as the production environment in the test container instance, inject new parameter values ​​into the runtime framework's configuration management layer, and complete the runtime environment initialization. Specifically, this includes: first, extracting the runtime framework version information corresponding to the production environment from the environment image repository in the configuration center, covering programming language runtimes such as Java JDK 1.8 and Python 3.8, application servers such as Tomcat 9.0 and Nginx 1.20, and middleware such as Redis 6.0 and Kafka 2.8, ensuring complete consistency with the production environment version; then, deploying the corresponding version's base image to the newly created test container using image pull commands; next, automatically starting the dependent component installation process. During installation, the version hash value of each component is verified. Only when the hash value completely matches the pre-recorded hash value of the same component in the production environment is the component installation completed. After all dependent components are installed, the parameter injection phase begins; parameter injection is performed using a layered injection approach. For framework-level parameters, such as setting the database connection pool size to 50, they are directly written to the specified location in the core configuration file of the running framework. For business-level parameters, such as setting the order timeout threshold to 60 seconds, they are injected into the configuration management layer of the running framework as environment variables to ensure that business parameters can be dynamically read by the framework. For sensitive parameters (such as interface keys), they are sent to the test container through an encrypted transmission channel and stored in a temporary secure cache area within the container. This cache area is only accessible to the framework configuration management layer. After all parameters are injected, the running framework is started, and initialization verification is performed. On the one hand, the framework startup log is checked line by line to confirm that there are no abnormal messages such as configuration loading failures or parameter parsing errors. On the other hand, the running status of the framework core process is verified. The PID of the core process is confirmed to exist and be stable through system process monitoring tools. At the same time, the CPU utilization of the core process is within the normal range of 5% to 30%, and the memory utilization is within the normal range of 10% to 40%. If there are no abnormalities in the logs and the process running status meets the requirements, the initialization of the running environment is confirmed to be complete.

[0042] The process involves sequentially performing network connectivity verification, identity authentication verification, and basic functional operation testing. Network connectivity verification includes port reachability testing of the target service; identity authentication verification includes credential validity and permission scope verification; and basic functional operation testing includes core interface calls and response parsing. Specifically, this includes: First, conducting network connectivity verification using a layered testing strategy. At the bottom layer, a network connectivity testing tool performs 10 connectivity tests on each associated port of the target service, with a 1-second interval between each test. The number of successful responses for each test is recorded, and the connectivity success rate is calculated using the formula: Connectivity Success Rate = Number of Successful Responses ÷ Total Number of Tests × 100%. This success rate must reach 95% or higher to be considered port reachability qualified. At the upper layer, a domain name resolution test based on the service name is initiated, submitting a service name resolution request to the service registry. If a list of corresponding IP addresses is returned within 3 seconds, the service discovery function is considered successful. Normally, this ensures the test container can accurately locate the associated service via the service name. Next, identity authentication verification is performed, divided into two stages: credential validity and permission scope. In the credential validity verification stage, the authentication credentials (such as tokens and keys) in the configuration are encrypted according to the production environment's unified symmetric encryption rules (such as a 256-bit symmetric encryption algorithm), generating an encrypted credential string. This string is then compared one by one with the encrypted credential strings of the same type pre-stored on the server. If they match completely, the credential is considered valid. In the permission scope verification stage, based on the role-based access control model, the role information corresponding to the credential is first extracted. Then, the complete permission list for that role is queried from the permission management database. Each resource access permission involved in the configuration is verified to be included in this list, while also confirming that the permission's effective duration does not exceed the preset 90-day validity period. For example, if the configuration involves order query permissions, it must be confirmed that the role contains the permission identifier for order information query and that this permission has not expired.

[0043] Finally, basic functional operation tests were performed. First, a list of core interfaces associated with the target configuration item was compiled. For example, when configured as payment parameters, the core interfaces include payment initiation and payment status query. For each core interface, 10 calls were made to simulate the request parameters and call frequency of real business scenarios. The response timeout threshold for each call was set to 5 seconds. After the call was completed, the response result of each call was parsed. The interface call was considered successful only if three criteria were met simultaneously: First, the response status code was within the normal range of 200 to 299; second, the response body format strictly conformed to the interface's preset specifications, such as complete JSON key-value pairs and field data types that perfectly matched the interface definition; and third, the key business fields (such as payment amount and order number) were completely consistent with the request parameters or preset baseline values, with no data deviation.

[0044] Record response latency, success rate, and error type metrics during the testing process, generating preliminary verification results including pass and fail statuses. Specifically, metric recording employs a combination of real-time data collection and aggregated calculation. For response latency, record the time from request issuance to receiving a complete response for each API call. After removing one maximum and one minimum value, calculate the average of the remaining eight values: Average Response Latency = (Total Latency - Maximum Value - Minimum Value) ÷ 8. For success rate, separately count the number of successful network connections, authentication attempts, and API calls. Individual success rate = Number of successful attempts ÷ Total number of tests for that individual item × 100%. Error types are categorized and statistically analyzed into network errors, authentication errors, interface logic errors, and parameter format errors, recording the frequency and specific description of each type of error. Result generation follows the principle of full compliance, setting pass conditions: network connectivity success rate ≥ 90%, identity authentication verification fully passed, interface call success rate ≥ 90%, and no interface logic errors. If all conditions are met, the initial verification result is passed. If any one condition is not met, such as a network connectivity success rate of 85% or the occurrence of an interface logic error, the result is failed, and the failed indicators and error details are output as result attachments.

[0045] This embodiment employs multi-dimensional verification to cover core aspects affected by configuration, forming a complete basic verification chain from network connectivity and identity authentication to business functions. Compared to verification methods that only focus on parameter format, it can more comprehensively discover potential problems in the configuration and reduce risk omissions caused by single verification. Quantitative indicators and clear standards enhance the credibility of verification results. Through indicator calculation methods and clear pass conditions, the initial verification results are objective and traceable, avoiding the ambiguity of results caused by subjective judgment during testing. Independent container instances ensure the security and stability of the testing process. The isolated resources and network environment will not interfere with production services and will also avoid the impact of other test tasks, ensuring the smooth operation of the verification process. At the same time, dedicated storage space facilitates log traceability during subsequent troubleshooting.

[0046] In a preferred embodiment of the present invention, when the initial verification result is passed, based on the dependency topology relationship between microservices, the configuration item group that is indirectly related to the target configuration item is parsed, and a set of associated configuration item groups is generated, including:

[0047] The system retrieves dependency connection information between microservices from the service registry, including service call relationships and data flow. Specifically, when the system initiates the dependency information collection process, it first establishes an encrypted data interaction channel with the service registry via the TLS 1.3 protocol. Before establishing the channel, two-way identity verification is required. The system submits signature information containing its own service identifier and request timestamp to the registry. After successful verification, the registry returns an encryption certificate, and both parties complete key negotiation to ensure that subsequent data transmission is not tampered with or stolen. The service registry stores the runtime metadata and real-time interaction records of all microservices. In addition to the default 30-day time range filtering condition, the dependency information query request sent by the system to the registry also includes a filter that only returns data from active services. (Active services are defined as services with call records within the last 7 days); After the registry center responds, it returns structured dependency connection information in JSON array format. Each record contains complete fields. The service call relationship field covers the caller service identifier, the callee service identifier, the full path of the called interface, the interface version number, the specific business scenario triggered by the call (such as order creation triggering inventory query), and the average call time; the data flow field covers the data source service identifier, the data target service identifier, the middleware channel for data transmission, such as Kafka topics, RabbitMQ queues, data type (structured data labeled JSON / XML, unstructured data labeled file format), and transmission trigger conditions, such as scheduled push and event-driven.

[0048] Upon receiving data, the system immediately performs integrity checks. For each call relationship record, it checks whether the caller and callee identifiers are valid identifiers registered in the system and whether the interface path conforms to the standard format of service identifier / interface module / interface name. For each data flow record, it checks whether the transmission path contains the complete middleware address and channel name and whether the transmission trigger condition is clear. If a record is found to have missing fields or incorrect format, the system will mark the record as needing to be completed and send a targeted re-check request to the registry center. After completion, all valid data is stored in the tree structure table of the local dependency database according to the caller-callee relationship.

[0049] Based on the service identifier of the target configuration item, the direct and indirect dependent service sets are identified in the dependency connection information. Specifically, this includes: using the service identifier of the target configuration item (denoted as the core service S0) as the starting point for retrieval, and leveraging the tree index of the local dependency database, a hierarchical retrieval algorithm is initiated to identify dependent services. The first layer of direct dependent service identification employs bidirectional matching and interactive verification logic. First, the caller set A (caller = S0) and the caller set B (caller = S0) are filtered from the call relationship records. Then, the target service set C (data source = S0) and the source service set D (data target = S0) are filtered from the data flow records. The union of the four sets A, B, C, and D is taken to obtain the initial candidate set of direct dependent services. Subsequently, interactive verification is performed on each service in the candidate set, querying the average daily interaction count between the service and S0 over the past 30 days. If the number is ≥1 (excluding invalid dependencies from occasional calls), the service is considered a direct dependent service. If the service is directly dependent, it will be included in the final set of directly dependent services, denoted as set L1. Each service will be labeled with its interaction type (caller / callee, data sender / receiver). The identification of indirect dependent services at the second level and above uses node diffusion and hierarchical restriction logic. Each service in set L1 is used as a first-level diffusion node. The identification logic for direct dependencies is repeated, filtering the associated services of each node. After removing services already included in S0 and L1, a second-level dependent service set L2 is formed. Then, services in L2 are used as second-level diffusion nodes, and the same identification logic is executed to form a third-level dependent service set L3. The system presets a maximum search level of 3 levels because the impact of dependency propagation beyond 3 levels in a microservice architecture will be significantly weakened, and excessive searching will increase the cost of ineffective analysis. Finally, L2 and L3 are integrated into an indirect dependent service set, and each service is labeled with its dependency level with S0 (L2 is labeled as level 2, L3 as level 3), clearly distinguishing between direct and indirect dependencies.

[0050] Extract key configuration items from all dependent services, including database connection configuration, cache service configuration, and external interface configuration. Specifically, the system first establishes key configuration item filtering rules based on historical microservice failure data. These rules clearly define key configuration items as those directly affecting service startup, data interaction stability, and core business logic execution. These are further categorized into three core types: database connection configuration, cache service configuration, and external interface configuration. A list of non-key configuration items to exclude (such as log output format, interface display language, debug mode on / off, etc.) is also compiled. For each service in the L1, L2, and L3 sets, the system initiates a configuration query request through the configuration center's standard RESTful interface. The request header carries a service identifier and a temporary access token (the token is valid for 10 minutes to avoid...). (To avoid permission leaks), after retrieving all configuration items, the system performs categorized extraction according to filtering rules. For database connection configuration, it extracts six mandatory sub-parameters: database type (e.g., MySQL, Oracle), master-slave connection address, initial connection pool size, maximum number of connections, connection timeout, and number of retries. For cache service configuration, it extracts five sub-parameters: cache type (e.g., Redis, Memcached), cluster node IP and port, data expiration strategy (e.g., timed expiration, lazy deletion), cache key prefix, and serialization method. For external interface configuration, it forcibly extracts six sub-parameters: complete interface URL, request method (GET / POST, etc.), mandatory request header fields, authentication method, response body format, and mapping relationship of core response fields.

[0051] During the extraction process, the system performs dual checks on the completeness and format validity of each configuration item. If a sub-parameter is missing (e.g., the database connection configuration lacks the main connection address), the configuration item is marked as an anomaly, and the name of the missing parameter and the service to which it belongs are recorded. If the sub-parameter format is incorrect (e.g., the timeout is entered as a string instead of a number), it is marked as an invalid item, and examples of the incorrect and correct formats are recorded. After all extractions are completed, a list of critical configuration items for dependent services is generated. Only valid configuration items are retained in the list, while anomalies and invalid items are listed separately and synchronized to the operation and maintenance alarm system.

[0052] The dependency strength value of each configuration item is calculated based on the call frequency and data transfer volume. The configuration items are then prioritized according to their dependency strength values, generating a set of associated configuration item groups with weighted identifiers. Specifically, the system first analyzes historical fault data to determine the calculation dimensions and weight allocation for the dependency strength value. Call frequency directly reflects the tightness of service interaction, with a weight coefficient set to 0.6; data transfer volume reflects the scale of the business impact of the interaction, with a weight coefficient set to 0.4. The sum of the two weights is 1, conforming to the normalization principle and ensuring comparable calculation results. The specific calculation process is as follows: Full data from the past 30 days is extracted from the service call log database, and for each key configuration item, such as... Configure the cache expiration time for the inventory service, locate its associated core interaction interfaces, such as the inventory query interface, and collect three sets of core data: the total number of calls to this interface C (the number of interactions between the core service and dependent services), the total number of calls to all interfaces of the core service T, the total number of bytes of data transmitted by this interface D (the amount of data transmitted between the core service and dependent services), and the total number of bytes of data transmitted by all core services S. Calculate the call frequency percentage = C ÷ T, and then map the percentage to a score range of 0 to 10 according to the degree of business impact (score 1 for percentage ≤ 0.1, representing weak dependency; score 3 for 0.1 < percentage ≤ 0.3, representing relatively weak dependency; score 5 for 0.3 < percentage ≤ 0.5). A score of 5 corresponds to a medium dependency; 0.5 < percentage ≤ 0.7 corresponds to a score of 7, representing a relatively strong dependency; and percentage > 0.7 corresponds to a score of 10, representing a strong dependency. The final call frequency score = mapping score × 0.6; the data transfer volume percentage is calculated as D ÷ S, using a score mapping rule identical to the call frequency. The mapped score is then multiplied by a weighting coefficient of 0.4 to obtain the data transfer volume score; the dependency strength value = call frequency score + data transfer volume score. After all key configuration items are calculated, the system sorts them from highest to lowest dependency strength value. Simultaneously, the total number of configuration items N is counted, and priorities are assigned proportionally, with the top 20% (ranked 1 to 0.2N) having high priority. The first priority level is marked as weight 1, which requires close attention in subsequent testing; 20% to 60% (ranking 0.2N+1 to 0.6N) is medium priority, marked as weight 2, and tested according to the standard process; after 60% (ranking 0.6N+1 to N) is low priority, marked as weight 3, and the testing steps can be simplified; finally, the system integrates all configuration items according to the hierarchical structure of dependent service identifiers and priority weights, generating a set of associated configuration item groups. Each record in the set contains complete attributes, namely the service identifier and name, configuration item category, specific parameter value, dependency strength value, priority weight identifier, and also includes the basic data collection source (such as log library address and statistical time range).

[0053] This embodiment, by hierarchically searching for direct and indirect dependent services, overcomes the limitation of focusing only on directly related configurations, extending the scope of configuration influence to indirect dependent links. This avoids risk omissions caused by neglecting indirect related configurations, making the coverage of configuration health checks more comprehensive. Based on call frequency and data transmission volume, the originally vague degree of dependency is transformed into a measurable value, replacing subjective human judgment and making configuration priority ranking more objective and scientific. The set of related configuration items with weight labels allows subsequent virtual configuration topology space construction and detection path planning to focus on high-weight core configuration items, reducing meaningless detection steps and improving the targeting and efficiency of the overall configuration health check. By filtering non-critical configuration items through screening rules, the integrity of the analysis data is ensured while avoiding redundant data interference.

[0054] In a preferred embodiment of the present invention, a virtual configuration topology space is constructed based on the associated configuration item set, and three key configuration nodes are selected in the virtual configuration topology space to determine a circular detection area; based on the circular detection area, four verification nodes are selected located on the circumference, and two verification nodes are located in the outer area of ​​the circle. The outer detection boundary is constructed by calculating the tangents from the outer nodes to the circle, forming a circular verification path, including:

[0055] Based on the dependency strength values ​​and connectivity relationships of each configuration item in the associated configuration item set, a three-dimensional virtual configuration topology space is established. Each configuration item is mapped to its corresponding position in the spatial coordinate system according to its dependency strength value, resulting in the mapped configuration item. Specifically, when the system starts the topology construction process, a three-dimensional spatial coordinate system is first defined in conjunction with the core requirement of configuration health checks. The meaning of each axis is set around accurately reflecting the influence weight of configuration items. The X-axis is anchored to the dependency strength value, because this value directly reflects the degree of influence of the configuration item on the core service and is the core basis for priority ranking; the Y-axis corresponds to the dependency level, and the relationship between direct and indirect dependencies can be quickly located by distinguishing the levels; the Z-axis focuses on the interaction frequency, and configuration items with high-frequency interactions have a wider impact when anomalies occur, and need to be highlighted in the space; to avoid mutual interference between data from different dimensions, each axis has independent and clear mapping rules, and the X-axis adopts a 1:1 ratio. For example, in the mapping, since the dependency strength value itself has been standardized and quantified from 0 to 10, it can be directly used as the coordinate value to retain the original data characteristics to the greatest extent. For example, when the dependency strength value is 7.2, the X coordinate is 7.2. The Y-axis uses a fixed interval mapping: level 0 (core service) corresponds to Y=0, level 1 (direct dependency) corresponds to Y=2, level 2 corresponds to Y=4, and level 3 corresponds to Y=6. The interval is set to 2 to avoid the overlap of adjacent level nodes in space, while ensuring visual differentiation. The Z-axis uses a linear proportional mapping. First, the interaction frequency ratio is calculated (the number of interactions between a certain configuration item and the core service per day ÷ the total number of interactions between all configuration items of the core service per day), and then the ratio is mapped to the interval of 0 to 5. The formula is Z coordinate = ratio × 5. For example, if a certain configuration item interacts 2000 times per day and the core service interacts a total of 10000 times, the ratio = 2000 ÷ 10000 = 0.2, and the Z coordinate = 0.2 × 5 = 1.

[0056] After defining the mapping rules, the system traverses the set of associated configuration items, performing a complete process of feature extraction, coordinate calculation, and node generation for each configuration item. It extracts the dependency strength value (e.g., 6.5), the service dependency level (e.g., level 1), and the interaction frequency percentage (e.g., 0.3) of the configuration item, calculating the three-dimensional coordinates X=6.5, Y=2, and Z=1.5. These coordinates represent the unique position of the configuration item in the topology space. Subsequently, it constructs association links based on the call relationships and data flow between configuration items. The call relationship link points from the caller node to the callee node, and the data flow link points from the data source node to the target node. The thickness of the link lines is adjusted according to the interaction frequency percentage: thick lines (3 pixels wide) for frequencies above 0.5, medium lines (2 pixels wide) for frequencies between 0.2 and 0.5, and thin lines (1 pixel wide) for frequencies below 0.2. This ultimately forms a clearly defined, visually clear three-dimensional virtual configuration topology space with distinct nodes and relationships.

[0057] From the mapped configuration items, the three configuration nodes with the highest dependency strength values ​​are selected as standard points. Based on the spatial coordinates of the three standard points, the center coordinates and radius of the circumcircle are calculated to determine the circular detection area. Specifically, the system first sorts all mapped configuration item nodes in descending order of X-axis coordinates (dependency strength values), and selects the top three nodes as standard points, denoted as A(X1, Y1, Z1), B(X2, Y2, Z2), and C(X3, Y3, Z3). Since the circular detection area needs to be constructed in a plane, the three standard points are projected onto the XY plane (ignoring the Z-axis coordinates) to obtain the plane projection points A'(X1, Y1), B'(X2, Y2), and C'(X3, Y3). The center coordinates are calculated using the formula for the circumcircle of a triangle. First, the midpoint coordinates of sides AB and AC are calculated. The coordinates of the midpoint M of side AB are ((X1+X2)÷2, (Y1+Y ... 2)÷2), the coordinates of the midpoint N of side AC are ((X1+X3)÷2, (Y1+Y3)÷2); then calculate the slopes of sides AB and AC, the slope of side AB k1=(Y2-Y1)÷(X2-X1), the slope of side AC k2=(Y3-Y1)÷(X3-X1); according to the property that the product of the slopes of perpendicular lines is -1, we get the slope of the perpendicular bisector of side AB is -1÷k1, and the slope of the perpendicular bisector of side AC is -1÷k2. Then, the equations of the two perpendicular bisectors are listed: perpendicular bisector M is y-(Y1+Y2)÷2=(-1÷k1)(x-(X1+X2)÷2), and perpendicular bisector N is y-(Y1+Y3)÷2=(-1÷k2)(x-(X1+X3)÷2). The intersection point of the two equations is found; the coordinates of this intersection point (Ox, Oy) are the center of the circumcircle. The radius is the distance from the center to any projection point, calculated using the formula: radius r = The system determines the circular detection area on the XY plane using the center coordinates and radius length. If a special case occurs during the calculation process where the slope of a side is infinite (vertical line) or 0 (horizontal line), the system will automatically match the corresponding simplified algorithm. For example, when side AB is a vertical line, the perpendicular line is directly calculated in the horizontal direction to ensure the accuracy of the center calculation.

[0058] Four circumferential verification nodes are selected on the circumference of the circular detection area at four azimuth angles: 0 degrees, 90 degrees, 180 degrees, and 270 degrees. Based on the center coordinates of the circular detection area, the first outer verification node is selected by extending twice the radius in the positive X-axis direction, and the second outer verification node is selected by extending twice the radius in the negative Y-axis direction. Specifically, the selection of circumferential verification nodes is based on the polar coordinate principle, with the center (Ox, Oy) of the circular detection area as the pole and the positive X-axis as the polar axis, at 0 degrees, 90 degrees, 180 degrees, and 270 degrees. The coordinates of the verification nodes on the circle are calculated using four fixed azimuth angles of 270 degrees. The coordinates of the 0-degree node are (Ox+r, Oy), representing the radius moved from the center along the positive X-axis; the coordinates of the 90-degree node are (Ox, Oy+r), representing the radius moved along the positive Y-axis; the coordinates of the 180-degree node are (Ox-r, Oy), representing the radius moved along the negative X-axis; and the coordinates of the 270-degree node are (Ox, Oy-r), representing the radius moved along the negative Y-axis. After calculating the target coordinates, the system matches the target coordinates in the three-dimensional topological space. For configuration item nodes corresponding to the location, taking coordinates (10.07, 3.05) as an example, search for nodes within a 0.2 range around this coordinate. If they exist, select them directly; otherwise, calculate the Euclidean distance between this coordinate and all surrounding nodes, and select the node with the smallest distance as a supplement to ensure that there is a corresponding verification node for each azimuth angle. The selection of verification nodes outside the circle focuses on covering edge risks. Two outer nodes in different directions are selected to cover the extended area of ​​core dependencies and the edge dependency area. The first outer node extends along the positive X-axis (the positive X-axis corresponds to the direction of increasing dependency strength, and the extension can cover strongly dependent associated nodes), and is twice the radius from the center of the circle, with coordinates (Ox+2r, Oy). The second outer node extends along the negative Y-axis (the negative Y-axis corresponds to the direction of decreasing dependency level, and the extension can cover low-level edge nodes), and is also twice the radius from the center of the circle, with coordinates (Ox, Oy-2r). Selecting nodes at these two locations as outer verification nodes can effectively make up for the problem of insufficient coverage of edge configuration items by the circular detection area.

[0059] Based on the center coordinates and radius of the circular detection area, two sets of tangent equations from the two outer verification nodes to the circular detection area are calculated. The outer detection boundary area is then constructed based on these tangent equations. Specifically, the outer detection boundary is constructed using the tangents from the outer nodes to the circular area, forming a ring-shaped detection range to ensure no blind spots at the junction of the core and outer areas. Taking the first outer node P(Px, Py) as an example, the tangent equation from it to the circular detection area is calculated. First, the distance L from node P to the center O(Ox, Oy) is calculated. According to geometric relationships, the tangent is perpendicular to the line connecting the center to the point of tangency. Let the point of tangency be T(Tx, Ty), then (Tx-Ox)(Tx-Px)+(Ty-Oy)(Ty-Py)=0 (the perpendicular dot product of vectors is 0). Simultaneously, the point of tangency lies on the circle, satisfying... Solve the two equations simultaneously to obtain the coordinates of the two tangent points T1 and T2, and then obtain the equations of the two tangent lines. The equation of the line passing through points P and T1 is (y-Py)=[(T1y-Py)÷(T1x-Px)](x-Px), and the equation of the line passing through points P and T2 is (y-Py)=[(T2y-Py)÷(T2x-Px)](x-Px). Use the same method to calculate the equations of the two tangent lines from the second outer node Q to the circular region. The four tangent lines (if they overlap, take the unique value) together form a closed outer detection boundary region. The annular area between this region and the circular detection region is the core range of the subsequent business flow simulation detection. If the equation has no real solution during the calculation process (such as the distance of the outer node from the center of the circle is less than the radius), the system will determine that the node selection is invalid and automatically continue to extend along the original direction to a position twice the radius from the center of the circle to reselect a node to ensure that the tangent equation is solvable.

[0060] Based on the spatial distribution of the circumferential and outer-circumferential verification nodes, and in accordance with the test execution timing requirements, all verification nodes are sequentially connected to form a complete circular verification path. Specifically, the system first formulates test execution timing rules based on test efficiency and coverage integrity, executing them from the outer perimeter to the core and back to the outer perimeter. This approach not only identifies fundamental issues with outer edge nodes to prevent them from affecting the test results of core nodes, but also reduces the spatial jump distance between nodes, improving test execution efficiency. Based on these rules and the spatial distribution of each node, the node connection order is determined. Specifically, the order is as follows: first connect the first outer-circumferential node P, then connect the 0-degree circumferential node, then the 90-degree circumferential node, then the second outer-circumferential node Q, followed by the 270-degree circumferential node, then the 180-degree circumferential node, and finally connect back to the first outer-circumferential node P, forming a complete closed path. During the path connection process, the system will communicate... Path compliance is verified by judging the intersection of line segments and regions. For adjacent nodes, such as a 90-degree circular node and a Q node, a line segment is constructed between the two points. It is checked whether the line segment is completely within the annular area formed by the outer detection boundary and the circular detection area. The verification method is to take the midpoint of the line segment and determine whether the distance from the midpoint to the center of the circle is greater than the radius and less than twice the radius. If it is satisfied, the path is compliant. If it is not satisfied, such as the distance from the midpoint to the center of the circle is less than the radius, it means that the path enters the interior of the circular area. The connection order is then adjusted. For example, the 90-degree circular node-Q node is adjusted to the 90-degree circular node-270-degree circular node-Q node to ensure that the adjusted path still meets the requirements of the annular area coverage. The final annular verification path has dual coverage characteristics: the circular nodes cover the core configuration with high dependence intensity, the outer nodes cover the outer edge configuration, and the annular area through which the path passes covers the connection zone between the core and the edge.

[0061] This embodiment transforms the dependency strength, hierarchy, and interaction frequency of configuration items into spatial locations through a three-dimensional topological space, making the originally abstract dependency relationships intuitively presented. This solves the problem of ambiguous dependency relationships in configuration detection and facilitates the rapid identification of core associated configurations. The circular detection area focuses on core configurations with high dependency strength, while the outer nodes and tangent boundaries cover the outer edge configurations. The resulting ring path achieves full-range detection of both core and edge configurations, avoiding the limitations of detection that only focuses on local configurations and reducing risk omissions. By selecting standard points based on dependency strength values ​​to construct the detection area, detection resources are concentrated on high-risk configuration nodes. At the same time, the ring path is planned according to time sequence rules, reducing invalid jumps and making test execution more efficient, avoiding the resource waste caused by indiscriminate detection. The ring verification path covers the key links of the configuration dependency chain. Business flow simulation detection based on this path can more realistically restore the impact of configuration changes on the entire business chain. Through spatial mapping and path planning, the chain risks that configuration changes may cause are exposed in advance during the testing phase. Compared with the post-release remediation model, this achieves proactive risk identification and prevention.

[0062] In a preferred embodiment of the present invention, based on a circular verification path, business flow simulation detection is performed in an isolated test environment to obtain path execution data. Key inflection points are identified by analyzing the curvature change features in the path execution data, and configuration adjustment parameters are generated, including:

[0063] Following the connection order of the verification nodes in the circular verification path, the business scenario tests corresponding to each verification node are executed sequentially in the isolated test environment. Response time, error rate, and resource consumption metrics for each verification node are collected during the test process, forming a complete path execution data sequence. Specifically, this includes: before testing, binding nodes, scenarios, and parameters to ensure the business relevance between the test scenario and the configuration node; each verification node corresponds to the core business scenario of its service, i.e., the database connection configuration node is bound to the high-frequency order query scenario, which needs to simulate the product inventory verification operation before a user places an order; the cache service configuration node is bound to the hot-selling product cache read scenario, focusing on high-traffic periods during promotions. The test involves: acquiring product data; configuring external interface nodes to bind payment result callback reception scenarios, replicating the response data format of third-party payment platforms; strictly aligning scenario details with peak production environment characteristics, setting concurrency to 80% of peak production levels (to avoid resource bottlenecks in the test environment); using production-de-identified data for request parameters, such as order numbers prefixed with ORD2025 followed by a random 6-digit number; configuring interface call intervals based on an average of 1.5 seconds according to production log statistics; and adhering to the rule of sequential node execution and starting the next node only after data archiving, ensuring that the test script for the next node is triggered only after all test data from the previous node has been completely written to the database, thus preventing CPU and memory resource conflicts between nodes. Distortion of metrics caused by contention; metric collection adopts a real-time capture tool and periodic algorithm purification mode, clearly defining the measurement unit and collection logic for each metric. Specifically, the request latency statistics component of the interface performance testing tool captures the raw latency of each request. Data purification is triggered every 10 consecutive requests. During purification, the maximum and minimum latency values ​​are first removed to eliminate interference from accidental factors such as network jitter and instantaneous resource usage peaks. Then, the average of the remaining 8 latency values ​​is calculated using the formula: Average response time = (Total latency of 10 requests - Maximum latency - Minimum latency) ÷ 8. The result is rounded to one decimal place, and the unit of measurement is uniformly milliseconds. Error rate and response time are statistically analyzed using the same 10-request period. The number of erroneous requests is counted by combining the status codes returned by the interface (200 series status codes indicate success, 4xx and 5xx series status codes indicate errors) with business error codes (e.g., code 2001 represents database connection failure). The specific calculation formula is: Error rate = (number of erroneous requests ÷ 10) × 100%. The calculation result is rounded to two decimal places and the unit of measurement is percentage. Errors are also categorized by type into three categories: connection timeout (request time exceeds 5 seconds), parameter anomaly (missing required fields or incorrect field format), and logical error (request data does not meet business rule requirements).

[0064] Resource consumption data is collected from the services of the nodes using system monitoring tools. Different operating systems employ different collection methods. Linux uses the built-in task management commands to capture CPU and memory usage in real time, and uses input / output statistics commands to collect disk I / O rates. Windows obtains the corresponding metrics through the Performance Monitor application interface. CPU and memory usage are measured as percentages, and disk I / O rates are measured in megabytes per second. The collection cycle is 5 seconds per instance, with each node tested for 5 minutes, for a total of 60 data collections. The arithmetic mean of 60 data points is taken as the resource metric for that node. The formula is: Average resource utilization rate = (sum of real-time utilization rates in 60 data points) ÷ 60. CPU and memory utilization rates are in percentage (%), and disk I / O rate is in MB / s. All results are rounded to two decimal places. All metrics are organized in a structured format according to node number, test start timestamp (accurate to milliseconds), average response time (milliseconds), error rate (%), CPU utilization rate (%), memory utilization rate (%), and disk I / O (MB / s) to form an ordered path execution data sequence. Each node corresponds to a unique data set to ensure that the data is traceable to the specific test stage.

[0065] Execution performance curves are generated based on path execution data sequences, and discrete curvature calculations are performed on the execution performance curves to identify curvature abrupt change points. Specifically, based on time-series data and performance indicator data from the path execution data sequences, execution performance curves in a two-dimensional coordinate system are generated. This includes: to address performance evaluation biases caused by differences in the units of measurement of different indicators, a standardized two-dimensional coordinate system needs to be constructed first. Before this, the indicator collection process requires a combination of real-time tool capture and periodic algorithm refinement, clearly defining the measurement units and collection logic for each indicator. Response time collection uses the request time statistics module of the interface performance testing tool to capture the raw time of each business request, measured in milliseconds. A data refinement process is triggered every 10 consecutive requests, during which the maximum time and the maximum time of one request are removed. The minimum time is used to eliminate interference from accidental factors such as network jitter and instantaneous resource usage peaks. Then, the average time of the remaining 8 requests is calculated. The specific calculation formula is: Average response time = (Total time of 10 requests - Maximum time - Minimum time) ÷ 8. The calculation result is rounded to one decimal place, and the final unit of measurement is uniformly milliseconds. The error rate and response time adopt the same statistical period of 10 requests. That is, through the status code returned by the interface (200 series status codes represent successful requests, and status codes starting with 4 and 5 series status codes represent requests that fail), combined with the error codes defined by the business system (such as code 2001 representing database connection failure), the number of erroneous requests in this period is counted. The specific calculation formula is: Error rate = (Number of erroneous requests ÷ 10) × 100%. The calculation result is rounded to two decimal places, and the unit of measurement is percentage. Errors are categorized and labeled according to type, specifically into three categories: connection timeout (request takes more than 5 seconds), parameter anomaly (request lacks required fields or the field format is incorrect), and logical error (request data does not meet business rule requirements). Resource consumption is collected by system monitoring tools to gather resource usage data of the service to which the verification node belongs. Different operating systems use corresponding tools and methods. Linux operating systems use the system's built-in task management commands to capture the CPU and memory usage in real time, and use input / output statistics commands to collect disk input / output rates. Windows operating systems obtain the corresponding indicator data through the performance monitor application interface. The CPU and memory usage are measured in percentages, and the disk input / output rate is measured in megabytes per second.

[0066] After completing the indicator collection, the coordinate system construction and indicator normalization process can begin. The specific process is as follows: Based on the test data of the health configuration over the past 6 months, the health range of each indicator is determined (exceeding the range indicates performance abnormality). A linear mapping method is used to convert the original indicator values ​​into positive scores of 0 to 100 (the higher the score, the better the indicator performance), ensuring that indicators with different dimensions are converted into a unified score. The specific rules and calculations are as follows: Response time (positive indicator: the smaller the value, the better), health range 50 milliseconds to 500 milliseconds, normalization formula is: Score = (maximum value of health range - current indicator value) ÷ (maximum value of health range - minimum value of health range) × 100. In this formula, both the numerator and denominator are milliseconds, and the dimensionless score is obtained after dimension cancellation; Error rate (negative indicator: the smaller the value, the better), health range 0% to 5%, first calculate the negative score and then convert it to a positive score, formula is: Negative score = (current indicator value - minimum value of health range) ÷ (maximum value of health range - minimum value of health range) × 100, positive score = 100 - negative score. Both numerator and denominator are %, and their dimensions are offset. Resource consumption (negative indicator: the smaller the value, the better) is calculated as follows: CPU health range 10% to 60%, memory 15% to 70%, and disk I / O 5MB / s to 40MB / s. Each indicator is calculated separately according to the error rate normalization rule, and the arithmetic mean of the three is taken as the comprehensive resource consumption score, ensuring that the three resource indicators have equal weight. The indicator weights are set in combination with the business impact: response time weight 0.4 (directly affecting user experience), error rate weight 0.3 (related to business correctness), and comprehensive resource consumption score weight 0.3 (determining service stability). The weights are summed to 1. The calculation formula is: Comprehensive performance score = response time score × 0.4 + error rate score × 0.3 + comprehensive resource consumption score × 0.3. The result is rounded to two decimal places and the dimension is unified as points. The test timing scale of each node minus the comprehensive performance score is used as a two-dimensional coordinate point. B-spline interpolation is used to connect all points to generate a smooth and continuous execution performance curve. The rise and fall of the curve intuitively reflect the performance changes of each node.

[0067] Discrete sampling is performed on the performance curve to obtain a set of discrete data points uniformly distributed on the curve. The curvature value of each data point in the set of discrete data points is calculated to form a curvature value distribution sequence. Specifically, the discrete sampling is based on the principle of uniformly covering the curve and accurately capturing fluctuations. The number of samples is consistent with the total number of verification nodes N to ensure that each node corresponds to a core sampling point and avoid sampling redundancy or omission. In specific operation, first calculate the total span of the horizontal axis = total number of nodes - 1 (e.g., 8 nodes correspond to a span of 7), and then determine the sampling interval = total span ÷ N (interval for 8 nodes = 7 ÷ 8 = 0.875). Starting from the horizontal axis scale 1, sampling positions are selected sequentially according to the interval. The horizontal coordinate of the i-th sampling point = 1 + (i - 1) × interval. The vertical coordinate (comprehensive performance score) corresponding to the horizontal coordinate is looked up through the curve equation to obtain the coordinates of the sampling point. , For example, the x-coordinate of the 3rd sampling point of 8 nodes is 1 + (3 - 1) × 0.875 = 2.75. Looking up the curve equation, we find that when x = 2.75, y = 72.3. Therefore, the coordinates of this sampling point are (2.75, 72.3). The curvature value is calculated using a three-point approximation model, reflecting the curvature degree through the slope change of three adjacent points (the more severe the curvature, the larger the curvature value, representing a more significant performance change). The reference point is selected based on the i-th sampling point. Taking the core as the sample point, the preceding sampling points are taken. and subsequent sampling points When constructing curve segments, if the first and last sampling points lack reference points, the coordinates of adjacent nodes are used to fill in the gaps; slope calculation is performed by first calculating... Duan He The slope of the segment is given by the formula k1 = ( - ) ÷ ( - k2=( - ) ÷ ( - The slope is calculated as minutes / node number, but the dimensions cancel each other out when calculating the change. The curvature value is calculated by first calculating the slope change Δk = |k2-k1| (taking the absolute value to eliminate directional influence), then calculating the total horizontal distance Δx between the three points. - The final curvature value is calculated as Δk ÷ Δx, and the result is rounded to four decimal places. The curvature values ​​are calculated sequentially according to the sampling point numbering, and the results are organized into a structured sequence of sampling point number, node number, and curvature value, which is the curvature value distribution sequence.

[0068] This analysis examines the curvature changes of consecutive data points in the curvature value distribution sequence, identifies curvature abrupt changes where the curvature change exceeds a preset threshold, and records the position coordinates and magnitude of these abrupt changes on the performance curve. Specifically, the core of curvature abrupt change judgment is that the curvature change exceeds a preset threshold. This threshold is dynamically calculated based on historical health data to avoid misjudgments or omissions caused by fixed thresholds. The preset threshold is calculated by extracting 50 valid performance curves from healthy configurations (no performance failures after deployment) within the past 3 months, calculating the average μ and standard deviation σ of the curvature change magnitude of consecutive sampling points in each curve, and setting the threshold to μ + 2σ (in statistics, 2σ covers 95% of normal data; exceeding this range indicates an anomaly). The analysis then iterates through the curvature value distribution sequence, calculating the curvature change magnitude of two consecutive sampling points... The rate change amplitude is calculated using the formula: Change Amplitude = |Curvature Value of Current Sampling Point - Curvature Value of Previous Sampling Point|. If the change amplitude is greater than the threshold, the current sampling point is considered a curvature abrupt change point. After identifying the abrupt change point, three types of core information are recorded: First, the curve position coordinates (test time series scale - comprehensive performance score), such as (3.625, 68.5); second, the abrupt change characteristic data (curvature value, change amplitude, and abnormal indicators), such as a curvature value of 1.2, a change amplitude of 0.9, and an abnormal indicator of a sudden increase in response time; third, the associated business information (node ​​number, business scenario, and core configuration parameters), such as node 3, the scenario being high-frequency order query, and the parameter being the database connection pool size. If two or more consecutive sampling points are abrupt change points, they are merged into a change interval, and the start and end coordinates of the interval are recorded.

[0069] Based on the location coordinates and magnitude of curvature inflection points, combined with the preset importance weights for each business scenario, key inflection points affecting configuration are determined. Specifically, curvature inflection points only reflect the severity of performance fluctuations; therefore, key inflection points with large performance fluctuations and high business impact need to be selected based on business importance to ensure that configuration optimization focuses on core businesses. First, a dynamically updated business scenario-weight mapping library is established, with weights tiered according to business value. Core businesses (transaction payment, order creation) have a weight of 0.8; anomalies in these businesses directly lead to revenue losses. Important businesses (inventory query, logistics synchronization) have a weight of 0.5; anomalies affect the smoothness of business processes. General business operations (log statistics, data backup) have a weight of 0.2, and anomalies have no impact on core processes. The mapping library is bound to the verification node, and each node is associated with the weight value of its scenario by default. The configuration impact is calculated as the curvature change amplitude × the business scenario weight value. Both are dimensionless data, which comprehensively reflect the technical severity and business impact of performance mutations. All mutation points are sorted in descending order of configuration impact, and the top 30% of mutation points are selected as key turning points. If a mutation point is associated with multiple business scenarios, such as cross-service interaction nodes involving both inventory query and order creation, the highest weight value of the associated scenario is used in the calculation to ensure that mutation points of core businesses are not missed.

[0070] Based on the location distribution characteristics and magnitude of change of key inflection points, configuration adjustment parameters are generated, including specific optimization directions and clear adjustment values. Specifically, this includes: identifying the root cause based on the characteristics of key inflection points and generating actionable configuration adjustment parameters. That is, combining the inflection point's abnormal metrics and associated configuration parameters to pinpoint the root cause of performance issues. If the abnormality is a sudden increase in response time with normal CPU utilization, and the associated parameter is the database connection pool size, the root cause is insufficient connection pool leading to request queuing. If the abnormality is a sudden increase in error rate with normal response time, and the associated parameter is the interface authentication key, the root cause is key expiration leading to authentication failure. The core configuration parameters of the node to which the inflection point belongs are queried through the parameter-scenario association table in the configuration center. Excluding irrelevant parameters, such as log level parameters which do not affect response time, we narrow down the optimization to 1-2 target parameters. We then use the magnitude of change matching method to calculate the adjustment value. The core logic is to establish a quantitative correlation between parameter adjustment magnitude and performance improvement effect through historical data, and to infer the required adjustment amount based on the overall performance score decrease. The specific calculation process is illustrated below with an example (target parameter is the database connection pool size): First, calculate the magnitude of the overall performance score decrease. This involves selecting the previous stable performance node as the benchmark node (ensuring the benchmark data is free from abnormal interference). The difference between the benchmark node and the overall performance score at the turning point quantifies the degree of performance degradation. The formula is: Performance Decrease = |Turning Point Overall Performance Score|| Score - Baseline Node Overall Performance Score | ÷ Baseline Node Overall Performance Score × 100%; The second step is to extract historical adjustment data and calculate adjustment coefficients. Extract the past 6 months of historical records of the target parameters to be optimized (such as database connection pool size) from the configuration adjustment log library. Filter out valid records that show a clear performance improvement after adjustment and have no new anomalies. Valid records refer to adjustment records that meet three criteria: First, business scenario matching—the business scenario corresponding to the record is consistent with the business scenario of the current turning point (e.g., both are high-frequency order query scenarios); second, clear performance effect—the overall performance score improvement after adjustment is ≥5% (excluding minor fluctuations), and the improvement effect is stable and lasts for more than 1 hour (excluding instantaneous improvements); third... No derivative anomalies were observed, and the adjustments did not trigger new performance issues (such as no memory overflow or database deadlock after connection pool adjustments). Valid records must include the following core fields: adjustment time, parameter values ​​before adjustment, parameter values ​​after adjustment, overall performance score before and after adjustment, and related business scenario. An adjustment coefficient is calculated based on the valid records, which is the performance improvement corresponding to a unit parameter adjustment. The formula is: Adjustment coefficient = Historical performance improvement ÷ Number of historical parameter adjustment units. For example, if the selected valid records show that for every 10 units increase in the database connection pool size, the overall performance score improves by 15%, then the adjustment coefficient = 15% ÷ 10 = 1.5% / unit, meaning that for every 1 unit adjustment in the connection pool size, the overall performance score changes by 1.5%; The third step is to calculate the parameter adjustment range. Divide the decrease in the overall performance score by the adjustment coefficient to obtain the number of parameter adjustment units required to restore performance. The formula is: Adjustment range = Performance decrease ÷ Adjustment coefficient. For example, the adjustment range is 27. The fourth step is to determine the final adjustment value. Combine the root cause to determine the adjustment direction (increase if the root cause is insufficient parameters, decrease if the root cause is excessive parameters). Add / subtract the adjustment range from the current parameter value to obtain the final adjustment value. For example, if the current value of the connection pool is 50, and the root cause is insufficient connection pool, the final adjustment value is 50 + 27 = 77. The final configuration adjustment parameters include three core parts: First, the target configuration item identifier (service name - configuration category - parameter name), such as order service - database - connection pool size; Second, adjustment details (current value, adjusted value, optimization direction), such as current 50, adjusted value 77, optimization direction increase; Third, adjustment basis (turning point coordinates, configuration impact, performance decrease), such as turning point (3.625, 68.5), configuration impact 0.72, performance decrease 40%, ensuring that the adjustment operation is traceable and verifiable. .

[0071] This embodiment captures abrupt changes in performance curves through curvature analysis and filters key inflection points by combining business weights. It focuses configuration optimization on critical parameters affecting core business operations, resolving issues of vague performance anomaly localization and untargeted optimization during testing. It calculates adjustment values ​​based on quantified indicator data, replacing optimization methods reliant on manual experience. This provides clear data support for configuration adjustments, offering specific optimization directions and values, reducing the operational difficulty for operations personnel. It incorporates the importance weight of business scenarios into inflection point determination, ensuring that configuration optimization prioritizes core business stability. This ensures a high degree of alignment between technical configuration adjustments and business value requirements, avoiding a disconnect between technical optimization and business needs. From indicator collection and curve generation to parameter output, data at each stage is interconnected and traceable, providing a basis for this configuration optimization. By identifying key inflection points affecting configuration, it optimizes parameters that may cause performance issues in advance, preventing core business anomalies after configuration changes are released, and providing pre-emptive configuration-level protection for the stable operation of the microservice architecture.

[0072] In a preferred embodiment of the present invention, based on configuration adjustment parameters, the new parameter values ​​are optimized and corrected. When the corrected parameters pass the final health check, the deployment to the corresponding microservice is completed; otherwise, the deployment process is blocked and reverted to a historical healthy version, including:

[0073] Based on the specific optimization direction and explicit adjustment values ​​contained in the configuration adjustment parameters, the new parameter values ​​of the target configuration items are corrected item by item to obtain the corrected parameter values. Specifically, this includes: first, performing structured parsing of the configuration adjustment parameters to extract the core information of each target configuration item to be optimized, including the target configuration item identifier (service name - configuration category - parameter name), current value, adjusted value, optimization direction, and adjustment basis, ensuring that the parsed information is complete and unambiguous; then, initiating the item-by-item correction process, based on the target configuration item identifier, locating the target configuration item storage path of the corresponding microservice through the service configuration index in the configuration center. For example, the database connection pool size parameter storage path for the order service is order service / database configuration / connection pool maximum number of connections. Parameter correction is performed according to the optimization direction. If the optimization direction is to increase, the current value of the target configuration item is replaced with the adjusted value (e.g., the current value of 50 is replaced with 77); if the optimization direction is to increase, the current value of the target configuration item is replaced with the adjusted value. To reduce the timeout, update the value according to the adjusted value, such as changing the interface timeout from 60 seconds to 45 seconds. If the optimization direction is to update (applicable to non-numerical parameters such as authentication keys), directly replace it with the new valid parameter value. During the correction process, special processing must be performed for parameter types. That is, integer parameters (such as connection pool size) must be ensured to have an integer value after correction, floating-point parameters (such as cache invalidation probability) must retain a preset number of decimal places (default 2 digits), and character parameters (such as keys) must be ensured to conform to the character encoding requirements of the configuration center, such as UTF-8. After each parameter correction is completed, a correction log is recorded immediately. The log content includes the correction time, operator, target configuration item identifier, value before correction, value after correction, and adjustment basis, forming a complete correction traceability chain. After all target configuration items are corrected, a parameter correction list is generated. The list includes the correction status (success / failure) of each configuration, the comparison before and after correction, and anomaly description (if any), to ensure that the correction results are verifiable.

[0074] The corrected parameter values ​​undergo format specification validation and business rule consistency verification. A final health check is then performed on the corrected parameter values ​​in an isolated test environment. This final health check includes load stress testing, abnormal scenario testing, and data consistency testing. When all tests in the final health check pass verification, the corrected parameter values ​​are published to the corresponding microservice configuration center. If any test in the final health check fails verification, the publication process is immediately halted, and the system automatically reverts to the previous verified healthy version stored in the configuration center. Specifically, this includes:

[0075] For each corrected parameter, a format specification check is performed. Type check verifies that the parameter type matches the default type in the configuration center; for example, integer parameters cannot be decimals or characters. Value range check requires numeric parameters to be within a preset reasonable range; for example, the reasonable range for database connection pool size is 10 to 200, and the corrected value 77 must meet this range requirement. Character parameters must meet length limits; for example, the interface key length is 32 bits, and the corrected value must strictly match. Format check requires date parameters to conform to the year-month-day hour:minute:second format, and IP address parameters to conform to IPv4 or IPv6 format, ensuring that the parameter format can be correctly parsed by the microservice. If a check fails, the parameter is immediately marked as failed, and the reason for failure is recorded. For example, if the connection pool size 777 exceeds the reasonable range of 10 to 200, subsequent processes are suspended, and manual review is triggered.

[0076] Perform business logic consistency verification on the corrected parameters and associated configuration parameters. Verify that the corrected parameters do not conflict with other core configuration parameters of the microservice. For example, after correcting the database connection pool size, ensure that it matches the maximum number of database connections to avoid exceeding the database's capacity. Verify the adaptability of parameters to business scenarios. For example, after correcting the payment timeout time of the order service, ensure that it is coordinated with the response timeout time of the payment service to avoid business process bottlenecks. After the consistency verification passes, generate a verification report. If there are conflicts or adaptability issues, mark it as a consistency verification failure and clarify the relationship between conflicting parameters. For example, if the connection pool size of 77 exceeds the maximum number of database connections of 50, proceed to the parameter adjustment and re-evaluation process.

[0077] In the isolated test environment, three core tests are executed according to preset standards. The load stress test simulates the concurrent request volume during peak production hours (set at 1.2 times the peak production concurrency) for 30 minutes, collecting microservice response time, error rate, and resource consumption indicators (CPU, memory, disk I / O) to ensure that the indicators are within healthy ranges, such as response time ≤ 500 milliseconds and error rate ≤ 1%. The abnormal scenario test simulates abnormal scenarios such as network interruption, data loss, and unavailability of dependent services, such as database connection interruption and external interface timeout, to test the fault tolerance capability of the microservice under the corrected parameters, ensuring that the service does not crash, data is not lost, and the abnormal recovery time is within the preset threshold (such as service returning to normal within 10 seconds after network recovery). The data consistency test compares the business data before and after the execution of the corrected parameters, such as order creation and payment settlement data, to ensure the consistency of data generation, storage, and query, such as consistent order amount calculation results, accurate payment status synchronization, and no data corruption or loss.

[0078] If all tests for format specification verification, business rule consistency verification, and final health verification pass, the automatic release process is triggered: the corrected parameter values ​​are synchronized to the corresponding microservice configuration center, overwriting the original parameter values, and the parameter version number in the configuration center is updated (the version number increments in the format of major version number, minor version number, and correction version number, such as V1.2.5 updated to V1.2.6). At the same time, a configuration update notification is released to the relevant operations and development personnel. If any of the above tests fail, the release process is immediately blocked, and the parameter rollback mechanism is automatically triggered. The parameter value of the target configuration item is restored to the previous verified healthy version stored in the configuration center (traceable by version number, such as rolling back to V1.2.4), and a rollback log is generated, including the rollback time, triggering reason, and parameter values ​​before and after the rollback. At the same time, an anomaly alarm is sent to notify relevant personnel to investigate the reason for the failure. If the response time exceeds the standard during load stress testing, the parameter value needs to be readjusted. After the problem is resolved, the correction and verification process is restarted.

[0079] This embodiment improves the reliability of configuration adjustments by using structured parsing, specialized type processing, and format validation to avoid microservice malfunctions caused by incorrect parameter corrections or non-standard formats. Business rule consistency verification ensures that the corrected parameters are highly matched with associated configurations and business scenarios, preventing business process interruptions or functional failures caused by parameter conflicts. Finally, health checks simulate production environment scenarios to proactively identify potential performance bottlenecks and insufficient fault tolerance caused by parameter adjustments, reducing online failures after configuration release. Correction logs, verification reports, and version management mechanisms make the entire configuration adjustment process traceable. The automatic rollback function quickly restores a healthy configuration when verification fails, reducing the scope and duration of the failure's impact. The streamlined process from parameter correction and verification to release / rollback reduces manual intervention, improves the efficiency of configuration updates, and ensures that each operation conforms to specifications, guaranteeing the stable operation of the microservice architecture.

[0080] like Figure 2 As shown, embodiments of the present invention also provide a configuration health check management method based on dynamic detection, including:

[0081] Step 1: Receive the update request for the target configuration item in the configuration center and extract the new parameter value of the configuration item;

[0082] Step 2 is used to dynamically construct an isolated test environment based on the new parameter values, load the new parameter values ​​into the isolated test environment, execute a predefined basic health probe set, and obtain preliminary verification results;

[0083] Step 3: When the initial verification result is passed, based on the dependency topology between microservices, parse the configuration item group that is indirectly related to the target configuration item and generate a set of related configuration item groups;

[0084] Step 4: Based on the set of associated configuration items, construct a virtual configuration topology space, and select three key configuration nodes in the virtual configuration topology space to determine the circular detection area; based on the circular detection area, select four verification nodes located on the circumference and two verification nodes located outside the circle, and construct the external detection boundary by calculating the tangents from the outside nodes to the circle to form a circular verification path;

[0085] Step 5: Based on the circular verification path, perform business flow simulation detection in the isolated test environment to obtain path execution data, and identify key turning points by analyzing the curvature change features in the path execution data to generate configuration adjustment parameters;

[0086] Step 6: Adjust the parameters based on the configuration, optimize and correct the new parameter values. When the corrected parameters pass the final health check, complete the release to the corresponding microservice; otherwise, block the release process and revert to the historical healthy version.

[0087] It should be noted that this method is the same as the method described above for the system. All implementation methods in the above system embodiments are applicable to this embodiment and can achieve the same technical effect.

[0088] Embodiments of the present invention also provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the system as described above. All implementations in the above system embodiments are applicable to this embodiment and can achieve the same technical effects.

[0089] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A configuration-based health check management system based on dynamic detection, characterized in that, include: The extraction module is used to receive update requests for target configuration items in the configuration center and extract the new parameter values ​​of the configuration items. The verification module is used to dynamically build an isolated test environment based on new parameter values, load the new parameter values ​​into the isolated test environment, execute a predefined set of basic health probes, and obtain preliminary verification results. The parsing module is used to parse the configuration item group that is indirectly related to the target configuration item based on the dependency topology relationship between microservices when the initial verification result is passed, and generate a set of associated configuration item groups. The calculation module is used to construct a virtual configuration topology space based on the set of associated configuration items, and select three key configuration nodes in the virtual configuration topology space to determine a circular detection area; based on the circular detection area, four verification nodes are selected on the circumference and two verification nodes are located in the outer area of ​​the circle. The external detection boundary is constructed by calculating the tangents from the outer nodes to the circle, forming a circular verification path. The identification module is used to perform business flow simulation detection in an isolated test environment based on the circular verification path, obtain path execution data, and identify key turning points by analyzing the curvature change features in the path execution data, and generate configuration adjustment parameters. The optimization module is used to adjust parameters based on configuration, optimize and correct new parameter values, and publish to the corresponding microservice when the corrected parameters pass the final health check. Otherwise, halt the release process and revert to a previous healthy version.

2. The configuration health check management system based on dynamic detection according to claim 1, characterized in that, Receive update requests for target configuration items from the configuration center and extract the new parameter values ​​for the configuration items, including: Receive configuration change notifications pushed by the configuration center, parse the configuration change notifications to obtain the identification information of the target configuration item; Based on the identification information, the corresponding new parameter values ​​are extracted from the storage component of the configuration center.

3. The configuration health check management system based on dynamic detection according to claim 2, characterized in that, Based on the new parameter values, an isolated test environment is dynamically constructed and loaded into it. A predefined set of basic health probes is then executed to obtain preliminary validation results, including: Create independent test container instances based on the configuration type and associated service characteristics of the new parameter values; Deploy the same version of the runtime framework and dependent components as the production environment in the test container instance, inject the new parameter values ​​into the configuration management layer of the runtime framework, and complete the runtime environment initialization; The network connectivity verification, identity authentication verification, and basic function operation test are performed sequentially. The network connectivity verification includes port reachability detection of the target service, the identity authentication verification includes verification of credential validity and permission scope, and the basic function operation test includes calling and parsing the core interface. Record response latency, success rate, and error type metrics during the testing process, and generate preliminary verification results including pass and fail statuses.

4. The configuration health check management system based on dynamic detection according to claim 3, characterized in that, When the initial validation result is passed, based on the dependency topology between microservices, the configuration item groups that are indirectly related to the target configuration item are parsed, and a set of related configuration item groups is generated, including: Obtain dependency connection information between microservices from the service registry, including service call relationships and data flow; Based on the service identifier to which the target configuration item belongs, identify the set of directly dependent services and the set of indirectly dependent services in the dependency connection information; Extract the key configuration items of all dependent services, including database connection configuration, cache service configuration, and external interface configuration; The dependency strength value of each configuration item is calculated based on the call frequency and data transfer volume. The configuration items are then prioritized according to their dependency strength values ​​to generate a set of associated configuration item groups with weight identifiers.

5. The configuration health check management system based on dynamic detection according to claim 4, characterized in that, Based on the set of associated configuration items, a virtual configuration topology space is constructed, and three key configuration nodes are selected in the virtual configuration topology space to determine a circular detection region. Based on the circular detection region, four verification nodes are selected located on the circumference, and two verification nodes are located outside the circle. The external detection boundary is constructed by calculating the tangents from the outside nodes to the circle, forming a circular verification path, including: Based on the dependency strength value and connection relationship of each configuration item in the associated configuration item group set, a three-dimensional virtual configuration topology space is established, and each configuration item is mapped to the corresponding position in the spatial coordinate system according to the dependency strength value to obtain the mapped configuration item. Select the three configuration nodes with the highest dependency strength values ​​from the mapped configuration items as standard points. Calculate the center coordinates and radius of the circumcircle based on the spatial coordinates of the three standard points to determine the circular detection area. Four circumferential verification nodes are selected on the circumference of the circular detection area according to four azimuth angles of 0 degrees, 90 degrees, 180 degrees and 270 degrees; the first outer verification node is selected by extending twice the radius in the positive direction of the X-axis based on the center coordinate of the circular detection area, and the second outer verification node is selected by extending twice the radius in the negative direction of the Y-axis. Based on the center coordinates and radius of the circular detection region, two sets of tangent equations from the two outer verification nodes to the circular detection region are calculated, and the outer detection boundary region is constructed according to the tangent equations. Based on the spatial distribution of the circumferential and outer verification nodes, and in accordance with the test execution timing requirements, all verification nodes are sequentially connected to form a complete circular verification path.

6. The configuration health check management system based on dynamic detection according to claim 5, characterized in that, Based on the circular verification path, business flow simulation testing is performed in an isolated test environment to obtain path execution data. Key inflection points are identified by analyzing the curvature change characteristics in the path execution data, and configuration adjustment parameters are generated, including: Following the connection order of the verification nodes in the circular verification path, the business scenario tests corresponding to each verification node are executed sequentially in the isolated test environment, and the response time, error rate and resource consumption indicators of each verification node during the test process are collected to form a complete path execution data sequence. Execution performance curves are generated based on path execution data sequences, and discrete curvature calculations are performed on the execution performance curves to identify curvature abrupt change points in the execution performance curves. Based on the location coordinates and change magnitude of the curvature abrupt change point, combined with the preset importance weight values ​​for each business scenario, the key turning points of configuration impact are determined. Based on the location distribution characteristics and change magnitude of key inflection points, configuration adjustment parameters are generated, which include specific parameter optimization directions and clear adjustment values.

7. The configuration health check management system based on dynamic detection according to claim 6, characterized in that, Execution performance curves are generated based on path execution data sequences, and discrete curvature calculations are performed on the execution performance curves to identify curvature abrupt change points, including: Based on the time series data and performance index data in the path execution data sequence, an execution performance curve in a two-dimensional coordinate system is generated. Discrete sampling is performed on the performance curve to obtain a set of discrete data points uniformly distributed on the curve, and the curvature value of each data point in the set of discrete data points is calculated to form a curvature value distribution sequence. Analyze the curvature changes of continuous data points in the curvature value distribution sequence, identify curvature abrupt change points where the curvature change amplitude exceeds a preset threshold, and record the position coordinates and change amplitude values ​​of the curvature abrupt change points in the performance curve.

8. The configuration health check management system based on dynamic detection according to claim 7, characterized in that, Based on the configuration adjustment parameters, the new parameter values ​​are optimized and corrected. When the corrected parameters pass the final health check, the deployment to the corresponding microservice is completed. Otherwise, halt the release process and revert to a previous healthy version, including: Based on the specific parameter optimization direction and clear adjustment values ​​contained in the configuration adjustment parameters, the new parameter values ​​of the target configuration items are corrected item by item to obtain the corrected parameter values. The corrected parameter values ​​are validated for format specifications and business rule consistency. In the isolated test environment, a final health check is performed on the corrected parameter values. The final health check includes load stress testing, abnormal scenario testing, and data consistency testing. When all test items of the final health check pass the verification, the corrected parameter values ​​are published to the corresponding microservice configuration center. When any test item of the final health check fails the verification, the publication process is immediately blocked, and the system automatically reverts to the previous verified healthy version stored in the configuration center.

9. A configuration health check management method based on dynamic detection, wherein the method implements the system as described in any one of claims 1 to 8, characterized in that, include: Step 1: Receive the update request for the target configuration item in the configuration center and extract the new parameter value of the configuration item; Step 2 is used to dynamically construct an isolated test environment based on the new parameter values, load the new parameter values ​​into the isolated test environment, execute a predefined basic health probe set, and obtain preliminary verification results; Step 3: When the initial verification result is passed, based on the dependency topology between microservices, parse the configuration item group that is indirectly related to the target configuration item and generate a set of related configuration item groups; Step 4: Based on the set of associated configuration items, construct a virtual configuration topology space, and select three key configuration nodes in the virtual configuration topology space to determine the circular detection area; based on the circular detection area, select four verification nodes located on the circumference and two verification nodes located outside the circle, and construct the external detection boundary by calculating the tangents from the outside nodes to the circle to form a circular verification path; Step 5: Based on the circular verification path, perform business flow simulation detection in the isolated test environment to obtain path execution data, and identify key turning points by analyzing the curvature change features in the path execution data to generate configuration adjustment parameters; Step 6: Adjust the parameters based on the configuration, optimize and correct the new parameter values, and when the corrected parameters pass the final health check, complete the deployment to the corresponding microservice. Otherwise, halt the release process and revert to a previous healthy version.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when executed by a processor, implements the system as described in any one of claims 1 to 8.

Images