A micro-service adaptive load balancing system with a scheduler as the core

Abstract

The present application relates to the technical fields of industrial internet, cloud platform scheduling control, micro-service management and distributed resource allocation, and specifically relates to a micro-service adaptive load balancing system with a scheduling program as the core, which can solve the problems of static solidification of micro-service load distribution, poor global load visibility and existence of load pseudo-equilibrium in the existing industrial cloud platform, and at the same time, solve the technical drawbacks of service abnormality relying on manual processing and scheduling operation without fault rollback mechanism. By setting up an independent scheduling center to link multiple groups of basic service clusters, relying on long connection to realize real-time collection of service state and heartbeat, combining capacity constraints and real device load to complete dynamic adaptive allocation, it can independently handle service over-limit, disconnection and other abnormalities and complete load redistribution, while supporting scheduling state rollback and man-machine integrated scheduling mode. The present application has strong decoupling, convenient operation and maintenance and outstanding fault self-healing ability, and can effectively improve the resource utilization, business scalability and overall high availability of the industrial cloud platform.

Description

Technical Field

[0001] This invention relates to the fields of industrial internet, cloud platform scheduling and control, microservice governance and distributed resource allocation technology, and in particular to a microservice adaptive load balancing system with a scheduler as its core, which is suitable for the operation scenario of an industrial IoT cloud platform with one scheduling center corresponding to multiple base service instances, multiple registration groups and a large number of device access objects. Background Technology

[0002] When deploying basic services, existing industrial cloud platforms typically connect multiple Base service instances to the system simultaneously to jointly undertake tasks such as registration group initialization, device data acquisition, project operation, real-time communication, alarm handling, and subsequent microservice invocation. To enable multiple Base services to work collaboratively, common solutions typically employ manual allocation, fixed mapping, or simple round-robin allocation. This means that operations and maintenance personnel pre-specify a registration group and bind it to a specific Base service, or specify the target instance sequentially when adding a new registration group.

[0003] While such solutions are simple to implement, their scheduling logic is typically distributed across various service instances, lacking a unified central control node. This makes it impossible to monitor the connection status, current number of service groups, number of devices, available capacity, and load changes of all Base service instances in real time. Especially in industrial settings, where there are significant differences in the number of devices, communication frequencies, and business pressure among registration groups, using static allocation methods can easily lead to situations where some Base services are under continuous high pressure due to a large number of devices and registration groups, while other Base services remain idle for extended periods.

[0004] Furthermore, existing solutions often require manual intervention when service instances disconnect abnormally, exceed capacity limits, migrate, or are reassigned. Especially when a Base service goes offline, becomes unassignable, or reaches its limit, there is a lack of a closed-loop mechanism that allows a central scheduler to automatically identify and trigger cancellation, migration, reassignment, and recovery. Therefore, existing solutions struggle to meet the high availability, dynamic scaling, and continuous load balancing requirements of industrial IoT platforms.

[0005] The existing technology has the following five inherent defects: 1. Lack of a unified scheduling center. In existing technologies, each Base service typically operates independently, lacking an independent scheduler to uniformly manage all Base service instances, registration group distribution relationships, and current load status, resulting in poor overall system visibility and coarse control granularity.

[0006] 2. The allocation strategy is too static. Traditional solutions typically allocate registration groups based on manual experience, fixed binding, or simple round-robin, without considering the number of groups currently allocated to the Base service, the number of devices, whether further allocation is allowed, and the current state of the instance, making it difficult to adaptively adjust when the load changes.

[0007] 3. Inability to handle load differences between groups. The number of devices in registered groups on an industrial platform varies greatly, and the same number of registered groups may correspond to completely different processing pressures. If only "averaging the number of groups" is applied without "balancing the number of devices and the load," it is easy to cause a false balance.

[0008] 4. Lack of anomaly migration mechanism. When a Base service exceeds its capacity, actively reports exceeding limits, experiences heartbeat timeout, or disconnects, the existing solution lacks an automatic migration and reallocation process initiated by the scheduler, making it difficult to restore overall balance in a timely manner.

[0009] 5. Lack of a recoverable and rollback-able scheduling loop. If operations such as registration group allocation, deallocation, restart, and migration fail, existing solutions typically cannot save the previous state and perform rollback or recalculation, resulting in insufficient stability.

