Cloud platform resource intelligent management system and method based on distributed edge computing

Abstract

The application relates to the technical field of cloud platform resource management, in particular to a cloud platform resource intelligent management system and method based on distributed edge computing. The system comprises a resource sensing unit, a task analysis unit and an intelligent scheduling unit. The intelligent scheduling unit is used for realizing optimal matching of resources and tasks, generating resource allocation instructions based on resource dynamic data and task characteristic parameters by using a multi-objective optimization algorithm with dynamic weight adjustment combined with load balancing logic. The system further comprises an execution monitoring unit. The hardware running state and software resource configuration of edge nodes and the cloud platform are collected and pretreated in multiple dimensions by the resource sensing unit, the task characteristics are quantitatively analyzed by the task analysis unit, and the multi-objective optimization algorithm with dynamic weight adjustment based on task priority and node load difference is used by the intelligent scheduling unit, so that the matching and adaptation degree of resources and task requirements is improved, the resource allocation is more suitable for actual task scenarios, and the situation of resource mismatch or redundant allocation is reduced.

Description

Technical Field

[0001] This invention relates to the field of cloud platform resource management technology, and more specifically, to a cloud platform resource intelligent management system and method based on distributed edge computing. Background Technology

[0002] In a distributed edge computing and cloud platform collaborative architecture, the heterogeneity of edge node resources and the dynamic nature of task requests place sophisticated demands on resource management technologies. Efficient resource management requires real-time awareness of the resource status of edge nodes and the cloud platform, accurate parsing of task requirements, intelligent matching of resources and tasks, and end-to-end execution monitoring to address core issues such as low resource utilization and large fluctuations in task latency, thereby supporting stable operation in high-concurrency, low-latency scenarios.

[0003] For example, Chinese patent CN202310637663.3 discloses a cloud platform resource management system and method based on multi-source nodes. The system includes a multi-source node management module, a message sending and receiving module, a cloud platform resource management module, and a cloud platform early warning module. The output of the multi-source node management module is connected to the input of the message sending and receiving module; the output of the message sending and receiving module is connected to the input of the cloud platform resource management module; the output of the cloud platform resource management module is connected to the input of the cloud platform early warning module. The system also provides a cloud platform resource management method based on multi-source nodes. By dynamically adjusting or planning the resources of the cloud platform under different access request volumes, it can effectively manage server resources within the multi-source nodes of the cloud platform. When the access request volume surges, it ensures the orderly operation of the cloud platform and improves the utilization efficiency of the cloud platform. For example, Chinese patent CN202211635379.4 discloses a cloud platform resource management method, system, and electronic device, including: splitting an application into several processes based on business logic, determining the resource configuration components that the processes depend on; monitoring changes in process version information, so as to call the prior processes associated with the process version information through the current version of the process; and having the resource configuration components sequentially call the resources corresponding to the prior processes from the cloud platform based on business logic to encapsulate the resource model corresponding to the application. This invention reduces the difficulty of resource scheduling for cloud platforms and their deployed applications during application creation and subsequent maintenance management when version information is updated.

[0004] While the aforementioned technical solutions possess corresponding design advantages, they also exhibit the following significant limitations: First, insufficient accuracy in resource scheduling: Although CN202310637663.3 dynamically adjusts resources through multi-source nodes, it fails to integrate multi-dimensional data on edge node hardware operating status and software resource configuration, and does not construct a dynamic correlation model between task priority and node load differences, resulting in limited accuracy in dynamic "resource-task" matching. Second, lack of closed-loop optimization capabilities: CN202211635379.4 focuses on business process decomposition and version management, relying on preset rules for resource allocation. It lacks real-time monitoring of resource status, emergency scheduling for abnormal scenarios, and iterative optimization mechanisms for scheduling strategies, making it difficult to adapt to complex scenarios involving heterogeneous edge computing nodes and dynamic changes in task requests. Therefore, we propose a cloud platform resource intelligent management system and method based on distributed edge computing. Summary of the Invention

[0005] The purpose of this invention is to provide a cloud platform resource intelligent management system and method based on distributed edge computing to solve the problems mentioned in the background art.

[0006] To address the aforementioned technical problems, one objective of this invention is to provide an intelligent cloud platform resource management system based on distributed edge computing, comprising: The resource awareness unit is used to collect and preprocess dynamic resource data of distributed edge computing nodes and cloud platforms in real time, and obtain hardware operating status and software resource configuration information through multi-dimensional collection interfaces. The task parsing unit is used to process feature extraction of task requests and determine the resource requirement parameters and execution constraints of the task through a structured parsing process. The intelligent scheduling unit is used to achieve optimal matching of resources and tasks. Based on dynamic resource data and task characteristic parameters, it uses a multi-objective optimization algorithm with dynamic weight adjustment combined with load balancing logic to generate resource allocation instructions. The dynamic weight adjustment dynamically adjusts the matching parameter weights according to real-time resource load differences and task priorities. The execution monitoring unit is used for resource scheduling and process tracking. It executes allocation instructions through an instruction conversion mechanism and collects task execution status data in real time.

[0007] Furthermore, in the effectiveness evaluation module 450, the calculation of evaluation indicators specifically includes the following steps: First, calculate resource utilization rate. : The "actual resource usage of the task" is the average resource usage value recorded by the status acquisition module 420 during the task execution period, and the "allocated resource amount" is the resource parameter in the instruction of the intelligent scheduling unit 300; the value of U ranges from 0 to 1, and the closer it is to 1, the more reasonable the resource allocation is. Then, the task completion rate was calculated. : Successfully completing a task means completing the task without any abnormal exits within the specified time. Then, calculate the load balancing improvement rate. : ,in The load difference coefficient is defined for the intelligent scheduling unit 300. A positive value indicates improved load balancing.

[0008] As a further improvement to this technical solution, the resource sensing unit includes a hardware acquisition module and a software acquisition module, wherein: The hardware acquisition module establishes communication with the hardware monitoring interface of the cloud platform through the hardware interface of the distributed edge node, and collects CPU core utilization, memory page swapping frequency, storage input / output throughput and network port data packet forwarding rate in real time. The hardware interface supports PCIe, USB and Ethernet protocols. The software acquisition module interacts with the operating systems of edge nodes and cloud platforms through the application programming interface to collect the number of service instances of deployed applications, the amount of resources consumed by processes and threads, the versions of software dependency libraries, and the health check status of services.

[0009] As a further improvement to this technical solution, the resource sensing unit further includes a data preprocessing module, which preprocesses the collected data, including the following steps: S130.1 Receive raw data output from the hardware acquisition module and the software acquisition module, add a timestamp to each data item and create an index; S130.2. Call the preset resource threshold range parameters to perform point-by-point anomaly detection on the raw data and mark data points that exceed the normal fluctuation range; S130.3 For the marked abnormal data points, a linear interpolation method is used for data repair. The interpolation method generates supplementary data based on the changing trend of three consecutive normal data points before and after the abnormal point. S130.4. Convert the repaired hardware resource data and software resource data into JSON or CSV format to generate a standardized resource dataset containing data type identifiers.

[0010] Furthermore, the repaired hardware and software resource data will be uniformly converted into JSON or CSV format. Specifically, the JSON format uses a key-value pair structure, including data acquisition timestamps, data type identifiers (such as "CPU utilization" and "memory usage"), data source node identifiers, and specific values; the CSV format uses a tabular structure, storing data in a fixed column order of timestamp, data type, node identifier, and value. During the conversion process, it is necessary to ensure that the field definitions of different types of resource data are consistent to facilitate unified parsing by the subsequent resource management module.

