Micro-grid monitoring system based on micro-service architecture

Abstract

The invention discloses a micro-grid monitoring system based on a micro-service architecture. The system comprises an access layer, a core service layer and a component layer. And the access layer provides a uniform address to the outside for the client to access, receives a request sent by the client, and forwards the request to the corresponding core service layer module for processing. The core service layer is composed of a plurality of independently-deployed and loosely-coupled micro-services, corresponding services are flexibly called according to business requirements, and efficient data processing and function response are achieved. And the component layer is responsible for performing real-time monitoring on the running state and the calling link of each micro-service, has a flow control capability, and supports registration discovery and dynamic configuration management of the micro-service. The micro-service architecture and the modular design are adopted, the flexibility, the expandability and the fault-tolerant capability of the system are remarkably improved, high-concurrency access can be effectively supported, and the application requirements of large-scale micro-grid monitoring and health management are met.

Description

Technical Field

[0001] The present invention relates to the field of smart grid monitoring technology, and in particular to a microgrid monitoring system based on a microservice architecture, which realizes the real-time collection of microgrid operating status, control instruction issuance, equipment management and health report analysis functions under multi-role authority management. Background Art

[0002] With the rapid development of distributed energy and microgrid technologies, the variety and number of devices in power systems are increasing, significantly increasing the complexity of data collection, monitoring, and management. Traditional systems typically utilize a monolithic architecture. However, with the increasing use of software technologies in business scenarios, the business applications within these monolithic architectures are becoming increasingly complex. Systems encompass not only information systems but also numerous other systems that are closely connected to them. The coupling between these systems is dynamic and complex, making the overall system behavior difficult to describe simply by superimposing the characteristics of a single autonomous system. The increasing coupling between code logic and modules reduces system scalability, making it difficult to flexibly adapt to the rapid expansion of equipment and the continuous evolution of business functions. Furthermore, the monolithic architecture's business services are limited in functionality, making it difficult to meet the real-world demands of multi-role and multi-business collaboration. The performance and responsiveness of these systems are insufficient to meet the demands of concurrent access from large-scale devices and real-time data processing. Summary of the Invention

[0003] The present invention aims to provide a microgrid monitoring system based on a microservice architecture, which achieves high scalability, high reliability and efficient collaboration of multiple services by modularly decoupling functions such as device management, data acquisition, user permissions and health report analysis.

[0004] The present invention comprises:

[0005] The access layer is used to provide a unified access portal to the outside world and perform user authentication and request routing;

[0006] The core service layer consists of multiple independently deployed, loosely coupled microservices, including at least:

[0007] User management microservice, used to implement multi-role user rights management;

[0008] Device management microservices, used to manage the registration, configuration, and status monitoring of microgrid sites and their devices;

[0009] Control microservices, used to collect device operation data in real time and issue control instructions;

[0010] Health report microservice, used to generate device health index and various statistical reports based on operating data;

[0011] The component layer is used to implement microservice registration discovery, dynamic configuration, security control, log monitoring, and distributed transaction management;

[0012] The access layer, core service layer and component layer communicate through standardized interfaces to support high-concurrency monitoring, multi-service collaboration and elastic expansion of the microgrid.

[0013] The microservice system of the present invention achieves high cohesion, low coupling and flexible expansion of the system by splitting complex businesses into independent functional modules. Each microservice is based on containerized deployment, has good isolation and maintainability, and supports elastic scaling and rapid iteration. The integration of basic components such as service registration and discovery, configuration management, authentication and authorization, and log monitoring improves the system's automated operation and maintenance capabilities and security. Each business service collaborates through standardized interfaces, enhancing the system's reliability, scalability and fault self-healing capabilities, and can flexibly respond to changing business needs and large-scale concurrent access in power grid monitoring scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 Schematic diagram of the overall system architecture;

[0015] Figure 2 This system software uses components and architecture diagram;

[0016] Figure 3 Schematic diagram of user rights management in the system;

[0017] Figure 4 Control microservices and the underlying IoT gateway real-time data collection timing diagram;

[0018] Figure 5 The equipment data table generates a factor map;

[0019] Figure 6 Report data generation timing diagram. DETAILED DESCRIPTION

