A cross-platform resource scheduling system in a hybrid cloud environment

Abstract

This invention relates to the field of node allocation technology and discloses a cross-platform resource scheduling system in a hybrid cloud environment. The system includes: supply nodes actively broadcasting status beacons containing semantic tags of resource profiles and availability time-domain tags of future availability trends to a shared information bus, and adaptively switching broadcast modes based on the arrival rate of declaration messages; demand units asynchronously complete matching decisions and occupancy declarations locally through intent filters. This invention avoids the inherent latency and cross-platform information barriers of traditional polling scheduling through a decentralized, asynchronous, and autonomous matching method, thereby improving scheduling response speed. Its embedded risk prediction and congestion adjustment mechanisms ensure the reliability of node allocation and the overall stability of the system in a large-scale heterogeneous environment.

Description

Technical Field

[0001] This invention relates to a cross-platform resource scheduling system in a hybrid cloud environment, belonging to the field of node allocation technology. Background Technology

[0002] In current cloud computing practices, in order to meet the stringent real-time requirements of modern applications for resource scheduling, the industry has gradually explored the use of asynchronous communication methods based on the publish-subscribe model in order to replace the decision delay and cross-platform information barriers inherent in traditional centralized polling scheduling. This decentralized asynchronous method, through the active broadcasting of the availability status by resource providers and the subscription and local matching by demanders, theoretically makes it possible to achieve millisecond-level scheduling response, which has become a development direction in this field.

[0003] However, when we examine this decentralized scheduling method in the context of large-scale and highly dynamic hybrid cloud applications, its seemingly efficient appearance conceals deep-seated reliability and stability bottlenecks caused by incomplete information and unrestrained behavior. On the one hand, the state information broadcast by the supply nodes is essentially only a momentary snapshot, which cannot reflect the possible state changes of the nodes due to pre-set maintenance tasks within a very short time window in the future. This may result in the demander receiving a fragile commitment, with the task being assigned to a node that is about to experience performance degradation or interruption, thus causing execution failure. On the other hand, the decentralized free competition mechanism, when faced with a scarce or popular resource node, will inevitably trigger a large number of demand units to initiate occupancy declarations, forming a declaration storm. This disorderly signaling congestion will not only impact the information bus but also cause the target node to fall into an unstable state due to overload.

[0004] Specifically, existing asynchronous scheduling methods have several shortcomings in their progress towards engineering applications: 1. Scheduling decisions lack the ability to predict future availability trends of supply nodes, leading to potential reliability issues in resource allocation; 2. The lack of an adaptive adjustment mechanism for signaling congestion in resource hotspot scenarios results in insufficient overall system stability under extreme conditions. Therefore, the technical problem this invention aims to solve is how to construct a node allocation system that not only leverages the low-latency advantage of asynchronous communication but also integrates a forward-looking assessment of the future stability of supply nodes and inherently possesses the ability to adaptively adjust signaling congestion under high-concurrency competition, thereby improving the reliability of scheduling decisions and the stability of system operation. Summary of the Invention

[0005] This invention provides a cross-platform resource scheduling system in a hybrid cloud environment. Its main purpose is to solve the problems of insufficient resource allocation reliability and poor system stability caused by the lack of prediction of future states and adjustment of signaling congestion in existing asynchronous scheduling methods.

[0006] To achieve the above objectives, this invention provides a cross-platform resource scheduling system in a hybrid cloud environment. The system includes a shared information bus, supply nodes, and demand units.

[0007] The supply node is configured to publish a status beacon message to a public topic on the shared information bus. The status beacon message contains a set of semantic tags describing its resource profile and an availability time domain tag generated based on a preset job schedule table local to the supply node. The availability time domain tag is used to describe the availability status trend of the supply node in a future time window.

[0008] The supply node is also configured to: monitor the arrival rate of resource occupancy declaration messages on a declaration topic, and when the message arrival rate exceeds a congestion threshold associated with the resource type of the supply node, switch to a directed invitation mode, in which the publication of status beacon messages to the public topic is stopped, and status beacon messages are instead sent directly to a demand unit in a demand unit list containing historical successful occupancy records;

[0009] The demand unit is configured to: subscribe to a public topic and filter received status beacon messages locally based on an intent filter containing a desired semantic tag and a desired availability temporal tag to complete the matching with the supply node from which the status beacon message originates locally; and is configured to, after completing the matching, publish a resource occupancy claim message containing the identifier of the target supply node to the claim topic on the shared information bus.

[0010] Preferably, the supply node is configured to generate an availability time-domain label by reading the job plan of an internal task with predetermined attributes that will impact the performance of the supply node recorded in its local system; the availability time-domain label is set as a discrete value to characterize the stability state of the supply node in a future time window due to the execution of the internal task.

