New energy centralized control center resource scheduling method and system based on cloud edge collaboration

Abstract

The invention discloses a new energy centralized control center resource scheduling method and system based on cloud edge collaboration, and relates to the related field of new energy intelligent scheduling, and the method comprises the steps: collecting an application task of a new energy centralized control center, decomposing the application task into a plurality of micro services, the plurality of micro-services are deployed in a collaborative environment formed by the cloud center and the plurality of edge nodes; obtaining service attributes of a plurality of micro-services and real-time state information of a collaborative environment, and defining a plurality of placement strategies for the plurality of micro-services based on a dynamic placement algorithm of multi-factor weighted evaluation; and based on a plurality of placement strategies, dynamically adjusting the number of running instances of a plurality of micro-services through an elastic capacity expansion and contraction decision. According to the resource scheduling method and the resource scheduling device, the technical problems of resource allocation rigidness and response lag in the resource scheduling of the existing new energy centralized control center are solved, and the technical effects of improving the resource utilization efficiency and guaranteeing the real-time performance and reliability of services are achieved.

Description

Technical Field

[0001] This application relates to the field of intelligent scheduling of new energy, and in particular to a resource scheduling method and system for a new energy centralized control center based on cloud-edge collaboration. Background Technology

[0002] Against the backdrop of the large-scale development of new energy power systems, centralized monitoring and efficient scheduling of distributed new energy units such as wind farms and photovoltaic power plants are crucial for ensuring stable grid operation and improving energy absorption capacity. Currently, the main approach employs resource allocation based on fixed rules or a centralized scheduling architecture, deploying computing tasks uniformly in cloud data centers or some pre-defined edge nodes. However, existing methods lack dynamic perception and collaborative decision-making capabilities regarding multi-dimensional environmental factors such as network status and service load. This results in difficulties meeting the low-latency requirements of high-real-time services and failing to achieve global resource optimization across cloud and edge nodes when facing real-time fluctuating business demands.

[0003] At present, the resource scheduling of new energy centralized control centers suffers from technical problems such as rigid resource allocation and delayed response. Summary of the Invention

[0004] This application provides a resource scheduling method and system for new energy centralized control centers based on cloud-edge collaboration. It collects application tasks from the new energy centralized control center and breaks them down into multiple microservices, deploying them in a collaborative environment comprised of the cloud center and edge nodes. The system obtains the service attributes of the microservices and the real-time status information of the collaborative environment. A dynamic placement algorithm with multi-factor weighted evaluation determines the optimal deployment location for each microservice and forms a placement strategy. Based on this strategy, combined with elastic scaling decisions, and by dynamically adjusting the number of running instances of the microservices according to real-time operating indicators and external events, the system solves the technical problems of rigid resource allocation and delayed response in existing new energy centralized control center resource scheduling, achieving the technical effects of improving resource utilization efficiency and ensuring the real-time performance and reliability of business operations.

[0005] This application provides a resource scheduling method for a new energy centralized control center based on cloud-edge collaboration, comprising: collecting application tasks of the new energy centralized control center, decomposing the application tasks into multiple microservices, wherein the multiple microservices are deployed in a collaborative environment consisting of a cloud center and multiple edge nodes; obtaining the service attributes of the multiple microservices and the real-time status information of the collaborative environment, defining multiple placement strategies for the multiple microservices based on a dynamic placement algorithm with multi-factor weighted evaluation; and dynamically adjusting the number of running instances of the multiple microservices based on the multiple placement strategies through elastic scaling decisions.

[0006] In a possible implementation, the application tasks of the new energy control center are collected, and the application tasks are decomposed into multiple microservices. The following processing is performed: the original monolithic application of the new energy control center is identified and deconstructed to obtain the application tasks; according to the business domain boundary and functional cohesion principle, the application tasks are split into multiple microservices with a coupling degree less than a preset independent coupling threshold.

[0007] In a possible implementation, the service attributes of the multiple microservices and the real-time status information of the collaborative environment are obtained. Based on a dynamic placement algorithm with multi-factor weighted evaluation, multiple placement strategies are defined for the multiple microservices, and the following processes are performed: multiple strategy files are configured for the multiple microservices based on their service attributes, wherein each strategy file includes weight coefficients of multiple decision factors; based on the multiple strategy files and the real-time status information of the collaborative environment, the comprehensive scores of the multiple microservices deployed in the cloud center and multiple edge nodes are calculated respectively, and the location with the highest comprehensive score is selected as the migration target of the multiple microservices, thereby generating the multiple placement strategies.

[0008] In a possible implementation, the following processing is performed: the multiple decision factors include real-time requirements, data locality requirements, computational intensity, and resource costs.