[0020] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0021] The present invention proposes a microgrid monitoring system based on a microservice architecture, which aims to improve the security, stability and intelligence level of microgrid operation. The system includes an access layer, a core service layer and a component layer. The access layer provides a unified address for client access, receives requests sent by the client, and forwards the requests to the corresponding core service layer module for processing. The core service layer is composed of multiple independently deployed and loosely coupled microservices, which flexibly call corresponding services according to business needs to achieve efficient data processing and functional response. The component layer is responsible for real-time monitoring of the operating status and call links of each microservice, has flow control capabilities, and supports registration discovery and dynamic configuration management of microservices. The present invention adopts a microservice architecture and modular design, which significantly improves the flexibility, scalability and fault tolerance of the system, can effectively support high concurrent access, and meet the application requirements of large-scale microgrid monitoring and health management.

[0022] In a preferred embodiment, the access layer consists of a gateway and an authentication module. The gateway serves as a unified entry point, isolating external access from internal systems through routing policies to ensure the security of dynamic microservice routing. Clients access the system through the gateway address. After submitting a request, the gateway dispatches the request to the specific service and returns the result. The complexity of the power grid system requires that all requests be dispatched through the microservice gateway. The authentication module ensures access security and stores legitimate user information for the gateway to verify permissions. The gateway verifies client requests and only grants access if the request is legitimate.

[0023] In a preferred embodiment, the core service layer includes a user management microservice, a device management microservice, a control microservice, and a health report microservice. Among them, the user management microservice is responsible for the unified management of system users; the device management microservice is responsible for managing the life cycle of all system sites and the equipment and points therein, including the addition, deletion, and modification of power station points and the registration, configuration, and status monitoring of the equipment therein; the control microservice provides real-time data reception or issues commands to the underlying IoT gateway, and also includes storing data in a time series database for data analysis by other microservices; the health report microservice provides historical data collection, storage, and display of historical operating data of the equipment through the real-time data collected by the control microservice, supports daily, monthly, annual, and other statistical methods, and evaluates the health status of the entire microgrid. Finally, it outputs the microgrid health index to achieve data visualization and better represent the real-time status of the microgrid for operation and maintenance personnel.

[0024] In a preferred embodiment, the component layer is mainly responsible for the overall maintenance of the system and plays a stabilizing role. It mainly includes a service discovery and registration module, a configuration module, a transaction module, a security control module, and a log monitoring module. The service discovery and registration module is used to realize calls between microservices. After the microservice instance is started, it is registered with the service center, and the service is regularly accessed by comparing the service address of each registration. Whether it is available is determined based on the health status of the service, thereby realizing decoupling between microservices; the configuration module is used to perform centralized configuration management of the parameters and switches of the entire service group, and provide microservices with unified dynamic configuration information storage in multiple environments; the transaction module is used to ensure data consistency of multi-service and multi-data source operations in distributed scenarios, and prevent data anomalies; the security control module realizes traffic governance, circuit breaking and degradation, and improves the stability and security of the system; the log monitoring module is responsible for collecting, analyzing and visualizing system operation logs and performance indicators to facilitate fault location and operation and maintenance management.

[0025] In this application, "points" refer to physical quantities (such as voltage, current, temperature, and switching values) that can be collected or controlled by a device. To enable unified management and flexible expansion of different types of devices, a universal point data structure has been designed, which includes the device ID, point list, collection interval, protocol type, and more.

[0026] Example:

[0027] Reference Figure 1 The microgrid monitoring system based on the microservice architecture generally includes an access layer 100, a core service layer 200 and a component layer 300.

[0028] The access layer 100 provides a unified address for clients to access the system. The access layer 100 receives control command requests or grid health analysis requests sent by clients and distributes the requests to the core service layer 200. The core service layer 200 calls the corresponding microservices based on these requests, completes the control command issuance, and executes the grid health analysis task. The component layer 300 is responsible for monitoring the operating status and call links of the microservices and controlling the overall traffic, including the registration, discovery, and configuration of the microservices.

