Container-based power grid algorithm management method and related device
By adopting a containerized microservice decomposition and canary iteration approach for power grid algorithm management, the problem of difficult iteration in traditional power grid algorithm systems is solved, thereby improving the reliability and flexibility of power grid algorithms and meeting the rapid response requirements of new power systems.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUANGZHOU KETENG INFORMATION TECH
- Filing Date
- 2026-01-29
- Publication Date
- 2026-06-05
Smart Images
Figure CN122152625A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of electronic digital processing technology, and in particular to a containerized power grid algorithm management method and related equipment. Background Technology
[0002] Traditional power grid algorithm software systems typically employ a monolithic architecture, tightly coupling core algorithms from multiple stages such as generation, transmission, and distribution into a massive system. This architecture makes algorithm iteration and upgrades extremely difficult; any modification, testing, or deployment of a single algorithm requires affecting the entire system, resulting in a cumbersome and lengthy process accompanied by extremely high operational risks. With the advancement of new power system construction, the uncertainties and volatility brought about by the high proportion of renewable energy integration into the power grid place unprecedented demands on the agile iteration and rapid response capabilities of various algorithms. Therefore, the current rigid development and operation model can no longer meet the urgent needs of the power grid for real-time performance, reliability, and flexibility. Summary of the Invention
[0003] The main objective of this application is to propose a containerized power grid algorithm management method and related equipment, which can improve the reliability, flexibility and system observability of power grid algorithm iteration.
[0004] To achieve the above objectives, one aspect of this application proposes a containerized power grid algorithm management method, the method comprising:
[0005] Obtain the power grid algorithm characteristics corresponding to the algorithms of the entire power grid process; Based on the characteristics of the power grid algorithm, the entire power grid algorithm is decomposed into microservices to obtain multiple microservice information. For each microservice information, a corresponding containerized image and resource model are customized to obtain multiple initial microservice modules. By using container orchestration strategies and according to the priority and traffic ratio of each initial microservice module, the initial microservice modules are iterated in a gray-scale manner to obtain multiple target microservice modules. Collect monitoring metrics information corresponding to each target microservice module, and monitor each target microservice module at the container layer, microservice layer, algorithm layer and business layer based on the monitoring metrics information corresponding to each target microservice module to obtain management monitoring information corresponding to each target microservice module, and generate a full-process monitoring report based on the management monitoring information corresponding to multiple target microservice modules respectively.
[0006] In some embodiments, the process of microservice decomposing the entire power grid algorithm based on its characteristics yields multiple microservice information, and customizing corresponding containerized images and resource models for each microservice information results in multiple initial microservice modules, including: Based on the characteristics of the power grid algorithm, the algorithm for the entire power grid process is divided according to the business domain, and the interface of each microservice is standardized and defined to obtain the information of the multiple microservices; A base image is selected and an algorithm dependency layer and a business adaptation layer are configured according to the information of each microservice to obtain the multiple initial microservice modules. Obtain historical resource data corresponding to each initial microservice module; Based on the historical resource data, resource requirements analysis is performed on each initial microservice module to obtain resource quota information corresponding to each initial microservice module. Based on the resource quota information corresponding to each initial microservice module, resource configuration is performed on each initial microservice module.
[0007] In some embodiments, the step of selecting a base image and configuring an algorithm dependency layer and a business adaptation layer according to the information of each microservice to obtain the plurality of initial microservice modules includes: Based on the microservice information, install the corresponding algorithm dependency layer in each initial microservice module; A data adaptation algorithm is set in the selected base image. The data adaptation algorithm is used to perform format conversion and data cleaning on the business data in the base image corresponding to each microservice information to obtain the multiple initial microservice modules.
[0008] In some embodiments, before performing canary iterations on each of the initial microservice modules using container orchestration strategies and according to the priority and traffic ratio of each initial microservice module to obtain multiple target microservice modules, the method further includes: Each initial microservice module is subjected to functional verification, performance verification, compatibility verification, and security verification to obtain each verified initial microservice module. The process involves using container orchestration strategies and, based on the priority and traffic ratio of each initial microservice module, performing canary iterations to obtain multiple target microservice modules, including: By using container orchestration strategies and according to the priority and traffic ratio of each initial microservice module, canary iterations are performed on each verified initial microservice module to obtain multiple target microservice modules.
[0009] In some embodiments, the step of iterating through container orchestration strategies and according to the priority and traffic ratio of each initial microservice module to obtain multiple target microservice modules includes: Select the initial microservice module with the highest priority in the process and perform canary iterations to obtain and deploy the initial microservice module that has completed the iteration. Gradually increase the traffic proportion of the initial microservice module that has completed the iteration, and monitor in real time whether the initial microservice module that has completed the iteration has anomalies. If it is determined that the initial microservice module that has completed the iteration does not experience any anomalies when the proportion of traffic exceeds a preset traffic threshold, then the target microservice module is obtained.
[0010] In some embodiments, the initial microservice module with the highest priority in the selection process undergoes canary iterations to obtain and deploy the initial microservice module that has completed the iteration, including: Acquire real-time monitoring data and power grid operating data; the power grid operating data is used to describe the operation of the power grid. Based on the real-time monitoring data and power grid operating data, each initial microservice module is subjected to gray-scale iteration to obtain and deploy the initial microservice modules that have completed the iteration.
[0011] In some embodiments, after collecting monitoring metric information corresponding to each target microservice module, and monitoring each target microservice module at the container layer, microservice layer, algorithm layer, and business layer based on the monitoring metric information corresponding to each target microservice module to obtain management monitoring information corresponding to each target microservice module, and generating a full-process monitoring report based on the management monitoring information corresponding to multiple target microservice modules respectively, the method further includes: If the full-process monitoring report indicates that the problem originates from the resource configuration of the first target microservice module, then the container elastic quota of the first target microservice module is adjusted; the first target microservice module can be any target microservice module. If the full-process monitoring report indicates that the problem originates from the algorithm of the first target microservice module, then a topology analysis of the algorithm of the first target microservice module is performed using a deep learning model to obtain an algorithm analysis report corresponding to the first target microservice module. If the full-process monitoring report indicates that the problem originates from the environment compatibility of the first target microservice module, then the data adaptation algorithm within the first target microservice module is updated.
[0012] To achieve the above objectives, another aspect of this application proposes a containerized power grid algorithm management device, the device comprising: The feature acquisition module is used to acquire the power grid algorithm features corresponding to the algorithms of the entire power grid process. The algorithm splitting module is used to split the entire power grid algorithm into microservices based on the characteristics of the power grid algorithm, obtain multiple microservice information, and customize corresponding containerized images and resource models for each microservice information to obtain multiple initial microservice modules. The service iteration module is used to perform canary iterations on each initial microservice module according to container orchestration strategies and the priority and traffic ratio of each corresponding link to obtain multiple target microservice modules. The service monitoring module is used to collect monitoring indicator information corresponding to each target microservice module, and monitor each target microservice module at the container layer, microservice layer, algorithm layer and business layer according to the monitoring indicator information corresponding to each target microservice module, to obtain management monitoring information corresponding to each target microservice module, and generate a full-process monitoring report based on the management monitoring information corresponding to multiple target microservice modules respectively.
[0013] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.
[0014] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.
[0015] To achieve the above objectives, another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods described above. The embodiments of this application include at least the following beneficial effects: This application provides a containerized power grid algorithm management method, device, electronic device, storage medium, and program product. This solution obtains the power grid algorithm characteristics corresponding to the power grid algorithm in all stages; it decomposes the power grid algorithm into microservices based on the power grid algorithm characteristics to obtain multiple microservice information, and customizes corresponding containerized images and resource models for each microservice information to obtain multiple initial microservice modules; it iterates each initial microservice module in a gray-scale manner through container orchestration strategies and according to the stage priority and traffic ratio corresponding to each initial microservice module to obtain multiple target microservice modules; it collects the monitoring indicator information corresponding to each target microservice module, and monitors each target microservice module at the container layer, microservice layer, algorithm layer, and business layer based on the monitoring indicator information corresponding to each target microservice module to obtain management monitoring information corresponding to each target microservice module, and generates a full-stage monitoring report based on the management monitoring information corresponding to each of the multiple target microservice modules. Implementing the embodiments of this application enables the execution of a canary iterative release strategy according to preset priorities and traffic ratios, based on container orchestration strategies and the real-time importance and business traffic distribution of each microservice within the power grid segment. This gradually upgrades the initial module to the target microservice module, achieving a smooth transition and controllable risks. Furthermore, it enables three-dimensional monitoring and closed-loop analysis at the container layer, microservice layer, algorithm layer, and business layer, generating a comprehensive monitoring report covering all aspects of the power grid. This allows for refined management, intelligent scheduling, and continuous optimization of the algorithm service throughout its entire lifecycle, improving the reliability, flexibility, and observability of power grid algorithm iterations. Attached Figure Description
[0016] Figure 1 This is a schematic diagram of an implementation environment provided in an embodiment of this application; Figure 2 This is a flowchart of the containerized power grid algorithm management method provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the containerized power grid algorithm management device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.
[0018] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”
[0019] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.
[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.
[0021] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.
[0022] 1) Kubernetes is an open-source container orchestration system used to automate the deployment, scaling, and management of containerized applications. It originates from Google's years of experience operating in production environments and incorporates best practices from the community. 2) CPU (Central Processing Unit), as the core of computer system operation and control, is the final execution unit for information processing and program execution.
[0023] In traditional power grid algorithm applications, most technologies employ a monolithic architecture, resulting in high coupling between algorithm modules and blurred business boundaries. This makes it difficult to flexibly decompose and independently iterate the algorithms based on the business characteristics of different stages of the power grid, such as generation, transmission, distribution, and consumption. Furthermore, the algorithms are highly dependent on the environment; significant differences in system-level libraries and toolchain versions across different deployment environments can easily lead to issues like missing dependencies and incompatible data formats during deployment. This necessitates substantial manpower to troubleshoot environment compatibility problems, severely impacting algorithm deployment efficiency and making it difficult to guarantee consistent algorithm performance across different environments.
[0024] Traditional power grid algorithms lack systematic version management and comprehensive pre-verification mechanisms in their iterative processes. Regarding version management, there is a lack of effective correlation between code, container images, and algorithm performance metrics, making full-chain traceability impossible. Furthermore, unclear branch management strategies easily lead to version confusion and conflicts between old and new versions, increasing the difficulty of iteration rollback. The pre-verification stage primarily focuses on checking the integrity of algorithm functions, with insufficient coverage of performance stability (such as responsiveness under high concurrency scenarios), compatibility with existing power grid systems (such as data interaction with dispatch automation systems and distribution master stations), and security protection capabilities (such as container vulnerabilities, data encryption, and access control). This results in some potentially problematic algorithm versions being deployed, potentially causing power grid service interruptions or data security risks.
[0025] Traditional power grid algorithm iteration also faces problems such as incomplete operation and maintenance monitoring and a lack of iteration closed loop. Monitoring systems are mostly concentrated at the basic hardware or simple service level, failing to cover all dimensions such as container running status, microservice interface performance, core algorithm indicators, and the impact on power grid business. This makes it difficult to capture operational anomalies of the algorithm under actual working conditions after iteration in real time, resulting in delayed alarm response. In addition, after the algorithm iteration is completed, there is a lack of systematic evaluation based on the needs of power grid business. The analysis of the iteration effect remains superficial and does not delve into key factors such as resource allocation, algorithm model, and environmental adaptation. It also fails to form a continuous improvement closed loop of "evaluation-analysis-optimization-re-iteration," making it difficult for the algorithm performance to be continuously optimized with the development of power grid business and failing to meet the high requirements of the power grid for power supply reliability, operational efficiency, and security.
[0026] In view of this, this application provides a containerized power grid algorithm management solution, which can improve the reliability, flexibility and system observability of power grid algorithm iteration.
[0027] The containerized power grid algorithm management method provided in this application relates to the field of electronic digital processing technology. This containerized power grid algorithm management method can be applied to terminals, servers, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the containerized power grid algorithm management method, but is not limited to the above forms.
[0028] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.
[0029] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.
[0030] like Figure 1The diagram shown is a schematic representation of an implementation environment provided in an embodiment of this application. (Refer to...) Figure 1 The implementation environment includes at least one terminal 102 and a server 101. The terminal 102 and the server 101 can be connected via a network, either wirelessly or via a wired connection, to complete data transmission and exchange.
[0031] Server 101 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.
[0032] Additionally, server 101 can also be a node server in a blockchain network. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms.
[0033] Terminal 102 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. Terminal 102 and server 101 can be directly or indirectly connected via wired or wireless communication, and this embodiment of the application does not impose any limitations.
[0034] For example, based on Figure 1 The implementation environment shown in this application embodiment provides a containerized power grid algorithm management method. The following description uses the application of the containerized power grid algorithm management method in server 101 as an example. It can be understood that the containerized power grid algorithm management method can also be applied in terminal 102.
[0035] Figure 2 This is an optional flowchart of a containerized power grid algorithm management method provided in this application embodiment. The execution subject of the containerized power grid algorithm management method can be any of the aforementioned electronic devices (including servers or terminals). Figure 2 The method may include, but is not limited to, steps S201 to S204.
[0036] Step S201: Obtain the power grid algorithm features corresponding to the power grid full-process algorithm.
[0037] In some embodiments, deep feature extraction of algorithms across the entire power grid involves systematically acquiring and analyzing the intrinsic attributes of various algorithms in the entire power grid business chain, including power generation, transmission, distribution, and consumption, in terms of functional positioning, computational logic, data dependencies, real-time performance, and resource requirements. This results in the formation of a set of power grid algorithm features that can comprehensively characterize the technical features and operational requirements of the algorithms.
[0038] Step S202: Based on the characteristics of the power grid algorithm, the algorithm of the entire power grid process is split into microservices to obtain multiple microservice information. For each microservice information, a corresponding containerized image and resource model are customized to obtain multiple initial microservice modules.
[0039] In some embodiments, based on the principles of algorithmic functional cohesion and clear business boundaries, traditional monolithic algorithm systems are broken down into multiple highly autonomous, single-function independent service units, forming a clear set of microservice information. Subsequently, a dedicated containerized image is customized for each initial microservice module, and its code, runtime environment, and dependency libraries are packaged as a standardized and portable delivery unit to ensure environmental consistency and eliminate dependency conflicts. At the same time, based on the computational intensity, memory requirements, and real-time requirements of each microservice, a quantitative resource model is constructed for it, and the upper and lower limits of CPU, memory, and storage resources are clearly allocated.
[0040] As an optional implementation, the algorithms for all aspects of the power grid are divided according to business domains based on the characteristics of the power grid algorithm, and the interfaces of each microservice are standardized to obtain multiple microservice information; a base image is selected and the algorithm dependency layer and business adaptation layer are configured according to the information of each microservice to obtain multiple initial microservice modules; historical resource data corresponding to each initial microservice module is obtained; resource demand analysis is performed on each initial microservice module based on the historical resource data to obtain resource quota information corresponding to each initial microservice module; and resource configuration is performed on each initial microservice module according to the resource quota information corresponding to each initial microservice module.
[0041] Specifically, the algorithms for the entire power grid process can be divided according to business domains, specifically into four major business domains based on the core aspects of the power grid: the generation-side algorithm domain (including load forecasting and unit optimal scheduling algorithms), the transmission-side algorithm domain (including fault diagnosis and power flow calculation algorithms), the distribution-side algorithm domain (including topology analysis and fault location algorithms), and the consumer-side algorithm domain (including energy efficiency optimization and demand response algorithms). Each business domain can then be further subdivided into microservices based on functional independence. For example, the transmission-side algorithm domain can be split into "transmission fault diagnosis microservice" and "transmission power flow calculation microservice" to avoid cross-domain dependencies.
[0042] A unified RESTful API interface is designed for each initial microservice module, clearly defining the input and output data formats, such as the IEC 61850 protocol for power grid SCADA systems and the DL / T634.5 protocol for distribution automation systems. This is then solidified through the OpenAPI 3.0 specification document to ensure compatibility between microservices and with existing power grid systems, such as dispatch automation systems and distribution master stations. Timeout thresholds for interface calls are also defined, such as ≤300ms for core microservice interfaces and ≤1000ms for non-core interfaces, adapting to the real-time requirements of power grid operations. Containerized modeling is implemented for power grid algorithm microservices. For example, considering the coexistence of computationally intensive (e.g., fault diagnosis) and data-intensive (e.g., load forecasting) characteristics of power grid algorithms, customized container images and resource models are used to ensure that the container environment accurately matches the algorithm's operational requirements.
[0043] By employing a layered construction strategy, complete and independently runnable container images are created, resulting in multiple initial microservice modules with environmental consistency and tight integration with power grid operations. Then, CPU, memory, and network resource usage data for each initial microservice module are collected during historical operation. Through trend analysis and peak modeling of historical resource data, the resource behavior patterns of each microservice module are accurately identified, generating resource quota information reflecting its actual operational needs. Finally, based on this resource quota information, computing resource limits and guaranteed values are dynamically allocated to each microservice module, achieving refined and flexible resource allocation. This effectively improves the overall system resource utilization and operational stability, laying a solid resource management foundation for subsequent container orchestration and canary releases.
[0044] Furthermore, based on the information of each microservice, corresponding algorithm dependency layers are installed within each initial microservice module. Data adaptation algorithms are set in the selected base image to perform format conversion and data cleaning on the business data in the base image corresponding to each microservice, resulting in multiple initial microservice modules. Dedicated dependencies are installed for the algorithm characteristics of different microservices. For example, the "load forecasting microservice" requires integration of Python 3.9, numpy 1.24, pandas 2.0, and a power-specific PI database interface library; the "fault diagnosis microservice" requires integration of a C++17 environment, OpenCV 4.8 (for fault waveform analysis), and CUDA 12.0 (supporting GPU acceleration). Simultaneously, data adaptation algorithms are built into the image to perform format conversion and cleaning of data from different sources, such as real-time SCADA data and offline historical database data, avoiding service anomalies caused by data format incompatibility during iterative deployment.
[0045] After the build is complete, the startup speed of the image is tested using an automated script. The requirements are less than or equal to 10 seconds, dependency integrity, and data interface compatibility. That is, it should be able to read IEC 61850 protocol data normally. After verification, it is uploaded to the power grid's dedicated trusted image repository, such as the Harbor private repository, and labeled with "stage identifier-microservice name-algorithm version", such as "trans-faultDiagnosis-v1.0".
[0046] Based on historical operational data of algorithms across various power grid components, a resource requirement model for containers is established. Container resources can be one or more of CPU, memory, and GPU, avoiding over-allocation or under-allocation of resources. Specifically, historical data is collected using monitoring tools such as Prometheus. Prometheus is an open-source monitoring solution that uses a time-series database to store application metrics, analyzing the resource consumption of different microservices under "normal operating conditions" and "peak operating conditions." For example, the transmission fault diagnosis microservice experiences 85% CPU utilization and 1.2GB of memory usage during a fault (peak operating condition), while under normal operating conditions, CPU utilization is less than or equal to 30% and memory usage is 0.5GB. A "basic quota + elastic quota" is set for containers. The basic quota meets the needs of normal operating conditions, such as a basic CPU quota of 1 core and 1GB of memory for the fault diagnosis microservice. The elastic quota handles peak conditions, with a maximum of 2 CPU cores and 2GB of memory. Simultaneously, for GPU-dependent microservices such as power flow computing, the GPU model requirements and a GPU memory quota of greater than or equal to 4GB are clearly defined to ensure algorithm efficiency.
[0047] Algorithm dependency layers are deployed systematically in each initial microservice module, integrating the necessary computing framework, third-party libraries, and environment configurations for algorithm execution to form a complete and independent algorithm execution environment. An optimized base image is selected as a standardized carrier, and a data adaptation algorithm designed specifically for power grid business is embedded within it. This data adaptation algorithm achieves standardized processing and value extraction of multi-source heterogeneous business data by parsing data semantics, converting data formats, and cleaning invalid information. Finally, through the environmental protection of the algorithm dependency layer and the business collaboration of the data adaptation algorithm, multiple initial microservice modules with both algorithm execution integrity and data interaction consistency are constructed. This effectively improves the plug-and-play capability and cross-system collaboration efficiency of microservices in the complex power grid environment, laying a solid technical foundation for subsequent containerized deployment and business integration.
[0048] Step S203: Through container orchestration strategies and according to the priority and traffic ratio of each initial microservice module, perform canary iterations on each initial microservice module to obtain multiple target microservice modules.
[0049] In some embodiments, an architecture of "GitLab (code management) + Harbor (image management) + self-developed version association platform" is adopted. When code is committed, the CI / CD pipeline is automatically triggered to complete image building and tagging. The "code version number (e.g., Git Commit ID) - image version number (e.g., Harbor Tag) - algorithm core metrics (e.g., load forecasting MAE=0.02)" is stored in the association platform. A structured tag format is defined as: [stage identifier] - [microservice name] - v[version number] - [algorithm metric] - [build time], for example, "gen-loadForecast-v1.1-MAE0.01-20240520". The "algorithm metric" must include the core performance parameters of the version (e.g., error rate, accuracy, response time) to facilitate quick identification of version quality. The system employs a "main branch + dev branch + release-vX.X" architecture. The main branch remains stable, merging only validated iterations. The dev branch is used for new feature development, and the release branch is used for bug fixes and optimizations for specific versions, thus avoiding version inconsistencies. In some embodiments, functional verification, performance verification, compatibility verification, and security verification are performed on each initial microservice module to obtain each verified initial microservice module; through container orchestration strategies and according to the priority and traffic ratio of each corresponding link of each initial microservice module, canary iteration is performed on each verified initial microservice module to obtain multiple target microservice modules.
[0050] Functional verification can involve building a simulated power grid environment, such as a simulation platform based on PSCAD / EMTDC, and inputting operating condition data covering "normal, fault, and extreme weather (such as typhoons and cold waves)" to verify the completeness of microservice functions. For example, for the "distribution fault location microservice", it needs to be verified that it can identify 12 common faults such as "single-phase grounding, two-phase short circuit, and three-phase short circuit", and the location error is less than or equal to 50 meters, which meets the requirements of distribution business. The verification pass standard is 100% functional coverage, with no missing functions or logical errors.
[0051] Performance verification can be achieved by using stress testing tools to simulate different levels of concurrent request scenarios, systematically verifying the performance of microservice modules. By applying multi-tiered loads, including 100, 500, and 1000 concurrent users, core performance metrics of the microservices are comprehensively collected. The requirement is that the average response time of core business microservices should not exceed 500 milliseconds, and the response time of non-core services should be controlled within 1000 milliseconds. The power grid throughput must reach at least 100 transactions per second; simultaneously, the usage of underlying resources is monitored to ensure that CPU utilization does not exceed 70% and memory usage remains below 80%. For the special operating scenarios of the power grid, peak conditions of surged load forecasting service requests during peak electricity consumption periods are specifically simulated to verify the performance stability of the microservices under elastic resource quota guarantees. This ensures that service capacity can be maintained under extreme load conditions, without request timeouts or system crashes, thereby guaranteeing that the microservices can meet the stringent requirements of real-time power grid operation under various business pressures.
[0052] The compatibility verification phase may involve comprehensively testing the compatibility and interaction capabilities between the target microservice and the existing power grid business systems and other collaborative microservices. Specifically, this includes verifying its data communication functions with key platforms such as the power grid dispatch automation system and distribution master station system, ensuring stable reception of real-time telemetry data from the SCADA system (Supervisory Control And Data Acquisition) and accurate transmission of business processing results such as fault diagnosis reports to relevant systems. Simultaneously, it requires verifying the coordination of interface calls between microservices across business processes. For example, the call process between the electricity demand response microservice and the generator scheduling microservice requires complete matching of interface parameter formats, accurate transmission of business context, and a long-term interface call success rate of no less than 99.9%, thereby ensuring high reliability and data consistency of the business chain in complex system environments.
[0053] Security verification can address the high-level security requirements of the power grid as a critical information infrastructure by implementing a three-dimensional, in-depth defense test encompassing container security, data security, and access control. At the container security level, professional vulnerability scanning tools are used to comprehensively inspect container images, ensuring the absence of any high-risk vulnerabilities. Runtime behavior monitoring tools are used to detect abnormal activity in real time, rigorously preventing risks such as container escape and unauthorized file access. At the data security level, the focus is on verifying the high-strength encryption protocols used during data transmission. Advanced encryption standards are implemented to protect the stored algorithm model files, ensuring that sensitive information, including user electricity consumption data, is never leaked throughout its lifecycle. At the access control level, a role-based access control system is rigorously tested, confirming that only iterative administrators have deployment operation permissions, and operations personnel can only access monitoring data. This mechanism eliminates any possibility of unauthorized operations, building a complete and trustworthy secure microservice operating environment.
[0054] After functional verification, performance verification, compatibility verification, and security verification, a pre-verification report is generated to determine whether the version meets the iteration conditions; if it fails, it returns to the development stage for optimization until the requirements are met.
[0055] Through precise flow control and risk diversification mechanisms, the continuity and stability of the core power grid business during system iteration are effectively guaranteed, the operational risks brought about by version upgrades are significantly reduced, and the seamless evolution and reliability improvement of the power grid algorithm system under the microservice architecture are realized.
[0056] In some embodiments, the initial microservice module with the highest priority is selected for canary iteration to obtain and deploy the initial microservice module that has completed the iteration; the traffic ratio of the initial microservice module that has completed the iteration is gradually increased, and the initial microservice module that has completed the iteration is monitored in real time to see if any abnormality occurs; if it is determined that the initial microservice module that has completed the iteration has not experienced any abnormality when the traffic ratio is greater than a preset traffic threshold, then the target microservice module is obtained.
[0057] Based on the assessment of the impact of power grid operations, each link is divided into a three-level priority system: the core power generation and transmission links that directly affect the power supply security of the entire network are defined as P0 level, the power distribution links that affect the regional power supply reliability are defined as P1 level, and the power consumption links that are related to user experience are defined as P2 level.
[0058] During the canary release implementation, the initial deployment focused on the power efficiency optimization microservice at the P2 level. Service mesh technology routed 10% of the power-side business traffic to the new version container, while the remaining 90% was handled by the old version. A critical monitoring and evaluation phase followed, continuously observing the new version's performance in key metrics such as algorithm accuracy, response time, and resource utilization. If all metrics met expectations within one to two hours, the next phase began; any anomalies were immediately rolled back. Once the P2 level was verified as stable, the same mechanism was followed to advance the release process to the P1 level distribution and P0 level generation and transmission stages. For the P0 level, monitoring was extended to four hours at each traffic increment stage to ensure core business stability. After a full traffic switch for a stage was completed, the system continued 24-hour stability monitoring. Only when no anomalies were confirmed was the iteration considered complete, and the old version container was retained for 72 hours as an emergency rollback guarantee, ultimately achieving a smooth and reliable upgrade of the microservices across the entire power grid.
[0059] By combining priority-driven and traffic-gradual switching strategies, the microservice version upgrade process was made smooth, controllable, and risk-minimized while ensuring the high availability of core power grid services.
[0060] Furthermore, real-time monitoring data and power grid operating data are acquired; the power grid operating data is used to describe the operation of the power grid; based on the real-time monitoring data and power grid operating data, each initial microservice module is iterated in a gray-scale manner to obtain and deploy the iterated initial microservice modules.
[0061] During the dynamic resource optimization phase, intelligent management of container resources is achieved through the Vertical Pod Autoscaler component of the Kubernetes platform. This tool can automatically adjust resource quota configurations based on the actual operating load of microservices. When it is detected that microservices such as power distribution topology analysis have a memory usage rate that is consistently higher than the set threshold after version iteration, and memory leaks have been ruled out, their memory quotas will be automatically increased appropriately from the original level. Conversely, when it is detected that certain microservices are in a low CPU load state for a long time, their computing resource quotas will be reduced accordingly to save resources.
[0062] At the level of dynamic algorithm parameter tuning, a dedicated parameter tuning module is integrated within the container, enabling microservices to autonomously adjust algorithm parameter configurations based on the real-time operating conditions of the power grid. For example, the load forecasting microservice automatically adjusts the weighting of historical and real-time data to improve prediction accuracy when encountering extreme weather conditions; the fault diagnosis microservice dynamically adjusts its sensitivity parameters when the load on transmission lines changes, avoiding the risk of misjudgment under heavy loads and preventing the possibility of missed judgments under light loads. All parameter adjustment operations generate complete adjustment logs, recording detailed adjustment times, parameter change details, and performance indicator comparison data, forming a closed-loop optimization system from resource allocation to the underlying algorithm. This not only significantly improves the microservices' adaptability to the complex operating environment of the power grid but also provides valuable decision-making basis for subsequent system iterations.
[0063] Step S204: Collect monitoring indicator information corresponding to each target microservice module, and monitor each target microservice module at the container layer, microservice layer, algorithm layer and business layer according to the monitoring indicator information corresponding to each target microservice module to obtain management monitoring information corresponding to each target microservice module, and generate a full-process monitoring report based on the management monitoring information corresponding to multiple target microservice modules respectively.
[0064] In some embodiments, the basic operational status can be continuously tracked based on the container layer, with core resource indicators such as CPU and memory utilization, network throughput and GPU utilization. At the same time, the health status such as Pod readiness rate, restart frequency and image pull success rate can be monitored, and a multi-level alarm mechanism can be set up to provide real-time warnings for resource overruns and abnormal restarts.
[0065] The microservice layer focuses on interface performance and dependency quality. By collecting data such as call success rate, response time, timeout rate, and upstream and downstream service dependency performance, it ensures stable and reliable collaboration between services and sets graded thresholds to quickly detect performance degradation.
[0066] The algorithm layer monitoring is directly linked to the effectiveness of power grid operations. It conducts multi-dimensional evaluations of key business indicators such as load forecasting accuracy on the generation side, fault diagnosis accuracy on the transmission side, location error on the distribution side, and energy efficiency optimization rate on the consumption side, and establishes alarm rules closely linked to algorithm performance. The business layer evaluates the actual value of iterations from the perspective of power grid operation. It comprehensively measures the results through core business indicators such as power supply reliability, fault handling efficiency, line loss rate, and generation cost. Finally, a unified monitoring platform enables the visualization, integration, and drill-down analysis of data at all levels, and combined with real-time alarm pushes, forms a full-link observable capability from infrastructure to business value.
[0067] As an optional implementation, if the end-to-end monitoring report indicates that the problem originates from the resource configuration of the first target microservice module, then the container elastic quota of the first target microservice module is adjusted; the first target microservice module can be any target microservice module; if the end-to-end monitoring report indicates that the problem originates from the algorithm of the first target microservice module, then the algorithm of the first target microservice module is subjected to topology analysis accuracy through a deep learning model to obtain the algorithm analysis report corresponding to the first target microservice module; if the end-to-end monitoring report indicates that the problem originates from the environment adaptability of the first target microservice module, then the data adaptation algorithm within the first target microservice module is updated.
[0068] In the evaluation and optimization phase after iteration, a detailed iteration evaluation report is first generated within a preset time period, specifically seven days. The report compares the achievement of core algorithm metrics before and after iteration, and statistically analyzes resource utilization efficiency, service response performance, and impact on key business processes at each stage. Simultaneously, it accurately records various operational issues exposed during the iteration process.
[0069] For specific issues identified in the assessment, cross-functional teams were organized to conduct joint analysis, accurately pinpoint the root causes, and develop targeted optimization solutions: if the problem stemmed from insufficient resource allocation, container quota configurations were adjusted; if it involved insufficient algorithm accuracy, model optimization was initiated; and if it was caused by environmental compatibility, the data interaction module was updated. All optimization solutions adopted a phased rollout strategy, first completing verification testing in non-core business processes. Once confirmed to be effective, they were incorporated into subsequent iteration plans for formal implementation. This constructed a complete closed loop from effect evaluation and problem diagnosis to solution implementation, driving the continuous improvement of the power grid algorithm microservice's operational quality and business value through continuous optimization.
[0070] Steps S201 to S204 as illustrated in this embodiment involve: acquiring the power grid algorithm characteristics corresponding to the power grid full-process algorithm; performing microservice decomposition on the power grid full-process algorithm based on the power grid algorithm characteristics to obtain multiple microservice information; customizing corresponding containerized images and resource models for each microservice information to obtain multiple initial microservice modules; iterating each initial microservice module in a gray-scale manner using container orchestration strategies and according to the process priority and traffic ratio corresponding to each initial microservice module to obtain multiple target microservice modules; collecting monitoring indicator information corresponding to each target microservice module; and performing container layer, microservice layer, algorithm layer, and business layer analysis on each target microservice module based on the monitoring indicator information corresponding to each target microservice module. The system monitors and obtains management and monitoring information for each target microservice module. Based on the management and monitoring information for each target microservice module, it generates a full-process monitoring report. According to the container orchestration strategy, combined with the real-time importance of each microservice in the power grid and the distribution of business traffic, it executes a canary iteration release strategy according to preset priorities and traffic ratios, gradually upgrading the initial module to the target microservice module, achieving a smooth transition and controllable risks. It also implements three-dimensional monitoring and closed-loop analysis at the container layer, microservice layer, algorithm layer and business layer, generating a comprehensive monitoring report covering the entire power grid process. This enables refined management, intelligent scheduling and continuous optimization of the entire lifecycle of algorithm services, improving the reliability, flexibility and system observability of power grid algorithm iteration.
[0071] Please see Figure 3 This application also provides a containerized power grid algorithm management device that can implement the above-described method. The device includes: The feature acquisition module 301 is used to acquire the power grid algorithm features corresponding to the power grid full-process algorithm; The algorithm splitting module 302 is used to split the algorithm of the entire power grid into microservices according to the characteristics of the power grid algorithm, obtain multiple microservice information, and customize corresponding containerized images and resource models for each microservice information to obtain multiple initial microservice modules. Service iteration module 303 is used to perform canary iterations on each initial microservice module according to the container orchestration strategy and the priority and traffic ratio of each initial microservice module to obtain multiple target microservice modules. Service monitoring module 304 is used to collect monitoring indicator information corresponding to each target microservice module, and to monitor each target microservice module at the container layer, microservice layer, algorithm layer and business layer based on the monitoring indicator information corresponding to each target microservice module, to obtain management monitoring information corresponding to each target microservice module, and to generate a full-process monitoring report based on the management monitoring information corresponding to multiple target microservice modules respectively.
[0072] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.
[0073] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.
[0074] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.
[0075] Please see Figure 4 , Figure 4 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 401 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 402 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 402 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 402 and is called and executed by the processor 401 using the methods described in the embodiments of this application. Input / output interface 403 is used to implement information input and output; The communication interface 404 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 405 transmits information between various components of the device (e.g., processor 401, memory 402, input / output interface 403, and communication interface 404); The processor 401, memory 402, input / output interface 403 and communication interface 404 are connected to each other within the device via bus 405.
[0076] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.
[0077] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.
[0078] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.
[0079] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.
[0080] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0081] The containerized power grid algorithm management method, device, electronic device, storage medium, and program product provided in this application embodiment obtain the power grid algorithm characteristics corresponding to the algorithms of the entire power grid process; decompose the algorithms of the entire power grid process into microservices according to the power grid algorithm characteristics to obtain multiple microservice information, and customize corresponding containerized images and resource models for each microservice information to obtain multiple initial microservice modules; perform gray-scale iteration on each initial microservice module according to the link priority and traffic ratio corresponding to each initial microservice module through container orchestration strategy to obtain multiple target microservice modules; collect the monitoring index information corresponding to each target microservice module, and monitor each target microservice module at the container layer, microservice layer, algorithm layer, and business layer according to the monitoring index information corresponding to each target microservice module to obtain management monitoring information corresponding to each target microservice module, and generate a full-process monitoring report based on the management monitoring information corresponding to each target microservice module. This can improve the reliability, flexibility, and system observability of power grid algorithm iteration.
[0082] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.
[0083] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.
[0084] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0085] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.
[0086] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0087] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0088] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0089] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0090] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0091] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0092] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.
Claims
1. A containerized power grid algorithm management method, characterized in that, The method includes the following steps: Obtain the power grid algorithm characteristics corresponding to the algorithms of the entire power grid process; Based on the characteristics of the power grid algorithm, the entire power grid algorithm is decomposed into microservices to obtain multiple microservice information. For each microservice information, a corresponding containerized image and resource model are customized to obtain multiple initial microservice modules. By using container orchestration strategies and according to the priority and traffic ratio of each initial microservice module, the initial microservice modules are iterated in a gray-scale manner to obtain multiple target microservice modules. Collect monitoring metrics information corresponding to each target microservice module, and monitor each target microservice module at the container layer, microservice layer, algorithm layer and business layer based on the monitoring metrics information corresponding to each target microservice module to obtain management monitoring information corresponding to each target microservice module, and generate a full-process monitoring report based on the management monitoring information corresponding to multiple target microservice modules respectively.
2. The method according to claim 1, characterized in that, The power grid algorithm is decomposed into microservices based on its characteristics, resulting in multiple microservice information. For each microservice information, a corresponding containerized image and resource model are customized to obtain multiple initial microservice modules, including: Based on the characteristics of the power grid algorithm, the algorithm for the entire power grid process is divided according to the business domain, and the interface of each microservice is standardized and defined to obtain the information of the multiple microservices; A base image is selected and an algorithm dependency layer and a business adaptation layer are configured according to the information of each microservice to obtain the multiple initial microservice modules. Obtain historical resource data corresponding to each initial microservice module; Based on the historical resource data, resource requirements analysis is performed on each initial microservice module to obtain resource quota information corresponding to each initial microservice module. Based on the resource quota information corresponding to each initial microservice module, resource configuration is performed on each initial microservice module.
3. The method according to claim 2, characterized in that, The selection of a base image and the configuration of the algorithm dependency layer and business adaptation layer according to the information of each microservice result in the multiple initial microservice modules, including: Based on the microservice information, install the corresponding algorithm dependency layer in each initial microservice module; A data adaptation algorithm is set in the selected base image. The data adaptation algorithm is used to perform format conversion and data cleaning on the business data in the base image corresponding to each microservice information to obtain the multiple initial microservice modules.
4. The method according to claim 1, characterized in that, Before performing canary iterations on each initial microservice module using container orchestration strategies and according to the priority and traffic ratio of each initial microservice module to obtain multiple target microservice modules, the method further includes: Each initial microservice module is subjected to functional verification, performance verification, compatibility verification, and security verification to obtain each verified initial microservice module. The process involves using container orchestration strategies and, based on the priority and traffic ratio of each initial microservice module, performing canary iterations to obtain multiple target microservice modules, including: By using container orchestration strategies and according to the priority and traffic ratio of each initial microservice module, canary iterations are performed on each verified initial microservice module to obtain multiple target microservice modules.
5. The method according to claim 1, characterized in that, The process involves using container orchestration strategies and, based on the priority and traffic ratio of each initial microservice module, performing canary iterations to obtain multiple target microservice modules, including: Select the initial microservice module with the highest priority in the process and perform canary iterations to obtain and deploy the initial microservice module that has completed the iteration. Gradually increase the traffic proportion of the initial microservice module that has completed the iteration, and monitor in real time whether the initial microservice module that has completed the iteration has anomalies. If it is determined that the initial microservice module that has completed the iteration does not experience any anomalies when the proportion of traffic exceeds a preset traffic threshold, then the target microservice module is obtained.
6. The method according to claim 5, characterized in that, The initial microservice module with the highest priority in the selection process undergoes canary iterations to obtain and deploy the initial microservice modules that have completed the iterations, including: Acquire real-time monitoring data and power grid operating data; the power grid operating data is used to describe the operation of the power grid. Based on the real-time monitoring data and power grid operating data, each initial microservice module is subjected to gray-scale iteration to obtain and deploy the initial microservice modules that have completed the iteration.
7. The method according to any one of claims 1 to 5, characterized in that, After collecting monitoring metric information corresponding to each target microservice module, and monitoring each target microservice module at the container layer, microservice layer, algorithm layer, and business layer based on the monitoring metric information corresponding to each target microservice module to obtain management monitoring information corresponding to each target microservice module, and generating a full-process monitoring report based on the management monitoring information corresponding to multiple target microservice modules, the method further includes: If the full-process monitoring report indicates that the problem originates from the resource configuration of the first target microservice module, then the container elastic quota of the first target microservice module is adjusted; the first target microservice module can be any target microservice module. If the full-process monitoring report indicates that the problem originates from the algorithm of the first target microservice module, then a topology analysis of the algorithm of the first target microservice module is performed using a deep learning model to obtain an algorithm analysis report corresponding to the first target microservice module. If the full-process monitoring report indicates that the problem originates from the environment compatibility of the first target microservice module, then the data adaptation algorithm within the first target microservice module is updated.
8. A containerized power grid algorithm management device, characterized in that, The device includes: The feature acquisition module is used to acquire the power grid algorithm features corresponding to the algorithms of the entire power grid process. The algorithm splitting module is used to split the entire power grid algorithm into microservices based on the characteristics of the power grid algorithm, obtain multiple microservice information, and customize corresponding containerized images and resource models for each microservice information to obtain multiple initial microservice modules. The service iteration module is used to perform canary iterations on each initial microservice module according to container orchestration strategies and the priority and traffic ratio of each corresponding link to obtain multiple target microservice modules. The service monitoring module is used to collect monitoring indicator information corresponding to each target microservice module, and monitor each target microservice module at the container layer, microservice layer, algorithm layer and business layer according to the monitoring indicator information corresponding to each target microservice module, to obtain management monitoring information corresponding to each target microservice module, and generate a full-process monitoring report based on the management monitoring information corresponding to multiple target microservice modules respectively.
9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.