Cloud-native intelligent identification and verification system and method for batch maintenance data

Abstract

This invention belongs to the field of operation and maintenance management technology, specifically disclosing a cloud-native intelligent identification and verification system and method for batch maintenance data. Through one-click import and multi-threaded concurrent processing of maintenance data, it enables batch identification and verification of service data, improving the efficiency of maintenance data verification. Automatic verification by calling cluster microservice information ensures the accuracy of maintenance data. Automatic identification of SQL script information based on folder structure rules avoids manual matching errors and improves script execution accuracy. Based on thread pool management and asynchronous processing technology, it supports efficient concurrent execution of maintenance tasks, optimizing user experience. This invention solves the bottlenecks of existing technologies in maintenance efficiency, data verification, SQL script identification, and concurrent processing, achieving intelligent import, automatic verification, batch identification, and efficient concurrent execution of maintenance data, thus improving the automation level and execution efficiency of operation and maintenance operations.

Description

Technical Field

[0001] This invention belongs to the field of operation and maintenance management technology, specifically involving a cloud-native intelligent identification and verification system and method for batch maintenance data. Background Technology

[0002] Traditional DevOps maintenance and repair work requires maintenance personnel to perform maintenance operations one by one from top to bottom according to the maintenance microservice table. Each maintenance requires manually confirming service information, executing scripts, and recording results. The whole process is tedious, time-consuming, and extremely inefficient. In addition, maintenance data relies on manual entry, which is prone to errors in information such as service names and version numbers, leading to maintenance failures or affecting system stability.

[0003] Existing operation and maintenance systems lack automatic verification of information such as the existence and version number of microservices in the cluster when importing maintenance data, making it impossible to detect data errors in a timely manner and posing maintenance risks. The SQL scripts involved in maintenance need to be executed in a specified database. Traditional methods require manual confirmation of the target database for each script, which is prone to script execution errors. In addition, traditional maintenance tools are mostly single-threaded serial processing, which takes a long time to import and verify maintenance data, and cannot meet the needs of rapid maintenance. Summary of the Invention

[0004] The purpose of this invention is to provide a cloud-native intelligent identification and verification system and method for batch maintenance data, in order to solve the above-mentioned problems existing in the prior art.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, this invention provides a cloud-native intelligent identification and verification system for batch maintenance data, comprising a front-end presentation layer, a back-end service layer, a concurrent execution engine, a cluster interface layer, a script recognition engine, and a data storage layer. The front-end presentation layer is used to import maintenance tables and / or SQL script folders, and transmit the imported maintenance tables and / or SQL script folders to the back-end service layer. The back-end service layer is used to parse the maintenance tables, extract data from each microservice, and convert each microservice data into a list of service data objects, and / or to generate script traversal tasks based on the SQL script folders. The concurrent execution engine is used to split the list of service data objects into multiple service batches according to a preset thread pool size, each service batch containing several microservice data, with each thread in its thread pool independently processing one service batch, and / or to split the script traversal task into multiple scripts according to a preset thread pool size. The system identifies script recognition tasks and assigns each script recognition task to a thread in its thread pool. Each thread in the thread pool is used to, when processing microservice data in a corresponding service batch, call the cluster interface layer to query the basic information of each microservice in the cluster resources, use the basic information of each microservice to verify the corresponding microservice data, obtain the verification result of the corresponding microservice data, and update the verification result of the corresponding microservice data to the data storage layer in real time. Alternatively, it can be used to call the script recognition engine to perform script recognition on some SQL script files contained in the SQL script folder according to the corresponding script recognition task, obtain the script recognition result of each SQL script file, and update the corresponding script recognition result to the data storage layer in real time. The backend service layer is used to summarize the verification results of each microservice data in the data storage layer and feed them back to the frontend presentation layer, and / or summarize the script recognition results of each script in the data storage layer and feed them back to the frontend presentation layer.

[0006] In one possible design, each thread in the thread pool is used to asynchronously process microservice data for the corresponding service batch, and / or asynchronously process script identification tasks for each SQL script file.

[0007] In one possible design, the front-end presentation layer is used to obtain the verification results of the aggregated microservice data and / or the aggregated script identification results from the back-end service layer via WebSocket or polling.

[0008] In one possible design, the front-end presentation layer is used to display the verification results of the aggregated microservice data and / or the identification results of the aggregated scripts in tabular form.

