An intelligent load balancing scheduling system and method based on redundant microservices

Abstract

The application discloses a kind of based on redundancy microservice intelligent load balancing scheduling system and method, the system includes parameter configuration module, business communication module, data acquisition module, fault diagnosis module, storage pool, load statistical calculation module, prediction module, master-slave instance switching module;System is periodically collected microservice CPU data, real-time monitoring node load, in combination with preset threshold rule and prediction model, future load is pre-judged, and master-slave service state is dynamically adjusted.When microservice failure or node overload is detected, automatically trigger master-slave switching, avoid resource overload during business peak period;The application realizes the intelligent load balancing of master-slave node, solves the problem of uneven resource allocation in traditional architecture, significantly improves system resource utilization efficiency and operating stability.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of rail transit automation, and particularly relates to an intelligent load balancing scheduling system and method based on redundant microservices. BACKGROUND

[0002] In recent years, with the rapid development of urban rail transit industry, the power monitoring system as the core business to ensure the safety of rail transit power supply, its reliability and real-time requirements are increasing. The traditional power monitoring system is based on SCADA (data acquisition and monitoring) architecture, which undertakes real-time data acquisition, device state monitoring, remote control and fault alarm and other key functions, and is an important support for stable operation of rail transit power supply system. At the same time, the wide application of urban rail cloud platform promotes the intensification and virtualization transformation of industry IT infrastructure, aiming to improve the overall operation efficiency and reduce the construction cost through resource sharing and elastic scheduling.

[0003] In the implementation architecture of traditional SCADA system, the business function is usually completed by a single service process in centralized single process mode, and the business system is deployed in master-slave redundant dual machine hot standby mode. Specifically, two business nodes run simultaneously, and the service on one node is the master instance, responsible for real-time data processing, business operation and external service; the service on the other node is the standby instance, in standby state. The state synchronization between the master node and the standby node is realized through the heartbeat detection mechanism, and when the master node fails, the standby node can quickly switch to the master role, so as to guarantee the high availability of the system. In the urban rail cloud environment, this architecture is migrated to run in virtual machines, and the master node and the standby node are deployed in independent virtual machines, but the resource allocation strategy still continues the traditional mode, and the computing resource utilization rate of the standby node is significantly lower than that of the master node.

[0004] However, the existing technology has the outstanding problem of unbalanced resource utilization. Since the standby node is in idle state under normal circumstances, its virtual machine resources (such as CPU, memory) are at a low load level (10-15%) for a long time, while the master node may face a sudden load surge (more than 90%) during the peak period of business (such as power transmission and reception operation or multiple client concurrent access), resulting in response delay, control timeout and even service exception. This unreasonable resource allocation not only fails to fully utilize the redundancy of the standby node, but also makes the master node lack the support of elastic expansion under burst load, seriously affecting the reliability and availability of the system. SUMMARY

[0005] Invention purposes: The purpose of the application is to provide an intelligent load balancing scheduling system based on redundant micro services which can dynamically adjust the primary node allocation strategy before the business peak period, realize dynamic load balancing between primary and backup nodes, and improve the reliability and practicability of the system; on the other hand, an intelligent load balancing scheduling method based on redundant micro services is provided.

[0006] Technical scheme: The intelligent load balancing scheduling system comprises:

[0007] The parameter configuration module is used for setting the business node IP address, communication port, micro service CPU statistical period, heartbeat interval, failure determination rule, CPU threshold switching rule, primary and backup switching rule, prediction model library selection, prediction statistical period and prediction advance switching time.

[0008] The business communication module is used for establishing a communication link with other nodes, transmitting current node micro service data and receiving opposite node data, and storing in the communication cache area.

[0009] The data acquisition module is used for periodically acquiring the CPU occupation ratio of each micro service of the current node, and reading the opposite node data from the communication cache area and storing it in the storage pool.

[0010] The fault diagnosis module is used for detecting the failure state of the micro service, and marking the micro service as a fault state when the data acquisition module cannot obtain the CPU occupation ratio of the micro service.

[0011] The storage pool is used for storing real-time state data of the micro service and providing retrieval function.

[0012] The load statistical calculation module is used for calculating the real-time load of the node, comparing the load balancing parameters, and generating the primary and backup switching instruction.

[0013] The prediction module is used for periodically reading the real-time information of the micro service from the storage pool and storing it in the time series database to form historical load data, calculating according to the prediction model parameters set by the parameter configuration module, generating the future business load prediction result, and sending the advance adjustment instruction to the primary and backup instance switching module based on the prediction result.

[0014] The primary and backup instance switching module is used for executing the dynamic switching of the primary and backup states of the micro service.