[0010] Therefore, a new technical solution is urgently needed to solve the above-mentioned technical problems. Summary of the Invention

[0011] The purpose of this invention is to overcome the problems of the prior art and provide a microservice adaptive load balancing system with a scheduler at its core. This system addresses the lack of unified centralized scheduling and control in existing industrial IoT microservice load balancing architectures, the inability to globally perceive service load status, and the inability of traditional static allocation methods to accurately reflect real business loads, leading to uneven load distribution. Furthermore, existing systems cannot automatically handle abnormal scenarios such as service overload or disconnection, making automatic load migration and reallocation difficult. Moreover, various scheduling operations lack stateful rollback capabilities, resulting in poor scheduling stability and failing to meet the actual operational requirements of high availability, dynamic balancing, and fault self-recovery in industrial cloud platforms.

[0012] The above objectives are achieved through the following technical solutions: A microservice adaptive load balancing system with a scheduler at its core includes an independently deployed scheduling center module, a Base service cluster, and a visualization interaction module. The scheduling center module communicates with each Base service instance in the Base service cluster via a WebSocket long connection. The scheduling center module has built-in status acquisition module, capacity constraint module, load assessment module, allocation decision module, migration control module, fault recovery module, and consistency and recovery module. The status acquisition module is used to receive service information and heartbeat information periodically reported by each Base service instance, and maintain the mapping relationship between global Base services and sessions, and between registration groups and Base services; The capacity constraint module is configured with CanAssign and MaxAssignCount constraint parameters, which are used to filter and obtain a candidate set of allocable Base services. The load assessment module uses the number of devices in the registered group as the load weight, and counts the number of registered groups and the total number of devices that each Base service instance has carried to represent the business pressure. The allocation decision module dynamically allocates the registration groups to be allocated based on the ascending order of the total number of candidate Base service instance devices. The migration control module identifies Base service instances that exceed the limit and automatically completes the unbinding of registration groups and cross-instance reassignment. The fault recovery module determines the disconnected Base service instance based on the heartbeat timeout and reassigns it to an available instance by binding it to the registration group. The consistency and recovery module stores a snapshot of the state before the scheduling operation and performs a rollback when the operation fails. The visualization and interaction module is used to display the global scheduling status and receive automatic / manual scheduling instructions; The Base service instance is used to perform registration group loading and initialization, and to report the operation execution results to the scheduling center module.

[0013] Furthermore, the scheduling center module is the scheduling hub of SchedulerService, and a global mutual exclusion mechanism is used to ensure that only a single scheduler instance runs at any given time.

[0014] Furthermore, after each Base service instance starts, it actively establishes a WebSocket long connection and reports service information including at least the Base identifier, service IP, service port, RPC port, current running status, list of registered groups already hosted, and total number of devices. The status acquisition module classifies the Base service instance into four states: connected and schedulable, unallocable, over-limit, and disconnected, based on the last update time of the heartbeat message.

[0015] Furthermore, the CanAssign parameter of the capacity constraint module indicates whether the Base service instance allows the allocation of new registration groups, and the MaxAssignCount parameter indicates the maximum number of registration groups that the Base service instance can support. Both types of parameters can be dynamically adjusted through the operation and maintenance interface or preset in the configuration file.

[0016] Furthermore, before allocating the registration group, the allocation decision module removes Base service instances that are not connected, have CanAssign not set, or have reached the MaxAssignCount limit to generate a candidate set.

[0017] Furthermore, the adaptive allocation process of the allocation decision module includes: reading the candidate Base service set, obtaining the number of allocated groups and the total number of devices for each instance, sorting by the total number of devices from smallest to largest, and allocating the registration groups to be allocated in sequence. After each group is allocated, the corresponding Base service count is updated in real time and the candidate instances are reordered. If all candidate instances reach the capacity limit, the current round of allocation is terminated and an unallocated list is output.

[0018] Furthermore, the over-limit migration process of the migration control module is as follows: identify and mark the over-limit Base service instance, and issue a cancellation allocation instruction; after receiving the original Base service unbinding completion receipt, select the available Base service instance with the lowest total number of devices, and issue a batch allocation instruction to complete the registration group migration and redistribution.