[0009] In one possible design, the microservice data includes the associated service name and service version number, and the basic information of each microservice includes the service name, service version number, and service status of each microservice.

[0010] In one possible design, the script recognition engine presets script folder structure rules and is used to recognize some SQL script files contained in the SQL script folder according to the script folder structure rules.

[0011] In one possible design, the script identification result includes script file information, which includes file name, database name, unit number, maintenance date, and file path.

[0012] Secondly, this invention provides a cloud-native method for intelligent identification and verification of batch maintenance data, applied to the system described in the first aspect, the method comprising: Import the inspection form through the front-end presentation layer and transmit the inspection form to the back-end service layer; The backend service layer parses the maintenance table, extracts data from each microservice, and converts the data from each microservice into a list of service data objects. The concurrent execution engine splits the list of service data objects into multiple service batches based on the preset thread pool size, with each service batch containing several microservice data. Each thread in the concurrent execution engine thread pool calls the cluster interface layer to query the basic information of each microservice in the cluster resources, and uses the basic information of each microservice to verify the corresponding microservice data, obtain the verification result of the corresponding microservice data, and update the verification result of the corresponding microservice data to the data storage layer in real time. The backend service layer aggregates the verification results of each microservice in the data storage layer and feeds them back to the frontend presentation layer for display.

[0013] In one possible design, the method further includes: Import the SQL script folder through the front-end presentation layer and then transfer the imported SQL script folder to the back-end service layer; The backend service layer parses the SQL script folder and generates corresponding script traversal tasks; The concurrent execution engine splits the script traversal task into multiple script recognition tasks according to the preset thread pool size, and assigns each script recognition task to a thread in its thread pool. Each thread in the concurrent execution engine thread pool calls the script recognition engine to perform script recognition on some of the SQL script files contained in the SQL script folder according to the corresponding script recognition task, obtains the script recognition results of each SQL script file, and updates the corresponding script recognition results to the data storage layer in real time. The backend service layer aggregates the recognition results of each script in the data storage layer and feeds them back to the frontend presentation layer for display.

[0014] In one possible design, the method further includes: The concurrent execution engine configures thread pool parameters in response to parameter configuration instructions from operations and maintenance personnel. These thread pool parameters include the number of threads, thread idle lifespan, and task queue capacity.

[0015] Beneficial Effects: This invention enables batch identification and verification of service data through one-click import and multi-threaded concurrent processing of maintenance data, improving the efficiency of maintenance data verification. Automatic verification by calling cluster microservice information ensures the accuracy of maintenance data. Automatic identification of SQL script information based on folder structure rules avoids manual matching errors and improves script execution accuracy. Thread pool management and asynchronous processing technology support efficient concurrent execution of maintenance tasks, optimizing user experience. This invention overcomes the bottlenecks of existing technologies in maintenance efficiency, data verification, SQL script identification, and concurrent processing, achieving intelligent import, automatic verification, batch identification, and efficient concurrent execution of maintenance data, thus improving the automation level and execution efficiency of operation and maintenance work. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of the system architecture of Example 1; Figure 2 This is a schematic diagram of the script folder structure in Example 1; Figure 3 This is a flowchart illustrating the first part of the method in Example 2; Figure 4 This is a flowchart illustrating the second part of the method in Example 2. Detailed Implementation

[0018] It should be noted that the descriptions of these embodiments are intended to aid in understanding the invention and do not constitute a limitation thereof. The specific structural and functional details disclosed herein are merely for describing exemplary embodiments of the invention. However, the invention may be embodied in many alternative forms and should not be construed as being limited to the embodiments described herein.

[0019] It should be understood that, unless otherwise explicitly specified and limited, the corresponding terms should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be an electrical connection, a direct connection, or an indirect connection through an intermediate medium; it can also refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in the embodiments according to the specific circumstances.

[0020] Specific details are provided in the following description to provide a complete understanding of the exemplary embodiments. However, those skilled in the art will understand that the exemplary embodiments can be implemented without these specific details. For example, the system may be shown in block diagrams to avoid obscuring the example with unnecessary details. In other embodiments, well-known processes, structures, and techniques may be shown without non-essential details to avoid obscuring the embodiments.