[0029] Furthermore, the following is an explanation of the entire software architecture of the system. Figure 2This system, built on the SpringCloud Alibaba framework, utilizes a series of highly efficient components for microgrid monitoring and health assessment. At the access layer, Higress Gateway, combined with Spring Security and the OAuth 2.1 protocol, implements the authentication module 120 to ensure secure user authentication and access control. Nacos is used in the service registration and discovery module 310 and the configuration module 320, providing dynamic service registration, automatic discovery, and centralized management of configuration information, enhancing communication efficiency and scalability. Data exchange between business services relies on the Dubbo framework, which implements an efficient RPC mechanism and ensures the performance and stability of service collaboration. To enhance system availability and stability, Sentinel is introduced for flow control and circuit breaking, and Seata is used to ensure distributed transaction consistency. RocketMQ is used for asynchronous message processing. By decoupling producers and consumers, the system enhances scalability and fault tolerance in high-concurrency environments. For data storage, a combination of MySQL, Redis, and Tdengine is utilized: MySQL is used for relational data, Redis accelerates high-frequency data access, and Tdengine is specialized for efficient processing of time series data. In terms of deployment and operations, Docker containerization technology is used to encapsulate applications, simplify service deployment, and maintain a consistent environment. Furthermore, Kibana is used to centrally analyze and retrieve log data, providing support for operations personnel in troubleshooting, performance tuning, and decision-making.

[0030] Access layer 100 includes gateway 110, which provides a unified service invocation entry point. Using routing policies, it isolates external access from internal systems, effectively ensuring dynamic routing for microservices. Clients access services through the system frontend using a unified gateway address and submit command requests. The gateway then distributes the requests to specific services and returns a unified, visual result. Due to the large scale, high complexity, wide geographical coverage, and diverse communication protocols of power grid systems, all requests to access the service side must be dispatched and assigned to specific microservices by the microservice gateway to improve system security and reliability.

[0031] Optionally, access layer 100 also includes an authentication module 120, which ensures the security of external access. This module stores valid user information for gateway 110 to verify user permissions. For requests initiated from clients, gateway 110 invokes authentication module 120 based on the specified information in the user request to verify the legitimacy of the request before granting access.

[0032] Furthermore, the authentication module 120 uses Spring Security combined with the OAuth 2.1 protocol to implement unified identity authentication and permission verification for the microservice system. First, dependencies such as spring-boot-starter-security and spring-authorization-server are introduced into the authentication service, and parameters such as the authentication port, authorization endpoint, and token storage method are configured. As an independent microservice, the authentication module is responsible for handling login, authorization, token issuance, and verification. Each business microservice is declared as a protected resource server by introducing the spring-cloud-starter-oauth2 dependency and integrating the OAuth 2.1 client function. External access requests must first pass the authentication of the authentication module to obtain an access token (Access Token). The business microservice verifies the legitimacy of the request based on the token to ensure secure access to resources.

[0033] As key components of the system, the core service layer 200 and component layer 300 employ a microservices architecture to provide real-time monitoring and functional support for the microgrid. By decomposing monolithic applications into multiple microservice components with distinct responsibilities and single functions, the system's maintainability, scalability, and deployment flexibility are enhanced.

[0034] The core service layer includes user management microservice 210, device management microservice 220, control microservice 230, and health report microservice 240. Each microservice communicates through RPC or message queues and provides a RESTful API interface to the outside world.

[0035] The user management microservice 210 handles user registration, permission allocation, and identity authentication; the device management microservice 220 is responsible for managing the configuration information of devices and their collection points; the control microservice 230 receives real-time data and sends instructions to the access layer, while storing data for analysis; the health report microservice 240 provides statistical summaries, trend analysis, and various report formats based on historical data, and evaluates the health status of the power grid to support decision-making.

[0036] The component layer 300 includes a service discovery and registration module 310 , a configuration module 320 , a transaction module 330 , a security control module 340 and a log monitoring module 350 .

[0037] Furthermore, the service discovery and registration module 310 realizes the dynamic management and calling of microservice instances; the configuration module 320 centrally manages configuration parameters and provides unified dynamic configuration support; the transaction module 330 ensures data consistency of distributed operations; the security control module 340 improves system stability and security; and the log monitoring module 350 is used for fault location and operation and maintenance management to ensure efficient operation of the system.

