A cloud-edge collaborative micro-service elastic deployment method and system for distributed energy

Abstract

The application discloses a kind of cloud edge collaborative microservice elasticity deployment method and system of distributed energy, belong to energy internet and edge computing technical field, method: in the first cycle time slot, according to task load and front end, rear queue backlog data, utilize Lyapunov optimization theory, solve the total number of container copies required to be deployed for various microservices;In the second cycle time slot, solve the integer linear programming model, determine the container deployment location strategy of the minimum adaptive cost;In each running time slot, according to the container copy number of each edge computing device: the network delay between renewable energy data source and rear task queue backlog, solve the task issue optimization model, determine the task distribution quantity, so as to minimize the total delay of energy management system response.This application matches computing resources and differentiated service demand dynamically through double-time-slot multilevel decoupling optimization, quantifies deployment adjustment cost, reduces the response delay of energy management.

Description

Technical Field

[0001] This invention belongs to the field of energy internet and edge computing technology, specifically relating to a cloud-edge collaborative microservice elastic deployment method and system for distributed energy. Background Technology

[0002] With the acceleration of energy transition, the penetration rate of distributed renewable energy, represented by photovoltaics and wind power, in the power system is constantly increasing. This type of energy is characterized by intermittency, volatility, and geographical dispersion. In order to achieve safe and efficient consumption of a high proportion of renewable energy, the modern power system is evolving into an energy internet, which includes massive data collection points (smart meters, sensors), computing nodes (edge ​​gateways, power plant servers), and control execution units (inverters, energy storage converters).

[0003] As an improvement, to address the volatility of renewable energy, energy management systems need to perform various computationally intensive tasks in real time, such as: predicting photovoltaic / wind power output for the next few minutes to hours based on historical and real-time meteorological data; monitoring power generation and consumption at various nodes within the region and calculating power imbalances; calculating optimal charging and discharging strategies based on electricity price signals, load forecasts, and energy storage state of charge; and demand response management to coordinate adjustable loads and respond to grid dispatch commands. These tasks place extremely high demands on computational latency and reliability. The previous approach was to transmit all data back to the cloud for processing, but this resulted in significant communication latency and bandwidth bottlenecks, making it difficult to meet millisecond-level or second-level real-time control requirements. Therefore, pushing computing power down to the edge, closer to the data source (such as photovoltaic power plants and energy storage stations), has become an option, i.e., adopting a cloud-edge collaborative architecture.

[0004] In this architecture, edge computing devices typically consist of geographically distributed, heterogeneous (with varying CPU / GPU / memory configurations) general-purpose servers or industrial control computers, and the aforementioned energy management microservices are deployed using containerization technologies (such as Docker + Kubernetes). However, when applied to this scenario, the output fluctuations of renewable energy and changes in user load are highly dynamic, causing the computational load of various microservices to fluctuate dramatically. Furthermore, different service types have different resource requirements; power generation prediction services rely more on GPU resources, while load balancing services primarily rely on CPU and memory. Static deployment or simple threshold scaling strategies cannot achieve fine-grained resource allocation based on service type differences on resource-limited edge nodes, resulting in resource waste or service overload. Moreover, dynamically adjusting container deployments on edge devices requires time-consuming operations such as pulling images and starting containers. Existing solutions do not quantify and optimize these adaptive costs, leading to frequent system jitter during load fluctuations. Simultaneously, the network latency differences between different photovoltaic power plants, wind farms, and edge nodes are significant. Existing scheduling strategies do not adequately consider scheduling computing tasks to the edge nodes with the closest network distance and lowest load, increasing task response latency. In summary, the current distributed energy cloud-edge collaborative architecture lacks dynamic coordination between resource supply and differentiated service demands, and there is a relative lack of coordinated optimization between deployment adjustments and network heterogeneity. Summary of the Invention

[0005] This invention provides a cloud-edge collaborative microservice elastic deployment method and system for distributed energy, aiming to solve the problems of insufficient dynamic coordination between resource supply and differentiated service needs, and a lack of collaborative optimization between deployment adjustment and network heterogeneity in the current distributed energy cloud-edge collaborative architecture.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: This invention provides a cloud-edge collaborative microservice elastic deployment method for distributed energy resources, comprising the following steps: At the beginning of each first cycle time slot, based on the real-time monitoring of the task load of various energy management microservices and the backlog data of the front-end and back-end queues, the total number of container replicas required to be deployed for various microservices is solved using Lyapunov optimization theory to minimize the drift penalty function of the energy management system. At the beginning of each second cycle time slot, based on the total number of replicas of various microservice containers, and under the condition of satisfying the computing resource constraints of each edge computing device, an integer linear programming model is solved to determine the container deployment location strategy that minimizes the deployment adaptive cost of the energy management system. The container deployment location strategy is used to characterize the number of container replicas of various microservices deployed on each edge computing device. In each runtime slot, based on the current number of container replicas on each edge computing device, the network latency between each edge computing device and the renewable energy data source, and the backlog of the backend task queues on each edge computing device, the task distribution optimization model is solved to determine the number of tasks to be distributed from the frontend queue to the backend queues of each edge computing device, so as to minimize the total task response latency of the energy management system.