[0019] Furthermore, the disconnection recovery process of the fault recovery module is as follows: if the heartbeat timeout determines that the Base service instance is disconnected, the instance is marked and its bound registration group is set to the state of pending migration; if the operation and maintenance policy allows, the registration group to be migrated is handed over to the allocation decision module for reallocation; after the faulty Base service recovers the connection, it is re-included in the candidate set to participate in subsequent allocation.

[0020] Furthermore, the visualization interaction module supports both automatic and manual scheduling modes; the automatic scheduling includes one-click allocation and adaptive rebalancing; the manual scheduling supports manually specifying the Base service, batch cancellation, and batch restart of registration groups, and all manual operations are uniformly verified by the scheduling center to check the online status of instances, capacity constraints, and registration group occupancy status.

[0021] Furthermore, the scheduling center module also includes a metadata loading module and a mapping publishing module; the metadata loading module loads Base service, registration group, and device metadata from MySQL; the mapping publishing module pushes a complete global allocation mapping view to the audit log and subscription module.

[0022] Furthermore, the system is adapted to the industrial internet architecture. The underlying data sources include gateways, HMIs, PLCs, and sensors. It connects to the data platform via protocols such as XNet, MQTT, and Modbus. The data platform interfaces with TDengine, MySQL, and Redis databases. The scheduler is independent of the business microservices and can complete load balancing governance without modifying the original business logic of the Base service.

[0023] The present invention provides a microservice adaptive load balancing system with a scheduler at its core. It achieves global awareness and unified management of the status of all services by building an independent centralized scheduling architecture, achieves accurate load balancing by allocating resources based on the load weight of real devices to avoid the problem of false load balancing, achieves autonomous repair of service anomalies through an automated anomaly migration and fault recovery mechanism, achieves stable and controllable scheduling operations through a scheduling status snapshot rollback mechanism, and achieves flexible operation and maintenance management through a human-machine collaborative scheduling mode. It effectively improves the system's resource utilization, operational stability, fault tolerance and adaptability to industrial scenarios. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the layered architecture of a microservice adaptive load balancing system with a scheduler as its core, as described in this invention. Figure 2 This is a schematic diagram of the internal modules and interaction architecture of the scheduling center of a microservice adaptive load balancing system with a scheduler as its core, as described in this invention. Detailed Implementation

[0025] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. The described embodiments are merely some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] like Figure 1 and Figure 2 As shown, this solution provides a microservice adaptive load balancing system with a scheduler at its core. The overall architecture is divided into three layers: front-end business access layer, scheduling service governance layer, and underlying industrial data source layer. The core components include: independently deployed scheduling center module, Base service cluster, and visualization interaction module. The scheduling center module communicates with each Base service instance in the Base service cluster via a WebSocket long connection. The scheduling center module has built-in status acquisition module, capacity constraint module, load assessment module, allocation decision module, migration control module, fault recovery module, consistency and recovery module; it is also equipped with metadata loading module and mapping publishing module.

[0027] The status acquisition module is used to receive service information and heartbeat information periodically reported by each Base service instance, and maintain the mapping relationship between global Base services and sessions, and between registration groups and Base services; The capacity constraint module is configured with CanAssign and MaxAssignCount constraint parameters, which are used to filter and obtain a candidate set of allocable Base services. The load assessment module uses the number of devices in the registered group as the load weight, and counts the number of registered groups and the total number of devices that each Base service instance has carried to represent the business pressure. The allocation decision module dynamically allocates the registration groups to be allocated based on the ascending order of the total number of candidate Base service instance devices. The migration control module identifies Base service instances that exceed the limit and automatically completes the unbinding of registration groups and cross-instance reassignment. The fault recovery module determines the disconnected Base service instance based on the heartbeat timeout and reassigns it to an available instance by binding it to the registration group. The consistency and recovery module stores a snapshot of the state before the scheduling operation and performs a rollback when the operation fails. The visualization and interaction module is used to display the global scheduling status and receive automatic / manual scheduling instructions; The Base service instance is used to perform registration group loading and initialization, and to report the operation execution results to the scheduling center module.