[0038] The following further describes the core functions and logical relationships of each layer of the system. The core service layer 200 is related as follows:

[0039] Reference Figure 3 In the microgrid monitoring system based on the microservices architecture of the present invention, the user management microservice 210 is responsible for identity management, permission allocation, and user information maintenance for all system users. Users in the system are primarily divided into three categories: platform administrators, operations managers (i.e., those responsible for work at the corresponding microgrid site), and ordinary users (also known as general operators at the corresponding site). Unless otherwise specified, "user" herein refers collectively to all three categories, with specific operational permissions varying depending on the user role. The platform administrator is a built-in system role with the highest permissions. They can create and delete users, reset passwords, assign roles, configure platform parameters, manage global resources such as devices and reports, and designate operations managers. Operations managers are assigned by the platform administrator and have advanced management permissions for the microgrid or site they are responsible for, including adding and managing ordinary users, allocating devices, configuring monitoring tasks, and viewing and exporting relevant reports. Ordinary users are added by operations managers and have limited operational permissions for their assigned devices or sites, such as real-time monitoring, data querying, report downloading, and health status analysis.

[0040] The device management microservice 220 includes a device information management unit, a device allocation unit, and a point configuration unit. The device information management unit is used to uniformly register, maintain, and update the basic information of all devices in the system. Platform administrators can use this unit to add, modify, delete, and configure parameters for devices. The device allocation unit is used to implement hierarchical allocation and authorization between devices, operations managers, and ordinary users. Platform administrators can assign devices to operations managers, who can then assign devices to ordinary users and adjust device ownership based on actual needs.

[0041] The control microservice 230 includes a configuration unit, a data collection unit, an instruction issuing unit, and a real-time data display unit.

[0042] Furthermore, after the above-mentioned user configuration and device configuration, the configuration unit creates a dedicated data table for each device for data collection and storage, based on the different structural properties of different devices and the inconsistency of the number of physical quantities to be monitored. A "device point structure tree" is constructed using the "device ID" + "communication register address table" of the device information table (the aforementioned MySQL relational database) to set each physical quantity attribute (sequence number, field name, label, address, ...), and stored in the buffer database (the aforementioned Redis). The purpose of storing the buffer database is to query the physical quantity point information at high speed during message parsing to facilitate efficient point-by-point parsing. Finally, the collected real-time data will be stored in the time series database (the aforementioned Tdengine), such as Figure 4 As shown, the "communication register address table" comes from the communication data format table of each device.

[0043] The data collection unit is used to subscribe to the topics published by the IoT gateway to the proxy server, collect the operation data and status information of the collection equipment in real time, and persist the collected data to the time series database. The overall process is as follows: Figure 5 As shown in the figure, the time series database supports automatic creation of real-time data tables to achieve efficient storage and management.

[0044] The instruction issuing unit is responsible for transmitting remote instructions from the Web end to the underlying gateway. Specifically, users can edit and issue control instructions through the Web interface. After receiving the instruction, the instruction issuing unit first performs format verification and permission verification on the instruction content, and then publishes the instruction to the proxy server in JSON format. The underlying IoT gateway can subscribe to this topic.

[0045] The real-time data display unit is used to dynamically visualize the latest device operating data. Specifically, the control microservice 230 collects device status and operating data through the real-time data display unit and establishes a persistent connection with the front-end using the WebSocket protocol, enabling real-time data push between the back-end and the front-end. The front-end interface dynamically receives and displays the latest device data changes, providing real-time device operating status without the user having to manually refresh the page.

[0046] The health report microservice 240 includes a data aggregation unit, a report generation unit, a health analysis unit, and a report export unit. These units work together to implement comprehensive analysis and reporting services for the health status of the device.

[0047] Furthermore, the data aggregation unit is responsible for real-time access to the microgrid operation data stream from the time series database TDengine through the RocketMQ message queue, including electrical parameters, equipment status information, and environmental variables.

[0048] The report generation unit supports the summary and statistics of historical data in a scheduled or on-demand manner according to the needs of users or administrators, and automatically generates daily, monthly, annual and other forms of operation reports. The specific process is as follows Figure 6 As shown, the front end initiates a report data request by calling the specified interface. The system obtains the report point configuration at the controller layer. After constructing the query parameters, the core service layer determines the query sub-table based on the report type and calls the executor for data query. The data access layer interacts with the TDengine database to obtain the required time series data.