[0009] In a possible implementation, based on the real-time status information of the multiple policy files and the collaborative environment, the comprehensive scores of the multiple microservices deployed in the cloud center and multiple edge nodes are calculated respectively, and the following processing is performed: the cloud center and multiple edge nodes are used as candidate locations; the network status information of each candidate location is extracted from the real-time status information of the collaborative environment; the scoring model of each decision factor is called to score each microservice, and the factor scores of each microservice in each candidate location are obtained; and the comprehensive score of each microservice in each candidate location is calculated by weighted summation based on the weight coefficients of multiple decision factors corresponding to the microservices in the multiple policy files.

[0010] In a possible implementation, the following process is performed: if the difference in the overall score between the cloud center and any edge node for the same microservice is less than a preset threshold, then the edge node is selected as the migration target.

[0011] In a possible implementation, based on the multiple placement strategies, the number of running instances of the multiple microservices is dynamically adjusted through elastic scaling decisions, and the following processes are performed: Real-time performance metrics for each microservice instance are continuously collected through monitoring agents deployed in the cloud center and various edge nodes. These real-time performance metrics include CPU utilization, memory utilization, network I / O, and average request response time. The real-time performance metrics are compared with preset scaling threshold rules for each microservice to generate scaling strategies corresponding to each of the multiple microservices. These scaling threshold rules include horizontal scaling rules, horizontal scaling rules, and an event-driven pre-scaling mechanism. Based on the scaling strategies corresponding to each of the multiple microservices, the number of running instances of the multiple microservices is dynamically adjusted through an elastic scaling controller.

[0012] In a possible implementation, the following process is performed: when the elastic scaling controller fails to perform a scaling operation on any edge node, a resource exhaustion feedback signal is generated, which carries the target microservice ID and the edge node ID; the feedback signal is used as a dynamic environmental factor to exclude the edge node ID and recalculate the placement strategy of the target microservice ID.

[0013] In a possible implementation, the following processing is performed: The event-driven pre-scaling and scaling-down mechanism includes: real-time monitoring of external events, which include at least weather warnings, power grid dispatch instructions, and equipment planned maintenance notifications; when any external event is received, scaling-up operations are performed on the associated microservice instances according to the preset event-service mapping relationship, wherein the event-driven pre-scaling and scaling-down mechanism has a higher priority than the horizontal scaling-up rules and the horizontal scaling-down rules.

[0014] This application also provides a resource scheduling system for a new energy centralized control center based on cloud-edge collaboration, including: an application task decomposition module, used to collect application tasks of the new energy centralized control center, decompose the application tasks into multiple microservices, and deploy the multiple microservices in a collaborative environment composed of a cloud center and multiple edge nodes; a placement strategy definition module, used to obtain the service attributes of the multiple microservices and the real-time status information of the collaborative environment, and define multiple placement strategies for the multiple microservices based on a dynamic placement algorithm with multi-factor weighted evaluation; and a running instance number adjustment module, used to dynamically adjust the number of running instances of the multiple microservices based on the multiple placement strategies and through elastic scaling decisions.

[0015] The proposed cloud-edge collaborative resource scheduling method and system for new energy centralized control centers first collects application tasks from the new energy centralized control center, decomposes these tasks into multiple microservices, and deploys these microservices in a collaborative environment consisting of a cloud center and multiple edge nodes. Then, it acquires the service attributes of these microservices and the real-time status information of the collaborative environment. Based on a dynamic placement algorithm with multi-factor weighted evaluation, it defines multiple placement strategies for these microservices. Finally, based on these placement strategies, it dynamically adjusts the number of running instances of the microservices through elastic scaling decisions. Through this process, the proposed method and system achieve the technical effects of improving resource utilization efficiency and ensuring the real-time performance and reliability of business operations. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings of the embodiments of the present invention will be briefly described below. Flowcharts are used in this application to illustrate the operations performed by the system according to the embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed precisely in sequence. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from these processes.

[0017] Figure 1 This is a flowchart illustrating the resource scheduling method for a new energy centralized control center based on cloud-edge collaboration, as provided in an embodiment of this application.

[0018] Figure 2 This is a schematic diagram of the structure of a cloud-edge collaborative new energy centralized control center resource scheduling system provided in an embodiment of this application.

[0019] Figure labeling: Application task decomposition module 10, placement strategy definition module 20, running instance number adjustment module 30. Detailed Implementation

[0020] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0021] This application provides a resource scheduling method for a new energy centralized control center based on cloud-edge collaboration, such as... Figure 1 As shown, the method includes: Step S100: Collect application tasks from the new energy control center, decompose the application tasks into multiple microservices, and deploy the multiple microservices in a collaborative environment consisting of the cloud center and multiple edge nodes.

[0022] Specifically, a distributed application data acquisition tool is used to connect to the business system interface of the new energy control center to collect application tasks in batches, including data monitoring, power scheduling, and equipment maintenance. Employing the bounded context analysis method from the Domain-Driven Design framework, combined with a microservice decomposition tool, the collected application tasks are broken down into independently deployed microservices. All microservices are connected to a distributed architecture composed of cloud center and edge nodes through a cloud-edge collaborative network. The edge nodes are deployed locally at the new energy power plant, while the cloud center is deployed in a remote data center, achieving hierarchical collaboration.