[0028] The specific implementation mechanisms of each module in this system are as follows: (1) Deployment mechanism of centralized scheduling program The scheduling center module serves as the scheduling hub for the SchedulerService. It employs a global mutual exclusion mechanism to ensure that only a single scheduler instance runs at any given time, acting as an independent control service separate from all Base service instances. The scheduling hub undertakes all core management and control tasks: receiving Base service instance connections, maintaining Base session mappings, saving registration group-Base allocation mappings, displaying the running status of all Base instances, and uniformly executing allocation, cancellation, migration, restart, and fault recovery control.

[0029] (2) Base service status reporting and heartbeat monitoring mechanism After each Base service instance starts, it actively establishes a WebSocket long connection and reports complete service information at once. The service information includes at least the Base identifier, service IP, service port, RPC port, current running status, list of registered groups already hosted, and total number of devices. After establishing the long connection, it continuously pushes heartbeat messages periodically.

[0030] The status acquisition module classifies the Base service instance into four running states based on the last update timestamp of the heartbeat message: connected and schedulable, online but not allocable, capacity exceeded, and disconnected due to heartbeat timeout. The status acquisition module refreshes the global in-memory status database in real time, providing real-time data for load assessment and allocation decisions.

[0031] (3) Base service capacity constraint model The capacity constraint module is configured with two types of core constraint parameters: the CanAssign parameter indicates whether the Base service instance is allowed to add new registration group assignments, and the MaxAssignCount parameter indicates the maximum number of registration groups that the Base service instance can support; both types of parameters can be dynamically adjusted online through the operation and maintenance interface, or can be preset and fixed through a local configuration file.

[0032] Before the allocation decision module performs the registration group allocation, it automatically filters out three types of Base service instances that do not meet the conditions: disconnected instances, instances marked as prohibited from allocation by CanAssign, and instances whose registered groups have reached the MaxAssignCount limit. The remaining instances form the allocable candidate set.

[0033] (4) Registration Group Load Quantification Evaluation Model Abandoning the traditional single load balancing metric that only counts the number of registered groups, this invention constructs a two-dimensional load assessment model: for each registered group, it maintains a registered group identifier, registered group name, running status, affiliated Base service, and number of mounted devices; the load assessment module simultaneously counts two load metrics for each Base service instance: the total number of allocated registered groups and the total number of devices supporting all registered groups. The total number of devices is used as the core load weight to accurately reflect the real data acquisition, communication, and alarm processing pressure in industrial scenarios, avoiding the pseudo-balance problem caused by simply averaging the number of groups.

[0034] (5) Adaptive dynamic allocation algorithm flow The allocation decision module triggers allocation from various sources, including one-click automatic allocation commands, manual allocation commands, and load imbalance rescheduling commands. The complete allocation steps are as follows: Step 1: Read all online Base services that meet capacity constraints and generate a candidate instance set; Step 2: Call the load assessment module to obtain the current number of groups allocated and the total number of devices for each candidate Base service; Step 3: Sort the candidate Base services in ascending order according to the total number of currently supported devices; Step 4: Take out the registration groups to be assigned one by one, traverse the sorted candidate Base services, and check whether the MaxAssignCount limit has been reached for each one; Step 5: If the candidate Base service has not reached its capacity limit, the currently registered group will be assigned to the instance, and the number of assigned groups and the total number of devices for the Base service will be updated synchronously. Step 6: If the first-ranked Base service has reached its allocation limit, then check the next candidate instance. Step 7: After each registration group assignment is completed, update the load data of all candidate instances in real time and re-sort them in ascending order; Step 8: If all candidate Base services have reached their capacity limit, terminate this round of allocation and output a list of unallocated registration groups.

[0035] Allocation execution closed loop: The scheduling center module generates batch allocation commands and sends them to the corresponding Base service instance via WebSocket; after receiving the instructions and completing the registration group construction and initialization loading, the Base service returns batch allocation response, initialization completion response, and new registration group status response to the scheduling center in sequence; after receiving the receipt, the scheduling center synchronously updates the global memory mapping relationship, the registration group running status, and the Base service load count, forming a complete allocation feedback closed loop.

