A micro-service resource dynamic scheduling method and device

Abstract

The application discloses a micro-service resource dynamic scheduling method and device, the method comprises the following steps: constructing a real-time calling topology graph and collecting runtime data; using an unsupervised learning model to encode the calling subgraph of a business execution instance into a paradigm fingerprint vector; comparing the real-time paradigm fingerprint vector with a known paradigm fingerprint library to perform unsupervised identification of unknown events; when a new paradigm is identified, generating a resource portrait thereof and incrementally updating the paradigm knowledge base; and based on the identified paradigm and resource portrait thereof, performing predictive collaborative resource scheduling. The application identifies unknown events through unsupervised learning, incrementally learns to adapt to new businesses, realizes rapid response to emergencies and online self-adaptation to business iteration, and reduces business delay and improves system reliability through predictive scheduling.

Description

Technical Field

[0001] This application relates to the field of computer program control devices and resource management technology, specifically to a method and device for dynamic scheduling of microservice resources. Background Technology

[0002] Modern complex software systems, especially high-frequency trading systems in finance, widely adopt microservice architecture. In this architecture, business functions are decomposed into a series of independent services that collaborate through lightweight communication mechanisms such as application programming interfaces (APIs). To cope with dynamic changes in business load, a resource scheduling system is typically needed to automatically adjust the computing resources, such as central processing unit (CPU) and memory resources, used by each microservice instance.

[0003] In specific application scenarios such as high-frequency trading in finance, where there are extremely high requirements for system response latency and uncertainty handling capabilities, server clusters are typically deployed within the exchange's data center to reduce network latency. However, traditional microservice resource scheduling methods face inherent technical bottlenecks in such scenarios, mainly manifested in the following two technical issues:

[0004] First, there's the issue of real-time identification of unknown event patterns. Financial markets operate with a high degree of uncertainty. Specific market conditions, such as sudden major news events, can trigger cascading market reactions (sometimes called "black swan" events), generating entirely new, instantaneous traffic patterns and microservice call chains within the server cluster. The topology and propagation characteristics of these new patterns have not appeared in the system's historical operational data, constituting unknown patterns. Therefore, any predictive model that relies on supervised learning training based on historical data samples, such as methods for predicting resource usage based on time series data, will fail when unknown events occur due to the lack of precedents to learn from, failing to respond promptly and potentially leading to missed trading opportunities or incurring risks.

[0005] Second, there's the issue of online adaptation in scheduling models. To maintain market competitiveness, financial institutions frequently update their business strategies and deploy them to server clusters in production environments. Each new strategy typically corresponds to a new set of microservices or introduces entirely new combinations of call logic for existing microservices, leading to new resource consumption characteristics. For scheduling systems, completely retraining the scheduling model offline for each newly deployed strategy would be extremely time-consuming and computationally expensive, potentially causing service interruptions or performance degradation—unacceptable in the financial sector where business continuity is paramount. Therefore, existing scheduling methods lack the ability to quickly and automatically integrate the behavioral patterns of new business logic into the existing scheduling model without interrupting service. Summary of the Invention

[0006] To achieve the above objectives, one aspect of this application provides a dynamic scheduling method for microservice resources, which integrates unsupervised learning and incremental learning, and is applied to a microservice system deployed in a server cluster. The method includes the following steps:

[0007] Step 1: Construct a real-time call topology graph and collect multi-dimensional runtime data. This step captures the dynamic behavior of the microservice system in real-time and non-intrusively, transforming it into structured graph data. Specifically, a distributed tracing agent is deployed at the infrastructure layer of the server cluster. This agent leverages kernel-level monitoring technologies such as Extended Berkeley Packet Filter (eBPF) to capture network communication metadata between all microservice instances in real time. The collected metadata includes at least the unique identifier of the source service, the unique identifier of the target service, the request initiation timestamp, the response completion timestamp, the request payload size, the response payload size, the method name of the Remote Procedure Call (RPC), and a globally unique tracing ID. Based on the collected metadata, a Real-time Call Topology Graph (RCTG) is dynamically constructed and maintained in memory. This graph is a weighted directed graph G=(V, E, W), where each node v_i in the node set V represents a microservice instance; each edge e_ij in the directed edge set E represents an API call from the source service instance v_i to the target service instance v_j; and the weight set W corresponds one-to-one with the edges. The weight w_ij of each edge is a multi-dimensional vector containing detailed runtime attributes of the call, such as quantitative metrics like call latency and network throughput.

[0008] Optionally, to comprehensively characterize the runtime state of nodes, this step also synchronously collects internal performance metrics for each microservice instance, such as CPU utilization, memory usage, disk I / O rate, and network I / O rate. This node attribute data, along with the graph topology data, will be used in subsequent steps.