[0015] The intelligent load balancing scheduling system realizes flexible policy customization through a parameter configuration module, ensures real-time synchronization of data between nodes through a business communication module, accurately monitors microservice CPU load through a data collection module, quickly identifies abnormal services through a fault diagnosis module, efficiently manages real-time state data through a storage pool, dynamically evaluates node load and triggers balancing strategies through a load statistics calculation module, intelligently predicts traffic trends based on historical data through a prediction module, and finally executes dynamic adjustment through a primary and backup instance switching module. The overall system realizes real-time load balancing, rapid fault disaster recovery, and resource utilization optimization of microservice clusters, effectively avoids node overload, and improves system stability and response efficiency.

[0016] Preferably, the business communication module realizes data synchronization between nodes through multi-threaded Socket communication, including:

[0017] Allocating an independent thread and read-write buffer area for each target node;

[0018] Organizing and sending local microservice data packets (LocalPacket) according to the heartbeat interval;

[0019] Receiving and parsing the opposite node data packet into structured data and updating to the storage pool.

[0020] The business communication module adopts a multi-threaded Socket communication mechanism, allocates an independent thread and read-write buffer area for each target node to ensure stable data transmission under high concurrency, organizes and sends local microservice data packets (LocalPacket) based on a preset heartbeat interval to realize real-time synchronization of node states, receives and parses the opposite node data packet, and updates to the storage pool quickly, effectively reducing communication delay, improving cluster data consistency, and ensuring the real-time and reliability of load balancing scheduling.

[0021] Preferably, the data collection module polls the microservice name list by calling the operating system API function, obtains the CPU occupancy information of each microservice, takes the node name + microservice name as the unique key, takes the JSON format data containing CPU occupancy, service state, and timestamp as the value, and stores it in the two-dimensional structure data table of the storage pool.

[0022] The data collection module accurately obtains the real-time CPU occupancy of each microservice through operating system API polling, takes "node name + microservice name" as the unique key, and stores it in the two-dimensional data table in structured JSON format, ensuring the uniqueness and traceability of the monitoring data. This design realizes efficient collection and standardized storage of microservice resource occupancy, providing high-efficiency, low-redundancy basic data support for load statistics and prediction analysis.

[0023] Preferably, the load statistics calculation module traverses the microservice state data in the storage pool to perform the following operations: if all microservices are in standby state, the highest priority microservice is set as master according to priority; if there is multi-master conflict, the redundant instance is degraded to standby state according to priority.

[0024] The load statistics calculation module intelligently performs master-slave switching strategy by dynamically analyzing the microservice state data in the storage pool: when it is detected that all microservices are in standby state, the highest priority instance is automatically promoted to master; if there is multi-master conflict, the redundant instance is automatically degraded according to priority to ensure that the optimal master-slave distribution is always maintained. This mechanism effectively avoids resource contention and service conflict, while ensuring high availability and achieving intelligent dynamic balancing of load.

[0025] Preferably, the prediction module uses ARIMA model to perform time series analysis on historical load data, predicts the time point of future business peak period, and triggers the master-slave instance switching module to adjust the microservice state based on the predicted switching time.

[0026] The prediction module intelligently analyzes historical load data through ARIMA time series model, accurately predicts the future business peak period, and actively triggers master-slave state adjustment based on the preset switching time in advance. This design realizes forward-looking load balancing scheduling, effectively avoids performance degradation due to insufficient resources during business peak period, and significantly improves the adaptive ability and stability of the system in the scenario of traffic fluctuation.

[0027] The intelligent load balancing scheduling method of the application comprises the following steps:

[0028] (1) The parameter configuration module obtains the microservice startup sequence, deploys multiple independent microservices split by the SCADA system on at least two business nodes; each microservice subscribes to the message channel after startup and runs as a standby instance by default;

[0029] (2) The data acquisition module obtains the microservice name list, polls the operating system API to collect CPU occupancy information of each microservice according to the preset statistical period; writes the collected CPU occupancy information, corresponding microservice state identifier and collection timestamp into the storage pool; if the collection fails, it is marked as a fault state;

[0030] (3) The business communication module obtains the node IP and communication port, establishes a multi-threaded Socket link; obtains the CPU occupancy information and state identifier of each microservice from the storage pool according to the heartbeat interval, encapsulates it as a structured data packet, sends it to the opposite node through the read-write buffer area mechanism, and updates the local storage pool after receiving and parsing the opposite data into the same structure;

[0031] (4) The load statistical calculation module periodically traverses the CPU occupancy information and state identifier of each microservice in the storage pool: according to a preset strategy, the master-slave instance distribution is dynamically adjusted, and the state adjustment result is written back to the storage pool, and the state query interface is provided to the outside for the master-slave state query service of each microservice;