[0036] (6) Automatic migration closed-loop mechanism for exceeding limits The complete execution flow of the migration control module is as follows: Step 1: The scheduling center receives the overload information actively reported by the Base service, or the load assessment module determines that the Base service's capacity has exceeded the limit, and marks the Base as an overload node; Step 2: The scheduling center issues a cancellation instruction to the original Base service that has exceeded the limit; Step 3: Wait for the original Base service to return a response indicating that the unbinding is complete; Step 4: Select the target instance with the lowest total number of host devices from the remaining allocable, non-overloaded Base candidate set; Step 5: Generate batch allocation instructions and send them to the target Base service to complete the registration group migration and reallocation; The entire process forms a fully automated migration loop: over-limit identification, issuance of unbinding instructions, receipt of unbinding receipts, selection of the optimal target, and completion of new mapping assignment.

[0037] (7) Base service disconnection fault recovery mechanism The fault recovery module continuously monitors the heartbeat timeout of each Base service. When a Base service fails to push a heartbeat for a preset period, the instance is determined to be disconnected, the disconnection time is recorded, and an operation and maintenance notification is pushed. All registration groups bound to the disconnected Base are marked as abnormal and awaiting migration. When the operation and maintenance policy allows, the registration groups awaiting migration are included in the allocation pool and rebalanced by the allocation decision module to other healthy and available Base service instances. After the original faulty Base service restores its WebSocket connection, it re-reports its service metadata and heartbeat, the scheduling center updates its running status, and it is re-included in the candidate set to participate in subsequent registration group allocation.

[0038] (8) Consistency and transaction rollback mechanism The consistency and recovery module handles all types of scheduling operations, including allocation, cancellation, migration, and restart. Before executing an operation, it caches a complete global mapping snapshot. If the operation fails or the Base service returns an exception receipt, it automatically retrieves the snapshot and rolls back to the stable state before the operation, ensuring the consistency of the global registration group and the Base allocation mapping relationship and avoiding business interruption and mapping errors.

[0039] (9) Mechanism for the integration of manual and automatic scheduling The system supports dual scheduling modes: fully automatic scheduling and manual scheduling by operations and maintenance personnel. Fully automatic scheduling includes one-click allocation, scheduled adaptive rebalancing, and automatic anomaly migration. Manual scheduling allows operations and maintenance personnel to manually select specified Base services, choose target registration groups, assign single or batches of services, cancel batch assignments, and restart registration groups in batches. All manual operations are uniformly verified by the scheduling center, with verification items including: whether the target Base service is online, whether CanAssign allows allocation, whether the MaxAssignCount limit has been exceeded, and whether the target registration group is already occupied by other instances. This achieves a converged governance mode of manual control, automatic balancing, and unified scheduling.

[0040] (10) Visualized operation and maintenance interaction mechanism The visual interaction module provides a graphical scheduling operation interface, which displays the following: all Base service instances, all registered groups, status color indicators, the mapping relationship between registered groups and Base allocation, the number of devices supported by each instance, CanAssign allocation permissions, and MaxAssignCount allocation limit. The interface is equipped with control functions: one-click load balancing, reallocation by device number, Base instance filtering, registered group status filtering, batch cancellation of allocation, and batch restart of registered groups. Operation and maintenance personnel can view the load balancing results in real time and manually intervene in the scheduling process as needed.

[0041] (11) Supporting auxiliary modules Metadata loading module: Used to load complete metadata of Base service, registration group, and device from MySQL database to provide basic data for scheduling decisions; Mapping Publishing Module: Used to push the complete global allocation mapping view to the audit logs and subscription service modules, so that upper-layer business modules can consume the mapping data.

[0042] (12) Overall Industrial Internet Adaptation Architecture like Figure 1 As shown, the overall layered architecture of the system is as follows: Top-level: PC browser, mobile APP / browser, WeChat mini-program, third-party caller, connecting to business microservices such as push, SMS, email, permissions, configuration, production progress, alarms, and data aggregation; Mid-tier data platform: Stores basic data, performs general transformations, manages devices, and forwards data, with supporting TDengine, MySQL, and Redis databases; The underlying data source layer includes gateways, HMIs, PLCs, and various sensors, which access the platform via heterogeneous network protocols such as XNet, MQTT, XinjeModbus, FRPC, and ModbusTCP. The scheduler is deployed independently within the scheduling service system, completely decoupled from business microservices, and can achieve load balancing governance without modifying the original Base service business logic.

[0043] On the one hand, this solution also provides a microservice adaptive load balancing method with a scheduler at its core, which is implemented by the aforementioned system; On the other hand, this solution also provides a computer-readable storage medium for storing a computer program that implements the above-mentioned adaptive load balancing method when executed by a processor.