[0009] Step two involves extracting business execution instances and encoding them to generate paradigm fingerprint vectors. This step uses unsupervised learning to encode the "business execution instances" in the real-time call topology graph to generate paradigm fingerprint vectors that represent their respective "business execution paradigms." Specifically, the system slices the real-time call topology graph at fixed time windows, obtaining a series of graph snapshots. For each snapshot, the system uses a tracking ID to identify a complete call subgraph with business causality triggered by the initial external request; this subgraph is considered a "business execution instance." Then, the subgraph structure of these business execution instances, along with the multi-dimensional attribute data of their nodes and edges, is input into a graph autoencoder model. The encoder part of this autoencoder aggregates neighbor node information to compress the structure and attribute information of the entire subgraph into a fixed-dimensional low-dimensional dense vector, which is the paradigm fingerprint vector (PFV) of the business execution instance.

[0010] This application constructs the real-time service call relationship as a topology graph and uses the graph autoencoder, an unsupervised learning model, to compress and encode the complex call subgraph representing specific business logic into a low-dimensional "paradigm fingerprint vector". Through subsequent vector comparison, it achieves rapid and unprecedented identification of unknown event patterns.

[0011] The graph autoencoder is an unsupervised neural network model whose basic structure includes an encoder and a decoder. The encoder is responsible for mapping the input graph structure data to a low-dimensional latent vector space, while the decoder attempts to reconstruct the original graph structure from this low-dimensional vector. By training the model to minimize the difference between the input graph and the reconstructed graph, the encoder is optimized to learn a compact vector representation that can effectively capture the core structure and attribute features of the graph data, i.e., the paradigm fingerprint vector referred to in this application.

[0012] Furthermore, to more accurately characterize the dynamic characteristics of business execution paradigms, the aforementioned graph autoencoder model can employ a Temporal Graph Network (TGN) model. Unlike Graph Convolutional Networks (GCNs) or Graph Attention Networks (GATs) that only process static graph structures, the TGN model can capture and encode dynamic temporal information such as the timestamps of call events, durations, and call sequence relationships through its built-in memory modules. The paradigm fingerprint vector generated by this model is a "spatiotemporal paradigm fingerprint" that can simultaneously represent business topology and temporal behavior. It has higher information density and discriminative power, and can more accurately distinguish business patterns with similar topologies but different execution rhythms, thereby improving the accuracy of subsequent identification and scheduling.

[0013] Step 3: Unsupervised identification of unknown events based on paradigm fingerprint vectors. This step identifies previously unseen unknown event patterns appearing in the system in real time. The system maintains a "known paradigm fingerprint database," which stores the paradigm fingerprint vectors of all common business patterns learned during normal system operation. When a new business execution instance occurs, the system generates a real-time paradigm fingerprint vector for it using the model from Step 2 and calculates the distance between this real-time fingerprint vector and all vectors in the "known paradigm fingerprint database." Preferably, this distance metric uses cosine distance or Euclidean distance, and a preset distance threshold δ is used. If the minimum distance between the real-time fingerprint vector and all known fingerprint vectors in the database is greater than the threshold, the system determines that the business execution instance is an "unknown event pattern," triggers an alarm, and persistently stores the call subgraph constituting the unknown pattern, related node performance indicators, and the anomaly's paradigm fingerprint vector.

[0014] Step four involves incrementally updating the paradigm knowledge base and generating a resource requirement profile. This step enables online adaptation to handle unknown events or newly deployed business strategies. This step is triggered when an unknown event pattern is identified, or when a call pattern marked "new business launch" appears for the first time. Specifically, this step includes: First, performing new paradigm characterization, which involves extracting the complete call subgraph topology corresponding to the new pattern and statistically recording the peak, mean, and P99 quantile (i.e., 99% of the data are less than this value) of various performance indicators for all microservice instances within it during execution. These statistical data collectively constitute the "resource requirement profile" of the new paradigm. Next, performing incremental updates to the knowledge base, which involves treating the "paradigm fingerprint vector," "topology structure," and "resource requirement profile" of the new paradigm as a whole, encapsulating them into a new "paradigm knowledge entry," and storing it in the global "dynamic paradigm knowledge base." The "known paradigm fingerprint database" is used to achieve rapid vector retrieval and comparison. It can exist as a dedicated index of the dynamic paradigm knowledge base, or as an independent vector database (such as FAISS or Milvus) that keeps data synchronized with the dynamic paradigm knowledge base. Finally, incremental learning of the recognition model is performed, that is, the paradigm fingerprint vector of the new paradigm is used as a new category sample to update the "known paradigm fingerprint database" in step three online, so that the system can quickly recognize this new pattern in the future.

[0015] The contribution of this application also lies in the design of an incremental update mechanism for the paradigm knowledge base. Upon identifying a new business paradigm, the system encapsulates its fingerprint vector, topology, and resource requirement profile into paradigm knowledge entries, and uses an incremental learning algorithm to update the identification model online. This enables the scheduling system to quickly adapt to new businesses without interrupting service or requiring batch retraining.