[0021] Example 1: This embodiment provides a cloud-native intelligent identification and verification system for batch maintenance data, such as... Figure 1 As shown, the system includes a front-end presentation layer, a back-end service layer, a concurrent execution engine, a cluster interface layer, a script recognition engine, and a data storage layer. The front-end presentation layer is used to import maintenance tables and / or SQL script folders, and then transmit the imported maintenance tables and / or SQL script folders to the back-end service layer. The back-end service layer is used to parse the maintenance tables, extract data from each microservice, and convert each microservice data into a list of service data objects, and / or to generate script traversal tasks based on the SQL script folders. The concurrent execution engine is used to split the list of service data objects into multiple service batches according to a preset thread pool size. Each service batch contains several microservice data, and each thread in its thread pool independently processes one service batch. It is also used to split the script traversal task into multiple script recognition tasks according to a preset thread pool size, and to transmit each script recognition task... The task is assigned to each thread in its thread pool; each thread in the thread pool is used to call the cluster interface layer to query the basic information of each microservice in the cluster resources when processing the microservice data of the corresponding service batch, use the basic information of each microservice to verify the corresponding microservice data, obtain the verification result of the corresponding microservice data, and update the verification result of the corresponding microservice data to the data storage layer in real time, and / or to call the script recognition engine to perform script recognition on some SQL script files contained in the SQL script folder according to the corresponding script recognition task, obtain the script recognition result of each SQL script file, and update the corresponding script recognition result to the data storage layer in real time; the backend service layer is used to summarize the verification result of each microservice data in the data storage layer and feed it back to the frontend display layer, and / or summarize the script recognition result of each script in the data storage layer and feed it back to the frontend display layer.

[0022] In practice, the system adopts a front-end and back-end separation architecture. The concurrent execution engine, cluster interface layer, script recognition engine and data storage layer can all be deployed on the back-end. The front-end presentation layer can use the Vue.js framework (a progressive front-end framework built on standard HTML, CSS and JavaScript), the back-end service layer can use the Spring + Spring Boot architecture, and its deployment environment can be based on Kubernetes or Docker containerization. The database (data storage layer) can use MySQL.

[0023] During maintenance data verification, the front-end presentation layer supports one-click import of maintenance tables (via Excel format file upload) and uploads the file to the back-end service layer via the FormData interface object. After receiving the file, the back-end service layer can use the Apache POI or EasyExcel library to parse the maintenance table, extract data for each microservice, including the associated service name, service version number, and cluster type, and convert the data for each microservice into a list of service data objects.

[0024] The concurrent execution engine is used to split the list of service data objects into multiple service batches based on a preset thread pool size. Each service batch contains several microservice data, and each thread in its thread pool independently processes one service batch. When processing the microservice data of the corresponding service batch, each thread in the thread pool calls the cluster interface layer (which supports adaptation to the Kubernetes cluster API, querying Deployment, Service, and other resources in the cluster by calling the Kubernetes API) to query the basic information of each microservice in the cluster resources (the basic information includes the service name, service version number, and service status of each microservice). Then, it uses the basic information of each microservice to verify the corresponding microservice data, obtains the verification result of the corresponding microservice data, and finally updates the verification result of the corresponding microservice data to the data storage layer in real time. The backend service layer can summarize the verification results of each microservice data in the data storage layer and feed them back to the frontend presentation layer.

[0025] For each microservice data, verify the following: 1. Does the microservice exist in the cluster (determined by matching with the service names of each microservice); 2. Does the service version number match the version number running in the cluster (determined by matching with the service version numbers of each microservice); 3. Is the service status "running" (determined based on the service status of the matched microservice). For cluster interface layer calls, rate limiting strategies can be used to avoid API call overload; semaphores can be used to control the number of concurrent requests; a maximum execution time should be set for each task, and it should terminate if the timeout occurs.

[0026] The front-end presentation layer can obtain the verification results of the aggregated microservice data from the back-end service layer via WebSocket or polling, and display the verification results of the aggregated microservice data in a table. The table columns may include service name, service version number, verification status (pass / fail), failure reason, verification time, etc. The verification status can be indicated by color, with green for pass and red for failure.

[0027] When performing SQL script recognition related to maintenance, the front-end presentation layer supports importing SQL script folders. The back-end service layer can generate script traversal tasks based on the SQL script folders. The concurrent execution engine can split the script traversal tasks into multiple script recognition tasks (each script recognition task includes the recognition and processing of SQL script files contained in some subfolders under the SQL script folder) according to the preset thread pool size, and assign each script recognition task to a thread in its thread pool. Each thread independently processes a part of the subfolders, and during processing, it calls the script recognition engine to perform script recognition on some SQL script files contained in the SQL script folder according to the corresponding script recognition task, obtains the script recognition results of each SQL script file, and updates the corresponding script recognition results to the data storage layer in real time.