[0011] Preferably, the supply node is configured to calculate a congestion index. and compare it with the congestion threshold A comparison is made to determine whether the message arrival rate exceeds the congestion threshold; among which, ,in, In the first predetermined time window The number of resource occupancy declaration messages monitored by the internal supply nodes. It is a rated capacity parameter that characterizes the number of declared messages that a supply node can process per unit time when it is at full load.

[0012] Preferably, the demand unit is further configured to perform the following verification operations after the demand unit has completed matching with the supply node locally and before publishing the resource occupancy declaration message: send a micro-perturbation probe containing a standardized atomic operation request to the matched supply node; and publish the resource occupancy declaration message only if a response from the supply node is received within a second predetermined time and the round-trip time of the response is less than a fulfillment capability threshold associated with the task type of the demand unit.

[0013] Preferably, the supply node is further configured to: subscribe to the public topic while publishing a status beacon message to the public topic; and if it fails to receive the status beacon message published by itself from its subscription to the public topic within a third predetermined time after publishing the status beacon message, the supply node is triggered to perform a fault recovery operation that includes attempting to connect to an alternative shared information bus address.

[0014] Preferably, the supply node is further configured to: continuously listen for all resource occupancy declaration messages on the declaration topic; and when no resource occupancy declaration message for a supply node with the same set of semantic tags as itself is heard within a fourth predetermined time window, trigger the supply node to enter a predetermined low-power energy-saving state.

[0015] Preferably, the system further includes a heat analysis service; when a supply node receives a resource occupancy declaration message but is already in an occupied state, it is configured to: reply to the demand unit that sent the declaration message with a negative confirmation message containing a predetermined reason code for losing the competition; after receiving the negative confirmation message, the demand unit is configured to report the competition failure event information containing the reason code for losing the competition to the heat analysis service.

[0016] Preferably, the heat analysis service is configured to generate and maintain global heat data representing the competitive status of various resources based on the received competition failure event information; the demand unit is further configured to: when performing filtering by the intent filter, obtain the global heat data and preferentially select the supply node with the lower competitive status value in the global heat data for matching.

[0017] Preferably, the semantic tags include one or more tags that characterize the physical resource type, logical performance characteristics, and network environment of the supply node; the intent filter is configured to execute one or more matching rules for the logical AND operation between the semantic tags and the availability time-domain tags.

[0018] Preferably, the shared information bus is implemented based on a message queue protocol that supports publish-subscribe mode; both supply nodes and demand units are configured to encode status beacon messages, resource occupancy declaration messages, and other messages transmitted on the shared information bus into messages in a unified data exchange format.

[0019] Compared with the prior art, the beneficial effects of the present invention are:

[0020] 1. This invention constructs a decentralized node allocation method by having supply nodes actively broadcast status beacon messages containing semantic tags, and demand units asynchronously match and declare them locally based on intent filters. This method reduces the decision latency for resource matching from the second-level or even minute-level latency of network round trips and central processing under the traditional centralized polling method to the message propagation latency that relies solely on the information bus, thereby improving the scheduling response speed. At the same time, information interaction based on unified semantic tags describing resource profiles enables the system to bypass heterogeneous application programming interfaces between different cloud platforms, avoiding complex adapter development and maintenance. Structurally, it avoids information barriers in cross-platform resource scheduling, enhancing the system's versatility and ease of deployment.

[0021] 2. In this invention, when the supply node publishes a status beacon, it further includes an availability time-domain label generated based on its local work plan. The intent filter of the demand unit also matches based on this label. This mechanism expands the scheduling system's ability to perceive resources from focusing only on the current point-like availability status to a linear prediction of the evolution trend of availability status within a future time window. It enables the demand unit to proactively avoid vulnerable resources that are about to experience performance degradation or interruption due to internal maintenance tasks, thereby avoiding potential risks in task execution. This proactive risk consideration in scheduling decisions transforms the result of resource allocation from a one-off opportunity matching to a more reliable and predictable resource allocation, ensuring the continuity of critical business operations.

[0022] 3. This invention provides the ability of supply nodes to monitor the arrival rate of resource occupancy declaration messages and automatically switch from public broadcast to targeted invitation broadcast mode when the rate exceeds the congestion threshold associated with its resource type. This introduces an endogenous, supply-side-derived congestion control mechanism to the entire distributed system. This approach avoids signaling storms caused by a large number of concurrent requests when resource hotspots occur, maintaining the stability of the information bus and the availability of the supply nodes themselves. At the same time, in the targeted invitation mode, by prioritizing the demand units in historical successful occupancy records, the system can allocate limited resources to high-reputation tasks with good historical records in scenarios of extreme resource scarcity. This achieves implicit optimization of service quality in a decentralized architecture and improves the overall operational resilience of the system.