[0023] In one possible implementation, application tasks from the new energy control center are collected and decomposed into multiple microservices. Step S100 further includes step S110, identifying and deconstructing the original monolithic application of the new energy control center to obtain the application tasks. Specifically, static code analysis tools are used to decompile and analyze the source code of the monolithic application to identify its core business processes, data flow paths, and functional module boundaries. Dynamic link tracing tools are used to monitor the interface call relationships and data interaction frequency of the monolithic application during runtime to determine the coupling degree of each functional module. Based on the business scenario requirements identified through business interviews, functional units with complete business logic in the monolithic application are extracted into independent application tasks.

[0024] For example, for the original power dispatching unit application of the new energy centralized control center, the three core code modules of power prediction calculation, dispatching instruction generation and instruction issuance and execution were identified by static analysis tools. Dynamic tracing tools confirmed that the calls between the three modules are only implemented through a few interfaces and there is no deep code coupling. Finally, these three modules were deconstructed into three independent application tasks: power prediction task, dispatching instruction generation task, and instruction issuance and execution task.

[0025] Step S120: Based on the business domain boundaries and functional cohesion principles, the application task is divided into multiple microservices with coupling less than a preset independent coupling threshold. Specifically, business domain boundaries are determined using business domain segmentation standards, and functional units with high cohesion characteristics are selected using functional cohesion evaluation indicators such as functional relevance coefficients and data sharing rates. Coupling metric tools are used to calculate the coupling degree between each functional unit, including data coupling, control coupling, and content coupling. A preset independent coupling threshold is set; the lower the value, the lower the coupling degree. Functional units with coupling degrees below this threshold are encapsulated as independent microservices. The interface contracts of each microservice are defined using open application programming interface specifications, determining the request parameters, response format, invocation method, and error code system of the interface. A data model is defined using protocol buffers or JSON mode, specifying the type, length, constraints, and default values ​​of data fields.

[0026] For example, the data acquisition task is broken down into three microservices: photovoltaic module data acquisition, wind turbine data acquisition, and energy storage device data acquisition. A coupling metric tool is used to calculate that the coupling degree between these three microservices is below a preset threshold. An interface contract is defined for the photovoltaic module data acquisition microservice, explicitly supporting calls via Hypertext Transfer Protocol (HTTP). Request parameters include the site number and acquisition time range. The response format is JSON, containing fields such as module number, voltage, current, and power. The data model specifies that the power field is a floating-point type with a value range of 0 to 500 kilowatts.

[0027] Step S200: Obtain the service attributes of the multiple microservices and the real-time status information of the collaborative environment; and define multiple placement strategies for the multiple microservices based on a dynamic placement algorithm with multi-factor weighted evaluation.

[0028] Specifically, the service attributes of each microservice are obtained through a microservice registry, including real-time requirement level, data locality requirements, computational density parameters, and resource cost budget. Real-time status information of the collaborative environment is collected through a cloud-edge collaborative monitoring platform, including CPU utilization, remaining memory, and network bandwidth in the cloud center, and hardware resource utilization, local data storage, and communication latency with site equipment in edge nodes. The dynamic placement algorithm is implemented in Python or Java. Its core logic involves calculating the comprehensive score of each microservice in different deployment locations using multi-factor weighted calculations. The weight coefficients are determined using the analytic hierarchy process (AHP), and the location with the highest comprehensive score is the optimal deployment location. This generates a placement strategy that includes the deployment node ID, deployment time, and resource allocation scheme.

[0029] In one possible implementation, the service attributes of the multiple microservices and the real-time status information of the collaborative environment are obtained. Based on a dynamic placement algorithm with multi-factor weighted evaluation, multiple placement strategies are defined for the multiple microservices. Step S200 further includes step S210, configuring multiple strategy files for the multiple microservices based on their service attributes. Each strategy file includes weight coefficients for multiple decision factors, including real-time requirements, data locality requirements, computational intensity, and resource cost. Specifically, strategy files are written in YAML or JSON format, with each microservice corresponding to an independent strategy file. The weight coefficients of the decision factors are determined using the analytic hierarchy process (AHP) combined with actual business scenarios. First, a decision factor judgment matrix is ​​constructed, and its rationality is verified through a consistency check. Then, the weight coefficients of each factor are calculated, with the sum of the weight coefficients being 1.

[0030] For example, a strategy file is configured for the power control microservice, where the decision factor weight coefficients are configured as follows: real-time requirement 0.4, data locality requirement 0.3, computational intensity 0.2, and resource cost 0.1. This configuration is determined based on the business scenario. Power control needs to respond quickly to device commands, so real-time requirement is the highest, hence the largest weight; data needs to rely on local device data collection, so data locality requirement is the second highest, hence the next highest weight; computational intensity is moderate, hence the lower weight; and resource cost sensitivity is low, hence the lowest weight.