[0007] In some implementations, Lyapunov optimization theory is used to solve for the total number of container replicas, including: Construct a Lyapunov function based on front-end queue backlog and back-end queue backlog, and define Lyapunov drift across the first cycle slot; construct a drift penalty function, which is a weighted sum of Lyapunov drift and total system cost; by minimizing the upper bound of the drift penalty function, derive an optimization problem for solving the total number of container replicas, which is a quadratic programming problem with respect to the total number of container replicas; by solving the extreme points of the quadratic programming problem, obtain the optimal total number of container replicas.

[0008] Furthermore, the total system cost is obtained by weighted summation of deployment resource cost and deployment time cost; specifically: The deployment resource cost is the weighted sum of the CPU, GPU, and memory resources required for a single replica of each type of microservice multiplied by the total number of container replicas; the deployment time cost is the product of the startup time of the microservice container, the time weighting coefficient required for replica deployment, and the increase in the number of container replicas in the current time slot compared to the previous time slot.

[0009] Furthermore, the total system cost is calculated as follows: ; in, The total system cost, To deploy resources at a cost, Due to the time cost of deployment, and These represent the weighting coefficients for deployment resource cost and deployment time cost when calculating the total system cost; The calculation method for deployment resource costs is as follows: ; in, To deploy resources at a cost, The CPU resources required for a single replica of microservice a The GPU resources required for a single replica of microservice a The memory resources required for a single replica of microservice a , , These represent the weighting coefficients of CPU resources, GPU resources, and memory resources when calculating the cost of deployment resources. The total number of container replicas for microservice a; The deployment time cost is calculated as follows: ; in, Due to the time cost of deployment, For the startup time of microservice container 'a', This represents the weighting factor of the time required to deploy replicas when calculating the deployment time cost. This represents the total number of container replicas for microservice 'a' in the current time slot. This represents the total number of container replicas of microservice 'a' in the previous time slot.

[0010] In some implementations, the integer linear programming model aims to minimize the normalized deployment adaptive cost, with constraints on the deployment adaptive cost including: The total resource requirements of all container replicas deployed on each edge computing device for CPU, GPU, and memory resources shall not exceed the total resource limit of that edge computing device; the sum of the number of container replicas deployed on all edge computing devices for each microservice shall equal the total number of replicas of each type of microservice container. By introducing a first variable to indicate whether the microservice is deployed on an edge computing device, a second variable to indicate whether the container image needs to be downloaded, and a third variable to indicate whether the deployment has been scaled up, a linear relationship is established between the first, second, and third variables and the number of deployments in the current time slot and the number of deployments in the previous time slot, respectively.

[0011] Furthermore, the normalized deployment adaptive cost is the ratio of the deployment adaptive cost to the maximum value of the overall system deployment adaptive cost; the deployment adaptive cost is obtained by summing the upper bound of image download time and the upper bound of container startup time; the upper bound of image download time is determined by the product of the ratio of the size of the image layer that the microservice needs to download to the download speed of the edge computing device from the external image repository, and the first and second variables; the upper bound of container startup time is determined by the product of the third variable and the startup time of the microservice container.

[0012] In some implementations, the task delivery optimization model aims to minimize the overall latency cost of task response. The overall latency cost is obtained by weighted summation of energy data transmission latency cost and task processing queuing latency cost. The energy data transmission latency cost is the sum of the products of the network latency between each edge computing device and the renewable energy data source and the number of tasks distributed to that edge computing device. The task processing queuing latency cost is the sum of the products of the number of tasks distributed to each edge computing device, the backlog of the task queue at the backend of that edge computing device plus one, and the number of container replicas of the corresponding microservice on that edge computing device. The constraints of the task distribution optimization model include: the sum of the number of tasks distributed to each edge computing device is equal to the number of tasks that the system can process, and the number of tasks distributed to a single edge computing device does not exceed the maximum processing capacity of the edge computing device.

[0013] In some implementations, the objective function of the task distribution optimization model is: ; in, The overall latency cost of task response, The cost of delays in energy data transmission The cost of queuing delays for task processing and These represent the weighting coefficients for transmission delay cost and processing delay cost when calculating the overall delay cost of the task response; The calculation method for energy data transmission delay cost is as follows: ; in, The network latency between edge computing device x and renewable energy data source at time t. Let be the number of microservices of type a that are distributed to edge computing device x at time t. A collection of edge computing devices, A collection of microservices; The calculation method for task processing queuing delay cost is as follows: ; in, The backend task queue of a microservice of type a on edge computing device x at time t is backlogged. Let t be the number of container replicas of microservice a deployed on edge computing device x.