[0023] 4. This invention also constructs multi-dimensional system self-healing and self-optimization capabilities through a series of collaborative mechanisms. For example, by having demand units issue micro-perturbation probes and verify their response times before occupying resources, the immediate fulfillment capability of allocated nodes is ensured, avoiding soft failures caused by the discrepancy between nominal and actual performance. Furthermore, by having supply nodes subscribe to the echoes of their own state beacons, low-overhead self-diagnosis and timely fault recovery of isolated network partitions are achieved, ensuring the integrity and accessibility of the resource pool. Finally, by having supply nodes bypass and listen to global occupancy declarations, the demand for similar resources is perceived in reverse, and energy-saving states are autonomously entered during periods of low demand, achieving distributed and bottom-up energy efficiency management. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the architecture of a cross-platform resource scheduling system in a hybrid cloud environment according to the present invention;

[0025] Figure 2 This is a schematic diagram of the mathematical model for the decay of heat value over time in the heat analysis service of this invention;

[0026] Figure 3 This is a schematic diagram of the core interaction process of a cross-platform resource scheduling system in a hybrid cloud environment according to the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. It should be noted that the specific embodiments described below are intended to explain this invention and are not intended to limit the scope of protection of this invention.

[0028] The cross-platform resource scheduling system in a hybrid cloud environment provided by this invention consists of three logically independent supply nodes, demand units, and a shared information bus serving as the asynchronous communication medium between them. The inter-node communication and resource allocation within the system follow an asynchronous interaction procedure based on a publish-subscribe model, replacing the traditional synchronous polling and centralized decision-making architecture. Specifically, supply nodes broadcast their resource status, while demand units subscribe and match locally, and complete resource allocation through an independent declaration mechanism upon successful matching. In a specific application scenario, such as an AI training platform that needs to uniformly schedule heterogeneous computing nodes distributed across different cloud service providers, the objective challenge lies in the incompatibility of API systems and data models across platforms, and the fact that training tasks have specific requirements regarding the availability and real-time performance of certain resources, such as specific GPU models. Stringent requirements; to address this challenge, the supply nodes in this system, i.e., any compute node with allocable resources, are configured to periodically publish status beacons to a public topic on the shared information bus, such as / beacon / resource / available. Each status beacon is a message encoded in a unified data exchange format, such as JSON, with its core payload being a set of semantic tags describing the node's resource profile. These tags can characterize one or more attributes, such as the node's physical resource type (e.g., type: GPU), logical performance characteristics (e.g., profile: High-IO, CUDA-v12), and its network environment. In this way, nodes from different sources can describe their own status using a unified information format, thus achieving cross-platform resource information exchange without relying on complex adapters.

[0029] Considering that the availability of cloud nodes is not only immediate but also affected by scheduled maintenance tasks, supply nodes are configured to read job schedules recorded in their local systems, such as cron in Linux or CronJob in Kubernetes, when building status beacons. This allows them to detect whether there are any high-priority internal tasks that will impact node performance within a predetermined time window, such as the next five minutes. Based on the detection results, an availability time-domain label is generated. This label is a discrete value, such as Stable or Degrading_Soon, representing the stability trend of the node within the future time window. Correspondingly, demand units, i.e., tasks or their agents, after subscribing to a public topic, filter the received status beacon messages locally according to an intent filter containing the desired semantic label and the desired availability time-domain label. This intent filter is configured to execute one or more matching rules based on the logical AND operation of the label. For example, for a task with high stability requirements, its... The filter can be set to require the condition `availability_horizon:Stable` to be met. This allows scheduling decisions to take into account the future stability of nodes, thereby improving the reliability of allocated resources. After a demand unit completes its local matching with a supply node, to avoid potential problems caused by the node's transient state, such as the noisy neighbor effect, leading to discrepancies between nominal and actual performance, the demand unit is further configured to perform a fulfillment capability verification operation before issuing an occupancy declaration. Specifically, the demand unit sends a micro-perturbation probe containing a standardized atomic operation request to the matched supply node. For example, for a node labeled High-IO, the probe can request it to write a 4KB standardized data block. The demand unit then measures the round-trip time of this operation locally and only continues to execute subsequent steps if the round-trip time is less than a fulfillment capability threshold associated with the demand unit's own task type. This verification step provides empirical evidence for the scheduling decision regarding the node's immediate fulfillment capability.