[0031] Step S220: Based on the real-time status information of the multiple policy files and the collaborative environment, calculate the comprehensive scores of the multiple microservices deployed in the cloud center and multiple edge nodes respectively. Select the location with the highest comprehensive score as the migration target of the multiple microservices, and generate the multiple placement strategies. If the difference in comprehensive scores between the cloud center and any edge node for the same microservice is less than a preset threshold, then the edge node is preferentially selected as the migration target. Specifically, the comprehensive score is calculated using a weighted summation formula: Comprehensive Score = (Real-time requirement score × Real-time weight) + (Data locality requirement score × Data locality weight) + (Computational intensity score × Computational intensity weight) + (Resource cost score × Resource cost weight). The scores of each decision factor are converted through quantification rules. For example, real-time requirement score: 100 points for response time ≤ 50ms, 80 points for 50ms < response time ≤ 100ms, 60 points for 100ms < response time ≤ 200ms, and 40 points for response time > 200ms. A preset threshold for the overall score difference is established. If the overall score difference between the cloud center and the edge node is less than or equal to the preset threshold, the edge-first deployment rule is triggered. The placement strategy is defined through the deployment resources of the container orchestration system, including deployment node labels, resource requests and limits, scheduling affinity rules, etc.

[0032] For example, the strategy file for protocol adaptation microservices has weight coefficients of 0.3 for real-time performance, 0.3 for data locality, 0.2 for compute intensity, and 0.2 for resource cost. The cloud center's factor scores are 70 for real-time performance, 60 for data locality, 80 for compute intensity, and 90 for resource cost, with a total score of 70×0.3 + 60×0.3 + 80×0.2 + 90×0.2 = 73. The edge node's factor scores are 90 for real-time performance, 90 for data locality, 70 for compute intensity, and 80 for resource cost, with a total score of 90×0.3 + 90×0.3 + 70×0.2 + 80×0.2 = 84. Edge nodes are selected as migration targets, and a placement strategy is generated.

[0033] In one possible implementation, based on the real-time status information of the multiple policy files and the collaborative environment, the comprehensive scores of the multiple microservices deployed in the cloud center and multiple edge nodes are calculated respectively. Step S220 further includes step S221, using the cloud center and multiple edge nodes as candidate locations. Specifically, through the node discovery function of the cloud-edge collaborative management platform, all available candidate locations are automatically identified and included. Candidate locations must meet preset availability conditions, such as normal network connectivity, hardware resource remaining quantity ≥30%, and a ready running status. A unique identifier is assigned to each candidate location, such as cloud center-001, edge node-001, edge node-002, and associated with its physical location information and hardware configuration information. The availability of candidate locations is monitored in real time through a node health check tool. If a candidate location experiences network interruption, hardware failure, or other problems, it is automatically removed from the candidate location list and re-added after the fault is repaired.

[0034] Step S222: Extract network status information for each candidate location from the real-time status information of the collaborative environment; call the scoring model of each decision factor to score each microservice; obtain the factor score for each microservice at each candidate location; and calculate the comprehensive score for each microservice at each candidate location by weighting and summing the weight coefficients of multiple decision factors corresponding to the microservice in multiple policy files. Specifically, the network status information is extracted through network monitoring tools and includes parameters such as communication latency, bandwidth utilization, packet loss rate, and network jitter at the candidate location. The scoring models for each decision factor are based on preset quantitative rules and calibrated using machine learning algorithms. First, fixed quantitative rules are set for each decision factor. For example, the real-time requirement scoring rules are: 100 points for a response time ≤ 50 milliseconds, 80 points for 50 milliseconds < response time ≤ 100 milliseconds, 60 points for 100 milliseconds < response time ≤ 200 milliseconds, and 40 points for a response time > 200 milliseconds; the data locality requirement scoring rules are: 100 points for local data percentage ≥ 80%, and 80 points for 60% ≤ local data percentage < 80%. Scoring rules for computational intensity: ≥80% CPU utilization per instance earns 100 points; 60% ≤ CPU utilization <80% earns 80 points; 40% ≤ CPU utilization <60% earns 60 points; resource cost scoring rules: ≤1 RMB deployment cost per unit time earns 100 points; 1 RMB < cost ≤3 RMB earns 80 points; 3 RMB < cost ≤5 RMB earns 60 points; cost >5 RMB earns 40 points. Then, a calibration model is trained using logistic regression. The training data consists of historical deployment factor parameters and actual effect score samples. The initial scores output by the quantification rules are input into the calibration model to obtain the final factor scores. Weighted summation is implemented using Python's numerical computation extension library. The weight coefficients in the strategy file are read and matrix operations are performed with the corresponding factor scores to obtain the comprehensive score.