[0014] In some implementations, the backlog of the front-end queue in the next time slot is equal to the sum of the front-end queue backlog in the current time slot minus the number of tasks distributed to each edge computing device and the number of newly arrived tasks in the current time slot; the backlog of the back-end queue in the next time slot does not exceed the sum of the back-end queue backlog in the current time slot minus the number of tasks processed in the current time slot minus the number of tasks distributed to the edge computing device. The duration of the first cycle time slot is greater than the duration of the second cycle time slot, and the duration of the second cycle time slot is greater than the duration of the running time slot; the first cycle time slot and the second cycle time slot satisfy an integer multiple relationship.

[0015] This invention also provides a cloud-edge collaborative microservice elastic deployment system for distributed energy, used to implement the aforementioned cloud-edge collaborative microservice elastic deployment method for distributed energy, including a container replica number dynamic calculation module, a container replica deployment location selection module, and a microservice delivery location selection module; wherein: The container replica number dynamic calculation module is used to: at the beginning of each first cycle time slot, based on the real-time monitoring of the task load of various energy management microservices and the backlog data of the front-end and back-end queues, use Lyapunov optimization theory to solve for the total number of container replicas required to be deployed for various microservices that minimize the drift penalty function of the energy management system. The container replica deployment location selection module is used to: at the beginning of each second cycle time slot, based on the total number of replicas of various microservice containers, and under the condition of satisfying the computing resource constraints of each edge computing device, solve an integer linear programming model to determine the container deployment location strategy that minimizes the adaptive deployment cost of the energy management system. The container deployment location strategy is used to characterize the number of container replicas of various microservices deployed on each edge computing device. The microservice delivery location selection module is used to: in each runtime slot, based on the number of container replicas of each edge computing device, the network latency between each edge computing device and the renewable energy data source, and the backlog of the backend task queues of each edge computing device, determine the number of tasks to be distributed from the frontend queue to the backend queues of each edge computing device by solving the task delivery optimization model, so as to minimize the total task response latency of the energy management system.

[0016] Compared with existing technologies, the cloud-edge collaborative microservice elastic deployment method and system for distributed energy in this invention has the following advantages: This invention, through long-term resource elastic planning, can effectively track the minute-level slow fluctuations in renewable energy output and dynamically calculate the number of container replicas, thus relatively avoiding resource waste or computational bottlenecks. Through short-term deployment location optimization and sub-second task distribution, it can quickly respond to changes in network latency and differences in device load, scheduling computing tasks to the most suitable edge nodes, reducing task response latency and meeting the real-time requirements of energy management. This invention improves the resource utilization of the entire edge cluster by differentially deploying different types of microservices (CPU-intensive, GPU-intensive, and memory-intensive) to heterogeneous edge nodes. The hierarchical optimization mechanism highly decouples the resource planning, location selection, and task distribution modules, facilitating independent upgrades and expansions, and enabling relatively flexible adaptation to more diverse future energy management application scenarios. Furthermore, based on Lyapunov optimization theory, the algorithm provides provable performance guarantees between system cost and queue backlog, obtaining the optimal solution for deployment location through integer linear programming. This invention decomposes the complex energy management task scheduling and microservice deployment problem into three collaborative optimization sub-problems, which sequentially solve the decisions on how much computing resources to deploy, where to deploy computing resources, and to whom to distribute computing tasks in a dynamic energy environment, thereby achieving the goals of efficient utilization of computing resources and real-time energy management tasks. Attached Figure Description

[0017] The accompanying drawings are provided to further understand the invention and constitute a part of this invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0018] Figure 1 This is a schematic diagram of the architecture of a cloud-edge collaborative microservice elastic deployment system for distributed energy according to the present invention. Figure 2 This is a schematic diagram of the internal resources of the edge computing device in the cloud-edge collaborative microservice elastic deployment method for distributed energy according to the present invention. Figure 3 This is a schematic diagram of the system front-end and back-end queue model and task processing flow in an embodiment of a cloud-edge collaborative microservice elastic deployment method for distributed energy according to the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0020] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0021] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0022] It should be noted that the apparatus and methods disclosed in the embodiments herein can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments herein. In this regard, each block in a flowchart or block diagram may represent a module, program, or part of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system to perform the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0023] In addition, the functional modules in the various embodiments of this article can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0024] How can we provide an intelligent, elastic microservice deployment method specifically designed for distributed renewable energy systems, oriented towards cloud-edge collaborative computing, to optimize dynamic resource adaptation, geographic heterogeneity awareness, differentiated service scheduling, and deployment cost control?