[0032] (5) The load statistical calculation module obtains the load threshold rule, and statistically calculates the real-time CPU load of each node; if the total CPU load of the master node exceeds the threshold value and the difference with the standby node exceeds the preset range, the microservice with the highest CPU occupancy in the node is selected to be degraded to the standby state, and the corresponding microservice in the standby node is promoted to the master state, and the state identifier of the corresponding microservice in the storage pool is updated;

[0033] (6) The prediction module obtains the ARIMA model parameters, based on the historical microservice CPU occupancy information in the time series database, the monthly peak value rule is statistically calculated by using a sliding window, the business peak period of the high-load microservice is predicted, and the adaptive switching of the master-slave instance is triggered in advance.

[0034] The intelligent load balancing scheduling method proposed in the application realizes efficient resource scheduling through multiple steps: in the initialization stage (step 1), a high-availability infrastructure is constructed by multi-node microservice deployment and standby state preset; in the real-time monitoring stage (steps 2-3), periodic CPU collection and multi-node data synchronization are adopted to ensure the real-time and accuracy of state perception; in the dynamic scheduling stage (steps 4-5), the master-slave distribution is intelligently adjusted based on the load threshold to realize load balancing between nodes; in the predictive scheduling stage (step 6), the business peak is predicted by time series analysis, and resource allocation is completed in advance. The method forms a complete closed loop from infrastructure deployment, real-time state monitoring to dynamic load balancing and predictive scheduling, effectively solves the problems of uneven utilization of master-slave resources, response delay of burst traffic and other problems in traditional architecture, and significantly improves the stability and resource utilization efficiency of the system as a whole.

[0035] Preferably, step 2 comprises:

[0036] The data acquisition module calls the GetServiceList interface to obtain the microservice name list from the parameter configuration module, and obtains the statistical period of each microservice through the GetCircle interface;

[0037] According to the statistical period, the operating system API is polled to obtain the CPU occupancy information of each microservice;

[0038] The obtained data is stored in a two-dimensional structure data table with node name+microservice name as the unique key and JSON format data containing CPU occupancy, service state and timestamp as the value; wherein:

[0039] When the CPU occupancy information is successfully acquired, if there is a corresponding key value in the storage pool, the timestamp field is updated, otherwise a record is added and the service state is initialized to standby;

[0040] When the CPU occupancy information fails to be acquired, the corresponding microservice state is marked as failure and the timestamp field is not updated;

[0041] The storage pool is a memory database, a relational database or a distributed database;

[0042] The service state includes three states of master, standby and failure.

[0043] The dynamic polling mechanism is used to realize accurate collection of microservice running state: the data collection module calls the system API to obtain the CPU occupancy ratio of each microservice according to the configuration period, and uses a structured storage scheme to ensure data integrity and timeliness. Through intelligent state update logic and flexible data storage support, a high-reliability microservice monitoring foundation is built, which provides real-time and accurate data support for subsequent load balancing decisions. This design not only ensures the real-time performance of state monitoring, but also enhances the fault tolerance of the system through fast failure identification.

[0044] Preferably, step 3 comprises:

[0045] The business communication module calls the GetNodeInfo interface to obtain the IP address, communication port and heartbeat interval parameters of each node;

[0046] According to the number of nodes, a corresponding number of communication threads are created, each thread is allocated an independent read buffer area and a write buffer area, and a TCP connection is established through Socket;

[0047] According to the heartbeat interval, the microservice running data of the node is periodically obtained from the microservice state storage table, and is organized into a LocalPacket data packet with the node name + microservice name as the smallest unit;

[0048] The LocalPacket is stored in the read buffer area, and is sent to the target node by the communication thread through Socket, and the buffer data is cleared after receiving the confirmation reply, otherwise the retransmission mechanism is triggered;

[0049] The data packet sent by the opposite end node is received and stored in the write buffer area;

[0050] The ParsePacket interface is called to parse the data packet content, which is converted into a two-dimensional key-value structure same as the microservice state storage table, wherein the key is the node name + microservice name, and the value is the JSON data containing the CPU occupancy ratio, service state and timestamp;

[0051] The parsed data is first temporarily stored in a temporary memory mapping area, and then is updated in batches to the micro-service state storage table: if the corresponding key exists in the table, the field is updated, otherwise a record is added; after the update, the corresponding data in the temporary memory mapping area is cleared.

[0052] The efficient synchronization of data between nodes is achieved through a multi-threaded Socket communication architecture: based on dynamic thread allocation and double buffer area design (read / write buffer area isolation), combined with the heartbeat mechanism to periodically package and transmit LocalPacket data packets, ensuring real-time and reliable transmission of micro-service state information; through intelligent parsing and storage mechanism (temporary storage in temporary mapping area and batch update) and automatic retransmission strategy, the consistency of data is ensured while the efficiency of cross-node communication is significantly improved, providing low-latency and high-availability distributed state synchronization capability for the system, effectively supporting the real-time requirements of load balancing decisions.