[0016] Optionally, the incremental learning process of the above recognition model employs classification or clustering algorithms that support online learning, such as incremental support vector machines (SVM) or adaptive nearest neighbor indexes, thereby avoiding costly batch retraining.

[0017] Step 5: Perform predictive resource scheduling based on paradigm awareness. This step utilizes information from a dynamic paradigm knowledge base to perform proactive and predictive collaborative scheduling. The scheduling logic is divided into two scenarios. The first scenario is predictive scheduling for known paradigms. When an incoming request successfully matches the fingerprint of its initial subgraph formed at the beginning of its call chain with a known paradigm, the system immediately determines that the paradigm is about to be fully executed. The scheduler then retrieves the complete topology and resource requirement profile corresponding to the paradigm from the knowledge base, and proactively and in parallel pre-allocates resources or pre-expands instances according to their resource profiles for all downstream microservice instances expected to be called in the paradigm's call chain. The second scenario is contingency scheduling for unknown paradigms. When a pattern is identified as an "unknown event," the scheduler immediately initiates an emergency resource allocation strategy to ensure system stability. Preferably, this strategy is a graph diffusion-based "influence radius" strategy, that is, temporarily configuring resource redundancy for the initial node of the unknown pattern subgraph and its adjacent downstream nodes to prevent the performance impact from spreading rapidly.

[0018] Accordingly, another aspect of this application provides a microservice resource dynamic scheduling device, which includes: a data acquisition module for constructing a real-time call topology graph and acquiring multi-dimensional runtime data; a paradigm encoding module for extracting business execution instances and encoding them to generate paradigm fingerprint vectors; an event recognition module for performing unsupervised recognition of unknown events based on the paradigm fingerprint vectors; a knowledge base update module for incrementally updating the paradigm knowledge base and generating resource profiles; and a scheduling execution module for performing paradigm-aware predictive resource scheduling.

[0019] This application has the following beneficial effects:

[0020] 1. By using unsupervised paradigm fingerprint extraction and anomaly detection, the scheduling system is equipped with the ability to identify and respond to unknown emergencies, solving the technical problem of traditional methods failing to respond to unknown events.

[0021] 2. Through incremental knowledge base updates and model learning, the scheduling system can adapt to newly launched business strategies online and quickly, solving the technical problems of long iteration cycles and inability to adapt to high-frequency business iterations in traditional models.

[0022] 3. By using paradigm-aware predictive scheduling, resource allocation decisions are transformed from delayed responses to individual services to proactive and collaborative allocation across the entire business chain, reducing end-to-end business latency and improving system performance and reliability in extreme scenarios.

[0023] 4. This application transforms the resource scheduling problem from the traditional numerical prediction-based method into a problem of identifying spatiotemporal behavior patterns of business execution, thereby enabling more accurate handling of latency and uncertainty requirements in scenarios such as high-frequency financial trading. Attached Figure Description

[0024] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0025] Figure 1 This is a flowchart of a microservice resource dynamic scheduling method according to an embodiment of this application.

[0026] Figure 2 This is a schematic diagram of a microservice resource dynamic scheduling device according to an embodiment of this application.

[0027] Figure 3 This is a schematic diagram illustrating the fingerprint generation principle of a business execution paradigm according to an embodiment of this application.

[0028] Figure 4 This is a schematic diagram of a paradigm-aware predictive resource scheduling logic according to an embodiment of this application.

[0029] Figure 5 This is a schematic diagram illustrating the distribution of paradigm fingerprint vectors in a two-dimensional reduced-dimensional space and the identification of unknown events according to an embodiment of this application.

[0030] Figure 6 This is a schematic diagram comparing the resource allocation effects of a predictive scheduling method according to an embodiment of this application and a traditional reactive scheduling method. Detailed Implementation

[0031] The present application will now be described in further detail with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the scope of the present application.

[0032] To enable those skilled in the art to better understand this application, the following first explains some key terms involved in this application. In this application, "Paradigm Fingerprint Vector" (PFV), or simply "Paradigm Fingerprint," refers to a fixed-dimensional, low-dimensional, dense vector that compresses the structure and attribute information of the call subgraph representing a business execution instance through models such as graph autoencoders. In some preferred embodiments, when a temporal graph neural network model is used, the generated Paradigm Fingerprint Vector can simultaneously represent the business topology and temporal behavior; this is called a "spatiotemporal Paradigm Fingerprint," which is essentially a specific or enhanced form of the "Paradigm Fingerprint Vector."

[0033] Example 1

[0034] This embodiment provides a method for dynamic scheduling of microservice resources. This method is applied to microservice systems deployed in a server cluster, such as a high-frequency trading system in finance. (Refer to...) Figure 1 The specific process of this method may include the following steps:

[0035] Step S1: Construct a real-time call topology graph and collect multi-dimensional runtime data. The goal of this step is to capture the dynamic behavior of the microservice system in real time with low overhead, providing a data foundation for subsequent pattern recognition.