[0025] Based on this, the present invention provides a cloud-edge collaborative microservice elastic deployment method for distributed energy, comprising the following steps: At the beginning of each first cycle time slot, based on the real-time monitoring of the task load of various energy management microservices and the backlog data of the front-end and back-end queues, the total number of container replicas required to be deployed for various microservices is solved using Lyapunov optimization theory to minimize the drift penalty function of the energy management system. At the beginning of each second cycle time slot, based on the total number of replicas of various microservice containers, and under the condition of satisfying the computing resource constraints of each edge computing device, an integer linear programming model is solved to determine the container deployment location strategy that minimizes the deployment adaptive cost of the energy management system. The container deployment location strategy is used to characterize the number of container replicas of various microservices deployed on each edge computing device. In each runtime slot, based on the current number of container replicas on each edge computing device, the network latency between each edge computing device and the renewable energy data source, and the backlog of the backend task queues on each edge computing device, the task distribution optimization model is solved to determine the number of tasks to be distributed from the frontend queue to the backend queues of each edge computing device, so as to minimize the total task response latency of the energy management system.

[0026] This invention utilizes Lyapunov optimization theory in the first time slot to dynamically calculate the total number of container replicas based on real-time monitoring of microservice task load and queue backlog status. This effectively tracks the slow-dynamic characteristics of renewable energy output fluctuations and load changes, achieving optimal planning of computing resource supply while ensuring system queue stability. In the second time slot, this invention solves an integer linear programming model to determine the optimal deployment location of container replicas. It incorporates the differentiated resource constraints of geographically heterogeneous edge devices into the decision-making process, enabling differentiated location selection based on the resource requirements of different types of microservices, maximizing resource utilization efficiency with limited edge computing resources. Furthermore, this invention determines the number of tasks to be distributed by solving the task distribution optimization model in each runtime slot. It considers the real-time network latency differences between each edge device and the renewable energy data source, as well as the backend task queue backlog status on each device. This allows computing tasks to be dynamically distributed to the edge node with the closest network distance and the lightest current load for processing, collaboratively optimizing the overall system computing cost and resulting in better real-time task response.

[0027] In some embodiments, the present invention is carried out according to the following steps: Step 1 1) such as Figure 1 As shown, the present invention provides a system comprising multiple distributed renewable energy sites (such as photovoltaic power plants, energy storage stations, and industrial and commercial parks). Figure 1 This is a schematic diagram of the system architecture. Each site deploys an edge computing device (such as an edge gateway or server), and the devices are connected to each other and to the central cloud via industrial Ethernet or 5G. All edge devices constitute a geographically heterogeneous computing cluster.

[0028] A user initiates a service request to the system (e.g., predict the photovoltaic output of power plant A for the next 5 minutes). The request first reaches the task distribution server, where the system's core components make decisions based on the method of this invention: determining the number of replicas for each energy microservice container; determining on which edge device these containers should be deployed; and determining which device to distribute the request to for processing. The decision results are then distributed to each edge node for execution via a container orchestration engine (such as Kubernetes). A Pod serves as the smallest unit of service deployment.

[0029] The basic workflow of the system is as follows: Users first send service requests to the system. These requests are routed through a task distribution server and distributed to different edge devices and cloud servers according to server deployment, device load, and device access latency, based on a specific strategy. Simultaneously, the system updates the deployment of various services on different devices in real time based on the load of each task. After completing the corresponding computation task, the results are returned to the user. In geographically heterogeneous computing environments, edge devices closer to the user often have lower network latency than cloud servers. Therefore, while ensuring good service quality, if each microservice can be reasonably allocated computing resources and deployed on suitable edge devices, the system's computing resource reserves and user-perceived latency will be reduced, and system resource utilization will be effectively improved.

[0030] 2) such as Figure 2 As shown, assume the system contains a number of edge devices. Edge devices use It is believed that they can be uniformly represented as a set of computing devices. For any edge device , Indicates edge device x CPU resources; use Indicates edge device x GPU resources; use Indicates edge device x Memory resources; Indicates device x Download speed from external mirror repositories; for edge devices x Between users t Delayed use of time express.

[0031] The system deploys services using containers. Assume the system provides a total of [number] services. Regarding the services provided by the system a The various computing resources required by the corresponding containers are represented as follows: (Using...) Indicates the CPU resources required for server deployment; use Indicates the GPU resources required for server deployment; using Indicates the memory resources required for server deployment; use Indicates the startup time required for server deployment; use This indicates the size of the additional image layer that needs to be downloaded.

[0032] Assuming in In the gaps of time, there are Each of the users sent a request to the system, among which the first user sent a request to the system. A service request initiated by a user within a time slot can be represented as: So, regarding the service a exist t The rate at which time-slot service requests arrive at the system can be expressed as The number of requests arriving for all services in the system can be expressed as Assuming service The request has reached the limit. Therefore, the following relation holds: (4-1); (4-2); (4-3); The entire system collaboratively processes service requests through service container replicas deployed on geographically heterogeneous devices. Assuming within a time slot... At that time, the system is in the device Deployment services The number of container replicas is Due to the limitations of computing resources on each device, there is a maximum limit to the number of deployable replicas per device. Assuming that on a device... x The number of tasks processed by the i-th replica within time slot t is Its processing speed will likely vary depending on the tasks required to be processed in different time slots, but it can be assumed that there is a maximum replica processing speed. Make ,in The maximum allowable response latency for the task. For the entire system, the total number of container replicas deployed for service 'a' is considered to be... The service request processing rate for service a is The service request processing rate for service a on device x is .