[0053] Preferably, step 4 comprises:

[0054] The load statistics calculation module periodically obtains micro-service running data of each node from the micro-service state storage table, and stores it in memory according to the two-dimensional structure of [node identifier, [micro-service identifier, running data]];

[0055] Traverse the memory data structure: if all micro-service instances are in standby state, set the highest priority micro-service instance to active state according to the preset priority; if multiple active instances of the same micro-service are detected, retain the highest priority instance and downgrade the rest to standby state according to the priority;

[0056] Write the adjusted state data back to the micro-service state storage table, and provide real-time active-standby state query service to the outside through the state query interface, which returns the current active-standby state of the input micro-service identifier.

[0057] Dynamic active-standby management is achieved through intelligent state arbitration mechanism: the load statistics calculation module periodically scans micro-service running data, and automatically handles two scenarios of all-standby state (promote the highest priority to active) and multiple active conflicts (retain the highest priority and downgrade redundant instances) using priority strategy, ensuring that each micro-service always maintains the optimal active-standby distribution. Through real-time state writing and query interface opening, both the consistency of state within the cluster and the reliable service state awareness capability for external systems are guaranteed, effectively improving the self-healing capability and service availability of the system.

[0058] Preferably, step 6 comprises:

[0059] The prediction module obtains ARIMA model parameters and prediction configuration parameters;

[0060] Collect CPU occupancy information of each microservice from the microservice state storage table in a medium-frequency statistical period, and store it into a time series database; the medium-frequency statistical period is 1 minute;

[0061] Based on the historical 24-hour CPU occupancy information of each microservice in the time series database, the monthly peak value rule of the power-off operation microservice of the SCADA system is statistically calculated by using a sliding window;

[0062] The historical peak value time point and CPU occupancy information are input into an ARIMA model to predict the peak value time of the power-off operation microservice in the next 24 hours;

[0063] 30 minutes before the predicted peak value time arrives, the power-off operation microservice is switched from the primary node to the backup node, and the service state and timestamp in the state storage table are updated.

[0064] The intelligent predictive scheduling significantly improves the ability of the system to cope with business peaks: the prediction module analyzes the historical 24-hour CPU data based on the ARIMA model, accurately predicts the future peak period of the power-off operation microservice by combining the sliding window statistics, and actively triggers the primary-backup switching 30 minutes before the peak arrives. This mechanism effectively avoids the business delay caused by the traditional passive response mode through forward-looking resource allocation, ensures that the key microservice always has the optimal load bearing capacity during the peak period, and guarantees the consistency of cluster data through real-time state updating.

[0065] Advantages: Compared with the prior art, the present application has the following significant advantages: 1. Through the dynamic primary-backup switching mechanism and predictive scheduling, the node overload problem caused by the centralized operation of multiple primary services during the business peak period is effectively prevented; based on real-time load monitoring and prediction model, the resource allocation of primary and backup nodes is automatically balanced, the system resource utilization efficiency and operation stability are significantly improved, and the defect of uneven load of primary and backup nodes in the traditional architecture is overcome; 2. The business peak is predicted by using time series analysis, and the primary-backup distribution of microservices is adjusted in advance to ensure that the system can still maintain balanced load during the peak period. This mechanism significantly improves the response speed of critical business (such as power-off operation) and enhances the anti-shock ability of the system in high-concurrency scenarios; 3. Combined with heartbeat detection, CPU monitoring and state marking, the rapid perception and automatic recovery of microservice faults are realized. The system can complete the isolation of abnormal instances and the takeover of backup instances in a very short time, ensure the continuous and stable operation of services, and significantly reduce the impact of faults on business; 4. Lightweight communication and efficient data synchronization strategy are adopted, so that the system can dynamically adjust the deployment scale of microservices while maintaining low-latency inter-node collaboration. This design provides scalable technical support for the microservice evolution of the SCADA system, and adapts to future business growth needs. BRIEF DESCRIPTION OF DRAWINGS

[0066] Figure 1 It is a system structure schematic diagram of the present application;

[0067] Figure 2 This is a schematic diagram of splitting a single SCADA service process into multiple microservices according to the present invention;

[0068] Figure 3 The content and structure of each microservice storage in the data table of the present invention. DETAILED DESCRIPTION

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