[0030] Once the fulfillment capability verification passes, the demand unit publishes a resource occupancy claim message containing the target supply node's identifier to a dedicated claim topic on the shared information bus, such as / beacon / resource / claim. All supply nodes are also configured to subscribe to this claim topic. When a supply node receives a claim message for itself, it updates its status to occupied and stops broadcasting its availability beacon. However, when facing a scarce resource node, concurrent claims from multiple demand units can create a signaling storm, impacting the information bus and the target node. Therefore, supply nodes are configured to monitor the arrival rate of resource occupancy claim messages on the claim topic and determine congestion status through a defined procedure. Specifically, supply nodes calculate a congestion index. and compare it with a congestion threshold. In comparison, among which, The calculation formula was determined as follows: Here, In the first predetermined time window The number of resource usage declaration messages monitored by the supply node for itself. This is a rated capacity parameter characterizing the number of declared messages that the supply node can process per unit time. The value is set between, for example, 0.8 and 0.95, depending on the service level; when At this time, the supply node switches from public broadcast mode to targeted invitation mode. In this mode, it stops publishing status beacons to the public topic and instead selects one or more demand units from a list of demand units containing historical successful occupancy records, and sends status beacon messages directly to them. Through this mode switch, the supply node achieves source flow control of declaration messages, thereby maintaining the stability of the system in high-concurrency scenarios. In a specific embodiment, the supply node controls the congestion index. The calculation depends on the rated capacity parameters. With the first scheduled time window All are generated by a set of deterministic procedures, in which the rated capacity parameters A standardized offline stress testing procedure was established, which involves sending standard resource occupancy declaration messages containing 32-byte random identifiers to target provisioning nodes at a rate of 10 requests per second within an isolated test network, while monitoring the 99th percentile of their processing time. ,when When the request rate exceeds twice the node's baseline processing time of 10 requests per second under low load for the first two consecutive times, that moment is recorded as the maximum effective rate. And take 80% of it as the final value. Numerical values; in parallel, the first predetermined time window The value of is determined by the average network round-trip time calculated by the supply node after performing 100 ICMP probes to its configured heat analysis service address during initialization. The decision was made, and the specific settings were as follows: The larger of the two, 200 milliseconds.

[0031] To further enhance system resilience, the system integrates a series of collaborative mechanisms. Firstly, to address information silos caused by network partitioning, supply nodes, while publishing status beacons to a public topic, are also configured to subscribe to that topic. If, within a very short, predetermined third time window after publishing the message, they fail to receive the message from their own subscription, a fault recovery operation is triggered locally. This operation includes attempting to connect to a pre-defined backup shared information bus address in the configuration file. Secondly, for energy efficiency management, supply nodes are configured to continuously monitor all resource occupancy declaration messages on the declared topic and locally analyze the occupancy frequency of similar nodes with the same key semantic tags. When no occupancy events for similar nodes are detected within a fourth predetermined time window, the supply node determines that the current demand for that type of resource is at a low point and autonomously triggers entry into a predetermined low-power energy-saving state. Furthermore, to utilize the scheduling process… The system includes a heat analysis service to optimize subsequent decisions by providing failure event information. When a supply node receives a resource occupancy declaration message but is already in an occupied state, it is configured to reply to the demand unit that sent the declaration message with a negative acknowledgment message containing a predetermined failure reason code such as Already_Claimed. After receiving the message, the demand unit reports the failure event information containing the failure reason code to the heat analysis service. Based on the received failure event information, the service generates and maintains global heat data representing the competition status of various resources. This heat data is then periodically broadcast to all demand units. When executing their intent filters, demand units use this global heat data as a reference and prioritize matching with supply nodes that have lower competition status values ​​in the heat data among multiple matching supply nodes. This routing method directs business requests to nodes with less competition, thereby forming a balanced load distribution across the system.

[0032] Example 1: In a scenario where a large streaming media service platform is handling the global simultaneous premiere of a series, the platform needs to allocate nodes with low latency to handle massive, instantaneous concurrent user access requests in a hybrid cloud environment. The objective challenge of this scenario is that within the first few minutes of the premiere, the effective demand for GPU nodes with specific encoding / decoding acceleration capabilities will surge instantaneously. Traditional scheduling methods struggle to simultaneously meet the requirements of low latency allocation and reliable decision-making under such a large scale of concurrent requests, easily leading to user connection failures due to decision-making bottlenecks or information delays. When the premiere event is triggered, the system deployed on the platform, following the above scheme, begins operation. A massive number of clients representing user sessions act as demand units, subscribing to public topics on the shared information bus. Meanwhile, the globally distributed supply nodes, i.e., various GPU servers, continuously supply data to the platform. The topic releases a status beacon containing semantic tags and availability time-domain tags. At this time, the intent filter of a demand unit located in the European region simultaneously matches two supply nodes that match their GPU tags. Node A has lower network latency, but its availability time-domain tag in its status beacon is Degrading_Soon. This tag is generated by the node based on a scheduled snapshot task that it is about to execute locally. Node B has slightly higher network latency, but its availability time-domain tag is Stable. The demand unit's intent filter is configured to prioritize nodes with the Stable tag, so it automatically ignores node A and initiates a takeover process for node B. This decision-making process avoids a foreseeable service interruption caused by internal node maintenance by integrating two types of information: the current performance of the node and its future state trend.