[0033] like Figure 3As shown, the system can be viewed as a discrete-time system model. In each time slot t, users randomly generate new service requests. These requests first arrive at the front-end queue of the corresponding service a. Then, tasks are distributed based on service deployment, system load, and routing latency of user requests. The tasks are then queued in the backend queue of distribution device x. Backlog, and the backlog of backend queues on all devices deploying service a is represented as .here and Let represent the number of service request backlogs in the front-end queue and the back-end queue at time slot t, respectively. Then, we can obtain the following relationship: (4-4); Suppose that at time slot t, the number of requests for service a arriving in the system is . The number of requests the system processes for service a is The number of requests processed on device x is The number of service requests for service a distributed to device x is For requests distributed from the front-end queue to the back-end queue, the following relation holds: (4-5); To ensure that task distribution matches system processing efficiency, the task distribution in this invention satisfies the following relationship: (4-6); Therefore, the relevant queue backlog in the system satisfies: (4-7); (4-8); (4-9); During the deployment of replicas, the system needs to increase its resource usage to meet load response requirements. The system cost can be divided into the following two parts: Part 1, Deployment Resource Costs: Assume that at time slot t, the deployment resource cost for service a is... The calculation method is as follows: (4-10); In the formula, This represents the weighting coefficient of CPU resources in the calculation cost. This represents the weighting coefficient of GPU resources in computational cost. This represents the weighting coefficient of memory resources when calculating costs.

[0034] Part Two, Deployment Time Cost: Assume that at time slot t, the deployment time cost of service a is... The calculation method is as follows: (4-11); In the formula, The weighting factor for the time required to deploy replicas when calculating costs.

[0035] Therefore, the total system cost The calculation method is as follows: (4-12); In the formula, and These represent the weighting coefficients for deployment resource and deployment time costs when calculating costs, respectively.

[0036] Step 2: The microservice deployment plan is broken down into three phases: First, based on the load of various services deployed in the system and the system status, the number of container replicas required for each type of service is determined; then, based on the task load and resource usage of each edge device, the deployment location of each container replica within the system is determined; finally, based on the service load of each device and the network latency relative to the user, the location for task dispatch and processing is determined. The system will meet the requirements at each time slot. Adjustments are made in real time, and the required computing resources are deployed according to the corresponding optimization algorithm; the system will meet the requirements in each time slot. When doing so, consider adjusting the deployment location of the service. and satisfy ,in The specific deployment process for the three phases is as follows: S1, Calculation of the number of container replicas (corresponding to long-period time slots) (e.g., 1-5 minutes). This stage addresses the question of how much to deploy. Within each cycle... At the start time, the system performs the following operations to obtain the number of deployment replicas of various services a in time slot t. : (1) Observe the relevant system status. The system will listen for task requests from each user and observe the number of task requests for service a within time slot t. And the backlog of service a in the front-end and back-end queues of the current time slot system. and wait; (2) Formulate container deployment strategy. Based on the current system parameters and the observed system state, the system solves the Lyapunov optimization problem (4-13) to obtain the number of deployed replicas of service a in the current time slot t. The Lyapunov optimization problem is defined as follows: (4-13); In the formula, V is a non-negative control parameter used to balance system service response latency and total system cost. For microservices The maximum number of container replicas that can be deployed.

[0037] (3) Update the system task queue backlog. Based on the system parameters, the observed system status and the system deployment strategy, update the task backlog status of the system front-end queue and back-end queue respectively using Equations (4-7) and (4-9).

[0038] S2, Container replica deployment location selection (corresponding to short-cycle time slots) ,and (e.g., 10-30 seconds). Based on the number of container replicas deployed as determined in S1. This addresses the question of where to deploy the system. In each cycle... At the initial moment, solve the following optimization problem to determine which edge devices these replicas are specifically placed on, i.e., the deployment location selection of container replicas for the entire system in the current time slot, denoted as . ,in This indicates that the current time slot t is in the device. Deployment services The number of container copies.

[0039] The problem is modeled as an integer linear programming problem as shown in (4-14). The optimization objective is to minimize the cost incurred by the system due to deployment adjustments, primarily including the time to pull container images from new devices and the time to start containers at new locations. Constraints include: the resource requirements (CPU, GPU, memory) of all containers on each device cannot exceed the device capacity. Solving this ILP model yields the optimal deployment location matrix. .