[0070] like Figure 1 As shown, the intelligent load balancing scheduling system described in the present invention includes a parameter configuration module, a business communication module, a data acquisition module, a storage pool, a fault diagnosis module, a load statistics calculation module, a master-slave instance switching module and a prediction module. The parameter configuration module sets the IP address and communication port of each business node, the CPU statistical cycle of each microservice, the communication heartbeat interval between business nodes, the microservice failure judgment rule, the CPU threshold switching rule, the microservice master-slave instance switching rule, the prediction model library selection, the prediction statistical cycle, the prediction advance switching time, etc.; the business communication module is mainly responsible for establishing links with other nodes and transmitting the relevant data of each microservice of the current node, and receiving the relevant data transmitted by other nodes and storing it in the communication buffer area; the data acquisition module periodically samples the CPU share of each microservice of the current node, and reads the relevant data of other nodes from the communication buffer area, and stores it in the storage pool according to the predefined method; the storage pool is responsible for data storage and provides fast data retrieval function; the load statistics calculation module is responsible for retrieving data from the storage pool, and statistically calculating the real-time load of the current node and other nodes, and comparing it with the predefined load balancing parameters, and sending business instructions to the master-slave instance switching module; the prediction module regularly reads relevant data from the storage pool, and calculates the prediction results based on the relevant model prediction parameters read in the parameter configuration module, and sends relevant business instructions to the master-slave instance switching module.

[0071] The intelligent load balancing scheduling method of the present invention comprises the following steps:

[0072] Step 1: Deploy microservices

[0073] 1.1 As Figure 2As shown, the SCADA system function services are split into remote control execution microservices (operate_server), digital quantity processing microservices (di_process), analog quantity processing microservices (ai_process), light card analysis microservices (summary_server), coloring calculation microservices (topo), power outage operation microservices (stop_power), power transmission operation microservices (start_power), formula calculation microservices (scada_calculate), data acquisition microservices (data_acquire), protocol conversion microservices (fes_pscada), real-time database access microservices (rdb_server), commercial database submission microservices (sql_commit), and alarm information microservices (alarm_server).

[0074] 1.2 The above microservices are respectively deployed on node 1, node 2, …, node N (generally 2 nodes for project deployment, and 2 nodes are taken as examples below for description), and a parameter acquisition interface GetStartOrder is called to obtain the microservice start order from the parameter configuration module, and the microservices are started according to the predefined requirements.

[0075] 1.3 After all the microservices are started, a parameter acquisition interface GetRegsterChannel is called to obtain a subscription channel number, a message channel is subscribed, external subscription information is provided, and a message receiving instruction is waited for.

[0076] 1.4 Each microservice runs according to normal logic, and a parameter acquisition interface IsSuppliService is periodically called. Since it is just started, the interface calling result is false by default (the interface when true will be described in detail below), so each microservice does not provide services externally, that is, a standby instance of the microservice runs.

[0077] Step 2: Store real-time state information of microservices

[0078] 2.1 The data acquisition module calls a parameter acquisition interface GetServiceList to obtain a name list of microservices started by the current node from the parameter configuration module, calls GetCircle to obtain a statistical period of each microservice, and then calls an operating system API function through the period to obtain CPU occupation ratio information of each microservice by polling microservice names in the name list.

[0079] 2.2 The data collection module stores the above data in the storage pool in the form of a data table. The data table is named Table-MicroServiceInfo. The stored data adopts a two-dimensional structure and is stored in a key-value mode. The node name + microservice name is the only key. The value includes a custom data type info. The info data uses json format and includes at least three fields: CPU percentage, service status, and timestamp (for details, see Figure 3 );

[0080] 2.3 The storage pool described in step 2.2 can be an in-memory database, a relational database, or a distributed database;

[0081] 2.4 There are three microservice states: active, standby, and faulty.

[0082] 2.5 For step 2.1, call the operating system API function to obtain the CPU usage information of each microservice. If the information can be obtained normally, first query the data table in the storage pool using the node name + microservice as the keyword for the current microservice. If this entry is found, update the microservice timestamp field and refresh the time. If this entry is not found, it is assumed that the current microservice is started for the first time. In this case, add a record, set the current microservice status to standby, and obtain the current time and write it to the timestamp field.

[0083] 2.6 If the CPU usage of a microservice cannot be obtained, it means that the microservice is not started or is continuously running due to a microservice failure. Therefore, the current microservice status is set to fault and the timestamp information is not updated.

[0084] Step 3: Send information between nodes

[0085] 3.1 The business communication module calls the parameter acquisition interface GetNodeInfo to obtain the IP addresses of each business node to be communicated, the communication port list, and the communication heartbeat interval between business nodes from the parameter configuration module. It then starts the same number of communication threads based on the number of nodes to be communicated (the current node is node1, so the target node is node2, so the current thread is Tread_NodeName2). Within each thread, it requests two communication buffers from the operating system: a read buffer and a write buffer. It then establishes a TCP link with the target node through a socket and sends a test message to verify that the link is communicating properly.