[0035] Step S300: Based on the multiple placement strategies, dynamically adjust the number of running instances of the multiple microservices through elastic scaling decisions.

[0036] Specifically, elastic scaling is implemented based on a container orchestration platform. It associates microservice deployment resources with a horizontal container instance autoscalorie controller and automatically adjusts the number of container instances based on preset scaling rules and real-time performance metrics. The scaling decision-making process includes four stages: metric collection, threshold comparison, policy generation, and execution adjustment. When adjusting the number of instances, it follows the principle of scaling up before scaling down, and prioritizing the shutdown of idle instances during scaling down to avoid impacting service availability.

[0037] For example, the power prediction microservice is deployed on edge node 001 with an initial number of 2 instances. When the horizontal container instance autoscaler controller detects that the CPU utilization of this microservice exceeds the scaling threshold for 5 consecutive minutes, a scaling policy is automatically generated, adjusting the number of instances to 4. Subsequently, when the CPU utilization falls below the scaling-down threshold for 5 consecutive minutes, a scaling-down policy is generated, adjusting the number of instances to 2. During scaling-down, the two last started instances with the lowest request volume are prioritized for shutdown.

[0038] In one possible implementation, based on the multiple placement strategies, the number of running instances of the multiple microservices is dynamically adjusted through elastic scaling decisions. Step S300 further includes step S310, where monitoring agents deployed in the cloud center and various edge nodes continuously collect real-time operational metrics for each microservice instance. These real-time operational metrics include CPU utilization, memory utilization, network I / O, and average request response time. Specifically, the monitoring agents employ a time-series database monitoring tool node exporter and a container monitoring tool component. The node exporter is deployed at the host level of each node, collecting physical resource metrics such as CPU, memory, and network. The container monitoring tool component is deployed at the container level, collecting container resource metrics such as CPU utilization, memory utilization, network I / O, and disk I / O for each microservice container. The average request response time is collected through the service mesh's sidecar agent. The sidecar agent intercepts all inbound and outbound requests from the microservice, records the request start and end times, calculates the response time, and reports it. The frequency of metric collection is configurable. For example, physical resource metrics can be collected every 15 seconds, container resource metrics and request response time metrics can be collected every 5 seconds, and the collected metrics are pushed to the time series database monitoring server for storage via the Hypertext Transfer Protocol interface.

[0039] Step S320: Compare the real-time operating metrics of the instance with the preset scaling threshold rules for each microservice to generate scaling strategies corresponding to the multiple microservices. The scaling threshold rules include horizontal scaling rules, horizontal scaling rules, and an event-driven pre-scaling mechanism. The event-driven pre-scaling mechanism includes: real-time monitoring of external events, including at least weather warnings, power grid dispatch instructions, and planned equipment maintenance notifications; upon receiving any external event, scaling operations are performed on the associated microservice instances according to the preset event-service mapping relationship. The event-driven pre-scaling mechanism has higher priority than the horizontal scaling and horizontal scaling rules. Specifically, the scaling threshold rules are defined through YAML files and stored in the configuration center. For example, a horizontal scaling rule is set to trigger scaling when CPU utilization is ≥80% for ≥5 minutes, memory utilization is ≥75% for ≥5 minutes, or average request response time is ≥100 milliseconds for ≥5 minutes. Each scaling operation adds 1 to 2 instances, with a maximum of 10 instances. For example, the horizontal scaling-down rule is set to trigger scaling-down when the CPU utilization is ≤30% for ≥10 minutes or the memory utilization is ≤40% for ≥10 minutes. Each scaling-down reduces 1 to 2 instances, with a minimum of 2 instances.

[0040] External events are monitored via an event bus implemented using a message queue tool deployed in a cloud center. The event bus receives external events through a Hypertext Transfer Protocol (HTTP) interface and a message queue telemetry transmission protocol. Event parsing uses JSON to verify the event format and extract key information such as event type, trigger time, and impact scope. The event-service mapping table is stored in a relational database using key-value pairs. An event-driven pre-scaling / shrinking mechanism is configured with priority, taking precedence over horizontal scaling rules. When an event is triggered, it directly overrides the regular scaling rules.

[0041] For example, the horizontal scaling rule for the power prediction microservice is a CPU utilization of ≥80% for 5 minutes, while the horizontal scaling rule is a CPU utilization of ≤30% for 10 minutes. When the event bus receives a gale warning event from the meteorological department, after verifying the event format, it queries the event-service mapping table and finds that the event is associated with both the power prediction microservice and the status monitoring microservice. Because the event-driven mechanism has higher priority, the elastic scaling controller does not need to wait for the CPU utilization threshold to be triggered; it directly issues an instruction to the container orchestration system to scale up the number of power prediction microservice instances on edge node 001 from 2 to 4.