[0040] (4-14); In the formula, The deployment plan for the previous time slot; This is the upper bound of the image download time. This serves as an upper bound for container startup time. The first variable represents whether microservice a is deployed on edge device x; The second variable indicates whether the image needs to be downloaded when microservice a is deployed on edge device x; The third variable indicates whether the deployment of microservice a on edge device x has been scaled up; This represents the maximum adaptive cost of the overall system.

[0041] Deployment Adaptive Cost The calculation method is as follows: ; Normalized deployment adaptive cost The calculation method is as follows: .

[0042] S3, Microservice distribution location selection (corresponding to each system runtime slot) (e.g., 1 second or sub-second). This stage addresses the question of "who gets the task." Within each fine-grained time slot... The system needs to distribute arriving energy data and computing requests to edge devices that have already deployed corresponding microservice replicas. This decision is based on the current real-time state of the system: the number of service replicas on each device, the network latency between the device and the data source (such as photovoltaic inverters and weather stations), and the backlog of backend task queues for the service on the device. The specific distribution location selection process is as follows: (1) Observe the system status. Observe the queue backlog of service a on each edge device x. Network communication latency on edge devices And the number of container replicas of service a on each edge device x, selected based on the S2 container deployment location. wait.

[0043] (2) Microservice distribution location selection strategy. Based on the known system state, the optimization problem (4-15) is solved to obtain the strategy for allocating all types of services to all edge devices at the current time. ,in Let represent the number of services of type 'a' distributed to edge device x at time t, and let represent the actual task distribution based on this strategy. The optimization problem to be solved is defined as follows: (4-15); in, Indicates edge device Upload service Maximum task processing capacity This represents the total cost of all edge server service responses. This represents the total cost of a service response from an edge server. Indicates the cost of sending the task. Indicates the cost of task processing; and These represent the computational weights for task sending and task processing, respectively, when calculating the overall cost of the system's overall task response. The calculation method for these parameters is as follows: (4-16); Thus, through the above three-stage strategy (S1, S2, and S3), a cloud-edge collaborative microservice elastic deployment strategy for a distributed energy system can be realized, yielding the number of container replicas for any service a in each time slot t. The number of deployments of any edge device x And the service distribution volume of the final specific edge device. .

[0044] This invention also provides a cloud-edge collaborative microservice elastic deployment system for distributed energy, including a container replica number dynamic calculation module, a container replica deployment location selection module, and a microservice distribution location selection module; wherein: The container replica number dynamic calculation module is used to: at the beginning of each first cycle time slot, based on the real-time monitoring of the task load of various energy management microservices and the backlog data of the front-end and back-end queues, use Lyapunov optimization theory to solve for the total number of container replicas required to be deployed for various microservices that minimize the drift penalty function of the energy management system. The container replica deployment location selection module is used to: at the beginning of each second cycle time slot, based on the total number of replicas of various microservice containers, and under the condition of satisfying the computing resource constraints of each edge computing device, solve an integer linear programming model to determine the container deployment location strategy that minimizes the adaptive deployment cost of the energy management system. The container deployment location strategy is used to characterize the number of container replicas of various microservices deployed on each edge computing device. The microservice delivery location selection module is used to: in each runtime slot, based on the number of container replicas of each edge computing device, the network latency between each edge computing device and the renewable energy data source, and the backlog of the backend task queues of each edge computing device, determine the number of tasks to be distributed from the frontend queue to the backend queues of each edge computing device by solving the task delivery optimization model, so as to minimize the total task response latency of the energy management system.

[0045] In some embodiments, the system of the present invention is deployed in the following manner to implement a cloud-edge collaborative microservice elastic deployment method for distributed energy, the system comprising: 1) Energy System Status Monitoring Module: Used to monitor data of distributed renewable energy systems in real time, including the output of each power generation unit, the demand of the load unit, the state of charge of the energy storage unit, and the network latency between each edge computing device and the data source.

[0046] 2) Container Replica Count Dynamic Calculation Module: Connected to the energy system status monitoring module, used for each first cycle time slot. Triggered, the dynamic calculation of the number of container replicas is executed, and the total number of container replicas for various energy management microservices is planned.

[0047] 3) Container replica deployment location selection module: Connected to the dynamic resource planning module and the energy system status monitoring module, it is used in each second cycle time slot. Triggered, the container replica deployment location selection is executed, and the specific deployment plan of the container on each edge computing device is output.

[0048] 4) Microservice delivery location selection module: Connected to the energy system status monitoring module and container location decision module, it is used to trigger the microservice delivery location selection in each time slot and output the specific distribution strategy of energy data and management tasks to each edge computing device.

[0049] 5) Container orchestration execution engine: Connected to the dynamic resource planning module, container location decision module and task distribution and scheduling module, it receives the decision results of the above modules and drives the workload on each edge computing device node through the Kubernetes cluster control plane, and actually completes the container creation, destruction, scaling up and down and task load balancing of the energy management microservice.