[0033] Furthermore, when a new high-performance GPU cluster goes live, its state beacons containing scarce semantic tags are instantly matched by the intent filters of a large number of demand units. These demand units almost simultaneously publish resource occupancy declaration messages to the declaration topic, resulting in a high-intensity message concurrency. Under this condition, each supply node in the cluster locally monitors a sharp increase in the arrival rate of its received declaration messages, leading to a surge in its congestion index. The congestion threshold was quickly exceeded. In response, these supply nodes automatically switched from public broadcast mode to targeted invitation mode, immediately ceasing the publication of status beacons to public topics. This intercepted the declaration messages for the cluster at the source, and the load on the information bus quickly decreased. Subsequently, these nodes selected a subset of demand units from their historical successful occupancy records and sent status beacons directly to them, transforming global disordered competition into local ordered allocation. This mechanism, while maintaining the low-latency characteristics of local matching of demand units, suppressed the disordered concurrency of declaration messages through the autonomous behavior of supply nodes, thus balancing the response speed of resource allocation and the operational stability under high load at the system level. During the initial broadcast, node allocation continued without intervention from a central decision-making unit. User access requests were smoothly guided to supply nodes distributed globally that met their service quality requirements and were in a stable state in the present and for some time to come. The system's operation did not focus on improving the processing capacity of a single decision point, but rather on building an information interaction and matching market in which each node autonomously participates, enabling resource scheduling to be completed in a distributed and collaborative manner.

[0034] Example 2: To objectively evaluate the performance and stability of the technical solution of this invention in handling large-scale concurrent scheduling requests, this comparative experiment was conducted. The purpose of the experiment was to quantitatively evaluate the performance of the solution of this invention compared with traditional centralized scheduling schemes and basic asynchronous scheduling schemes in terms of scheduling latency, success rate, and system bus load, especially the performance difference under simulated resource hotspot conditions. The experiment was conducted in a simulated hybrid cloud environment based on Kubernetes, containing 500 heterogeneous virtual nodes. The node types included general-purpose CPU nodes and GPU computing nodes. All communication between nodes was published through a Redis deployed within the cluster. The subscription service is implemented as a shared information bus. To simulate high-concurrency scenarios, a 300-second lightning congestion test load was designed. After the test began, the number of new demand units per second increased exponentially, peaking at the 60th second and remaining thereafter. All demand units were configured to prioritize requesting a hot resource pool consisting of 10 specific high-performance GPU nodes. Three control groups were set up: Group A used a centralized round-robin scheduler with a polling period of 2 seconds; Group B used a basic publish-subscribe scheduling method without congestion control mechanisms; and Group C used the complete technical solution of this invention, where the congestion threshold of the supply nodes was... The setting is intended to balance response sensitivity and system stability; the value of this parameter is related to the node's rated capacity parameter. Related, that is Set as A safety percentage is set to trigger a protection mechanism before a node reaches its processing capacity limit. In this experiment, for GPU nodes in the hot resource pool, its safety percentage is calibrated through offline stress testing. To process 150 declaration messages per second, and accordingly... The value was set to 0.8; after the experiment started, the key performance indicators of each group were continuously monitored, and the typical data under different concurrent request scales are shown in Table 1.

[0035] Table 1: Performance comparison of scheduling schemes under different concurrent request scales.

[0036]

[0037] Analysis of the data in Table 1 shows that, under low concurrency, the asynchronous methods of groups B and C are superior to the polling method of group A in terms of scheduling latency. When the concurrency scale increases to 2000, the bottleneck effect of the centralized scheduler in group A becomes apparent, with a sharp increase in latency and a decrease in success rate. Although group B has lower latency, the peak load of its declared topics surges, showing signs of message congestion, and its success rate also begins to decline. In contrast, group C maintains a low average scheduling latency and a high success rate, with its peak load of declared topics suppressed to a level lower than that of group B. When the concurrency scale reaches 8000, the scheduling success rate of group B drops sharply due to overload of declared topics, while the core indicators of group C remain stable. Its peak load is close to that at 2000 concurrency and does not increase linearly with the number of requests. The reason for this phenomenon is that the hot resource pool supply nodes in group C's scheme have local congestion indices. Exceeding the set congestion threshold Subsequently, it automatically switched from public broadcast mode to targeted invitation mode, stopping the external status beacon broadcast, thereby suppressing message concurrency at the signaling source and maintaining the stability of the information bus and the node itself.