[0036] Specifically, this step can be broken down into the following sub-steps: First, deploy a distributed tracing agent in the operating system kernel of each node in the server cluster. Preferably, this agent is implemented based on Extended Berkeley Packet Filtering (eBPF) technology. eBPF is a mechanism that allows secure and efficient execution of custom code within the operating system kernel space. It enables deep observation and programming of system and network events without modifying kernel source code or loading kernel modules, thus exhibiting extremely low performance overhead, which is crucial for latency-sensitive scenarios. The agent program captures network communication packets between all microservice instances non-intrusively by attaching eBPF-based probes to key functions in the kernel network protocol stack (such as tcp_sendmsg and tcp_recvmsg). Secondly, the agent parses structured network communication metadata from the captured data packets. This metadata includes the IP address and port of the source service instance, the IP address and port of the target service instance, the request initiation timestamp, the response completion timestamp, the request payload size, the response payload size, the method name of the Remote Procedure Call (RPC), and a globally unique tracking ID transmitted through protocol headers (such as HTTP Headers or gRPC Metadata). Next, the collected metadata is streamed to a centralized data processing engine, such as using a message queue (like Apache Kafka), for real-time processing by a stream processing platform (like Apache Flink). Finally, based on the received metadata, the data processing engine dynamically constructs and maintains a Real-time Call Topology Graph (RCTG) in memory. This graph is a weighted directed graph G=(V, E, W). A node v_i represents a microservice instance, uniquely identified by its IP address and port number. A directed edge e_ij represents a successful API call, pointing from the caller v_i to the callee v_j. The weight w_ij of an edge is a multi-dimensional vector, and its specific quantification value may include metrics such as the latency of this call (response completion timestamp - request initiation timestamp) and network throughput ((request load size + response load size) / latency).

[0037] As a preferred implementation, this step also synchronously collects internal performance metrics for each microservice instance. This can be achieved by deploying a performance monitoring agent (such as Prometheus Node Exporter) on the nodes. The collected metrics include CPU utilization (e.g., the percentage of CPU time spent in user mode and kernel mode per unit time), memory usage (e.g., resident set size RSS), disk I / O rate, and network I / O rate. These node attribute data are associated with the node v_i, providing a basis for subsequent generation of resource profiles.

[0038] The principle behind using eBPF for data acquisition lies in its ability to run sandboxed programs within the operating system kernel. This allows for secure and efficient observation of system events without modifying the kernel source code or application code, resulting in extremely low performance overhead. This is crucial for latency-sensitive scenarios such as financial transactions. As an alternative, sidecar proxies (such as Envoy) based on service mesh technology can be used for data acquisition. However, the network proxy introduced in this approach incurs additional communication latency. Therefore, eBPF is the superior choice for this scenario.

[0039] Step S2 involves extracting business execution instances and encoding them to generate paradigm fingerprint vectors. The core of this step is to use an unsupervised learning model to transform the unstructured "business execution instance" call subgraph representing the "business execution paradigm" into a standardized, low-dimensional mathematical representation, namely the paradigm fingerprint vector.

[0040] Reference Figure 3 The specific implementation of this step is as follows: The system slices the real-time call topology graph generated in step S1 using a preset, fixed time window (e.g., the time window size can be set to 500 milliseconds), obtaining a series of graph snapshots sorted by time. For each graph snapshot, the system uses a globally unique tracking ID to associate all cascading calls triggered by the same external request, forming a complete call subgraph with business causality. This subgraph completely depicts the execution process of a specific business in terms of topology and node / edge attributes, and is therefore called a "business execution instance". Then, the subgraph structure of these business execution instances and their multi-dimensional attribute data of nodes and edges are provided as input to a pre-trained graph autoencoder model. The encoder part of this autoencoder iteratively aggregates the information of neighboring nodes through a multi-layer graph neural network (GNN) layer, and finally compresses and encodes the structure and attribute information of the entire input subgraph into a fixed-dimensional low-dimensional dense vector, such as a 128-dimensional floating-point vector. This vector is the "paradigm fingerprint vector" (PFV) of the business execution instance.

[0041] To more accurately capture the temporal characteristics of business execution, the encoder part of the aforementioned graph autoencoder model is preferably implemented using a Temporal Graph Network (TGN). Unlike static Graph Convolutional Networks (GCNs) or Graph Attention Networks (GATs), the TGN model includes a memory module that records and updates the historical state of each node. When processing call events, TGN not only considers the current topology but also combines temporal information such as the timestamp of the event and the call sequence relationship to generate node embeddings. This allows the final generated paradigm fingerprint vector to simultaneously represent the spatial topology and temporal execution rhythm of the business. The underlying principle is that TGN treats the graph as a series of timestamped event streams and learns the dynamic evolution pattern of the graph by updating the memory and computing the embeddings. For example, in a financial transaction scenario, a "quick order placement" business and a "complex inquiry" business may call the same few microservices with similar topologies, but their call order, intervals, and latency are significantly different. TGN can effectively distinguish between these two patterns, while static graph models may confuse them.