[0011] As a further improvement to this technical solution, the task parsing unit includes a basic feature library module and a constraint template module, wherein: The basic feature library module is used to build and maintain the task feature dictionary, supports keyword updates and feature label mapping, receives external feature data through an interface to update the keyword table, and associates the matched keywords with the corresponding task feature labels. The constraint template module is used to build and manage constraint rule templates, supports dynamic loading of templates according to task type, adjusts the threshold range in the template based on historical data, and provides constraint parameter query services through an interface. The constraint rule template contains constraint parameter verification rules and exception handling logic.

[0012] As a further improvement to this technical solution, the task parsing unit further includes a task receiving and verification module, a feature extraction module, a requirement parameter determination module, and a constraint condition generation module, wherein: The task receiving and verification module is used to receive task requests, verify the compliance of data formats, and extract basic information. The feature extraction module calls the task feature dictionary of the basic feature library module to segment the task request text and match keywords, generating a feature label set containing task type and processing scenario. The requirement parameter determination module converts the feature label set into quantitative resource requirement parameters (including computing resource quantity, peak memory, total storage, and network bandwidth). The constraint generation module calls the rule template of the constraint template module, matches the constraint parameters corresponding to the task type, determines the maximum allowable latency, encryption level and compatibility requirements, and generates a structured task requirement report.

[0013] As a further improvement to this technical solution, the intelligent scheduling unit adopts a multi-objective optimization algorithm with dynamic weight adjustment to achieve optimal matching of resources and tasks; the dynamic weight adjustment mechanism calculates the objective function weights using a dual-factor approach of real-time resource load difference coefficient and task priority coefficient; the multi-objective optimization algorithm takes maximizing resource utilization, minimizing task execution latency, and optimizing load balance as optimization objectives, and triggers secondary optimization by combining a preset load balance judgment threshold.