[0038] Example 3: This example combines Figures 1 to 3 This document describes the implementation of a cross-platform resource scheduling system in a hybrid cloud environment, such as... Figure 1 As shown, the system mainly consists of a supply node cluster, a demand unit cluster, a shared information bus, and a heat analysis service. Supply nodes 1 to N in the supply node cluster all contain semantic tags and time-domain tags and have congestion monitoring capabilities. They publish status beacons to common topics in the shared information bus and also have the ability to connect to a backup shared information bus when a fault recovery mechanism is triggered. Demand units 1 to N in the demand unit cluster contain intent filters and micro-perturbation probes. They receive status beacons by subscribing to common topics and publish occupancy claims to the claim topics in the shared information bus after matching. Supply nodes also listen to these claim topics to confirm resource occupancy. Furthermore, when a demand unit experiences a competition failure event, it reports the event to the heat analysis service. This service generates global heat data and then broadcasts the data to all demand units to assist in their subsequent decision-making.

[0039] like Figure 2 As shown, this graph represents the heat value over the time interval following the occurrence of the losing event. The graph shows the changing curves at three different decay constants. Under the given value, the heat value decreases from the initial value of 10. The curve with a value of 0.2 (fast decay) decreases the most rapidly. The curve with a value of 0.1 (moderate attenuation) is next, while... The curve with a value of 0.05 (slow decay) is the flattest. This mechanism makes recent resource competition events have a higher weight in the global heat data than long-term events, thus enabling the data to more accurately reflect the real-time changes in the resource competition situation.

[0040] like Figure 3 The process involves supply nodes broadcasting status beacons containing resource profiles and availability trends to the shared information bus, which serves as an asynchronous communication medium. Demand units then asynchronously make matching decisions locally through intent filters and, upon successful decision-making, publish resource occupancy declarations to the shared information bus. Supply nodes receive these declarations and lock the resources. This process includes two key adaptive adjustment and optimization loops: a congestion adaptive adjustment loop where supply nodes monitor the declaration rate and switch from public broadcast to targeted invitation mode when it exceeds a threshold; and a heat analysis-based optimization loop where, upon receiving confirmation of a failed bid, a demand unit reports the event to a heat analysis service. This service aggregates events to generate global resource heat data, providing an optimization basis for future matching decisions by the demand unit.

[0041] Example 4: In a high-frequency trading computing cluster with service quality requirements, the operation and parameter configuration of the deployed supply nodes follow the following procedures to ensure the predictability and reliability of their node allocation behavior. For the demand units in the cluster used to execute latency-sensitive trading strategies, the performance capability threshold included in their intent filters is set by decomposing an offline benchmark calibration and an online task type association step. Before the supply node is deployed, 1000 standardized micro-perturbation probes are continuously sent to the node in an isolated network load-controlled environment, and the round-trip time of all responses is recorded. After removing the highest and lowest 5% of samples, the average value of the remaining samples is calculated, and this average value is used as the benchmark probe response time of the node. Given the latency sensitivity of trading tasks, their performance capability threshold is determined to be 1.5 times the benchmark probe response time. For other non-trading core log analysis tasks in the cluster, their performance capability threshold is set to 3.0 times the benchmark. This procedure quantitatively correlates the threshold setting with the inherent hardware performance of the node and the business attributes of the task.

[0042] To address network partitioning caused by switch failures or routing misconfigurations, each provisioning node is configured with a connection state machine comprising three states: primary, isolated, and standby, to perform fault recovery operations. During normal operation, the node is in the primary state, communicating via the primary shared information bus address and subscribing to its published state beacons to listen for beacon echoes. If no beacon echo is received within three consecutive publication cycles, the state machine switches from the primary to the isolated state. In the isolated state, the node stops all service communication and immediately attempts to establish a connection via a standby shared information bus address pre-installed in its startup configuration file. If the connection is successful, the state machine switches to the standby state and resumes its state beacon publication using the standby bus. To avoid frequent switching between primary and standby lines, a node in the standby state sends a lightweight connectivity probe request to the primary bus address at a low frequency. Only after three consecutive successful probe responses will the state machine switch back from the standby state to the primary state. This state machine provides deterministic self-healing logic for the node's network connectivity.