[0042] As an alternative, graph kernel-based methods or classic graph embedding algorithms (such as Node2Vec combined with graph pooling) can be used to generate vector representations of graphs, but graph autoencoders, especially TGN, are more capable of capturing deep structures and dynamic features.

[0043] Step S3: Unsupervised identification of unknown events based on paradigm fingerprint vectors. This step utilizes the paradigm fingerprint vectors generated in step S2 to compare the current operating business mode of the system with known normal modes in real time to detect anomalies.

[0044] Specifically, the system maintains a "known paradigm fingerprint database" in memory or a dedicated vector database (such as FAISS or Milvus). This database stores a set of paradigm fingerprint vectors for all regular business patterns learned by the system during its historical normal operation through step S2. When a new business execution instance is generated and its real-time paradigm fingerprint vector v_new is produced, the system calculates the distance between v_new and all known vectors v_known stored in the "known paradigm fingerprint database". This distance metric preferably uses cosine distance, and its calculation formula is: Distance(v_new, v_known) = 1 - (v_new · v_known) / (||v_new|| * ||v_known||), where "·" represents the vector dot product, "||v||" represents the Euclidean norm of vector v, and "*" represents scalar multiplication. Then, the minimum distance d_min between v_new and all vectors in the database is found. The system presets a distance threshold δ (for example, δ can range from 0.1 to 0.3, determined through statistical analysis of historical data). If d_min > δ, the system determines that the business mode represented by the execution instance is an "unknown event mode". At this time, the system will trigger an alarm and persistently store the complete call subgraph constituting the unknown mode, the performance indicators (CPU, memory, etc.) of all nodes in the subgraph during the event, and the paradigm fingerprint vector v_new of this anomaly for subsequent analysis and learning.

[0045] Reference Figure 5 The diagram illustrates this recognition principle. In the figure, the fingerprint vectors of known paradigms such as conventional trading paradigm A, market data query paradigm B, and after-hours settlement paradigm C form their own clusters in two-dimensional space after t-SNE dimensionality reduction. The fingerprint vector of the unknown event mode falls outside all known clusters, and the distance d to the nearest cluster is greater than the threshold boundary δ.

[0046] For example, in financial markets, a sudden "fat finger" error might cause a trading system to generate an unprecedented and complex call chain involving multiple microservices such as risk control, order cancellation, and anomaly reporting. The paradigm fingerprint vector generated by this chain will be far removed from all fingerprint vector clusters representing normal business processes like regular transactions and queries in the vector space. Therefore, its minimum cosine distance will exceed a threshold δ, allowing the system to successfully identify it as an unknown event. The underlying principle is that unsupervised learning models map semantically similar business patterns to neighboring regions in the vector space, while semantically completely different new patterns are mapped to distant, unknown regions.

[0047] Step S4 involves incrementally updating the paradigm knowledge base and generating a resource requirement profile. This step enables the system to adopt online adaptive learning capabilities, allowing it to integrate newly discovered patterns into its own knowledge system.

[0048] This step is triggered when step S3 identifies an "unknown event pattern," or when operations personnel actively introduce a new service pattern by deploying new services and attaching specific tags (e.g., adding the "new_service_release" tag to the metadata of the tracking ID). This step specifically includes:

[0049] Sub-step S401: Perform new paradigm characterization. The system extracts the complete call subgraph topology corresponding to the new pattern (e.g., stored in the form of an adjacency list) and queries the monitoring system to obtain time-series data of various performance metrics for all microservice instances contained in the subgraph during execution (i.e., within the time window from the start to the end of the call). Then, statistical analysis is performed on this data to calculate the peak, mean, and P99 quantile (i.e., 99% of the data are less than this value) of CPU utilization and memory usage for each microservice instance. These statistical data together constitute the "resource requirement profile" of this new paradigm, which accurately quantifies the specific computing resource requirements for executing this business model.

[0050] Sub-step S402: Perform incremental update of the knowledge base. The system encapsulates the new paradigm's "paradigm fingerprint vector," "topology," and "resource requirement profile" as an inseparable whole into a new "paradigm knowledge entry." This entry is then stored in a global, persistent, dynamic paradigm knowledge base. This knowledge base can be implemented using a document database (such as MongoDB) or a relational database. The "known paradigm fingerprint database" is used to achieve fast vector retrieval and comparison. It can exist as a dedicated index of the "dynamic paradigm knowledge base," or as an independent vector database (such as FAISS or Milvus) that maintains data synchronization with the dynamic paradigm knowledge base.

[0051] Sub-step S403 involves performing incremental learning of the recognition model. The paradigm fingerprint vector of the new paradigm is used as a new known sample to update the known paradigm fingerprint database described in step S3 online. If the database is based on a vector database, this operation typically corresponds to adding a new vector to the index, which is highly efficient. This step enables the system to recognize this new pattern as a known pattern in the future, rather than triggering a repeat alarm. For more complex recognition models, alternatively, algorithms supporting online learning, such as Incremental Support Vector Machines (SVMs) or adaptive k-nearest neighbors, can be used. These algorithms can update the decision boundary with new samples without accessing all historical data, thus avoiding costly batch retraining.