[0050] In summary, this invention addresses the challenges of geographically dispersed, heterogeneous computing resources, and high real-time data requirements in distributed renewable energy systems such as photovoltaics, wind power, and energy storage. At the first time slot level, based on Lyapunov optimization theory, it dynamically plans the total number of container replicas required for various microservices (power generation forecasting, load balancing, energy storage scheduling, etc.) according to the task load and queue status of these microservices, balancing computational resource costs with system stability. At the second time slot level, an integer linear programming model selects the optimal deployment location for the planned container replicas under edge device resource constraints, minimizing the adaptive cost of deployment adjustments. In each runtime slot, based on device load, network latency, and queue backlog, a task distribution optimization model is solved to achieve latency-aware energy data and management task distribution. By decoupling resource planning, location selection, and task distribution, this invention minimizes the overall system computational cost while ensuring the real-time performance and reliability of energy management tasks, thus improving the edge computing resource utilization and responsiveness of distributed renewable energy systems to a certain extent and demonstrating certain engineering applicability.

[0051] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Anyone skilled in the art can readily implement the present invention according to the description and above. Any modifications, alterations, or equivalent variations made using the technical content disclosed above are equivalent embodiments of the present invention. Furthermore, any modifications, alterations, or variations made to the above embodiments based on the essential technology of the present invention are still within the protection scope of the present invention.

Claims

1. A cloud-edge collaborative microservice elastic deployment method for distributed energy, characterized in that, Includes the following steps: At the beginning of each first cycle time slot, based on the real-time monitoring of the task load of various energy management microservices and the backlog data of the front-end and back-end queues, the total number of container replicas required to be deployed for various microservices is solved using Lyapunov optimization theory to minimize the drift penalty function of the energy management system. At the beginning of each second cycle time slot, based on the total number of replicas of various microservice containers, and under the condition of satisfying the computing resource constraints of each edge computing device, an integer linear programming model is solved to determine the container deployment location strategy that minimizes the deployment adaptive cost of the energy management system. The container deployment location strategy is used to characterize the number of container replicas of various microservices deployed on each edge computing device. In each runtime slot, based on the current number of container replicas on each edge computing device, the network latency between each edge computing device and the renewable energy data source, and the backlog of the backend task queues on each edge computing device, the task distribution optimization model is solved to determine the number of tasks to be distributed from the frontend queue to the backend queues of each edge computing device, so as to minimize the total task response latency of the energy management system.

2. The cloud-edge collaborative microservice elastic deployment method for distributed energy according to claim 1, characterized in that, Solving for the total number of container replicas using Lyapunov optimization theory includes: Construct a Lyapunov function based on front-end queue backlog and back-end queue backlog, and define Lyapunov drift across the first cycle slot; construct a drift penalty function, which is a weighted sum of Lyapunov drift and total system cost; by minimizing the upper bound of the drift penalty function, derive an optimization problem for solving the total number of container replicas, which is a quadratic programming problem with respect to the total number of container replicas; by solving the extreme points of the quadratic programming problem, obtain the optimal total number of container replicas.

3. The cloud-edge collaborative microservice elastic deployment method for distributed energy according to claim 2, characterized in that, The total system cost is obtained by weighted summation of deployment resource cost and deployment time cost; specifically: The deployment resource cost is the weighted sum of the CPU, GPU, and memory resources required for a single replica of each type of microservice multiplied by the total number of container replicas; the deployment time cost is the product of the startup time of the microservice container, the time weighting coefficient required for replica deployment, and the increase in the number of container replicas in the current time slot compared to the previous time slot.

4. The cloud-edge collaborative microservice elastic deployment method for distributed energy as described in claim 3, characterized in that, The total system cost is calculated as follows: ； in, The total system cost, To deploy resources at a cost, Due to the time cost of deployment, and These represent the weighting coefficients for deployment resource cost and deployment time cost when calculating the total system cost; The calculation method for deployment resource costs is as follows: ； in, To deploy resources at a cost, The CPU resources required for a single replica of microservice a The GPU resources required for a single replica of microservice a The memory resources required for a single replica of microservice a , , These represent the weighting coefficients of CPU resources, GPU resources, and memory resources when calculating the cost of deployment resources. The total number of container replicas for microservice a; The deployment time cost is calculated as follows: ； in, Due to the time cost of deployment, For the startup time of microservice container 'a', This represents the weighting factor of the time required to deploy replicas when calculating the deployment time cost. This represents the total number of container replicas for microservice 'a' in the current time slot. This represents the total number of container replicas of microservice 'a' in the previous time slot.