[0049] The health analysis unit processes all types of collected data, calculates and generates a unified health index HI value (0-100 scale) based on electrical parameters, device status and environmental variables, and provides health assessment and maintenance recommendations for each device.

[0050] The report export unit supports exporting generated health reports in multiple formats for easy download, archiving, or further analysis. Finally, the system pushes key data such as the health index (HI) value to the front-end console via the WebSocket protocol, enabling visual display and real-time monitoring of device health status.

[0051] Recombination Figure 1 and Figure 2 , details how the component layer 300 serves the core service layer above:

[0052] The service discovery and registration module 310 and the configuration module 320 are both implemented based on Nacos components to enhance the dynamic management capabilities and operational efficiency of the microservice system. Specifically, Nacos is first deployed in the system as a unified service registration and configuration center. For service registration and discovery, each microservice includes the Nacos dependency (spring-cloud-starter-alibaba-nacos-discovery) in its pom.xml file and adds the @EnableDiscoveryClient annotation to the main startup class, declaring the service's automatic registration and discovery capabilities. Upon startup, a microservice automatically registers key information such as its service name, IP address, and port number with the Nacos service center. Nacos regularly checks the health of each service instance through a heartbeat mechanism. If an instance fails to report a heartbeat for an extended period, it is automatically removed from the list of available services, ensuring real-time and accurate service discovery. When making remote calls, service consumers no longer need to hard-code the target service address. Instead, they dynamically retrieve a list of available instances from Nacos using the service name, enabling automatic discovery and load balancing between services.

[0053] For configuration management, each microservice includes dependencies such as spring-cloud-starter-alibaba-nacos-config in its pom.xml file and specifies the address and namespace of the Nacos configuration center in its configuration file. All microservice configuration information is centrally stored in the Nacos configuration center, supporting configuration isolation across multiple environments (development, testing, and production) and multiple versions. Upon startup, a microservice automatically pulls the required configuration information from Nacos. During operation, it detects configuration changes in real time through long polling or push mechanisms, enabling dynamic refreshes that take effect without restarting the microservice. Operations and maintenance personnel can centrally manage configuration information and publish changes through the Nacos console.

[0054] The transaction module 330 uses Seata microservices to ensure the consistency of distributed transactions. The system deploys an independent SeataServer and adds Seata-related dependencies to each business microservice, while configuring parameters such as the Seata service address and transaction grouping. Microservices participating in distributed transactions register with the Seata Server when they start and become part of the global transaction. When a business process involves multiple microservices or database operations, Seata manages the entire process uniformly through a global transaction ID (XID). After the initiator opens a global transaction, each participant reports the status to Seata before and after executing the local transaction. Seata uses the AT mode to automatically proxy the data source or the TCC mode to coordinate commit and rollback, ensuring that completed operations can be automatically rolled back in the event of any abnormality in any link to maintain data consistency.

[0055] The security control module 340 is implemented by integrating the Sentinel microservice into the system to perform real-time traffic monitoring and exception handling for each business interface. Each microservice automatically connects to the Sentinel client when it starts, monitors all external interfaces, and reports indicators such as request volume, response time, and exception ratio to the Sentinel console. When an interface request exceeds the set threshold (such as too high QPS) or the response is abnormal (such as increased latency or increased error rate), the security control module 340 immediately triggers the current limiting, circuit breaking, or degradation strategy to prevent the system from collapsing as a whole due to local failures. For example, in a service with a long call chain, if the downstream service is unavailable, the caller will no longer continue to wait, but the security control module 340 will directly return the preset response to avoid resource congestion.

[0056] The monitoring log module 350 improves the observability of the system through structured log collection and centralized analysis. Each microservice outputs operation logs, access logs, and exception logs in a unified format, which are regularly collected by the log collection agent and uploaded to the Elasticsearch cluster for storage and indexing. Kibana, as a visualization platform, provides multi-dimensional log query, statistics, and alarm functions. Operations and maintenance personnel can view the operating status, error distribution, and performance bottlenecks of each service through a graphical interface. At the same time, this module can be linked with the security control module 340. Once a current limiting or circuit breaker event is detected, the module will immediately record and push an alarm message to help quickly locate the source of the problem.