[0052] Step S5: Perform paradigm-aware predictive resource scheduling. This step is the final execution stage of this application, utilizing the knowledge base established in the previous steps to achieve resource scheduling that shifts from passive response to proactive prediction.

[0053] Reference Figure 4 The scheduling logic is divided into two cases based on whether the identified paradigm is known or unknown:

[0054] The first scenario is predictive scheduling based on known paradigms. When an external request enters the system, its call chain forms an initial call subgraph in the early stages of execution (e.g., after only the first 2-3 microservice calls). The system immediately generates a temporary paradigm fingerprint for this initial subgraph and quickly matches it with all known paradigm fingerprints in the "dynamic paradigm knowledge base." If the temporary fingerprint is highly similar to the fingerprint of a known paradigm (e.g., the "large order completion" paradigm) (i.e., the distance is less than a small matching threshold), the system immediately determines that the "large order completion" paradigm is about to be fully executed. The scheduler then retrieves the complete "topology" and "resource requirement profile" corresponding to this paradigm from the knowledge base. Based on this information, the scheduler can predictively know which downstream microservices (such as clearing services and risk control services) will be called intensively next. Therefore, the scheduler immediately interacts with the server cluster's resource orchestration system (such as Kubernetes) via API to proactively and in parallel pre-allocate resources (e.g., adjust their CPU limits and requests) or pre-scale instances (e.g., increase the number of replicas) for these downstream microservice instances that are expected to be invoked, according to the P99 quantile resource requirements recorded in their resource profiles. This proactive scheduling is significantly superior to traditional lagging scheduling based on individual service resource utilization thresholds, effectively preventing business latency spikes caused by insufficient resources.

[0055] Reference Figure 6 This diagram illustrates a comparison of the resource allocation effectiveness between the predictive scheduling method of this application and the traditional reactive scheduling method. In the diagram, the solid line represents the actual business load, the dashed line represents the predictive scheduling of this application, and the dotted line represents the traditional reactive scheduling. It can be seen that the resource adjustments in traditional reactive scheduling (dotted line) always lag behind changes in the actual load (solid line), thus creating resource lag areas during peak load periods. In contrast, the predictive scheduling of this application (dashed line), by identifying business patterns in advance, can accurately pre-allocate resources before peak load arrives, resulting in a high degree of fit between the resource supply curve and the actual load curve, effectively eliminating resource lag and ensuring service quality.

[0056] The second scenario is emergency scheduling for unknown paradigms. When a business pattern is identified as an "unknown event" in step S3, the scheduler immediately initiates an emergency resource allocation strategy to ensure the stability of the entire system and prevent the spread of the fault. Preferably, this strategy is a graph-based "radius of influence" strategy. Specifically, the scheduler first identifies the initial nodes (i.e., the earliest service instances called) that constitute the call subgraph of the unknown pattern. Then, it performs temporary, redundant resource allocation not only for these initial nodes but also for their first- or second-order downstream adjacent nodes in the call graph (e.g., temporarily raising their CPU limits to a higher safety value). The principle is that the performance pressure caused by unknown events is most likely to propagate downstream along the call chain. By providing sufficient resources in advance to nodes within the radius of influence, the rapid spread of performance problems can be effectively curbed, buying time for manual intervention or further system adaptation.

[0057] Example 2

[0058] This embodiment provides a microservice resource dynamic scheduling device. This device is the execution entity of the above method embodiments and can be implemented by computer hardware, software, or a combination thereof. (Refer to...) Figure 2 The device includes:

[0059] The data acquisition module 201 is used to construct a real-time call topology graph and collect multi-dimensional runtime data. This module is specifically responsible for deploying and managing the distributed tracing agent, receiving and processing the collected metadata, and maintaining the real-time call topology graph in memory. Its function corresponds to step S1 in Embodiment 1.

[0060] The paradigm encoding module 202 is used to extract business execution instances and encode them to generate paradigm fingerprint vectors. This module integrates a graph autoencoder model (preferably a temporal graph neural network model), which is responsible for encoding the business execution instance subgraphs extracted from the real-time call topology graph to generate paradigm fingerprint vectors. Its function corresponds to step S2 in embodiment 1.

[0061] The event recognition module 203 is used for unsupervised recognition of unknown events based on paradigm fingerprint vectors. This module maintains a known paradigm fingerprint database and calculates the distance between newly generated paradigm fingerprints and known fingerprints in the database in real time. It determines whether an event is unknown based on a preset threshold. Its function corresponds to step S3 in embodiment 1.