5. The cloud-edge collaborative microservice elastic deployment method for distributed energy according to claim 1, characterized in that, The integer linear programming model aims to minimize the normalized deployment adaptive cost. The constraints on the deployment adaptive cost include: The total resource requirements of all container replicas deployed on each edge computing device for CPU, GPU, and memory resources shall not exceed the total resource limit of that edge computing device; the sum of the number of container replicas deployed on all edge computing devices for each microservice shall equal the total number of replicas of each type of microservice container. By introducing a first variable to indicate whether the microservice is deployed on an edge computing device, a second variable to indicate whether the container image needs to be downloaded, and a third variable to indicate whether the deployment has been scaled up, a linear relationship is established between the first, second, and third variables and the number of deployments in the current time slot and the number of deployments in the previous time slot, respectively.

6. The cloud-edge collaborative microservice elastic deployment method for distributed energy according to claim 5, characterized in that, The normalized deployment adaptive cost is the ratio of the deployment adaptive cost to the maximum value of the overall system deployment adaptive cost; The cost of adaptive deployment is obtained by summing the upper bound of image download time and the upper bound of container startup time; The upper bound of image download time is determined by the ratio of the size of the image layer that the microservice needs to download to the download speed of the edge computing device from the external image repository, and the product of the first and second variables; the upper bound of container startup time is determined by the product of the third variable and the startup time of the microservice container.

7. The cloud-edge collaborative microservice elastic deployment method for distributed energy according to claim 1, characterized in that, The task delivery optimization model aims to minimize the overall latency cost of task response. The overall latency cost is obtained by weighted summation of energy data transmission latency cost and task processing queuing latency cost. The energy data transmission latency cost is the sum of the products of the network latency between each edge computing device and the renewable energy data source and the number of tasks distributed to that edge computing device. The task processing queuing latency cost is the sum of the products of the number of tasks distributed to each edge computing device, the backlog of the task queue at the backend of that edge computing device plus one, and the number of container replicas of the corresponding microservice on that edge computing device. The constraints of the task distribution optimization model include: the sum of the number of tasks distributed to each edge computing device is equal to the number of tasks that the system can process, and the number of tasks distributed to a single edge computing device does not exceed the maximum processing capacity of the edge computing device.

8. The cloud-edge collaborative microservice elastic deployment method for distributed energy according to claim 1, characterized in that, The objective function of the task distribution optimization model is: ； in, The overall latency cost of task response, The cost of delays in energy data transmission The cost of queuing delays for task processing and These represent the weighting coefficients for transmission delay cost and processing delay cost when calculating the overall delay cost of the task response; The calculation method for energy data transmission delay cost is as follows: ； in, The network latency between edge computing device x and renewable energy data source at time t. Let be the number of microservices of type a that are distributed to edge computing device x at time t. A collection of edge computing devices, A collection of microservices; The calculation method for task processing queuing delay cost is as follows: ； in, The backend task queue of a microservice of type a on edge computing device x at time t is backlogged. Let t be the number of container replicas of microservice a deployed on edge computing device x.

9. The cloud-edge collaborative microservice elastic deployment method for distributed energy according to claim 1, characterized in that, The backlog of the front-end queue in the next time slot is equal to the sum of the front-end queue backlog in the current time slot minus the number of tasks distributed to each edge computing device and the number of newly arrived tasks in the current time slot; the backlog of the back-end queue in the next time slot does not exceed the sum of the back-end queue backlog in the current time slot minus the number of tasks processed in the current time slot minus the number of tasks distributed to that edge computing device. The duration of the first cycle time slot is greater than the duration of the second cycle time slot, and the duration of the second cycle time slot is greater than the duration of the running time slot; the first cycle time slot and the second cycle time slot satisfy an integer multiple relationship.

10. A cloud-edge collaborative microservice elastic deployment system for distributed energy, used to implement the cloud-edge collaborative microservice elastic deployment method for distributed energy as described in any one of claims 1-9, characterized in that, This includes a module for dynamically calculating the number of container replicas, a module for selecting the deployment location of container replicas, and a module for selecting the location for microservice deployment; among which: The container replica number dynamic calculation module is used to: at the beginning of each first cycle time slot, based on the real-time monitoring of the task load of various energy management microservices and the backlog data of the front-end and back-end queues, use Lyapunov optimization theory to solve for the total number of container replicas required to be deployed for various microservices that minimize the drift penalty function of the energy management system. The container replica deployment location selection module is used to: at the beginning of each second cycle time slot, based on the total number of replicas of various microservice containers, and under the condition of satisfying the computing resource constraints of each edge computing device, solve an integer linear programming model to determine the container deployment location strategy that minimizes the adaptive deployment cost of the energy management system. The container deployment location strategy is used to characterize the number of container replicas of various microservices deployed on each edge computing device. The microservice delivery location selection module is used to: in each runtime slot, based on the number of container replicas of each edge computing device, the network latency between each edge computing device and the renewable energy data source, and the backlog of the backend task queues of each edge computing device, determine the number of tasks to be distributed from the frontend queue to the backend queues of each edge computing device by solving the task delivery optimization model, so as to minimize the total task response latency of the energy management system.

Images