[0044] Example 1 like Figure 1 As shown in the figure, this embodiment provides the overall architecture of the system, deployed on an industrial IoT cloud platform. The overall architecture consists of four layers: front-end access layer, business microservice layer, scheduling and governance layer, and underlying device data source layer, as detailed below: 1. Front-end access layer: Includes PC browser, mobile APP / browser, WeChat official account, mini program, and third-party system call interface, and uniformly connects to push service, SMS service, email service, access control, configuration business, large screen display, production progress, alarm microservice, historical data collection, device access and other business modules; and supports operation and maintenance operation, emergency handling, formula management, data aggregation, numerical change recording, project management, processing data and other functional modules.

[0045] 2. Data Platform Layer: Deploys TDengine time-series database, MySQL relational database, and Redis cache; includes built-in basic data storage, general data transformation module, device management module, heterogeneous data source communication module, and data forwarding service module, uniformly undertaking data interaction between upper-layer business and lower-layer devices.

[0046] 3. Scheduling and Governance Layer: The core is the SchedulerService scheduling center module, which is deployed independently and decoupled from all business microservices without changing the original business code; the scheduling center connects to all Base service instance clusters through WebSocket long connections to uniformly manage registration group allocation, load balancing, and fault migration.

[0047] 4. Bottom Data Source Layer: Industrial field gateways, HMI human-machine interfaces, PLC controllers, various sensors, and third-party data services serve as data sources; raw data from the devices is transmitted upwards via various industrial network protocols such as XNet, MQTT, XinjeModbus, FRPC, and ModbusTCP.

[0048] The scheduling center module is deployed globally with mutual exclusion. Only a single instance is allowed to run in a cluster environment to ensure a unique decision source for global scheduling and avoid allocation conflicts among multiple scheduling nodes.

[0049] Example 2 like Figure 2 As shown, this embodiment provides internal module interaction within the scheduling hub. The scheduling hub SchedulerService has six core functional modules built-in, plus a metadata loading module and a mapping publishing module. It externally interfaces with the scheduling operation terminal, the Base service cluster, and the audit log subscription module, as detailed below: Metadata loading module: At startup, it reads all Base service metadata, registration group metadata, and device metadata from the MySQL database and loads them into the scheduling center memory to provide basic data for status management and allocation decisions.

[0050] The Base state management module (i.e., the state acquisition module) maintains the WebSocket long-connection session pool, receives metadata reported by each Base service upon startup, and periodic heartbeat messages; it distinguishes four states of Base instances based on the heartbeat timestamp: connected and schedulable, unallocable, over-limit, and disconnected; and it maintains two core mapping tables in memory in real time: the Base identifier-session connection mapping table and the registration group identifier-belonging Base mapping table.

[0051] The Base service reports the following metadata fields upon startup: Base unique identifier, service IP address, service port, RPC communication port, current running status, complete list of registered groups, and total number of devices in all registered groups; heartbeat messages are continuously pushed at fixed intervals, and the heartbeat timeout threshold can be configured through the operation and maintenance interface.

[0052] Mapping and Publishing Module: When the global registration group-Base allocation mapping changes (assignment, unbinding, migration), it automatically pushes the complete and latest mapping view to the audit logs and RegGroupPubic subscription service for upper-layer business modules to consume the registration group ownership information.

[0053] Allocation and scheduling module (i.e., allocation decision module + capacity constraint module + load assessment module): (1) Capacity constraint logic: Read the CanAssign boolean flag of each Base service and the maximum registration group limit of MaxAssignCount; filter invalid instances before allocation and generate a candidate set; both types of parameters can be modified online by the scheduling operation terminal, and the modification will be updated in real time.

[0054] (2) Load assessment logic: Traverse the candidate Base, read the number of registered groups assigned to each instance and the total number of devices, and use the total number of devices as the core load weight.

[0055] (3) The adaptive allocation algorithm is executed as follows: Candidate Bases are sorted in ascending order by the total number of devices they support; Take out the registration groups to be assigned one by one, and check whether the sorted Base has not reached MaxAssignCount; After successful allocation, the number of groups and device counts of the Base are updated in real time, and the candidate list is reordered. If all Bases are full, allocation will stop, and the unallocated registration groups will be output to the scheduling interface for display.