[0043] In this financial transaction scenario, when a supply node becomes a resource hotspot due to its scarce hardware characteristics and its congestion index... Exceeding the congestion threshold When switching to targeted invitation mode, the procedure for selecting invitation targets is as follows: The supply node maintains a local list of historical successful occupancy records with a fixed size of 100, using the demand unit identifier as the key. Each entry in this list, in addition to recording the demand unit identifier, also contains a recent successful occupancy timestamp and a cumulative successful occupancy count counter. When targeted invitations are required, the supply node uses a weighted scoring function. Dynamically sort all items in the list, where For the current time, The most recently successfully occupied timestamp. To accumulate the number of successful attempts, It is a time difference An increasing decreasing function, and To pre-determine weights, nodes select several demand units with the highest scores to send invitations. This procedure prioritizes demand units with frequent and successful recent interactions when resource competition is intense. After a supply node switches to targeted invitation mode, it dynamically sorts its list of historical successful occupancy records based on a scoring function as follows. The resulting scores will be used for... The recent preference coefficient in this function It is a dimensionless floating-point number, a timescale constant, defined by the governance service in the global tag registry for each type of task. The time limit is set to 3600 seconds, which is uniformly set at the system level. After the demand unit is selected by the sorting mechanism and receives the targeted invitation message, the micro-disturbance probe it sends to perform the performance capability verification is not a public endpoint, but a one-time, time-limited security tokenized address that is dynamically generated and included by the supply node in the targeted invitation message. This address expires immediately after being used once or after a preset second predetermined time.

[0044] Example 5: In a continuously operating environment where the system of this invention has been deployed, to ensure the timeliness of the global heat data generated by the heat analysis service, the service follows a weighted calculation procedure based on time decay when aggregating and processing the information of lost competition events reported by the demand units. The service maintains a floating-point heat value in memory for each monitored resource entity. This heat value is not a simple count and accumulation of lost competition events, but rather dynamically decays over time. When the service receives a new lost competition event for a certain resource entity, its corresponding heat value... According to the formula To be updated, among which, This represents the popularity value of the entity at the time of the last update. The updated popularity value This refers to the time interval between this update and the last update. As a preset decay constant, the value of which is related to the average lifecycle of the business within the system, this procedure makes the weight of recent resource competition events in the global heat data higher than that of long-term events, so that the data can reflect the real-time changes in the resource competition situation.

[0045] To ensure that the availability time-domain labels published by supply nodes accurately reflect the stability of their future states, an initialization configuration procedure for a local event detection module must be executed before any new supply node is connected to the scheduling system. This procedure requires the system administrator to create an internal task impact level mapping table locally, based on the node's hardware characteristics and the expected operational strategy. This mapping table is a lookup table containing two columns: task name keywords and impact level. The task name keywords are preset strings extracted from the names of periodic tasks within the operating system to characterize the task's nature. The mapping table also includes pre-defined security patches. The keyword entries for snapshot-backup and kernel-reboot are divided into three discrete levels of impact: high, medium, and low. When the event detection module of the supply node periodically reads the local job plan table, it extracts the names of all tasks to be executed within a future time window and matches them with keywords in the mapping table to determine the impact level of each task. Finally, the availability time domain label published by the node is uniquely determined by the highest impact level among all tasks within that time window. This configuration procedure directly associates the generation logic of the availability time domain label with the clearly definable operation and maintenance events on the node.

[0046] Example 6: In a large-scale, long-running hybrid cloud scheduling system, to ensure the consistency of its semantic tagging system and the effectiveness of key control parameters, the system follows a standardized calibration and verification procedure executed by a centralized governance service during deployment and operation. This governance service first defines and maintains a versioned semantic tagging registry. This registry stores all permitted tags and their allowed value ranges in a hierarchical structure. When any supply node or demand unit first accesses the system, its client must obtain the current version of the tagging registry from the governance service as a local cache. Furthermore, before publishing a status beacon containing semantic tags, the supply node will self-verify the compliance of the tags based on the locally cached registry. Messages containing unregistered or incorrectly formatted tags will be rejected by the node itself. This procedure avoids node allocation failures due to tag misuse.

[0047] Furthermore, the governance service is configured to continuously analyze historical competition failure information aggregated by the heat analysis service and the micro-disturbance probe response logs of all nodes to dynamically optimize two key time parameters within the system. First, for the fourth predetermined time window when the supply node enters a low-power energy-saving state, the governance service statistically analyzes the arrival time interval of the declaration message according to different resource types and calculates the 95th percentile time interval during off-peak hours. Subsequently, the fourth scheduled time window for this resource type was set as The governance service then distributes updates to all corresponding supply nodes; secondly, for the second predetermined time (response timeout) of the micro-perturbation probe execution for the demand unit, the governance service calculates the 99th percentile of the round-trip time of all successful probe responses in the entire network environment. And set the second scheduled time as This value is also distributed to all demand units. Through this statistical and feedback adjustment based on global operational data, the system's control parameters can adapt to the actual load and network conditions.