[0014] As a further improvement to this technical solution, the intelligent scheduling unit, in conjunction with load balancing logic, generates resource allocation instructions, including the following steps: S300.1, Data Acquisition and Load Rate Calculation: The system acquires real-time resource data transmitted by the resource awareness unit and task characteristic parameters from the task parsing unit; the real-time resource data includes... CPU utilization of each edge node ( , (Total number of edge nodes) and memory usage The task characteristic parameters include the task priority identifier; Based on the CPU utilization rate and memory usage Calculate the first Overall load rate of each edge node : ; in, and These are the weighting coefficients for CPU and memory, respectively. ; S300.2 Calculation of Load Difference and Priority Coefficient: Calculate the load difference coefficient between nodes : ; in, for The highest overall load rate among all edge nodes; To achieve the minimum overall load factor; for The average overall load rate of each edge node, and ; Define task priority coefficients : Map priority coefficients based on task priority identifiers (mapping rules are preset by the system); S300.3, Dynamic Weight Construction: Calculate the weight correction coefficients of the objective function using a two-factor model: ;in, As a priority influencing factor, As a load balancing influencing factor, and ; Based on the system's preset basic weights (resource utilization, task latency, and initial load balancing proportions), if If the threshold is exceeded (the threshold is preset by the system), the load balancing weight ratio will be increased; S300.4, Multi-objective optimization solution: Constructing a multi-objective optimization function : ;in, , , The dynamic weights are modified according to S300.3 (corresponding to resource utilization, task latency, and load balancing respectively). As a resource utilization rate indicator, For task execution delay metrics, This is a load balancing metric. Iterative optimization using the particle swarm optimization algorithm, the number of iterations and Associate the data (association rules are preset by the system) to generate an initial resource allocation scheme; S300.5 Load Balancing Verification and Correction: Calculate the load balancing degree of the initial scheme : ; in, for Average overall load rate of each edge node; It is the first The overall load rate of each edge node; like If the preset equalization threshold is exceeded (the threshold is preset by the system), then: Calculate the resource migration amount of overloaded nodes (the migration amount formula is preset by the system). Select a lightly loaded node (that satisfies) ), (Assign node numbers) as migration targets to complete secondary optimization; S300.6, Instruction Generation and Verification: Convert the optimization plan into standardized resource allocation instructions (including node identifier, resource allocation amount, and deployment order). Generate instruction verification code : ; in, The cryptographic hash function is used, and the timestamp identifies the time the instruction was generated.

[0015] As a further improvement to this technical solution, the execution monitoring unit includes an instruction execution module and a status acquisition module, wherein: The instruction execution module converts the resource allocation instructions generated by the intelligent scheduling unit into operations that can be executed by the edge nodes, adapts to the resource configuration interfaces of different nodes through a protocol conversion mechanism, and executes the resource allocation operations. Furthermore, the resource allocation operation of the instruction execution module includes the following steps: First, verify the instruction checksum (by calling the verification logic of the intelligent scheduling unit 300), and after the verification is successful, perform protocol conversion; then wait for the node to return the execution result (such as a Modbus response frame or an MQTT acknowledgment message); finally, record the operation log (including instruction content, execution status, and timestamp).

[0016] The status acquisition module collects task execution status data in real time, including periodically collecting CPU, memory, and network usage data of edge nodes, as well as capturing key events during task execution (such as startup, completion, and exceptions).

[0017] As a further improvement to this technical solution, the execution monitoring unit also includes an exception handling module, a data synchronization module, and an effect evaluation module, wherein: The anomaly handling module performs anomaly detection and response based on the collected status data, compares the resource usage data with the preset threshold, and generates a temporary scheduling instruction when an anomaly is detected and sends it to the intelligent scheduling unit. The data synchronization module synchronizes the status data to the central control node, using an incremental transmission mechanism to synchronize only the status change data, and encrypts the transmitted data. The effect evaluation module is used to evaluate the effect of resource scheduling, calculate evaluation indicators, and feed the evaluation results back to the intelligent scheduling unit for parameter adjustment.

[0018] The second objective of this invention is to provide a cloud platform resource intelligent management method based on distributed edge computing. The aforementioned cloud platform resource intelligent management system based on distributed edge computing includes the following steps: S100, Multi-dimensional Resource Acquisition and Preprocessing: Real-time acquisition of hardware operating status and software resource configuration information of distributed edge computing nodes and cloud platforms; anomaly detection, repair and standardization processing of the acquired data; generation of resource datasets containing data type identifiers. S200, Task Feature Analysis and Requirement Generation: Extract feature tags from task requests, match them with a preset task feature dictionary and constraint rule template, convert the feature tags into quantified resource requirement parameters, determine the execution constraints of the task, and generate a structured task requirement report. S300, Dynamic Weighted Scheduling and Resource Allocation: Based on real-time resource data and task requirements, a multi-objective optimization algorithm with dynamic weight adjustment is adopted. The optimization weight is adjusted and optimized in combination with task priority and node load difference. The resource allocation scheme is solved with the objectives of maximizing resource utilization, minimizing task execution latency and optimizing load balance. The scheme is then checked and corrected for load balancing, and standardized resource allocation instructions are generated. S400, Execution Monitoring and Closed-Loop Optimization: Convert resource allocation instructions into executable operations and deploy them, collect resource usage status and key events during task execution in real time, trigger temporary scheduling for abnormal states, evaluate the effect of resource scheduling and feed the results back to the scheduling process, and iteratively optimize scheduling parameters.

[0019] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention uses a resource sensing unit to collect and preprocess the hardware operating status and software resource configuration of edge nodes and cloud platforms from multiple dimensions, combined with a task parsing unit to quantify and analyze task characteristics, and then uses a multi-objective optimization algorithm based on task priority and node load differences to dynamically adjust weights. This invention can improve the matching and adaptability between resources and task requirements, make resource allocation more in line with actual task scenarios, and reduce resource mismatch or redundant allocation. 2. By leveraging the load balancing verification and secondary optimization mechanism of the intelligent scheduling unit, and the real-time collection, anomaly handling, and effect evaluation feedback of the task execution status by the execution monitoring unit, this invention can adjust the resource allocation strategy in a timely manner when node load fluctuates or tasks change dynamically. This overcomes the limitations of static management, enhances the system's adaptability to heterogeneous edge computing nodes and dynamic task request scenarios, and ensures the stability and continuous optimization capability of the resource management process. 3. By combining the instruction conversion mechanism of the execution monitoring unit with the abnormal handling module, this invention can accurately convert resource allocation instructions into operations that can be executed by edge nodes, and quickly trigger temporary scheduling when an abnormality occurs, thereby reducing resource management interruptions caused by instruction execution deviations or abnormal states and improving the reliability of resource scheduling execution. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the system framework of the present invention; Figure 2 This is a schematic diagram of the method steps of the present invention; The meanings of the labels in the diagram are as follows: 100. Resource sensing unit; 110. Hardware acquisition module; 120. Software acquisition module; 130. Data preprocessing module; 200. Task parsing unit; 210. Basic feature library module; 220. Constraint template module; 230. Task receiving and verification module; 240. Feature extraction module; 250. Requirement parameter determination module; 260. Constraint generation module; 300. Intelligent scheduling unit; 400. Execution monitoring unit; 410. Instruction execution module; 420. Status acquisition module; 430. Exception handling module; 440. Data synchronization module; 450. Effect evaluation module. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention. Example 1

[0022] like Figure 1 As shown, this embodiment provides a cloud platform resource intelligent management system based on distributed edge computing, including: The resource sensing unit 100 is used to collect and preprocess dynamic resource data of distributed edge computing nodes and cloud platforms in real time, and obtain hardware operating status and software resource configuration information through multi-dimensional collection interfaces. In this embodiment, the resource sensing unit 100 includes a hardware acquisition module 110 and a software acquisition module 120, wherein: The hardware acquisition module 110 establishes communication with the hardware monitoring interface of the cloud platform through the hardware interface of the distributed edge node, and collects CPU core utilization, memory page swapping frequency, storage input / output throughput and network port data packet forwarding rate in real time. The hardware interface supports PCIe, USB and Ethernet protocols. As a further explanation of this embodiment, the hardware interface initialization of the distributed edge node in this embodiment requires the following steps: When using the PCIe interface, a configuration space probe command is first sent to obtain the device identifier and vendor identifier; for the USB interface, a device enumeration process is executed, and a descriptor acquisition request is sent to identify device information; when the Ethernet interface uses the Simple Network Management Protocol, the periodic polling mechanism of the management information base object tree needs to be initialized to ensure that the node status can be continuously monitored.

[0023] Meanwhile, the cloud platform hardware monitoring interface adaptation layer adopts an abstract design, setting unified hardware indicator collection interface specifications that cover collection standards for core resources such as CPU, memory, storage, and network. For different types of cloud platforms, such as open-source cloud platforms or container cluster platforms, corresponding interface implementation modules need to be developed to achieve cross-platform hardware data collection through standardized interface calls.

[0024] In addition, the system's default sampling frequency is 30 seconds per sampling. When the system load fluctuation of the edge node or cloud platform exceeds 20%, the sampling frequency is automatically adjusted. The adjustment rule is: New sampling interval = Base interval × (1 - Load fluctuation coefficient × Adjustment coefficient), where the load fluctuation coefficient is the ratio of the difference between the current load and the average load to the average load, and the adjustment coefficient is set to 0.3 (based on resource monitoring experience). Once the system load stabilizes, the sampling frequency automatically returns to the default value.

[0025] The software acquisition module 120 interacts with the operating systems of edge nodes and cloud platforms through the application programming interface to collect the number of service instances of deployed applications, the amount of resources consumed by process threads, the version of software dependency libraries, and the service health check status.

[0026] As a further explanation of this embodiment, in a Linux system environment, the number of service instances of deployed applications is obtained through the system management interface, specifically by querying the active unit list of the system service management process. Resource usage information for processes and threads is obtained by parsing the process status file maintained by the system kernel, which contains basic data such as process CPU usage time and memory usage. Meanwhile, in a containerized deployment environment, resource usage data within containers is obtained through interface queries for the container engine, by calling the container status query interface to obtain real-time resource statistics. For the container orchestration platform, pod-level resource usage data, including metrics such as CPU utilization and memory usage of each service instance, is obtained through the platform's built-in metrics service interface.

[0027] As a further explanation of this embodiment, this embodiment adopts differentiated health check methods for different types of services: For HTTP services, a header request is sent and the response status code is verified, with the normal response status code range being 200-299; For RPC services, a preset heartbeat probe packet is sent, and a 3-second timeout threshold is set. If no response is received within the threshold, it is marked as abnormal; For database services, basic query commands (such as query statements to verify connection validity) are executed, and service availability is determined by detecting the query response time. No response or response timeout is considered an abnormal health check.

[0028] In this embodiment, the resource sensing unit 100 further includes a data preprocessing module 130, which preprocesses the collected data, including the following steps: S130.1 Receive raw data output from hardware acquisition module 110 and software acquisition module 120, add timestamps to each data item and establish an index; S130.2. Call the preset resource threshold range parameters to perform point-by-point anomaly detection on the raw data and mark data points that exceed the normal fluctuation range; As a further explanation of this step, the 3σ principle can be used for point-by-point anomaly detection: For the collected time-series data sequence, first calculate the mean and standard deviation of all data before the current data point, then determine the normal fluctuation range as the mean ± 3 times the standard deviation. When a data point exceeds this range, it is marked as an anomaly. During the calculation process, the mean and standard deviation are dynamically updated as new data points are added, ensuring that the anomaly detection threshold can adapt to the normal fluctuations in resource data.

[0029] S130.3 For the marked abnormal data points, a linear interpolation method is used for data repair. The interpolation method generates supplementary data based on the changing trend of three consecutive normal data points before and after the abnormal point. As a further explanation of this step, linear interpolation is used for data repair, including the following steps: First, find three consecutive normal data points before the outlier and record their timestamps and values; then find three consecutive normal data points after the outlier and record their timestamps and values ​​as well; based on the changing trend of the normal data points before and after, linear interpolation is used to calculate supplementary data for the outlier, that is, by establishing a linear change model through the time interval and numerical difference between the outlier and the nearest preceding normal point, and the time interval and numerical difference between the nearest subsequent normal point, supplementary data is generated to replace the outlier.

[0030] S130.4. Convert the repaired hardware resource data and software resource data into JSON or CSV format to generate a standardized resource dataset containing data type identifiers.

[0031] As a further explanation of this embodiment, in this step, the repaired hardware and software resource data are uniformly converted into JSON or CSV format: JSON format adopts a key-value pair structure, including data acquisition timestamp, data type identifier (such as "CPU utilization" or "memory usage"), data source node identifier, and specific value; CSV format adopts a tabular structure, storing data in a fixed column order of timestamp, data type, node identifier, and value. During the conversion process, it is necessary to ensure that the field definitions of different types of resource data are consistent to facilitate unified parsing by the subsequent resource management module.

[0032] As a further explanation of this embodiment, regarding the data output interface, the standardized resource dataset generated by the data preprocessing module 130 is pushed to the intelligent scheduling unit 300 through a message queue mechanism. The queue name is uniformly "resource-data.normalized". The message body contains three core contents: first, dataset metadata, including the start and end times of collection, the number of edge nodes involved, and data type statistics; second, a list of data records, each record strictly following JSON or CSV format, including timestamp, data type identifier, node identifier, and specific value; and third, an integrity verification field, i.e., the MD5 hash value of the dataset. After receiving the dataset, the intelligent scheduling unit verifies it by recalculating the hash value. If there is an inconsistency, a data retransmission request is triggered. In addition, for the resource requirement parameter query of the task parsing unit 200, the resource perception unit 100 provides a synchronous query interface, which supports filtering data by task type and time range. The returned results include the average, peak, and fluctuation range of resources for the corresponding time period, providing data support for determining task requirement parameters.

[0033] Furthermore, for the management of anomalous data, data marked as anomalous and not yet repaired is temporarily stored in a local circular buffer on the edge node. The buffer capacity is fixed at 1000 records, managed according to the "first-in, first-out" principle. When the buffer is full, the record with the earliest timestamp is automatically discarded. Repaired anomalous data will overwrite the original anomalous record, and a "repair flag" field (with a value of "true") will be added to the dataset to facilitate subsequent units in identifying the data processing status. Unrepaired anomalous data is not included in the standardized dataset but is only retained as logs (with a retention period of 24 hours) to avoid affecting the accuracy of resource scheduling decisions.

[0034] It should be added that, in terms of module fault tolerance and interaction stability, each module of the resource awareness unit must have a redundancy mechanism to cope with communication interruptions and interface failures. When the hardware acquisition module 110 loses communication with the cloud platform hardware monitoring interface, it automatically starts a local cache to cache the raw acquisition data of the most recent 5 minutes. After communication is restored, it resends the data in batches according to the timestamp order. If network congestion is encountered during the resending process, the sending rate is automatically reduced (the interval between each sending is extended to twice the original interval). When the software acquisition module 120 fails to call the application interface, it triggers a retry mechanism (maximum of 2 retries, 1 second interval). After a retry fails, it switches to a backup acquisition path. For example, in a containerized environment, if the DockerEngine API call fails, it automatically switches to directly reading the cgroup file system to obtain CPU usage data. All faults and handling processes are recorded in local logs, including fault time, type, handling measures and results. The log files are rotated daily (retained for 7 days) for system operation and maintenance analysis.

[0035] The task parsing unit 200 is used to process the feature extraction of task requests and determine the resource requirement parameters and execution constraints of the task through a structured parsing process. In this embodiment, the task parsing unit 200 includes a basic feature library module 210 and a constraint template module 220, wherein: The basic feature library module 210 is used to build and maintain the task feature dictionary, supports keyword updates and feature label mapping, receives external feature data through an interface to update the keyword table, and associates the matched keywords with the corresponding task feature labels. As a further explanation of this embodiment, in the basic feature library module 210 of this embodiment, the storage and management method of the task feature dictionary specifically includes: the task feature dictionary is stored in a relational database table, and the core fields include "keywords" (such as "real-time video analysis" and "batch data processing"), "associated tags" (divided into two categories: "task category" and "application scenario", such as "real-time processing" and "industrial monitoring"), and "matching weight" (a value between 0 and 1, used for priority determination when matching multiple keywords). Among them, the "task category" tag is used to identify the core processing type of the task (such as "real-time processing" and "batch processing"), and the "application scenario" tag is used to describe the operating environment of the task (such as "industrial scenario" and "urban security scenario"). Each keyword is associated with at least one tag, for example, "real-time video analysis" is associated with "task category: real-time processing" and "application scenario: video scenario".

[0036] Furthermore, in the basic feature library module 210 of this embodiment, keyword updating includes the following steps: receiving external feature data through a standardized interface, the data format being a JSON array containing "keywords," "association tags," and "matching weights." The system first verifies the uniqueness of the keywords; if they already exist, it updates their "association tags" and "matching weights"; if they do not exist, it adds a new record. Each week, new words appearing ≥50 times in the task description text of the past 30 days are automatically extracted and stored in a pending review list. After the administrator reviews them through the backend interface, new words that meet the requirements are added to the dictionary, and records that do not pass are rejected with a reason.

[0037] Furthermore, in the basic feature library module 210 of this embodiment, the tag mapping matching logic specifically includes: after the task description text is segmented, if multiple keywords are matched, they are sorted from high to low according to their "matching weight," and the top 3 are selected as valid keywords. The "associated tags" of the valid keywords are extracted, and tags with the same "task category" are merged (e.g., if two keywords are both associated with "real-time processing," only one is retained). For the "application scenario" tag, all unique items are retained. For example, matching "real-time video analysis" (weight 0.9, tags "real-time processing" and "video scenario") and "industrial monitoring" (weight 0.8, tag "industrial scenario") ultimately generates a tag set of "task category: real-time processing; application scenario: video scenario, industrial scenario."

[0038] The constraint template module 220 is used to build and manage constraint rule templates, supports dynamic loading of templates according to task type, adjusts the threshold range in the template based on historical data, and provides constraint parameter query services through an interface. The constraint rule template contains constraint parameter verification rules and exception handling logic.

[0039] As a further explanation of this embodiment, the structure and management method of the constraint rule template in the constraint template module 220 of this embodiment specifically include: the constraint rule templates are stored in JSON format, each template corresponds to a unique "task category" (corresponding to the "task category" in the tag set), including a "template identifier" (such as "real-time processing template"), a "constraint parameter list" (including parameter name, threshold range, unit and verification rules. For example, "maximum latency: threshold 50-200 milliseconds, rule ≤ upper limit", "encryption level: threshold 2-3 levels, rule ≥ lower limit"), and "exception handling logic" (such as "return error message when maximum latency exceeds limit"). The templates are stored in a distributed file system, supporting quick retrieval by "task category". The validity of the templates is reviewed by the administrator every quarter, and invalid templates are marked as "discarded" and archived.

[0040] Furthermore, in the constraint template module 220 of this embodiment, the dynamic adjustment method for the threshold range includes: Based on execution data of similar tasks over the past 30 days, thresholds are automatically adjusted monthly: for numerical parameters (such as maximum latency), the 95th percentile of historical data is used as the new upper limit (ensuring that 95% of tasks can meet the requirements); for enumerable parameters (such as compatibility library versions), versions that have appeared ≥10 times in the past 30 days are added. Adjustment records are stored in the log, including the thresholds before and after the adjustment and the amount of data (e.g., "adjusted based on 1200 task data"). If the adjustment is ≥30%, the administrator is notified for confirmation, and the administrator can roll back to the historical threshold within 24 hours.

[0041] Furthermore, in the constraint template module 220 of this embodiment, the constraint parameter query service is implemented by providing an API interface that supports querying corresponding templates by "task category" and filtering results by parameter name (such as "maximum latency"). The interface returns complete template information with a response time of ≤100ms. Popular templates (query frequency ≥10 times / minute) are cached in memory for 5 minutes to ensure query efficiency in high-concurrency scenarios.

[0042] In this embodiment, the task parsing unit 200 further includes a task receiving and verification module 230, a feature extraction module 240, a requirement parameter determination module 250, and a constraint generation module 260, wherein: The task receiving and verification module 230 is used to receive task requests, verify the compliance of data formats, and extract basic information. As a further explanation of this embodiment, in the task receiving and verification module 230 of this embodiment, the data format verification rules specifically include: Task requests must be in JSON format and include four required fields: "task_id" (unique task identifier, UUID format), "task_content" (task description text, non-empty string), "submit_time" (submission timestamp, millisecond-level number), and "submitter" (submitter identifier, string, length ≤ 64). During validation, if any required field is missing or the format is incorrect (e.g., "submit_time" is not a number), an error message (e.g., "Missing task_id field") will be returned. After successful validation, the above basic information will be extracted and stored in a temporary cache, which will be valid for 5 minutes to avoid processing the same request repeatedly. Meanwhile, the exception handling mechanism in this embodiment specifically includes: if a network interruption occurs when receiving a request, the API interface automatically enables local temporary file caching, with the cache path set to " / var / tmp / task_requests / " and the file naming format "{task_id}.json". After the network is restored, the requests are resubmitted in the order of "submit_time". If the message queue fails to receive a request, the message is transferred to the dead letter queue and the reason for the failure is recorded for subsequent investigation.

[0043] The feature extraction module 240 calls the task feature dictionary of the basic feature library module 210 to segment the task request text and match keywords, generating a feature tag set containing task type and processing scenario. As a further explanation of this embodiment, in the feature extraction module 240 of this embodiment, text segmentation and keyword matching include the following steps: 240.1 Text preprocessing: Remove punctuation, line breaks, and other special characters from the task description and convert them to lowercase. 240.2. Word Segmentation Processing: Use a dictionary-based word segmentation tool to split the text and filter out meaningless words (such as "of", "for"), for example, "real-time video analysis task for industrial monitoring" is segmented into "industrial monitoring" and "real-time video analysis" after processing; 240.3. Keyword Matching: Adopt a combination method of "exact matching + prefix matching" - exact matching means that the word segmentation result is exactly the same as the dictionary keyword; the word segmentation result is the prefix of the keyword and the length ≥ 3 characters is prefix matching (such as "real-time video" matches "real-time video analysis"); 240.4. Tag Set Generation: Extract "task category" and "application scenario" tags from the top 3 matched keywords and organize them into a tag set by category.

[0044] The demand parameter determination module 250 converts the feature tag set into quantified resource demand parameters (including computing resource quantity, memory peak value, total storage, network bandwidth); As a further explanation of this embodiment, in the demand parameter determination module 250 of this embodiment, the mapping rules of the quantified resource demand parameters include: Computing resource quantity (number of CPU cores): Determine the baseline value by "task category" ("real-time processing" 2 cores, "batch processing" 1 core), and adjust the baseline value by "application scenario" ("video scenario" × 1.5, "industrial scenario" + 1 core); Memory peak value (GB): Refer to the historical memory average value of similar tag tasks and calculate it as the average value × 1.2 (reserving 20% redundancy). When there is no historical data, the default value for "real-time processing" is 4GB, and the default value for "batch processing" is 2GB; Total storage: Input data volume (extracted from the task description, if there is no clear value, the default value for "real-time processing" is 1GB, and the default value for "batch processing" is 10GB) + input data volume × 0.5 (intermediate result volume); Network bandwidth: The baseline for "real-time processing" is 10Mbps, the baseline for "batch processing" is 5Mbps, add 5Mbps for "industrial scenario", and subtract 3Mbps for "local scenario" (minimum 1Mbps).

[0045] Furthermore, in the demand parameter determination module 250 of this embodiment, the specific logic of parameter verification and correction includes: The system presets parameter upper limits (such as computing resource quantity ≤ 32 cores, memory peak value ≤ 64GB, etc.). If the calculation result exceeds the limit, call the resource awareness unit interface to obtain the maximum bearing capacity of the edge node, and reduce it proportionally with this value as the upper limit (for example, if 20 cores are calculated but the maximum of the node is 16 cores, then correct it to 16 cores). The corrected parameters need to meet the basic requirements of the task (such as bandwidth ≥ 1Mbps), otherwise return a parameter exception prompt.

[0046] The constraint generation module 260 calls the rule template of the constraint template module 220, matches the constraint parameters corresponding to the task type, determines the maximum allowable latency, encryption level and compatibility requirements, and generates a structured task requirement report.

[0047] As a further explanation of this embodiment, in the constraint generation module 260 of this embodiment, the method for determining and generating reports of constraints includes: Template matching: Match the constraint template with the "task category" in the tag set. If no match is found, use the default template (including basic constraints such as maximum latency of 500ms and encryption level 1). Constraints determined: Maximum allowable latency: Take the median value of the template threshold, and subtract 20% from "real-time processing" (e.g., if the threshold is 50-200ms, the median value is 125ms, and the corrected latency is 100ms). Encryption level: If the task description contains words such as "confidential" or "privacy," the upper limit of the template will be used; otherwise, the lower limit will be used. Compatibility requirements: Extract the version list from the template and find the intersection with the pre-installed versions of the nodes returned by the resource awareness unit; Report generation: Formatted as JSON, including task identifier, tag set, quantified resource parameters, constraints, and generation timestamp.

[0048] It should be added that, in the task parsing unit 200 of this embodiment, the data flow and fault tolerance mechanisms of each module include: First, the data flow includes: after the task request, task receiving and verification module 230, the task description text is passed to the feature extraction module 240 to generate a tag set; the tag set is passed to the requirement parameter determination module 250 to generate quantization parameters; the tag set and quantization parameters are passed to the constraint generation module 260, and finally a structured report is generated and pushed to the intelligent scheduling unit 300, with the data associated with "task_id" throughout the process; Then, the fault tolerance process is as follows: When no matching keywords are found during feature extraction, a default label set ("Task Category: General Processing") is returned and logged. When a template fails to match, the system automatically switches to the default template and alerts the administrator to provide a replacement. When any module encounters an error, it returns a prompt containing the error message and "task_id" for easy tracing.

[0049] The intelligent scheduling unit 300 is used to achieve optimal matching of resources and tasks. Based on dynamic resource data and task characteristic parameters, it uses a multi-objective optimization algorithm with dynamic weight adjustment combined with load balancing logic to generate resource allocation instructions. The dynamic weight adjustment dynamically adjusts the matching parameter weights according to real-time resource load differences and task priorities. In this embodiment, the intelligent scheduling unit 300 uses a multi-objective optimization algorithm with dynamic weight adjustment to achieve optimal matching of resources and tasks; the dynamic weight adjustment mechanism calculates the objective function weights using a dual-factor approach of real-time resource load difference coefficient and task priority coefficient; the multi-objective optimization algorithm takes maximizing resource utilization, minimizing task execution latency, and optimizing load balance as optimization objectives, and triggers secondary optimization by combining a preset load balance judgment threshold.

[0050] In this embodiment, the intelligent scheduling unit 300 generates resource allocation instructions in conjunction with load balancing logic, including the following steps: S300.1, Data Acquisition and Load Rate Calculation: The resource sensing unit 100 acquires real-time resource data transmitted by itself and task characteristic parameters acquired by the task parsing unit 200; the real-time resource data includes... CPU utilization of each edge node ( , (Total number of edge nodes) and memory usage The task characteristic parameters include the task priority identifier; In this step, the real-time resource data comes from the standardized resource dataset output by the resource awareness unit 100, and is synchronized every 5 seconds, including... CPU utilization of each edge node ( (Values ​​range from 0 to 1, representing 0% to 100%) and memory usage. (Values ​​range from 0 to 1); the task feature parameters are derived from the structured task requirement report of the task parsing unit 200, and include task priority identifiers.

[0051] Based on the CPU utilization rate and memory usage Calculate the first Overall load rate of each edge node : ; in, and These are the weighting coefficients for CPU and memory, respectively. ; S300.2 Calculation of Load Difference and Priority Coefficient: Calculate the load difference coefficient between nodes : ; in, for The highest overall load rate among all edge nodes; To achieve the minimum overall load factor; for The average overall load rate of each edge node, and ; Define task priority coefficients : Map priority coefficients based on task priority identifiers (mapping rules are preset by the system); In this step, the task priority coefficient The mapping rules are determined based on the quantitative analysis logic of task features by the task parsing unit 200 and the dynamic weight adjustment requirements of the intelligent scheduling unit 300, as follows: The task priority identifier is specified by the priority field in the task request, and is divided into 4 levels, each corresponding to a different task type and priority coefficient. Value: Priority indicator 1 indicates an emergency task, suitable for scenarios with extremely high real-time requirements such as industrial control commands and emergency response processing. Value 1.0; Priority identifier 2 indicates a high-priority task, suitable for high-time-sensitivity scenarios such as real-time video stream processing and critical business data calculation. A value of 0.8; priority indicator 3 indicates a medium-priority task, suitable for routine time-sensitive tasks such as batch data preprocessing and non-real-time monitoring and analysis. A value of 0.5; priority indicator 4 indicates a low-priority task, suitable for scenarios with low timeliness requirements such as log archiving and historical data backup. Value 0.3.

[0052] Furthermore, the mapping rules described above can be dynamically adjusted to adapt to different scenarios and system load conditions: Regarding scenario adaptation, if the "application scenario" tag extracted by the task parsing unit is "industrial control" or "medical emergency", then the task with priority 1 will... The value can be increased to 1.2; this adjustment needs to be manually enabled through the system configuration interface. Regarding load balancing, when the intelligent scheduling unit detects an overall resource load rate ≥ 80%, it automatically compresses low-priority coefficients, including those marked 4. The value drops to 0.2, indicating 3. The value was reduced to 0.4 to prioritize the resource needs of high-priority tasks; Meanwhile, the rules are configurable, and system administrators can modify the mapping relationship through the backend configuration interface, such as adding "priority identifier 5 (very low)" and mapping it. =0.1. After modification, the intelligent scheduling unit needs to be restarted for the configuration to take effect.

[0053] In addition, task priority coefficient Dynamic weight correction coefficient in the intelligent scheduling unit There is a closely related logic: when When the load difference coefficient K is 1.0 (urgent task), even if the load difference coefficient K is small, Priority still plays a major role. The default value is 0.7), ensuring that urgent tasks are prioritized for resource allocation; when When the priority is 0.3 (low priority task), More dependent on load balancing factor ( The default value is 0.7, to avoid low-priority tasks consuming too many resources and causing load imbalance.

[0054] S300.3, Dynamic Weight Construction: Calculate the weight correction coefficients of the objective function using a two-factor model: ;in, As a priority influencing factor, As a load balancing influencing factor, and ; Based on the system's preset basic weights (resource utilization, task latency, and initial load balancing proportions), if If the threshold is exceeded (the threshold is preset by the system), the load balancing weight ratio will be increased; It is understandable that the system's preset base weight in this step is resource utilization. =0.4, task latency =0.3, load balancing =0.3; if If the value exceeds the preset threshold (0.3), then increase the value. To 0.4, decrease Up to 0.3 (ensure) ).

[0055] S300.4, Multi-objective optimization solution: Constructing a multi-objective optimization function : ;in, , , The dynamic weights are modified according to S300.3 (corresponding to resource utilization, task latency, and load balancing respectively). As a resource utilization rate indicator, For task execution delay metrics, This is a load balancing metric. Iterative optimization using the particle swarm optimization algorithm, the number of iterations and Associate the data (association rules are preset by the system) to generate an initial resource allocation scheme; Specifically: Iterative optimization using a particle swarm optimization algorithm with 30 particles and a learning factor. = =2.0, inertia weight =0.7 (linearly decreasing to 0.4); number of iterations and Related: 10 times when ≤0.2, 0.2< ≤0.5 20 times, When the F value is greater than 0.5, 30 iterations are performed. Finally, when the change in F value over three consecutive iterations is less than or equal to 0.01, or when the maximum number of iterations is reached, an initial resource allocation scheme is generated.

[0056] S300.5 Load Balancing Verification and Correction: Calculate the load balancing degree of the initial scheme : ; in, for Average overall load rate of each edge node; It is the first The overall load rate of each edge node; like If the preset equalization threshold is exceeded (the threshold is preset by the system), then: Calculate the resource migration amount for overloaded nodes (the migration amount formula is preset by the system); the calculation formula is: ( ) Select a lightly loaded node (that satisfies) ), (Assign node numbers) as migration targets to complete secondary optimization; S300.6, Instruction Generation and Verification: Convert the optimization plan into standardized resource allocation instructions (including node identifier, resource allocation amount, and deployment order). Generate instruction verification code : ; in, It is a cryptographic hash function, and the timestamp identifies the time when the instruction was generated, which is used to verify whether the instruction has been tampered with during transmission.

[0057] The execution monitoring unit 400 is used to perform resource scheduling and process tracking. It executes allocation instructions through an instruction conversion mechanism and collects task execution status data in real time.

[0058] In this embodiment, the execution monitoring unit 400 includes an instruction execution module 410 and a status acquisition module 420, wherein: The instruction execution module 410 converts the resource allocation instructions generated by the intelligent scheduling unit 300 into operations that can be executed by the edge nodes, adapts to the resource configuration interfaces of different nodes through a protocol conversion mechanism, and executes the resource allocation operations. As a further explanation of this embodiment, in the instruction execution module 410 of this embodiment, the protocol conversion mechanism adapts to three types of edge node interfaces, specifically including: Industrial edge devices (supporting Modbus protocol): First, the resource allocation instructions are parsed into register operation instructions. For example, "allocate 2 units of computing resources" is mapped to write to register address 0x0001 (value 2), and "allocate 4 units of storage resources" is mapped to register address 0x0002 (value 4). Then, the instructions are sent through Modbus RTU mode, with the baud rate set to 9600bps, 8 data bits, and 1 stop bit.

[0059] IoT Nodes (supporting MQTT protocol): Encapsulate instructions into JSON format messages, including fields such as "node identifier", "computing resource quantity", and "storage resource quantity", and publish them to the topic "resource allocation / instruction" via an MQTT client, with the service quality level set to 1 (ensuring delivery at least once).

[0060] Containerized node (supports gRPC protocol): Calls the node's preset resource service interface, passing in a resource request structure (including node identifier and resource quantity parameters), with a timeout of 5 seconds. If it fails, it will retry twice (with a 1-second interval).

[0061] Furthermore, in the instruction execution module 410 of this embodiment, the resource allocation operation includes the following steps: First, verify the instruction check code (call the verification logic of the intelligent scheduling unit 300), and after the verification is passed, perform protocol conversion; then wait for the node to return the execution result (such as a Modbus response frame or an MQTT confirmation message); finally, record the operation log (including instruction content, execution status, and timestamp).

[0062] The status acquisition module 420 collects task execution status data in real time, including periodically collecting CPU, memory, and network usage data of edge nodes, as well as capturing key events during task execution.

[0063] As a further explanation of this embodiment, the data acquisition and event capture of the status acquisition module 420 in this embodiment includes the following steps: First, edge node resource data is collected periodically: computing resource utilization and storage resource utilization are collected every 3 seconds (based on system process files or node monitoring interfaces), and network throughput (input / output bytes) is collected every 5 seconds (based on network status commands or SNMP protocol); the data collection format is uniformly "node identifier + indicator name + value + timestamp".

[0064] Subsequently, key events in task execution are captured, including: task start (process identifier creation is detected), task pause (process status is "paused"), task completion (process exits normally, return code 0), task failure (process exits abnormally, return code is not 0), and resource overrun (computing / storage resource usage exceeds the allocated amount for 10 seconds). When an event is triggered, the event type, occurrence time, associated task identifier, and node identifier are recorded.

[0065] Then, the collected status data and event information are temporarily stored in the local buffer, waiting for the data synchronization module 440 to process them.

[0066] In this embodiment, the execution monitoring unit 400 further includes an exception handling module 430, a data synchronization module 440, and an effect evaluation module 450, wherein: The anomaly handling module 430 performs anomaly detection and response based on the collected status data, compares the resource usage data with the preset threshold, and generates a temporary scheduling instruction when an anomaly is detected and sends it to the intelligent scheduling unit 300. As a further explanation of this embodiment, in the anomaly handling module 430 of this embodiment, anomaly detection is based on the comparison of state data with a preset threshold. The threshold setting rule is as follows: Resource usage thresholds: Computing resource utilization ≥ 90%, storage resource utilization ≥ 95%, network bandwidth ≥ 120% of allocated amount (consistent for more than 10 seconds is considered abnormal); Task status thresholds: ≥3 task failures (within 1 minute) and ≥5 minutes of task pause time.

[0067] Furthermore, in the exception handling module 430 of this embodiment, the exception response process is as follows: First, when an anomaly is detected, extract the anomaly node identifier, anomaly type, and current resource data (e.g., "Node 1, computing resources exceeded limit, current utilization rate 92%"). Subsequently, a temporary scheduling instruction is generated, in the format of "node identifier + temporary resource adjustment amount + instruction type (emergency migration / resource expansion)", for example "node 1, temporarily increase computing resources by 1 unit, emergency migration"; Then, temporary instructions are sent through a dedicated channel (encrypted connection with the intelligent scheduling unit 300), while an exception handling log (including exception details, instruction content, and sending time) is recorded. Finally, monitor node status changes. If the anomaly is not resolved within 1 minute, repeat the command (up to 3 times) and trigger an alarm (notify the system administrator).

[0068] The data synchronization module 440 synchronizes the status data to the central control node, using an incremental transmission mechanism to synchronize only the status change data, and encrypts the transmitted data. As a further explanation of this embodiment, the incremental transmission and encryption processing of the data synchronization module 440 in this embodiment includes the following steps: First, determine incremental data: compare the current collected data with the last synchronized data, and mark it as data to be synchronized when the value changes by ≥5% (such as the computing resource utilization rate increases from 70% to 75%) or a critical event occurs (such as task failure); Subsequently, the incremental data is encrypted: the AES-128 encryption algorithm is used, the key is distributed periodically by the central control node (updated every 24 hours), and the encrypted content includes the data body, timestamp, and node identifier; Then, synchronize in batches according to "node groups" (10 nodes per group), with the synchronization cycle linked to the status acquisition frequency (default 5 seconds / time, shortened to 1 second / time in abnormal conditions). Finally, receive the synchronization confirmation message from the central control node. If no confirmation is received, retry after 3 seconds (up to 5 times). If the retry fails, save the data to the local backup directory.

[0069] The effect evaluation module 450 is used to evaluate the effect of resource scheduling, calculate evaluation indicators (such as resource utilization rate, task completion rate, etc.), and feed the evaluation results back to the intelligent scheduling unit 300 for parameter adjustment.

[0070] As a further explanation of this embodiment, the evaluation index calculation in the effect evaluation module 450 of this embodiment specifically includes the following steps: First, calculate resource utilization rate. : The "actual resource usage" is the average resource usage value recorded by the status acquisition module during task execution, and the "allocated resource usage" is the resource parameter in the instruction of the intelligent scheduling unit 300. The value of U ranges from 0 to 1, and the closer it is to 1, the more reasonable the resource allocation is. Then, the task completion rate was calculated. : Successfully completing a task means completing the task without any abnormal exits within the specified time. Then, calculate the load balancing improvement rate. : ,in The load difference coefficient defined for the intelligent scheduling unit. A positive value indicates improved load balancing.

[0071] Furthermore, the feedback mechanism in this embodiment is as follows: The evaluation indicators for the previous 24 hours are calculated daily at midnight, and an evaluation report (including indicator values, trend charts, and optimization suggestions) is generated and pushed to the intelligent scheduling unit 300 via an interface; if (Resource utilization rate is too low) or (Low task completion rate) triggers immediate feedback, and the intelligent scheduling unit adjusts dynamic weight parameters based on the report (such as increasing the weight of resource utilization). Example 2

[0072] like Figure 2 As shown, this embodiment also provides a cloud platform resource intelligent management method based on distributed edge computing. Based on the aforementioned cloud platform resource intelligent management system based on distributed edge computing, the method includes the following steps: S100, Multi-dimensional Resource Acquisition and Preprocessing: Real-time acquisition of hardware operating status and software resource configuration information of distributed edge computing nodes and cloud platforms; anomaly detection, repair and standardization processing of the acquired data; generation of resource datasets containing data type identifiers. S200, Task Feature Analysis and Requirement Generation: Extract feature tags from task requests, match them with a preset task feature dictionary and constraint rule template, convert the feature tags into quantified resource requirement parameters, determine the execution constraints of the task, and generate a structured task requirement report. S300, Dynamic Weighted Scheduling and Resource Allocation: Based on real-time resource data and task requirements, a multi-objective optimization algorithm with dynamic weight adjustment is adopted. The optimization weight is adjusted and optimized in combination with task priority and node load difference. The resource allocation scheme is solved with the objectives of maximizing resource utilization, minimizing task execution latency and optimizing load balance. The scheme is then checked and corrected for load balancing, and standardized resource allocation instructions are generated. S400, Execution Monitoring and Closed-Loop Optimization: Convert resource allocation instructions into executable operations and deploy them, collect resource usage status and key events during task execution in real time, trigger temporary scheduling for abnormal states, evaluate the effect of resource scheduling and feed the results back to the scheduling process, and iteratively optimize scheduling parameters.

[0073] Those skilled in the art will understand that the process of implementing all or part of the steps of the above embodiments can be carried out by hardware or by a program instructing the relevant hardware.

[0074] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A cloud platform resource intelligent management system based on distributed edge computing, characterized in that, include: The resource awareness unit (100) is used to collect and preprocess the dynamic resource data of distributed edge computing nodes and cloud platforms in real time, and obtain hardware operating status and software resource configuration information through multi-dimensional collection interfaces. The task parsing unit (200) is used to process the feature extraction of task requests and determine the resource requirement parameters and execution constraints of the task through a structured parsing process. The intelligent scheduling unit (300) is used to achieve optimal matching of resources and tasks. Based on dynamic resource data and task characteristic parameters, it uses a multi-objective optimization algorithm with dynamic weight adjustment combined with load balancing logic to generate resource allocation instructions. The dynamic weight adjustment dynamically adjusts the matching parameter weights according to real-time resource load differences and task priorities. The execution monitoring unit (400) is used to perform resource scheduling and process tracking, execute allocation instructions through the instruction conversion mechanism, and collect task execution status data in real time.

2. The cloud platform resource intelligent management system based on distributed edge computing according to claim 1, characterized in that, The resource sensing unit (100) includes a hardware acquisition module (110) and a software acquisition module (120), wherein: The hardware acquisition module (110) establishes communication with the hardware monitoring interface of the cloud platform through the hardware interface of the distributed edge node, and collects CPU core utilization, memory page swapping frequency, storage input / output throughput and network port data packet forwarding rate in real time. The software acquisition module (120) interacts with the operating systems of edge nodes and cloud platforms through the application programming interface to collect the number of service instances of deployed applications, the amount of resources occupied by process threads, the version of software dependency libraries, and the service health check status.

3. The cloud platform resource intelligent management system based on distributed edge computing according to claim 2, characterized in that, The resource sensing unit (100) further includes a data preprocessing module (130), which preprocesses the collected data, including the following steps: S130.1 Receive the raw data output by the hardware acquisition module (110) and the software acquisition module (120), add a timestamp to each data item and establish an index; S130.

2. Call the preset resource threshold range parameters to perform point-by-point anomaly detection on the raw data and mark data points that exceed the normal fluctuation range; S130.3 For the marked abnormal data points, a linear interpolation method is used for data repair. The interpolation method generates supplementary data based on the changing trend of three consecutive normal data points before and after the abnormal point. S130.

4. Convert the repaired hardware resource data and software resource data into JSON or CSV format to generate a standardized resource dataset containing data type identifiers.

4. The cloud platform resource intelligent management system based on distributed edge computing according to claim 3, characterized in that, The task parsing unit (200) includes a basic feature library module (210) and a constraint template module (220), wherein: The basic feature library module (210) is used to build and maintain the task feature dictionary, support keyword updates and feature label mapping, receive external feature data through the interface to update the keyword table, and associate the matched keywords with the corresponding task feature labels; The constraint template module (220) is used to build and manage constraint rule templates, supports dynamic loading of templates according to task type, adjusts the threshold range in the template based on historical data, and provides constraint parameter query services through the interface. The constraint rule template contains the verification rules of constraint parameters and the exception handling logic.

5. The cloud platform resource intelligent management system based on distributed edge computing according to claim 4, characterized in that, The task parsing unit (200) further includes a task receiving and verification module (230), a feature extraction module (240), a requirement parameter determination module (250), and a constraint generation module (260), wherein: The task receiving and verification module (230) is used to receive task requests, verify the compliance of data formats, and extract basic information; The feature extraction module (240) calls the task feature dictionary of the basic feature library module (210) to segment the task request text and match keywords to generate a feature tag set containing task type and processing scenario; The demand parameter determination module (250) converts the feature label set into quantitative resource demand parameters; The constraint generation module (260) calls the rule template of the constraint template module (220), matches the constraint parameters corresponding to the task type, determines the maximum allowable delay, encryption level and compatibility requirements, and generates a structured task requirement report.

6. The cloud platform resource intelligent management system based on distributed edge computing according to claim 5, characterized in that: The intelligent scheduling unit (300) uses a multi-objective optimization algorithm with dynamic weight adjustment to achieve optimal matching of resources and tasks; the dynamic weight adjustment mechanism calculates the objective function weights using real-time resource load difference coefficients and task priority coefficients as dual factors; the multi-objective optimization algorithm takes maximizing resource utilization, minimizing task execution latency, and optimizing load balance as optimization objectives, and triggers secondary optimization in conjunction with a preset load balance judgment threshold.

7. The cloud platform resource intelligent management system based on distributed edge computing according to claim 6, characterized in that, The intelligent scheduling unit (300) generates resource allocation instructions in conjunction with load balancing logic, including the following steps: S300.1, Data Acquisition and Load Rate Calculation: The resource acquisition unit (100) transmits real-time resource data, and the task feature parameters of the task parsing unit (200); the real-time resource data includes... CPU utilization of each edge node and memory usage The task characteristic parameters include the task priority identifier; Based on the CPU utilization rate and memory usage Calculate the first Overall load rate of each edge node : S300.2 Calculation of Load Difference and Priority Coefficient: Calculate the load difference coefficient between nodes : Define task priority coefficient Map priority coefficients based on task priority identifiers; S300.3, Dynamic Weight Construction: Calculate the weight correction coefficients of the objective function using a two-factor model: ;in, As a priority influencing factor, As a load balancing influencing factor, and ; Based on the system's preset basic weights, if If the threshold is exceeded, the load balancing weight ratio will be increased. S300.4, Multi-objective optimization solution: Constructing a multi-objective optimization function : ;in, , , The dynamic weights are those modified by S300.3; As a resource utilization rate indicator, For task execution delay metrics, This is a load balancing metric. Iterative optimization using particle swarm optimization, the number of iterations and Associate the data to generate an initial resource allocation plan; S300.5 Load Balancing Verification and Correction: Calculate the load balancing degree of the initial scheme : ； in, for Average overall load rate of each edge node; It is the first The overall load rate of each edge node; like If the preset equilibrium threshold is exceeded, then: Calculate the resource migration amount for overloaded nodes; Select a lightly loaded node as the migration target to complete the secondary optimization; S300.6, Instruction Generation and Verification: Convert the optimization plan into standardized resource allocation instructions; Generate instruction verification code : ; in, The cryptographic hash function is used, and the timestamp identifies the time the instruction was generated.

8. The cloud platform resource intelligent management system based on distributed edge computing according to claim 7, characterized in that, The execution monitoring unit (400) includes an instruction execution module (410) and a status acquisition module (420), wherein: The instruction execution module (410) converts the resource allocation instructions generated by the intelligent scheduling unit (300) into operations that can be executed by the edge nodes, adapts to the resource configuration interfaces of different nodes through a protocol conversion mechanism, and executes the resource allocation operations. The status acquisition module (420) collects task execution status data in real time, including periodically collecting CPU, memory, and network usage data of edge nodes, as well as capturing key events during task execution.

9. The cloud platform resource intelligent management system based on distributed edge computing according to claim 8, characterized in that, The execution monitoring unit (400) further includes an exception handling module (430), a data synchronization module (440), and an effect evaluation module (450), wherein: The anomaly handling module (430) performs anomaly detection and response based on the collected status data, compares the resource usage data with the preset threshold, and generates a temporary scheduling instruction when an anomaly is detected and sends it to the intelligent scheduling unit (300). The data synchronization module (440) synchronizes the status data to the central control node, adopts an incremental transmission mechanism to synchronize only the status change data, and encrypts the transmitted data. The effect evaluation module (450) is used to evaluate the effect of resource scheduling, calculate evaluation indicators, and feed the evaluation results back to the intelligent scheduling unit (300) for parameter adjustment.

10. A cloud platform resource intelligent management method based on distributed edge computing, based on the cloud platform resource intelligent management system based on distributed edge computing as described in any one of claims 1-9, characterized in that, Includes the following steps: S100, Multi-dimensional Resource Acquisition and Preprocessing: Real-time acquisition of hardware operating status and software resource configuration information of distributed edge computing nodes and cloud platforms; anomaly detection, repair and standardization processing of the acquired data; generation of resource datasets containing data type identifiers. S200, Task Feature Analysis and Requirement Generation: Extract feature tags from task requests, match them with a preset task feature dictionary and constraint rule template, convert the feature tags into quantified resource requirement parameters, determine the execution constraints of the task, and generate a structured task requirement report. S300, Dynamic Weighted Scheduling and Resource Allocation: Based on real-time resource data and task requirements, a multi-objective optimization algorithm with dynamic weight adjustment is adopted. The optimization weight is adjusted and optimized in combination with task priority and node load difference. The resource allocation scheme is solved with the objectives of maximizing resource utilization, minimizing task execution latency and optimizing load balance. The scheme is then checked and corrected for load balancing, and standardized resource allocation instructions are generated. S400, Execution Monitoring and Closed-Loop Optimization: Convert resource allocation instructions into executable operations and deploy them, collect resource usage status and key events during task execution in real time, trigger temporary scheduling for abnormal states, evaluate the effect of resource scheduling and feed the results back to the scheduling process, and iteratively optimize scheduling parameters.

Images