[0086] 3.2 The service communication module obtains the current node all microservice names and CPU occupancy from Table-MicroServiceInfo according to the time interval of the communication heartbeat interval between service nodes, and organizes them according to the node name + microservice as the minimum unit, and sends each node as an independent data packet (LocalPacket);

[0087] 3.3 The service communication module stores the LocalPacket obtained in step 2.2 into the read buffer area of each thread, and each communication thread periodically polls the read buffer area. When it is found that the read buffer area of the thread has a data packet, it is sent to the target node through the socket, and after confirming that the reply packet of the target node is received, the read buffer area data is deleted, otherwise the retransmission mechanism is started;

[0088] 3.4 When the socket of the communication thread of the node obtains the data packet sent by the opposite node, the data packet is immediately obtained from the socket and stored in the write buffer area of the communication thread;

[0089] 3.5 The service communication module periodically polls the write buffer area of each communication thread. If data is obtained, the ParsePacket interface is called to parse the data packet content, and the data stored in Table-MicroServiceInfo is converted into a two-dimensional key-value structure (key is node name + microservice name, value is custom data type info, info data adopts json format, including CPU occupancy, service state, timestamp). First stored in the local temporary TempMap memory;

[0090] 3.6 The service communication module periodically obtains the key of the temporary TempMap, and queries the Table-MicroServiceInfo table through the key. If the key is found, the microservice CPU occupancy, service state, and timestamp are updated. If the entry is not found, it is considered that the target node is the first time to send the microservice information to the current node, at this time a new record is added, the key-value is written into the Table-MicroServiceInfo table, and the current key in the TempMap is deleted. Then loop until the TempMap is empty.

[0091] Step 4: Redundancy calculation

[0092] 4.1 Load statistics calculation module periodically obtains microservice information of all nodes from Table-MicroServiceInfo, and stores the information in a two-dimensional key-value mode ( [key1, [key2, value2] ] ) in the memory CalculateMAP. (Where key1 is the node name, key2 is the microservice name, and value2 is a json string containing CPU ratio [CPU], service state [state], and timestamp [time])

[0093] 4.2 The load statistics calculation module traverses CalculateMAP, and obtains the service state (key1-key2-value2-state) according to each key1-key2. If all key1-key2-value2-state are standby, the highest priority key1-key2-value2-state is set to primary, and the other states remain unchanged. If there is a primary state, the state remains unchanged. If there are multiple primary states, the key1-key2-value2-state with low priority is set to standby according to the priority requirement, and the result is written back to CalculateMAP.

[0094] 4.3 The load statistics calculation module rewrites the data in CalculateMAP back to Table-MicroServiceInfo.

[0095] 4.4 The load statistics calculation module periodically obtains the primary and standby states of the microservice of the current node, and provides services to the API interface. The interface name is IsSuppliService (string Microservername ), and the input parameter is the microservice name. When the target microservice is in the primary state, the interface returns true, and when the target microservice is in the standby state, the interface returns false. (The source of the interface call mentioned in step 1.4)

[0096] Step 5: Load statistics and primary / standby switching

[0097] 5.1 The load statistics calculation module calls the parameter acquisition interface GetCPUInfo to obtain the CPU statistics period, CPU threshold switching rule, and microservice primary / standby instance switching rule from the parameter configuration module, and stores them in the local memory blocks CPUMap, CPUSwitchMap, and MicroServiceSwitchMap, respectively.

[0098] 5.2 Load statistics calculation module periodically obtains the micro-service CPU occupancy of all nodes from Table-MicroServiceInfo according to the CPU statistics time period in CPUMap, and calculates the CPU occupancy of each node in a node dimension, and obtains the CPU threshold of each node from CPUSwitchMap, and determines whether load adjustment is needed according to the CPU difference between nodes;

[0099] 5.3 If it is determined that a certain node needs to be adjusted (generally according to the principle of lowering the CPU), the CPU occupancy of each service of the node to be adjusted is traversed, and the least principle selection algorithm is used to select the micro-service to be adjusted, at this time the state of the micro-service is adjusted from the previous primary to standby, the timestamp is refreshed to the current time, and the primary and standby states and the timestamp of the micro-service in Table-MicroServiceInfo are rewritten by calling the database interface TableModifyByKey.

[0100] Step 6: Model prediction and business switching