[0028] The script recognition engine presets script folder structure rules and performs script recognition on some SQL script files contained in the SQL script folder according to these rules. For example... Figure 2 As shown, the script folder structure includes: the first layer is the maintenance date; the second layer is the database name; the third layer is the unit number; and the fourth layer is the SQL script file. The script recognition of the SQL script file can aggregate the recognition results of each script in the data storage layer and feed them back to the front-end presentation layer. The front-end presentation layer can obtain the aggregated script recognition results from the back-end service layer via WebSocket or polling.

[0029] The concurrent execution engine's thread pool can use Spring's `@Async` annotation or `CompletableFuture` to asynchronously process microservice data and / or script recognition tasks for each SQL script file in batches. Asynchronous task execution results are obtained through callbacks or `Future` mechanisms. Furthermore, the concurrent execution engine supports a progress bar displaying the verification and recognition progress of the corresponding tasks. A global thread pool is created during concurrent execution engine initialization. The thread pool configuration parameters can be set as follows: core thread count N. 核心 = Number of CPU cores × 2; Maximum number of threads N 最大 = Number of CPU cores × 4; Thread idle time T 空闲 =60 seconds; Task queue capacity Q capacity = 1000.

[0030] This system enables batch identification and verification of service data through one-click import and multi-threaded concurrent processing of maintenance data, improving the efficiency of maintenance data verification; it ensures the accuracy of maintenance data by calling cluster microservice information for automatic verification; it automatically identifies SQL script information based on folder structure rules, avoiding manual matching errors and improving script execution accuracy; and it supports efficient concurrent execution of maintenance tasks based on thread pool management and asynchronous processing technology, optimizing the user experience.

[0031] Example 2: This embodiment provides a cloud-native method for intelligent identification and verification of batch maintenance data, applied to the system in Embodiment 1, such as... Figure 3 As shown, the method includes the following steps: S101. Import the maintenance form through the front-end presentation layer and transmit the maintenance form to the back-end service layer. The front-end presentation layer supports one-click import of maintenance forms by users (upload via Excel format file) and uploads the file to the back-end service layer through the FormData interface object.

[0032] S102. The backend service layer parses the maintenance table, extracts data for each microservice, and converts this data into a list of service data objects. After receiving the file, the backend service layer can use the Apache POI or EasyExcel library to parse the maintenance table, extract data for each microservice, including the associated service name, service version number, and cluster type, and convert this data into a list of service data objects.

[0033] S103. The concurrent execution engine splits the service data object list into multiple service batches based on the preset thread pool size. Each service batch contains several microservice data. Each thread in the thread pool independently processes one service batch.

[0034] S104. Each thread in the concurrent execution engine thread pool calls the cluster interface layer to query the basic information of each microservice in the cluster resources, and uses the basic information of each microservice to verify the corresponding microservice data, obtaining the verification result of the corresponding microservice data, and updating the verification result of the corresponding microservice data to the data storage layer in real time. When processing the microservice data of the corresponding service batch, each thread in the concurrent execution engine thread pool can call the cluster interface layer (which supports adaptation to the Kubernetes cluster API, and queries the Deployment, Service, and other resources in the cluster by calling the Kubernetes API) to query the basic information of each microservice in the cluster resources (the basic information includes the service name, service version number, and service status of each microservice), and then use the basic information of each microservice to verify the corresponding microservice data, obtaining the verification result of the corresponding microservice data, and finally updating the verification result of the corresponding microservice data to the data storage layer in real time. For each microservice data, verify the following: 1. Whether the microservice exists in the cluster (determined by matching with the service name of each microservice); 2. Whether the service version number is consistent with the version number running in the cluster (determined by matching with the service version number of each microservice); 3. Whether the service status is running (determined based on the service status of the matched microservice).

[0035] S105. The backend service layer aggregates the verification results of each microservice data in the data storage layer and feeds them back to the frontend presentation layer for display. The backend service layer can aggregate the verification results of each microservice data in the data storage layer and feed them back to the frontend presentation layer. The frontend presentation layer can obtain the aggregated verification results of each microservice data from the backend service layer via WebSocket or polling and display the aggregated verification results of each microservice data in tabular form.