[0062] The knowledge base update module 204 is used to incrementally update the paradigm knowledge base and generate resource profiles. When a notification of an unknown event or a new business model is received, this module is responsible for extracting its topology, generating a resource requirement profile, and encapsulating it as a knowledge item and storing it in the "dynamic paradigm knowledge base". At the same time, it updates the recognition model online. Its function corresponds to step S4 in embodiment 1.

[0063] The scheduling execution module 205 is used to perform paradigm-aware predictive resource scheduling. Based on the output of the event recognition module, this module performs predictive scheduling with known paradigms or contingency scheduling with unknown paradigms. By interacting with the cluster resource orchestration system, it completes the pre-allocation or expansion of resources. Its function corresponds to step S5 in Embodiment 1.

[0064] Those skilled in the art will understand that each module in the above-described device can be implemented by software program instructions and stored in a storage medium, and executed by one or more processors to complete all or part of the steps of the method described in this application. This device can be deployed on the management node of a server cluster or run as a standalone control platform.

[0065] Example 3

[0066] This embodiment uses a high-frequency trading system for financial derivatives deployed in a data center as an example to further illustrate the implementation process of the method proposed in this application. The system is characterized by the fact that the vast majority of trading requests it processes daily exhibit statistically no correlation between different financial products, and system resource consumption shows stable random fluctuations. However, when specific macroeconomic signals appear in the market (e.g., a central bank in a region issues an unexpected interest rate adjustment decision), it instantly triggers highly correlated cascading trading and risk hedging behaviors across multiple asset classes, resulting in a "systemic risk shock" mode that is drastically different from conventional trading patterns in terms of topology and resource requirements. Traditional reactive scheduling methods based on individual service resource utilization thresholds, or predictive models trained on historically stable data, are unable to cope with such sudden and drastic pattern shifts that have never occurred before in history.

[0067] In this embodiment, the specific implementation steps of the method are as follows. First, the system continuously constructs a real-time call topology graph through an eBPF probe deployed on the server node kernel. When the aforementioned systemic risk impact event occurs, the probe captures requests initiated by the "Market Data Gateway Service" and flowing almost simultaneously to a large number of different "Strategy Calculation Service" instances. These instances then concentrate their calls to the downstream "Risk Control Service" and "Order Execution Service" within a very short period of time. This process forms a special call subgraph that has never appeared during normal periods, rapidly fanning out from a single point and then concentrating towards a few core services.

[0068] Next, the paradigm encoding module captures the complete call subgraph associated with the event. Because this event is characterized by the concurrency and temporal compactness of its calls, the encoder using a Temporal Graph Neural Network (TGN) can effectively capture these spatiotemporal features of "simultaneity" and "concentration." The model encodes this subgraph into a new paradigm fingerprint vector, denoted as PFV_shock. The event recognition module calculates the cosine distance between PFV_shock and all regular fingerprints in the known paradigm fingerprint database (e.g., PFV_normal_trade representing a single product transaction). Since the topology and temporal behavior represented by PFV_shock differ significantly from all known normal patterns, its calculated minimum distance is significantly greater than the preset threshold δ, therefore the system immediately classifies this as an unknown event.

[0069] Subsequently, the knowledge base update module was triggered. This module first characterized the unknown event. By analyzing monitoring data, it was found that during the event, the CPU utilization of the risk control service peaked at 500% of its normal level, while the database connection count of the order execution service surged by 1000%. These quantitative indicators were solidified into a resource requirement profile for this systemic risk impact paradigm. Afterward, the system incrementally stored the newly generated PFV_shock, its corresponding call topology, and this resource requirement profile as a new knowledge entry into the dynamic paradigm knowledge base. Simultaneously, PFV_shock was added to the known paradigm fingerprint database, completing the online learning of the new pattern.

[0070] To illustrate the predictive scheduling in this application, it is assumed that several weeks later, a similar macroeconomic signal emerges in the market, triggering another systemic risk shock event. When the initial invocation behavior of the event (i.e., the "market data gateway service" fans out requests to multiple "strategy calculation services") occurs, the initial subgraph fingerprint generated by the system can successfully match the PFV_shock stored in the knowledge base. Based on this, the scheduling execution module predicts that the downstream risk control service and order execution service will soon be under tremendous pressure. Before the actual load of these services increases, the scheduler, based on the resource profile stored in the knowledge base, proactively issues instructions to the cluster resource orchestration system to pre-increase the CPU resource limit of the risk control service by 5 cores and pre-start and warm up 10 new service instances for the order execution service. Through this predictive scheduling, resource configuration for relevant services is completed before the actual load increases, thereby effectively handling the resource pressure brought by the second shock and avoiding transaction delays or failures that may be caused by insufficient resources.