[0101] 6.1 The model prediction module calls the parameter acquisition interface GetPredicteInfo to obtain the prediction model library, prediction statistics period and prediction switching time in advance from the parameter configuration module; considering the strong periodicity of power services, the ARIMA model is used in this example; considering the short-term fluctuation and long-term trend prediction, the prediction statistics period in this example is divided into three frequencies, namely high-frequency statistics HighFre (5 seconds), medium-frequency statistics MiddleFre (1 minute) and low-frequency statistics LowFre (15 minutes); this example mainly predicts the power outage scenario in the evening, so the prediction switching time in advance is 30 minutes.

[0102] 6.2 The model prediction module obtains all micro-service information of the current node from Table-MicroServiceInfo every 5 seconds through medium-frequency statistics MiddleFre, and stores it in the time series database;

[0103] 6.3 The model prediction module obtains the CPU occupancy of each micro-service in the past 24 hours from the time series database, and calls the statistics module to calculate the time when the stop_power micro-service appears CPU peak value, and then uses a sliding time window to calculate the time point when the stop_power micro-service appears CPU peak value in a month according to day as a unit;

[0104] 6.4 The calculated time point and the CPU occupancy data of each micro-service in the past 24 hours are input into the ARIMA model to predict the time point when the stop_power micro-service peak value appears in the future 24 hours, and output the predicted time point;

[0105] 6.5 According to the predicted time point, switch in advance the time of prediction, this example is 30 minutes, switch in advance 30 minutes, adjust the state of micro service stop_power from primary to standby, refresh the timestamp to the current time, and rewrite the primary and standby state and timestamp of stop_power micro service in Table-MicroServiceInfo by calling the database interface TableModifyByKey.

Claims

1. An intelligent load balancing scheduling system based on redundant microservices, characterized in that: include: Parameter configuration module, used to set the business node IP address, communication port, microservice CPU statistical cycle, heartbeat interval, failure judgment rule, CPU threshold switching rule, active / standby switching rule, prediction model library selection, prediction statistical cycle and prediction advance switching time; The business communication module is used to establish communication links with other nodes, transmit the microservice data of the current node and receive the data of the opposite node, and store it in the communication buffer area; The data collection module is used to periodically collect the CPU usage of each microservice on the current node, read the peer node data from the communication buffer, and store it in the storage pool; The fault diagnosis module is used to detect the failure status of microservices. When the data collection module cannot obtain the CPU usage of a microservice, the microservice is marked as faulty. Storage pool, used to store real-time status data of microservices and provide retrieval functions; Load statistics calculation module, used to calculate the real-time node load, compare load balancing parameters, and generate master-slave switching instructions; The prediction module is used to periodically read real-time microservice information from the storage pool and store it in a time series database to form historical load data. It calculates the prediction model parameters set by the parameter configuration module to generate future business load prediction results, and sends advance adjustment instructions to the primary and standby instance switching module based on the prediction results. The prediction module uses the ARIMA model to perform time series analysis on the historical load data, predicts the time point of future business peaks, and triggers the primary and standby instance switching module to adjust the microservice status based on the predicted advance switch time. The master-slave instance switching module is used to perform dynamic switching of the master and standby states of microservices.

2. The intelligent load balancing scheduling system according to claim 1, characterized in that: The business communication module implements data synchronization between nodes through multi-threaded Socket communication, including: Allocate independent threads and read / write buffers to each target node; Organize and send the local service data packet LocalPacket of this node according to the heartbeat interval; Receive data packets from peer nodes, parse them into structured data, and update them to the storage pool.

3. The intelligent load balancing scheduling system according to claim 1, characterized in that: The data acquisition module polls the microservice name list by calling the operating system API function to obtain the CPU usage information of each microservice, and uses the node name + microservice name as the unique key and the JSON format data containing the CPU usage, service status and timestamp as the value to store it in the two-dimensional structure data table of the storage pool.

4. The intelligent load balancing scheduling system according to claim 1, characterized in that: The load statistics calculation module traverses the microservice status data in the storage pool and performs the following operations: if all microservices are in standby state, the highest priority microservice is set as the master according to priority; if there is a multi-master conflict, the redundant instance is downgraded to the standby state according to priority.