[0036] Furthermore, such as Figure 4 As shown, the method further includes: S201. Import the SQL script folder through the front-end presentation layer and transfer the imported SQL script folder to the back-end service layer.

[0037] S202. The backend service layer parses the SQL script folder and generates corresponding script traversal tasks. The backend service layer can generate script traversal tasks based on the SQL script folder (recursively traversing the SQL script folder; the first level of the SQL script folder is the maintenance date, the second level is the database name, the third level is the unit number, and the fourth level is the SQL script file).

[0038] S203. The concurrent execution engine splits the script traversal task into multiple script recognition tasks based on the preset thread pool size, and assigns each script recognition task to a thread in its thread pool. The concurrent execution engine can split the script traversal task into multiple script recognition tasks (each script recognition task includes the recognition and processing of SQL script files contained in some subfolders under the SQL script folder) based on the preset thread pool size, and assign each script recognition task to a thread in its thread pool to perform recursive traversal and recognition of the corresponding script files.

[0039] S204. Each thread in the concurrent execution engine's thread pool calls the script recognition engine to perform script recognition on a subset of SQL script files contained in the SQL script folder, based on its corresponding script recognition task. The resulting script recognition results are then updated to the data storage layer in real time. The concurrent execution engine has preset script folder structure rules, and each thread can perform folder hierarchical operations on the SQL script files contained in the SQL script folder according to these rules (e.g., ...). Figure 2 As shown, the first layer is the maintenance date, the second layer is the database name, the third layer is the unit number, and the fourth layer is the SQL script file and SQL script file identification.

[0040] S205. The backend service layer aggregates the script recognition results from the data storage layer and feeds them back to the frontend presentation layer for display. The backend service layer can aggregate the script recognition results from the data storage layer and feed them back to the frontend presentation layer. The frontend presentation layer can obtain the aggregated script recognition results from the backend service layer via WebSocket or polling.

[0041] Furthermore, the method also includes: the concurrent execution engine configuring thread pool parameters in response to parameter configuration instructions from operations and maintenance personnel, wherein the thread pool parameters include the number of threads, thread idle lifespan, and task queue capacity. For example, the thread pool parameters can be configured as: core thread count N. 核心 = Number of CPU cores × 2; Maximum number of threads N 最大 = Number of CPU cores × 4; Thread idle time T 空闲 =60 seconds; Task queue capacity Q capacity = 1000.

[0042] To verify the technical effectiveness of the method in this embodiment, let's take a maintenance operation involving 200 microservices in a certain group as an example: 1. Traditional method: Maintenance personnel need to inspect 200 services one by one according to the inspection form; each service takes an average of 1 minute (including confirming service information, executing scripts, and recording results); total time: 200 × 1 minute = 200 minutes ≈ 3.33 hours; data error rate: manual entry leads to about 5% service information errors.

[0043] 2. After adopting this invention: One-click import of inspection forms: Import via multi-threaded concurrency, taking approximately 2 minutes; Service verification: Verification of 200 services via multi-threaded concurrency, taking approximately 3 minutes; Script recognition: Recognition of 500+ SQL scripts via multi-threaded concurrency, taking approximately 1 minute; Total import and verification time: 2+3+1=6 minutes; Efficiency improvement: (200-6) / 200×100%=97%; Data error rate: Automatic verification reduces the error rate to below 0.1%.

[0044] 3. User experience: Operation steps: Reduced from 10+ steps to 2 steps (upload form, view results); Real-time feedback: Verification results are displayed in real time, no waiting required; Consistency guarantee: Automatic verification ensures that maintenance data is consistent with the actual situation of the cluster.