[0042] Step S330: Based on the scaling strategies corresponding to the multiple microservices, the number of running instances of the multiple microservices is dynamically adjusted through the elastic scaling controller. Specifically, the elastic scaling controller is implemented using a container orchestration system horizontal container instance autoscaler combined with a custom controller. The custom controller interacts with the container orchestration system application interface server through the container orchestration system client library, listens for changes in scaling strategies, and generates container instance scaling requests when a strategy update is detected. During scaling, the controller selects nodes with sufficient resources to create new microservice instances based on the remaining resources of the deployment nodes. After the new instances start, their availability is verified through health checks, and they are added to the service load balancer pool after passing the health check. During scaling down, the controller filters out instances to be deleted based on factors such as the number of requests and runtime of the instances, sends a termination signal to the instances, and executes the deletion operation after the instances have processed their current requests. The status changes during the scaling process are logged to the log analysis platform for monitoring and troubleshooting.

[0043] Step S331: When the elastic scaling controller fails to perform a scaling operation on any edge node, it generates a resource exhaustion feedback signal. This feedback signal carries the target microservice ID and the edge node ID. Specifically, the criteria for determining scaling operation failure include: the container orchestration system's application interface server returning a resource insufficiency error, instance creation timeout, and the number of health check failures exceeding a threshold. The elastic scaling controller captures scaling failure events by listening to the event resources of the container orchestration system, extracts the microservice deployment name and deployment node name from the event, and generates a feedback signal. The feedback signal is in JSON format and includes the fields: service number, edge node number, error type, error message, and timestamp. The feedback signal is submitted via Hypertext Transfer Protocol to the event receiving interface of the cloud-edge collaborative management platform and simultaneously stored in a key-value database cache for quick retrieval during subsequent recalculation of the placement strategy.

[0044] Step S332: The feedback signal is used as a dynamic environmental factor to exclude edge node IDs and recalculate the placement strategy for the target microservice ID. Specifically, after receiving the feedback signal, the cloud-edge collaborative management platform marks it as a dynamic environmental factor, updates the real-time status information of the collaborative environment, sets the node status corresponding to the edge node number in the feedback signal to resource exhaustion, and adds it to the temporary exclusion list. When recalculating the placement strategy, the dynamic placement algorithm reads the exclusion list, removes the edge node from the candidate positions, and recalculates the comprehensive score of the target microservice at each candidate position according to the updated candidate positions, the weight coefficients of the original strategy file, and the latest real-time node status information, following the method in step S222. The position with the highest comprehensive score is selected as the new deployment position, and a new placement strategy is generated. If all edge nodes are excluded, the cloud center is used as the default deployment position.

[0045] This application embodiment collects application tasks from the new energy centralized control center and decomposes them into multiple microservices. These microservices are then deployed in a collaborative environment consisting of a cloud center and edge nodes. The service attributes of the microservices and the real-time status information of the collaborative environment are obtained. A dynamic placement algorithm with multi-factor weighted evaluation is used to determine the optimal deployment location of each microservice and form a placement strategy. Based on this placement strategy, combined with elastic scaling decisions, and by dynamically adjusting the number of running instances of the microservices according to their real-time operating indicators and external events, the technical problems of rigid resource allocation and delayed response in the existing new energy centralized control center resource scheduling are solved. This achieves the technical effects of improving resource utilization efficiency and ensuring the real-time performance and reliability of business operations.

[0046] In the above text, refer to Figure 1 This paper describes in detail a resource scheduling method for a new energy centralized control center based on cloud-edge collaboration according to an embodiment of the present invention. Next, we will refer to... Figure 2 This invention describes a cloud-edge collaborative resource scheduling system for a new energy centralized control center, based on an embodiment of the present invention.

[0047] The cloud-edge collaborative new energy centralized control center resource scheduling system according to embodiments of the present invention is used to solve the technical problems of rigid resource allocation and delayed response in existing new energy centralized control center resource scheduling, thereby achieving the technical effects of improving resource utilization efficiency and ensuring the real-time performance and reliability of business operations. The cloud-edge collaborative new energy centralized control center resource scheduling system includes: an application task decomposition module 10, a placement strategy definition module 20, and a running instance quantity adjustment module 30.

[0048] The application task decomposition module 10 is used to collect application tasks from the new energy central control center and decompose the application tasks into multiple microservices. The multiple microservices are deployed in a collaborative environment consisting of a cloud center and multiple edge nodes. The placement strategy definition module 20 is used to obtain the service attributes of the multiple microservices and the real-time status information of the collaborative environment, and define multiple placement strategies for the multiple microservices based on a dynamic placement algorithm with multi-factor weighted evaluation. The running instance number adjustment module 30 is used to dynamically adjust the number of running instances of the multiple microservices based on the multiple placement strategies and through elastic scaling decisions.