[0057] Finally, after building the Docker image, each microservice is independently deployed in a containerized manner, achieving physical isolation between containers. Each microservice automatically registers with the Nacos service registry upon startup. The system uses Nacos to implement dynamic service registration and discovery, ensuring flexible scaling and efficient communication between microservice instances. Microservices can be declaratively called through standardized RESTful APIs.

[0058] In summary, the present invention adopts a microservices architecture and modular design to enhance system flexibility and scalability, support high-concurrency processing, and meet the needs of large-scale device access and real-time data. Modules communicate through standard interfaces to achieve multi-service collaborative operation.

Claims

1. A microgrid monitoring system based on microservice architecture, characterized in that: include: The access layer is used to provide a unified access portal to the outside world and perform user authentication and request routing; The core service layer consists of multiple independently deployed, loosely coupled microservices, including at least: User management microservice, used to implement multi-role user rights management; Device management microservices, used to manage the registration, configuration, and status monitoring of microgrid sites and their devices; Control microservices, used to collect device operation data in real time and issue control instructions; Health report microservice, used to generate device health index and various statistical reports based on operating data; The component layer is used to implement microservice registration discovery, dynamic configuration, security control, log monitoring, and distributed transaction management; The access layer, core service layer and component layer communicate through standardized interfaces to support high-concurrency monitoring, multi-service collaboration and elastic expansion of the microgrid.

2. A microgrid monitoring system based on microservice architecture according to claim 1, characterized in that: The access layer includes a gateway and an authentication module. The gateway dynamically distributes external requests to the corresponding microservices of the core service layer based on the routing strategy. The authentication module uses the OAuth 2.1 protocol to implement unified identity authentication and permission verification.

3. A microgrid monitoring system based on microservice architecture according to claim 1 or 2, characterized in that: The user management microservice divides user roles into platform administrators, operation and maintenance managers, and ordinary users, and assigns differentiated operation permissions based on roles.

4. A microgrid monitoring system based on microservice architecture according to claim 1 or 2, characterized in that: The device management microservice includes a device information management unit, a device allocation unit, and a point configuration unit, which are used to implement device lifecycle management and hierarchical authorization.

5. A microgrid monitoring system based on microservice architecture according to claim 1 or 2, characterized in that: The control microservices include: The data collection unit is used to receive device data uploaded by the IoT gateway in real time through the message queue and persist it to the time series database; The instruction issuing unit is used to issue the control instructions that have passed the format check and permission verification to the underlying IoT gateway through the proxy server; The real-time data display unit is used to push the latest device status to the front-end visualization interface in real time based on WebSocket.

6. A microgrid monitoring system based on microservice architecture according to claim 1 or 2, characterized in that: The health report microservice includes: Data aggregation unit, used to aggregate historical operation data in the time series database; Report generation unit, used to generate daily, monthly and annual reports on demand or on a scheduled basis; Health analysis unit, used to calculate the equipment health index HI on a scale of 0-100; Report export unit, used to export health reports in multiple formats.

7. A microgrid monitoring system based on microservice architecture according to claim 1, characterized in that: The service registration and discovery module and configuration module of the component layer are all implemented based on Nacos, supporting dynamic registration, health check and multi-environment configuration isolation of microservices.

8. A microgrid monitoring system based on microservice architecture according to claim 1 or 7, characterized in that: The transaction module of the component layer implements distributed transaction consistency based on Seata and adopts AT or TCC mode to manage cross-service transactions.

9. A microgrid monitoring system based on microservice architecture according to claim 8, characterized in that: The security control module of the component layer implements traffic management, circuit breaking, and degradation based on Sentinel; the log monitoring module implements centralized log collection, analysis, and visual alarms based on the ELK stack.

10. A microgrid monitoring system based on microservice architecture according to claim 1, characterized in that: Each microservice is independently deployed as a Docker container and communicates through RESTful API or RPC framework, supporting elastic scaling and rapid iteration.

Images