[0048] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0049] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A cross-platform resource scheduling system in a hybrid cloud environment, characterized in that, The system includes a shared information bus, supply nodes, and demand units: The supply node is configured to publish a status beacon message to a public topic on the shared information bus. The status beacon message contains a set of semantic tags describing its resource profile and an availability time domain tag generated based on a preset job schedule table local to the supply node. The availability time domain tag is used to describe the availability status trend of the supply node in a future time window. The supply node is also configured to: monitor the arrival rate of resource occupancy declaration messages on a declaration topic, and when the message arrival rate exceeds a congestion threshold associated with the resource type of the supply node, switch to a directed invitation mode, in which the publication of status beacon messages to the public topic is stopped, and status beacon messages are instead sent directly to a demand unit in a demand unit list containing historical successful occupancy records; The demand unit is configured to: subscribe to a public topic and filter received status beacon messages locally based on an intent filter containing a desired semantic tag and a desired availability temporal tag to complete the matching with the supply node from which the status beacon message originates locally; and is configured to, after completing the matching, publish a resource occupancy claim message containing the identifier of the target supply node to the claim topic on the shared information bus.

2. The cross-platform resource scheduling system in a hybrid cloud environment according to claim 1, characterized in that, The supply node is configured to generate an availability time-domain label by reading the job plan of an internal task with predetermined attributes that will impact the performance of the supply node, which is recorded in its local system; the availability time-domain label is set as a discrete value to characterize the stability state of the supply node in a future time window due to the execution of the internal task.

3. The cross-platform resource scheduling system in a hybrid cloud environment according to claim 1, characterized in that, The supply node is configured to calculate a congestion index. and compare it with the congestion threshold A comparison is made to determine whether the message arrival rate exceeds the congestion threshold; among which, ,in, In the first predetermined time window The number of resource occupancy declaration messages monitored by the internal supply nodes. It is a rated capacity parameter that characterizes the number of declared messages that a supply node can process per unit time when it is at full load.

4. The cross-platform resource scheduling system in a hybrid cloud environment according to claim 1, characterized in that, The demand unit is further configured to perform the following verification operations after the demand unit has completed matching with the supply node locally and before publishing the resource occupancy declaration message: send a micro-perturbation probe containing a standardized atomic operation request to the matched supply node; and publish the resource occupancy declaration message only if a response from the supply node is received within a second predetermined time and the round-trip time of the response is less than a fulfillment capability threshold associated with the task type of the demand unit.

5. A cross-platform resource scheduling system in a hybrid cloud environment according to claim 1, characterized in that, The supply node is further configured to: subscribe to the public topic while publishing a status beacon message to the public topic; and if it fails to receive the status beacon message published by itself from its subscription to the public topic within a third predetermined time after publishing the status beacon message, the supply node is triggered to perform a fault recovery operation that includes attempting to connect to an alternative shared information bus address.

6. A cross-platform resource scheduling system in a hybrid cloud environment according to claim 1, characterized in that, The supply node is further configured to: continuously listen for all resource occupancy declaration messages on the declaration topic; and when no resource occupancy declaration message is heard for a supply node that has the same set of semantic tags as itself within a fourth predetermined time window, the supply node is triggered to enter a predetermined low-power energy-saving state.

7. A cross-platform resource scheduling system in a hybrid cloud environment according to claim 1, characterized in that, The system further includes a heat analysis service; when a supply node receives a resource occupancy declaration message but is already in an occupied state, it is configured to reply to the demand unit that sent the declaration message with a negative confirmation message containing a predetermined reason code for losing the competition; after receiving the negative confirmation message, the demand unit is configured to report the competition failure event information containing the reason code for losing the competition to the heat analysis service.

8. A cross-platform resource scheduling system in a hybrid cloud environment according to claim 7, characterized in that, The heat analysis service is configured to generate and maintain global heat data representing the competitive status of various resources based on the received information on lost competition events; the demand unit is further configured to: when performing filtering by the intent filter, obtain the global heat data and prioritize matching with the supply nodes with lower competitive status values ​​in the global heat data.

9. A cross-platform resource scheduling system in a hybrid cloud environment according to claim 1, characterized in that, Semantic labels include one or more labels that characterize the physical resource type, logical performance characteristics, and network environment of the supply node; intent filters are configured to perform one or more matching rules for logical AND operations between semantic labels and availability time-domain labels.

10. A cross-platform resource scheduling system in a hybrid cloud environment according to claim 1, characterized in that, The shared information bus is implemented based on a message queue protocol that supports publish-subscribe mode; both supply nodes and demand units are configured to encode status beacon messages, resource occupancy declaration messages, and other messages transmitted on the shared information bus into messages in a unified data exchange format.

Images