[0049] The detailed description of the specific configuration of the application task decomposition module 10 is explained as follows: As mentioned above, the application tasks of the new energy central control center are collected and decomposed into multiple microservices. The application task decomposition module 10 may further include: an application task acquisition unit for identifying and deconstructing the original monolithic application of the new energy central control center to obtain the application tasks; and an application task splitting unit for splitting the application tasks into multiple microservices with a coupling degree less than a preset independent coupling threshold according to the business domain boundary and functional cohesion principle.

[0050] The specific configuration of the placement strategy definition module 20 is described in detail below: As mentioned above, the service attributes of the multiple microservices and the real-time status information of the collaborative environment are obtained. Based on a dynamic placement algorithm with multi-factor weighted evaluation, multiple placement strategies are defined for the multiple microservices. The placement strategy definition module 20 may further include: a strategy file configuration unit for configuring multiple strategy files for the multiple microservices based on the service attributes of the multiple microservices, wherein any strategy file includes weight coefficients of multiple decision factors; and a placement strategy generation unit for calculating the comprehensive scores of the multiple microservices deployed in the cloud center and multiple edge nodes based on the multiple strategy files and the real-time status information of the collaborative environment, selecting the location with the highest comprehensive score as the migration target of the multiple microservices, and generating the multiple placement strategies.

[0051] The strategy file configuration unit may further include: the multiple decision factors include real-time requirements, data locality requirements, computational intensity, and resource cost.

[0052] Specifically, based on the real-time status information of the multiple policy files and the collaborative environment, the comprehensive scores of the multiple microservices deployed in the cloud center and multiple edge nodes are calculated respectively. The placement policy generation unit may further include: a candidate location determination subunit for using the cloud center and multiple edge nodes as candidate locations; and a scoring subunit for extracting network status information of each candidate location from the real-time status information of the collaborative environment, calling the scoring model of each decision factor to score each microservice, obtaining each set of factor scores for each microservice in each candidate location, and performing weighted summation based on the weight coefficients of multiple decision factors corresponding to the microservices in the multiple policy files to calculate the comprehensive score of each microservice in each candidate location.

[0053] The placement strategy generation unit may further include: if the difference in the comprehensive score between the cloud center and any edge node for the same microservice is less than a preset threshold, then the edge node shall be selected as the migration target.

[0054] The detailed configuration of the running instance quantity adjustment module 30 is explained below: As mentioned above, based on the multiple placement strategies, the number of running instances of the multiple microservices is dynamically adjusted through elastic scaling decisions. The running instance quantity adjustment module 30 may further include: a real-time instance performance indicator collection unit, which continuously collects real-time instance performance indicators for each microservice through monitoring agents deployed in the cloud center and various edge nodes. The real-time instance performance indicators include CPU utilization, memory utilization, network I / O, and average request response time; a scaling strategy generation unit, which compares the real-time instance performance indicators with preset scaling threshold rules for each microservice to generate scaling strategies corresponding to the multiple microservices. The scaling threshold rules include horizontal scaling rules, horizontal scaling rules, and an event-driven pre-scaling mechanism; and a running instance quantity adjustment unit, which dynamically adjusts the number of running instances of the multiple microservices through an elastic scaling controller based on the scaling strategies corresponding to the multiple microservices.

[0055] The instance number adjustment unit may further include: a feedback signal generation subunit for generating a resource exhaustion feedback signal when the elastic scaling controller fails to perform a scaling operation on any edge node, the feedback signal carrying the target microservice ID and the edge node ID; and a placement strategy recalculation subunit for using the feedback signal as a dynamic environmental factor, excluding the edge node ID, and recalculating the placement strategy for the target microservice ID.

[0056] The scaling-up / scaling strategy generation unit may further include: an event-driven pre-scaling-up / scaling mechanism including: real-time monitoring of external events, the external events including at least weather warnings, power grid dispatch instructions, and equipment planned maintenance notices; when any external event is received, scaling-up operations are performed on the associated microservice instances according to the preset event-service mapping relationship, wherein the event-driven pre-scaling-up / scaling mechanism has a higher priority than the horizontal scaling-up rules and the horizontal scaling-down rules.

[0057] The cloud-edge collaborative new energy central control center resource scheduling system provided in this embodiment of the invention can execute the cloud-edge collaborative new energy central control center resource scheduling method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0058] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0059] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A resource scheduling method for a new energy centralized control center based on cloud-edge collaboration, characterized in that, include: The application tasks of the new energy central control center are collected and decomposed into multiple microservices. These microservices are deployed in a collaborative environment consisting of a cloud center and multiple edge nodes. The service attributes of the multiple microservices and the real-time status information of the collaborative environment are obtained, and multiple placement strategies are defined for the multiple microservices based on a dynamic placement algorithm with multi-factor weighted evaluation. Based on the aforementioned placement strategies, the number of running instances of the various microservices is dynamically adjusted through elastic scaling decisions.