[0045] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A cloud-native intelligent identification and verification system for batch maintenance data, characterized in that: It includes a front-end presentation layer, a back-end service layer, a concurrent execution engine, a cluster interface layer, a script recognition engine, and a data storage layer; the front-end presentation layer is used to import maintenance tables and / or import SQL script folders, and transmit the imported maintenance tables and / or SQL script folders to the back-end service layer; the back-end service layer is used to parse the maintenance tables, extract data from each microservice, convert each microservice data into a list of service data objects, and / or generate script traversal tasks based on the SQL script folder; The concurrent execution engine is used to split the service data object list into multiple service batches according to a preset thread pool size. Each service batch contains several microservice data. Each thread in its thread pool independently processes one service batch. And / or, according to a preset thread pool size, it splits the script traversal task into multiple script recognition tasks and assigns each script recognition task to each thread in its thread pool. Each thread in the thread pool is used to call the cluster interface layer to query the basic information of each microservice in the cluster resources when processing the microservice data of the corresponding service batch. It uses the basic information of each microservice to verify the corresponding microservice data, obtains the verification result of the corresponding microservice data, and updates the verification result of the corresponding microservice data to the data storage layer in real time. And / or, according to the corresponding script recognition task, it calls the script recognition engine to perform script recognition on some SQL script files contained in the SQL script folder, obtains the script recognition result of each SQL script file, and updates the corresponding script recognition result to the data storage layer in real time. The backend service layer is used to summarize the verification results of each microservice data in the data storage layer and feed them back to the frontend display layer, and / or summarize the script recognition results in the data storage layer and feed them back to the frontend display layer.

2. The cloud-native batch maintenance data intelligent identification and verification system according to claim 1, characterized in that, Each thread in the thread pool is used to asynchronously process microservice data for the corresponding service batch, and / or asynchronously process script recognition tasks for each SQL script file.

3. The cloud-native batch maintenance data intelligent identification and verification system according to claim 1, characterized in that, The front-end presentation layer is used to obtain the verification results of the aggregated microservice data and / or the aggregated script recognition results from the back-end service layer via WebSocket or polling.

4. The cloud-native batch maintenance data intelligent identification and verification system according to claim 1, characterized in that, The front-end presentation layer is used to display the verification results of the summarized microservice data and / or the summarized script identification results in tabular form.

5. The cloud-native batch maintenance data intelligent identification and verification system according to claim 1, characterized in that, The microservice data includes the associated service name and service version number, and the basic information of each microservice includes the service name, service version number and service status of each microservice.

6. The cloud-native batch maintenance data intelligent identification and verification system according to claim 1, characterized in that, The script recognition engine presets script folder structure rules and is used to recognize some SQL script files contained in the SQL script folder according to the script folder structure rules.

7. The cloud-native batch maintenance data intelligent identification and verification system according to claim 6, characterized in that, The script recognition result includes script file information, which includes file name, database name, unit number, maintenance date, and file path.

8. A cloud-native method for intelligent identification and verification of batch maintenance data, applied to the system described in any one of claims 1-7, characterized in that, include: Import the inspection form through the front-end presentation layer and transmit the inspection form to the back-end service layer; The backend service layer parses the maintenance table, extracts data from each microservice, and converts the data from each microservice into a list of service data objects. The concurrent execution engine splits the list of service data objects into multiple service batches based on the preset thread pool size, with each service batch containing several microservice data. Each thread in the concurrent execution engine thread pool calls the cluster interface layer to query the basic information of each microservice in the cluster resources, and uses the basic information of each microservice to verify the corresponding microservice data, obtain the verification result of the corresponding microservice data, and update the verification result of the corresponding microservice data to the data storage layer in real time. The backend service layer aggregates the verification results of each microservice in the data storage layer and feeds them back to the frontend presentation layer for display.

9. The cloud-native batch maintenance data intelligent identification and verification method according to claim 8, characterized in that, The method further includes: Import the SQL script folder through the front-end presentation layer and then transfer the imported SQL script folder to the back-end service layer; The backend service layer parses the SQL script folder and generates corresponding script traversal tasks; The concurrent execution engine splits the script traversal task into multiple script recognition tasks according to the preset thread pool size, and assigns each script recognition task to a thread in its thread pool. Each thread in the concurrent execution engine thread pool calls the script recognition engine to perform script recognition on some of the SQL script files contained in the SQL script folder according to the corresponding script recognition task, obtains the script recognition results of each SQL script file, and updates the corresponding script recognition results to the data storage layer in real time. The backend service layer aggregates the recognition results of each script in the data storage layer and feeds them back to the frontend presentation layer for display.

10. The cloud-native batch maintenance data intelligent identification and verification method according to claim 8 or 9, characterized in that, The method further includes: The concurrent execution engine configures thread pool parameters in response to parameter configuration instructions from operations and maintenance personnel. These thread pool parameters include the number of threads, thread idle lifespan, and task queue capacity.

Images