[0056] (4) Allocation closed loop: Generate BATCHASSIGN batch allocation instruction, and send WebSocket to the target Base; after Base executes the registration group initialization, it returns allocation completion receipt and initialization receipt in sequence; the scheduling center receives the receipt and updates the memory mapping table.

[0057] The overload migration module (i.e., the migration control module) receives overload messages actively reported by the Base, or marks the Base as an overload node after the allocation and scheduling module determines that the load exceeds the limit; it issues a GROUPCANCEL unbinding command to the original Base; after receiving the unbinding completion receipt, it selects the instance with the lowest device load from the normal candidate Bases and issues a new BATCHASSIGN command to complete the registration group migration.

[0058] Consistency and Recovery Module: Before performing allocation, GROUPCANCEL, RESTARTGROUP migration, and restart operations, cache the current global mapping snapshot; if Base returns an execution failure receipt or network interruption occurs, automatically retrieve the snapshot for rollback and restore the allocation relationship before the operation to ensure mapping consistency.

[0059] External Schedulerform / WiForm scheduling operation terminal (i.e., visual interaction module): The graphical interface displays all Bases, registration groups, number of devices, allocation relationships, CanAssign, MaxAssignCount, and instance running status in real time; it provides manual operation functions such as one-click allocation, batch cancellation, batch restart, instance filtering, and status filtering; after the manual operation is submitted, the allocation and scheduling module will uniformly verify the instance online status, capacity limit, and registration group occupancy, and execute the scheduling logic after the verification is passed.

[0060] Example 3 This embodiment demonstrates the complete fault recovery process of this system, as detailed below: 1. Disconnection determination: The BBase status management module continuously monitors the heartbeat time. If no heartbeat is received after the preset timeout period, the Base instance is marked as disconnected; an alarm is pushed to the scheduling operation terminal.

[0061] 2. Handling of abnormal registration groups: Mark all registration groups that have disconnected from the Base as pending migration; when the operation and maintenance policy allows automatic recovery, put the registration groups to be migrated into the allocation queue, and the D allocation and scheduling module will perform adaptive balanced allocation to other healthy Bases.

[0062] 3. Fault Node Recovery: After the original faulty Base network is repaired, it actively reconnects to the scheduling center WebSocket and re-reports complete metadata and heartbeat; the BBase status management module updates its status to schedulable and includes it in the candidate set to participate in the subsequent allocation of new registration groups; the registration groups that have been migrated will not be automatically returned, and if they need to be returned, it must be done manually by the operations and maintenance department.

[0063] Example 4 This embodiment is applied to a human-machine collaborative scheduling scenario, including: 1. Fully automated scheduling: Operations and maintenance personnel can click "One-click allocation" on the scheduling interface, and the scheduling center will automatically execute the complete adaptive allocation algorithm without manual intervention; migration and recovery will be automatically triggered when the base exceeds the limit or is disconnected.

[0064] 2. Manual Scheduling: The operations and maintenance personnel manually select a specified Base and check several registered groups on the operation terminal, and issue an allocation command; the scheduling center verifies that the target Base is online, CanAssign=true, the MaxAssignCount limit has not been reached, and the registered group is not occupied; if the verification is successful, the allocation is executed; if it fails, a pop-up window will prompt the reason for the constraint; batch GROUP can cancel the allocation and RESTARTGROUP restart the registered group is supported.

[0065] The above description is merely illustrative of the embodiments of the present invention and is not intended to limit the present invention. For those skilled in the art, any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A microservice adaptive load balancing system with a scheduler at its core, characterized in that, It includes an independently deployed scheduling center module, a Base service cluster, and a visualization interaction module. The scheduling center module communicates with each Base service instance in the Base service cluster via a WebSocket long connection. The scheduling center module has built-in status acquisition module, capacity constraint module, load assessment module, allocation decision module, migration control module, fault recovery module, and consistency and recovery module. The status acquisition module is used to receive service information and heartbeat information periodically reported by each Base service instance, and maintain the mapping relationship between global Base services and sessions, and between registration groups and Base services; The capacity constraint module is configured with CanAssign and MaxAssignCount constraint parameters, which are used to filter and obtain a candidate set of allocable Base services. The load assessment module uses the number of devices in the registered group as the load weight, and counts the number of registered groups and the total number of devices that each Base service instance has carried to represent the business pressure. The allocation decision module dynamically allocates the registration groups to be allocated based on the ascending order of the total number of candidate Base service instance devices. The migration control module identifies Base service instances that exceed the limit and automatically completes the unbinding of registration groups and cross-instance reassignment. The fault recovery module determines the disconnected Base service instance based on the heartbeat timeout and reassigns it to an available instance by binding it to the registration group. The consistency and recovery module stores a snapshot of the state before the scheduling operation and performs a rollback when the operation fails. The visualization and interaction module is used to display the global scheduling status and receive automatic / manual scheduling instructions; The Base service instance is used to perform registration group loading and initialization, and to report the operation execution results to the scheduling center module.