5. A method for intelligent load balancing scheduling based on redundant microservices, characterized in that: The following steps are involved: (1) The parameter configuration module obtains the microservice startup sequence and deploys multiple independent microservices split from the SCADA system on at least two business nodes; After each microservice is started, it subscribes to the message channel and runs as a standby instance by default; (2) The data collection module obtains a list of microservice names and polls the operating system API according to a preset statistical cycle to collect the CPU usage information of each microservice; the collected CPU usage information, the corresponding microservice status identifier, and the collection timestamp are written into the storage pool; If the acquisition fails, it is marked as a fault state; (3) The business communication module obtains the node IP and communication port, and establishes a multi-threaded socket link; obtains the CPU usage information and status identification of each microservice from the storage pool according to the heartbeat interval, encapsulates it into a structured data packet, and sends it to the peer node through the read-write cache mechanism. After receiving the peer data, it parses it into the same structure and updates it to the local storage pool; (4) The load statistics calculation module periodically traverses the CPU usage information and status identification of each microservice in the storage pool: dynamically adjusts the distribution of master and backup instances according to the preset strategy, and writes the status adjustment results back to the storage pool. At the same time, it provides the master and backup status query service of each microservice to the outside through the status query interface; (5) The load statistics calculation module obtains the load threshold rules and counts the real-time CPU load of each node; if the total CPU load of the active node exceeds the threshold and the difference with the standby node exceeds the preset range, the microservice with the highest CPU share in the node is selected to be downgraded to the standby state, and the corresponding microservice is promoted from the standby node to the active state, and the corresponding microservice status identifier in the storage pool is updated; (6) The prediction module obtains the ARIMA model parameters, uses the sliding window to calculate the monthly peak pattern based on the historical microservice CPU usage information in the time series database, predicts the business peak period of high-load microservices, and triggers the adaptive switching of the master and slave instances in advance.

6. The intelligent load balancing scheduling method according to claim 5, characterized in that: Step 2 includes: The data collection module calls the GetServiceList interface to obtain the microservice name list from the parameter configuration module, and obtains the statistical period of each microservice through the GetCircle interface; Poll the operating system API according to the statistical period to obtain the CPU usage information of each microservice; The acquired data is stored in a two-dimensional structure data table using the node name + microservice name as the unique key and JSON format data containing CPU usage, service status, and timestamp as the value; where: When the CPU usage information is successfully obtained, if the corresponding key value exists in the storage pool, the timestamp field is updated; otherwise, a new record is created and the service status is initialized to standby; When obtaining CPU usage information fails, the corresponding microservice status is marked as faulty and the timestamp field is not updated; The storage pool is an in-memory database, a relational database or a distributed database; The service status includes three states: active, standby and faulty.

7. The intelligent load balancing scheduling method according to claim 5, characterized in that: Step 3 includes: The business communication module calls the GetNodeInfo interface to obtain the IP address, communication port, and heartbeat interval parameters of each node; Create a corresponding number of communication threads based on the number of nodes, allocate independent read and write buffers to each thread, and establish a TCP connection through Socket; Periodically obtain the microservice operation data of this node from the microservice status storage table according to the heartbeat interval, and organize it into LocalPacket data packets with the node name + microservice name as the smallest unit; The LocalPacket is stored in the read buffer and sent to the target node through the Socket by the communication thread. The cached data is cleared after receiving the confirmation reply, otherwise the resend mechanism is triggered; Receive data packets sent by the peer node and store them in the write buffer; Call the ParsePacket interface to parse the data packet content and convert it into a two-dimensional key-value structure identical to the microservice status storage table, where the key is the node name + microservice name, and the value is JSON data containing CPU usage, service status, and timestamp. The parsed data is first temporarily stored in a temporary memory mapping area, and then updated in batches to the microservice state storage table: if the corresponding key exists in the table, the field is updated, otherwise a new record is added; after the update is completed, the corresponding data in the temporary memory mapping area is cleared.

8. The intelligent load balancing scheduling method according to claim 5, characterized in that: Step 4 includes: The load statistics calculation module periodically obtains the microservice operation data of each node from the microservice status storage table and stores it in the memory according to the two-dimensional structure of [node ID, [microservice ID, operation data]]; Traversing the data structure stored in the memory: if all microservice instances are in a standby state, setting the microservice instance with the highest priority to the active state according to a preset priority; if it is detected that there are multiple active instances of the same microservice, retaining the highest priority instance according to priority, and downgrading the others to a standby state; The adjusted status data is written back to the microservice status storage table, and the active / standby status query service is provided to the outside in real time through the status query interface. The interface returns the current active / standby status according to the input microservice identifier.

9. The intelligent load balancing scheduling method according to claim 5, characterized in that: Step 6 includes: The prediction module obtains ARIMA model parameters and prediction configuration parameters; Collect the CPU usage information of each microservice from the microservice status storage table at a medium-frequency statistical period of 1 minute and store it in the time series database. Based on the historical 24-hour CPU usage of each microservice in the time series database, a sliding window is used to calculate the monthly peak patterns of the power outage operation microservices split from the SCADA system. Input historical peak time points and CPU usage information into the ARIMA model to predict the peak time of power outage microservices within the next 24 hours; 30 minutes before the predicted peak time, the power outage operation microservice is switched from the active node to the standby node, and the service status and timestamp in the state storage table are updated.

Images