2. The resource scheduling method for a new energy centralized control center based on cloud-edge collaboration as described in claim 1, characterized in that, The application tasks of the new energy centralized control center are collected and decomposed into multiple microservices, including: Identify and deconstruct the original individual applications of the new energy central control center to obtain the application tasks; Based on the principles of business domain boundaries and functional cohesion, the application task is divided into multiple microservices with a coupling degree less than a preset independent coupling threshold.

3. The resource scheduling method for a new energy centralized control center based on cloud-edge collaboration as described in claim 1, characterized in that, Obtain the service attributes of the multiple microservices and the real-time status information of the collaborative environment. Based on a dynamic placement algorithm with multi-factor weighted evaluation, define multiple placement strategies for the multiple microservices, including: Based on the service attributes of the multiple microservices, multiple policy files are configured for the multiple microservices, wherein each policy file includes weight coefficients for multiple decision factors; Based on the real-time status information of the multiple policy files and the collaborative environment, the comprehensive scores of the multiple microservices deployed in the cloud center and multiple edge nodes are calculated respectively. The location with the highest comprehensive score is selected as the migration target of the multiple microservices, and the multiple placement strategies are generated.

4. The resource scheduling method for a new energy centralized control center based on cloud-edge collaboration as described in claim 3, characterized in that, The decision factors include real-time requirements, data locality requirements, computational intensity, and resource costs.

5. The resource scheduling method for a new energy centralized control center based on cloud-edge collaboration as described in claim 3, characterized in that, Based on the real-time status information of the multiple policy files and the collaborative environment, the comprehensive scores of the multiple microservices deployed in the cloud center and multiple edge nodes are calculated, including: The cloud center and multiple edge nodes were selected as candidate locations. The network status information of each candidate position is extracted from the real-time status information of the collaborative environment. The scoring model of each decision factor is called to score each microservice, and the factor score of each microservice at each candidate position is obtained. The comprehensive score of each microservice at each candidate position is calculated by weighted summation based on the weight coefficients of multiple decision factors corresponding to the microservice in multiple policy files.

6. The resource scheduling method for a new energy centralized control center based on cloud-edge collaboration as described in claim 5, characterized in that, If the difference in the overall score between the cloud center and any edge node for the same microservice is less than a preset threshold, then the edge node will be selected as the migration target.

7. The resource scheduling method for a new energy centralized control center based on cloud-edge collaboration as described in claim 1, characterized in that, Based on the aforementioned placement strategies, the number of running instances of the various microservices is dynamically adjusted through elastic scaling decisions, including: The monitoring agents deployed in the cloud center and various edge nodes continuously collect real-time performance metrics for each microservice instance. These real-time performance metrics include CPU utilization, memory utilization, network I / O, and average request response time. The real-time running metrics of the instance are compared with the preset scaling threshold rules for each microservice to generate scaling strategies for the multiple microservices respectively. The scaling threshold rules include horizontal scaling rules, horizontal scaling rules, and an event-driven pre-scaling mechanism. Based on the scaling strategies corresponding to the various microservices, the number of running instances of the various microservices is dynamically adjusted through an elastic scaling controller.

8. The resource scheduling method for a new energy centralized control center based on cloud-edge collaboration as described in claim 7, characterized in that, include: When the elastic scaling controller fails to perform a scaling operation on any edge node, it generates a resource exhaustion feedback signal, which carries the target microservice ID and the edge node ID. The feedback signal is used as a dynamic environmental factor to exclude edge node IDs and recalculate the placement strategy for the target microservice ID.

9. The resource scheduling method for a new energy centralized control center based on cloud-edge collaboration as described in claim 7, characterized in that, Event-driven pre-scaling and scaling mechanisms include: Real-time monitoring of external events, including at least weather warnings, power grid dispatch instructions, and planned equipment maintenance notices; When any external event is received, the associated microservice instance is scaled up according to the preset event-service mapping relationship. The event-driven pre-scaling and scaling-down mechanism has a higher priority than the horizontal scaling-up rules and horizontal scaling-down rules.

10. A new energy centralized control center resource scheduling system based on cloud-edge collaboration, characterized in that: The system is used to implement the cloud-edge collaborative new energy centralized control center resource scheduling method according to any one of claims 1-9, and the system includes: The application task decomposition module is used to collect application tasks from the new energy control center, decompose the application tasks into multiple microservices, and deploy the multiple microservices in a collaborative environment consisting of the cloud center and multiple edge nodes. The placement strategy definition module is used to obtain the service attributes of the multiple microservices and the real-time status information of the collaborative environment, and define multiple placement strategies for the multiple microservices based on a dynamic placement algorithm with multi-factor weighted evaluation. The instance number adjustment module is used to dynamically adjust the number of running instances of the multiple microservices based on the multiple placement strategies and through elastic scaling decisions.

Images