2. The microservice adaptive load balancing system with a scheduler as its core, as described in claim 1, is characterized in that... The scheduling center module is the scheduling hub of SchedulerService, and it uses a global mutual exclusion mechanism to ensure that only a single scheduler instance runs at any given time.

3. A microservice adaptive load balancing system with a scheduler as its core, as described in claim 1, is characterized in that... After each Base service instance starts, it actively establishes a WebSocket long connection and reports service information including at least the Base identifier, service IP, service port, RPC port, current running status, list of registered groups, and total number of devices. The status collection module classifies the Base service instance into four states: connected and schedulable, unallocable, over-limit, and disconnected, based on the last update time of the heartbeat message.

4. A microservice adaptive load balancing system with a scheduler as its core, as described in claim 1, is characterized in that... The CanAssign parameter of the capacity constraint module indicates whether the Base service instance allows new registration group allocation, and the MaxAssignCount parameter indicates the maximum number of registration groups that the Base service instance can support. Both types of parameters can be dynamically adjusted through the operation and maintenance interface or preset in the configuration file.

5. A microservice adaptive load balancing system with a scheduler as its core, as described in claim 4, is characterized in that... Before allocating a registration group, the allocation decision module removes Base service instances that are not connected, have CanAssign not set, or have reached the MaxAssignCount limit to generate a candidate set.

6. A microservice adaptive load balancing system with a scheduler as its core, as described in claim 1, is characterized in that... The adaptive allocation process of the allocation decision module includes: reading the candidate Base service set, obtaining the number of allocated groups and the total number of devices for each instance, sorting by the total number of devices from smallest to largest, and allocating the registration groups to be allocated in sequence. After each group is allocated, the corresponding Base service count is updated in real time and the candidate instances are reordered. If all candidate instances reach the capacity limit, the current round of allocation is terminated and an unallocated list is output.

7. A microservice adaptive load balancing system with a scheduler as its core, as described in claim 1, is characterized in that... The migration control module's over-limit migration process is as follows: identify and mark over-limit Base service instances, and issue a cancellation assignment command; after receiving the original Base service unbinding completion receipt, select the available Base service instance with the lowest total number of devices, and issue a batch assignment command to complete the registration group migration and reassignment.

8. A microservice adaptive load balancing system with a scheduler as its core, as described in claim 1, is characterized in that... The disconnection recovery process of the fault recovery module is as follows: if the heartbeat timeout determines that the Base service instance is disconnected, the instance is marked and its bound registration group is set to the state of pending migration; if the operation and maintenance policy allows, the registration group to be migrated is handed over to the allocation decision module for reallocation; after the faulty Base service recovers the connection, it is re-included in the candidate set to participate in subsequent allocation.

9. A microservice adaptive load balancing system with a scheduler as its core, as described in claim 1, is characterized in that... The visualization interaction module supports both automatic and manual scheduling modes. The automatic scheduling includes one-click allocation and adaptive rebalancing. The manual scheduling supports manually specifying the Base service, batch cancellation, and batch restart of the registration group. All manual operations are uniformly verified by the scheduling center to check the online status of instances, capacity constraints, and registration group occupancy status.

10. A microservice adaptive load balancing system with a scheduler as its core, as described in claim 1, characterized in that, The scheduling center module also includes a metadata loading module and a mapping publishing module; the metadata loading module loads Base service, registration group, and device metadata from MySQL; the mapping publishing module pushes a complete global allocation mapping view to the audit log and subscription module.

Images