[0071] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for dynamically scheduling microservice resources, applied to a microservice system deployed in a server cluster, characterized in that, The method comprises the following steps: Step S1, capturing network communication metadata between microservice instances in real time through a distributed tracing agent, and constructing a weighted directed real-time call topology graph based on the network communication metadata, while collecting performance indicators of each microservice instance as node attribute data; Step S2, identifying a call subgraph as a business execution instance from the real-time call topology graph using a globally unique trace ID; inputting the subgraph structure and node attribute data of the business execution instance into a graph autoencoder model to encode and generate a paradigm fingerprint vector; The graph autoencoder model in step S2 is a time series graph neural network model; the time series graph neural network model captures and encodes the timestamp, duration and call sequence relationship of the call event through its built-in memory module, thereby generating a time-space paradigm fingerprint representing the business topology structure and time sequence behavior as the paradigm fingerprint vector; Step S3, if the minimum distance between a real-time generated paradigm fingerprint vector and all vectors in a known paradigm fingerprint library is greater than a preset threshold, it is determined that the corresponding business execution instance is an unknown event mode; Step S4, when the unknown event mode is identified, a resource demand profile is generated for the mode, and the paradigm fingerprint vector, call subgraph topology and resource demand profile of the mode are stored in a dynamic paradigm knowledge base, and the known paradigm fingerprint library is updated online; Step S401, performing new paradigm characterization, extracting the complete call subgraph topology corresponding to the unknown event mode, and recording the peak value, mean value and P99 quantile of each performance indicator of all microservice instances during execution to constitute the resource demand profile; Step S402, performing knowledge base incremental update, encapsulating the paradigm fingerprint vector, call subgraph topology and resource demand profile of the unknown event mode into a new paradigm knowledge item and storing it in the dynamic paradigm knowledge base; Step S403, performing incremental learning of the identification model, taking the paradigm fingerprint vector of the unknown event mode as a new class sample, and performing online update on the known paradigm fingerprint library in step S3; Step S5, performing resource scheduling on the microservice system according to the matching result of the paradigm fingerprint vector and the dynamic paradigm knowledge base; When the fingerprint generated by the initial subgraph formed at the initial stage of the call link of the incoming request successfully matches a known paradigm in the dynamic paradigm knowledge base, the complete topology structure and resource demand profile corresponding to the known paradigm are retrieved from the knowledge base, and resource pre-allocation or instance pre-scaling is performed for all downstream microservice instances expected to be called in the paradigm call link; When a business execution instance is determined to be an unknown event mode in step S3, an emergency resource allocation strategy is started, and temporary resource redundancy is configured for the initial node and its first or second downstream adjacent nodes of the unknown event mode call subgraph.

2. The method of claim 1, wherein, The network communication metadata collected in the step S1 includes at least one of the following: source service unique identifier, target service unique identifier, request initiation timestamp, response completion timestamp, request load size, response load size, method name of remote procedure call, and the globally unique trace ID; and the node attribute data includes CPU usage, memory occupation, disk I / O rate, and network I / O rate.

3. The method of claim 2, wherein, In the step S3, the distance between the real-time generated paradigm fingerprint vector and all vectors in the known paradigm fingerprint library is calculated, and the cosine distance or Euclidean distance is used for measurement.

4. The method of claim 3, wherein, In the step S403, the online update of the known paradigm fingerprint library is performed by using an incremental support vector machine or an online learning algorithm of adaptive nearest neighbor index, so as to update the identification model with new samples without accessing all historical data.

5. The method of claim 4, wherein, The pre-allocation of resources or the pre-scaling of instances for downstream microservice instances is performed according to the P99 quantile of the performance indicators of each microservice instance recorded in the resource demand profile, to adjust the CPU limit, CPU request, or increase the number of replicas of the target microservice instance.

6. The method of claim 5, wherein, In the step S1, the distributed tracing agent uses the extended Berkeley packet filter (eBPF) technology to capture the network communication metadata in the operating system kernel of the server cluster in real time. 7.A micro-service resource dynamic scheduling apparatus, the scheduling apparatus is used to execute the scheduling method of any one of claims 1-6, characterized in that, Comprise: A data acquisition module for capturing network communication metadata between microservice instances in real time through a distributed tracing agent, and constructing a weighted directed real-time call topology graph based on the network communication metadata, while collecting internal performance indicators of each microservice instance as node attribute data; A paradigm encoding module for identifying a call subgraph as a business execution instance using a globally unique trace ID from the real-time call topology graph; inputting the subgraph structure and node attribute data of the business execution instance into a graph autoencoder model to encode and generate a paradigm fingerprint vector; An event identification module for maintaining a known paradigm fingerprint library, and determining that the corresponding business execution instance is an unknown event mode if the minimum distance between a real-time generated paradigm fingerprint vector and all vectors in the known paradigm fingerprint library is greater than a preset threshold; A knowledge base update module for generating a resource demand profile for the unknown event mode when the unknown event mode is identified, and storing the paradigm fingerprint vector, call subgraph topology, and resource demand profile of the mode into a dynamic paradigm knowledge base, and updating the known paradigm fingerprint library online; A scheduling execution module for performing resource scheduling on the microservice system according to the matching result of the paradigm fingerprint vector and the dynamic paradigm knowledge base.

Images