Cloud resource dynamic scheduling method based on micro-service dependency relationship

Abstract

The application discloses a cloud resource dynamic scheduling method based on micro-service dependency relationship, and relates to the technical field of resource scheduling.The application first combs explicit and implicit dependencies and generates a topological atlas based on calling logs, registration center data and resource monitoring data, and then configures core resource water level indexes for corresponding nodes in each dependency chain after the topological atlas is disassembled into a plurality of dependency chains, and calculates resource bottleneck conduction coefficients;then, the application collects core resource water level indexes in real time through a distributed monitoring engine, and calculates load conduction influence values;finally, the application executes hierarchical early warning according to chain levels, dependency levels and basic levels, and matches differentiated cloud resource elastic scheduling strategies.The application realizes accurate prediction and hierarchical control of dependency chain risks, improves the fine level of resource scheduling, and improves resource utilization rate while ensuring the stability of a micro-service system.

Description

Technical Field

[0001] This invention relates to the field of resource scheduling technology, specifically a dynamic scheduling method for cloud resources based on microservice dependencies. Background Technology

[0002] In scenarios where microservice architectures are widely used, dynamic scheduling of cloud resources has become a core technology for ensuring service stability and resource utilization. However, existing dynamic scheduling methods for cloud resources still have the following shortcomings: First, existing methods ignore the implicit data dependencies between microservices and do not consider the link transmission effect of node resource bottlenecks. As a result, scheduling decisions can only alleviate the pressure on local nodes and cannot prevent the risk from spreading in the dependency chain, ultimately causing a chain of failures. Secondly, existing methods do not construct a complete topology graph for the dependencies between microservices, resulting in scheduling decisions lacking accurate dependency support. Third, existing methods do not classify risks according to their impact scope and cannot distinguish between node-level, dependency-level and link-level risks, resulting in insufficient targeting of scheduling strategies. At the same time, scheduling strategies are disconnected from dependencies and risk levels, and resource allocation fails to match the importance and dependence of nodes in the link, resulting in resource waste or insufficient supply. Therefore, we continue with a dynamic scheduling method for cloud resources based on microservice dependencies. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a dynamic scheduling method for cloud resources based on microservice dependencies, which solves the problems of uncontrolled risk transmission in existing microservice dependency chains and insufficient accuracy in resource scheduling.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a dynamic scheduling method for cloud resources based on microservice dependencies, comprising: S1. Based on the call logs, service registry data and resource monitoring data of the microservice architecture, the explicit call dependencies and implicit data dependencies between microservices are automatically sorted out to generate a complete microservice topology map. Then, each independent dependency chain is decomposed from it, core resource level indicators are configured for the corresponding nodes in each dependency chain, and the resource bottleneck transmission coefficient is calculated. The resource bottleneck transmission coefficient is the product of the node core degree and the coupling degree. S2. Through a distributed monitoring engine, the core resource level indicators and resource bottleneck transmission coefficients of each node in the dependency chain are collected and synchronized in real time, and the impact of changes in the resource status of upstream nodes on the load transmission of downstream nodes is calculated. S3. Based on the core resource level indicators, resource bottleneck transmission coefficients, and load transmission impact values ​​of each node in the dependency chain, a three-level early warning is executed according to priority rules, and the corresponding cloud resource dynamic scheduling strategy is executed according to the triggered early warning level. The three-level early warning is specifically chain-level early warning, dependency-level early warning, and basic-level early warning.

[0005] As a further aspect of the present invention, the specific steps for constructing a microservice topology graph are as follows: The distributed data acquisition engine captures three types of data in real time: microservice call logs, service registry registration information, and resource monitoring data streams. Based on distributed tracing technology, the collected call logs are correlated and analyzed. By tracing the ID, the complete call chain of a single business request is linked together, and the explicit dependencies of direct calls between microservices are marked. Based on data flow analysis technology, we trace the data transmission path between microservices and mark implicit dependencies between microservices that are not directly called but have data interaction. Clearly define the unidirectional transmission direction and association form of all dependencies. The association form includes synchronous and asynchronous. Synchronous corresponds to explicit dependencies between microservices, and asynchronous corresponds to implicit dependencies between microservices. Using microservice nodes as vertices and identified dependencies as directed edges, a microservice topology graph is constructed using a graph database or graph computing engine, clearly labeling the name, service type, and association form of each directed edge.

[0006] As a further aspect of the present invention, the core resource level indicators specifically include CPU utilization, memory usage, thread pool load, interface response latency, and request concurrency.

[0007] As a further aspect of the present invention, the specific steps for calculating node coreness are as follows: Based on the microservice topology graph, extract two core dimensions of data for the target node: the node's in-degree X and out-degree Y; the number of sub-links directly associated with the node M; and the total number of sub-links N contained in the entire dependency chain. Calculate the core degree = [(X+Y) / (average in-degree of all nodes in the link + average out-degree of all nodes in the link)] × (M / N), where [(X+Y) / (average in-degree of all nodes in the link + average out-degree of all nodes in the link)].

[0008] As a further aspect of the present invention, the specific steps for calculating the coupling degree are as follows: Analyze the interaction protocol and intermediate component type between the target node and all downstream directly dependent nodes, record the interaction latency T, and determine whether there is a buffer component. If there is, record it as 1; otherwise, record it as 0. The interaction delay T represents the average time from when the upstream request is sent to when the downstream response is received. Calculate the single coupling degree = 1 - (T / D) × K, where D is the average interaction delay of the link, and K is the buffer component correction factor, which is 1 when it does not exist and ∈ (0,1) when it exists. Obtaining coupling degree = , where C i W represents the coupling degree between the target node and the i-th downstream node. i Let be the business weight of the i-th downstream node, and .

[0009] As a further aspect of the present invention, calculating the impact of changes in the resource status of upstream nodes on the load transmission of downstream nodes specifically includes: The core resource type of P is obtained based on the dependency interaction triggering logic between upstream node P and directly connected downstream node Q. The baseline value S of node P for this core resource type was collected. base Current real-time value S now Calculate the magnitude of resource changes Its value range is [0,1], and if it exceeds the range, the boundary value is directly taken; Based on the correlation form of the directed edges P and Q, the conduction attenuation coefficient Assign values: If the directed edge association is synchronous, then Take 1; if the directed edge association is asynchronous, then Take U, where U∈(0,1); Calculate the load transmission impact of P on Q = resource change magnitude × Conduction attenuation coefficient .

[0010] As a further aspect of the present invention, the core resource type of P obtained based on the dependency interaction triggering logic between the upstream node P and the directly connected downstream node Q specifically includes: if P and Q are in a request-call type interaction, then the request concurrency is taken as the core resource type; if P and Q are in a computing power processing type interaction, then the CPU utilization rate is taken as the core resource type; if P and Q are in a data storage type interaction, then the memory occupancy rate is taken as the core resource type; if P and Q are in a task queuing type interaction, then the thread pool load is taken as the core resource type.

[0011] As a further aspect of the present invention, the specific operation of executing the three-level early warning according to the priority rule is as follows: The three levels of alerts are prioritized as follows: chain-level alert > dependency-level alert > basic-level alert. Chain-level alerts are executed first, which includes: extracting the resource bottleneck transmission coefficient of all dependent nodes in the dependency chain, defining the node with the largest resource bottleneck transmission coefficient as a high-risk node in the chain; verifying whether the bottleneck transmission initiated by the high-risk node can directly or indirectly cover all other nodes in the chain, with the verification result being either "covers" or "does not"; if the verification result is that it can cover all other nodes in the chain, then the dependency chain is directly determined to have triggered a chain-level alert; otherwise, the dependency chain is directly determined not to have triggered a chain-level alert. Once a chain-level alert is triggered, that level is immediately locked, and subsequent dependency-level and basic-level checks will not be performed. Otherwise, a dependency-level check will be performed, which includes: Retrieve the dependency propagation thresholds and corresponding load propagation impact values ​​for all single-hop links from P to the next directly connected node Q in the current dependency chain. Filter out single-hop links PQ that have not triggered any single-node anomalies. If their load propagation impact value is ≥ the corresponding dependency propagation threshold, a dependency-level warning is triggered, the level is locked, and the basic-level judgment is terminated. Otherwise, perform the basic-level judgment, which includes: Collect real-time values ​​of core resource levels of each node in the dependency chain. If the real-time value of a certain core resource level indicator of any single node is greater than or equal to the corresponding indicator threshold, a basic-level warning is triggered; otherwise, the warning is not executed. The PQ single-hop link that does not trigger any single-node anomalies refers to the fact that the core resource level indicators of both the upstream node P and the directly connected downstream node Q do not exceed the corresponding indicator thresholds.

[0012] As a further aspect of the present invention, it is verified whether the bottleneck propagation initiated by the high-risk propagation node can cover the specific operations of all other nodes in the link: Identify nodes with high transmission risk and define them as transmission initiation nodes. Simultaneously extract all nodes in the dependency chain to form a complete list of link nodes. Based on the microservice topology graph, starting from the transmission initiation node, and following the unidirectional dependency direction of the microservice business flow, we can identify all downstream transmission paths that can be extended when the node initiates bottleneck transmission. All downstream nodes reached by the starting node in the statistically analyzed transmission path are merged to form a node reach set, which includes the transmission starting node itself and all downstream reach nodes. The node reach set is compared with the total list of link nodes: if the node reach set completely includes all nodes in the total list of link nodes, it is directly determined that the high transmission risk node can cover all other nodes in the link; otherwise, it is determined that it cannot be covered.

[0013] As a further aspect of the present invention, the execution of corresponding dynamic cloud resource scheduling strategies based on the triggered warning level specifically includes: If it is a basic-level early warning, the following scheduling strategy will be executed: For abnormal nodes, vertical scaling up or down will be automatically triggered, and the core resources of the node will be bound to the highest priority, limiting the resource usage ratio of non-core businesses to ≤5%; If it is a dependency-level warning, the following scheduling strategy will be executed: For upstream node P, its thread pool capacity will be increased to improve request processing capacity; for downstream node Q, the number of instances will be temporarily increased to distribute the load transmitted by node P. If it is a chain-level alert, the following scheduling strategy will be executed: For the cloud resource cluster where the current dependent chain is located, trigger the global resource pool expansion, increase the resource quota of the link by 50%, configure the core hub node in the link to resource exclusive mode, prohibit services outside the link from occupying its resources, and at the same time, start link-level resource isolation to physically isolate the current dependent chain from the resource pools of other unrelated links.

[0014] This invention provides a dynamic scheduling method for cloud resources based on microservice dependencies, which has the following advantages compared with existing technologies: (1) This invention generates a complete topology map by sorting out explicit calls and implicit data dependencies, and calculates the resource bottleneck transmission coefficient by combining core degree and coupling degree, so as to realize the dynamic quantification of the risk transmission capability of the dependency chain, block the spread of risk in the link from the source, and avoid the chain failure caused by local node anomalies; (2) This invention constructs a hierarchical early warning system to improve the accuracy of risk identification. It divides the early warning priority into chain level, dependency level and basic level, and realizes hierarchical judgment based on core resource indicators, transmission coefficient and load impact value, accurately matching risk scenarios of different ranges and avoiding misjudgment and lag caused by single threshold early warning. (3) Based on the warning level and the core attributes of the node in the link, the present invention formulates a differentiated strategy to ensure that the resource allocation conforms to the operation rules of the dependent chain, thereby avoiding non-core nodes from occupying redundant resources and ensuring the resource supply of core links and nodes. Attached Figure Description

[0015] Figure 1 This is a flowchart of the steps of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] like Figure 1 This invention provides a method for dynamic scheduling of cloud resources based on microservice dependencies; As an embodiment of this application, the specific steps include the following: S1. Based on the call logs, service registry data and resource monitoring data of the microservice architecture, the system automatically sorts out the explicit call dependencies and implicit data dependencies between microservices to generate a complete microservice topology map, and then decomposes each independent dependency chain from it, configures the core resource level indicators for the corresponding nodes in each dependency chain and calculates the resource bottleneck transmission coefficient. S2. Through a distributed monitoring engine, the core resource level indicators and resource bottleneck transmission coefficients of each node in the dependency chain are collected and synchronized in real time, and the impact of changes in the resource status of upstream nodes on the load transmission of downstream nodes is calculated. S3. Based on the core resource level indicators, resource bottleneck transmission coefficients, and load transmission impact values ​​of each node in the dependency chain, a three-level early warning is executed according to priority rules, and the corresponding cloud resource dynamic scheduling strategy is executed according to the triggered early warning level. The three-level early warning is specifically chain-level early warning, dependency-level early warning, and basic-level early warning.

[0018] As a second embodiment of this application, it is implemented based on the first embodiment, except that this embodiment includes: S1. Based on the call logs, service registry data, and resource monitoring data of the microservice architecture, the system automatically identifies explicit call dependencies and implicit data dependencies between microservices, generating a complete microservice topology map. The specific operations are as follows: The system uses a distributed data acquisition engine (such as Flink or Logstash Distributed Deployment Edition) to capture basic data sources in real time. These basic data sources include three types of data: microservice call logs, service registry registration information, and resource monitoring data streams. The call log directly records the call behavior between services, including the calling node, the receiving node, the call time, and the call result; The registration information in the service registry clearly defines all service nodes within the system, including full node metadata, deployment instances, and service status. Resource monitoring data streams can capture implicit relationships such as data sharing and asynchronous message passing, including resource-related data such as node CPU / memory usage and request concurrency. Relying solely on collected call logs will miss the metadata of offline nodes, relying solely on the registry center will not be able to obtain real-time dynamic call relationships, and the lack of resource monitoring data streams will make it impossible to associate the resource interaction logic behind the dependencies. Therefore, it is necessary to collect the above three types of data to obtain complete dependency information. Because microservice systems have the characteristics of distributed deployment, a large number of nodes, and high call frequency, centralized collection engines not only cannot cover all nodes, but are also prone to performance bottlenecks. Therefore, this invention adopts a distributed collection engine, which can be deployed in a distributed manner on various service clusters to achieve full-node data crawling. Based on distributed tracing technologies, such as SkyWalking's Trace tracing, the collected call logs are correlated and analyzed. By connecting the complete call chain of a single business request through the tracing ID, explicit dependencies between services are marked. Explicit dependencies (direct calls) are the core of microservice dependencies, but traditional log analysis cannot connect call chains across nodes. Distributed tracing technology uses tracing IDs to associate scattered call logs into a complete chain, avoiding bias in the identification of explicit dependencies. Based on data flow analysis technology, we can track the data transmission path between microservices and identify implicit dependencies that are not directly called but have data interaction. For example, if service A calls service B and service B synchronizes data to service C, although A and C have no direct calling relationship, there is data transmission between them. Therefore, they can be marked as implicit dependencies. Microservice architecture contains a large number of implicit dependencies, such as data interaction through message queues, caches, and databases. These dependencies have no direct calling relationship, but they can directly affect the transmission of resource bottlenecks. Data flow analysis can track the complete path of data from generation to consumption, filling the gap in the identification of implicit dependencies. Finally, the unidirectional transmission direction and association form of all dependencies are clarified. The association forms include synchronous and asynchronous. Synchronous corresponds to explicit dependencies between services, and asynchronous corresponds to implicit dependencies between services. Using nodes as vertices and identified dependencies as directed edges, a microservice topology graph is constructed using a graph database or graph computing engine. The name, service type, and association form (synchronous or asynchronous) of each directed edge are clearly labeled in the graph to ensure that the graph information is complete and interpretable. The microservice topology graph is broken down into individual microservice dependency chains, specifically including: By breaking down the data into business scenarios and combining this with data flow integrity verification, the business boundaries of each independent link are clearly defined. A microservice topology graph is a global dependency set of the entire system, containing all nodes and all types of dependencies. Without dimension division, it presents an unordered network structure, making it impossible to directly conduct risk analysis and early warning for single links. The key to microservice architecture design is to divide service domains according to business scenarios. At the same time, dividing the business into segments based solely on business scenarios can easily lead to incomplete links. For example, the separated order placement link may only include the order placement and verification nodes, but lack the payment node. A complete business link must be accompanied by the complete flow of data from generation to closure. Verification in this way can ensure that each link is a dual closed loop of business and data, rather than a fragmented combination of nodes. Based on the directed dependency relationship of the microservice topology graph, starting from the entry node corresponding to the decomposition dimension, the chain is connected along the dependency direction to the exit node to form a complete independent dependency chain, and irrelevant service nodes and dependencies outside the chain are eliminated. The entry node represents the starting node of the business request. This point is connected in a forward sequence along the dependency direction marked in the graph. It is the only way to restore the true flow of the business and conforms to the transmission law of microservice business-driven processes. In a microservice topology graph, some nodes or dependencies may have a weak correlation with the business scenario, but they are not the core components of the link. Such irrelevant nodes will lead to link redundancy. Performing the operation of removing irrelevant nodes and dependencies outside the link can achieve precise purification of the link, allowing the link to retain the core nodes and dependency relationships. Configure core resource level indicators for each node in each dependency chain, and calculate the resource bottleneck transmission coefficient for each node; The core resource level indicators specifically include CPU utilization, memory usage, thread pool load, interface response latency, and request concurrency: CPU utilization directly reflects the saturation of a node's computing resources and is the most basic indicator for determining a node's computing bottleneck. A node's computing bottleneck is the primary cause of dependency chain propagation. Without this indicator, it is impossible to capture the underlying operational risks of a node. Memory utilization rate is a key indicator that directly reflects the availability of storage resources on a node. Insufficient memory can lead to data loading failures, cache invalidation, and even node process crashes. It is the only core indicator for determining bottlenecks in node storage. Storage bottlenecks directly affect the node's business processing efficiency and then propagate to downstream dependencies. Thread pool load is a metric that directly reflects a node’s task processing capacity and task queuing status. It is a specific metric for determining a node’s task scheduling bottleneck. Scheduling bottlenecks are a core risk unique to nodes and cannot be covered by CPU / memory metrics, so they must be configured separately. Interface response latency is a comprehensive feedback of the overall operating status of a node. It can verify whether bottlenecks in computing power, storage, and scheduling have actually caused a decline in service capabilities. It is a key indicator for determining the effective bottlenecks of a node. Request concurrency is a core traffic entry point for nodes and the source of load propagation in the dependency chain. All resource pressures on a node, such as CPU, memory, and thread pool, are caused by the number of concurrent requests received. Furthermore, changes in the concurrency of upstream nodes are directly transmitted to downstream nodes, making it the fundamental cause of load propagation between nodes. Without this metric, it is impossible to pinpoint the initial source of load propagation in the dependency chain.

[0019] S2. The distributed monitoring engine collects and synchronizes the core resource level indicators and resource bottleneck transmission coefficients of each node in the dependency chain in real time, and calculates the impact of changes in the resource status of upstream nodes on the load transmission of downstream nodes. The calculation of the impact of upstream node resource status changes on load transmission to downstream nodes specifically includes: Based on the dependency interaction triggering logic between upstream node P and directly connected downstream node Q, a unique indicator that can directly cause load fluctuations in node Q is selected from the five core resource level indicators configured in P, and this indicator is taken as the core resource type of P: If P and Q are in a request-call type interaction, such as order verification → payment service, the interaction logic is: P actively initiates business requests to Q. The more requests P initiates, the more tasks Q needs to handle, and the higher the load on Q. Therefore, request concurrency is regarded as a core resource type. If P and Q are interacting in a computing power processing manner, such as data computing service → result push service, the interaction logic is as follows: after P completes data computing power processing, it pushes the result to Q. If the computing power consumption of P is higher (the CPU usage is higher), the dataset being processed is larger, and Q needs to receive and distribute more result data, resulting in a higher load on Q. Therefore, CPU utilization is taken as the core resource type. If P and Q are data storage type interactions, such as file storage service → file distribution service, the interaction logic is: Q reads files / data from P. The higher the memory usage of P (the more files / data stored), the greater the reading frequency and data transfer volume of Q, and the higher the load of Q. Therefore, memory usage is regarded as the core resource type. If P and Q are task-queuing type interactions, such as order submission service → order review service, the interaction logic is as follows: P's tasks will enter the thread pool for queuing and then be forwarded to Q. If the thread pool load of P is higher (the more queued tasks), then more tasks will be pushed to Q, and the load of Q will be higher. Therefore, thread pool load is regarded as the core resource type. The baseline value S of node P for this core resource type was collected. base Current real-time value S now Calculate the magnitude of resource changes Its value range is [0,1], and if it exceeds the range, the boundary value is directly taken; Based on the correlation form of the directed edges P and Q, the conduction attenuation coefficient Assign values: If the directed edge association is synchronous, then Take 1; if the directed edge association is asynchronous, then Take U, which is determined by the real-time buffering capability of the intermediate component. The stronger the buffering capability, the smaller U is, where U∈(0,1). Calculate the load transmission impact of P on Q = resource change magnitude × Conduction attenuation coefficient The essence of single-hop load propagation is that the intensity of resource changes at the current node, after being weakened by the interaction method, is ultimately transmitted to the next node and thus has a greater actual impact.

[0020] S3. Real-time collection of core resource level indicators, resource bottleneck transmission coefficients, and load transmission impact values ​​for each node in the dependency chain, and execution of three-level early warnings according to priority rules. The three-level early warnings specifically include chain-level early warning, dependency-level early warning, and basic-level early warning. The specific operation is as follows: The three levels of early warning are prioritized as follows: chain-level early warning > dependency-level early warning > basic-level early warning; Prioritize chain-level alerts; the specific steps are as follows: Extract the resource bottleneck transmission coefficient of all dependent nodes in the dependency chain, define the node corresponding to the largest resource bottleneck transmission coefficient as the high transmission risk node of the link, extract the maximum value of the coefficient, the node is the only node with the strongest transmission capacity in the link, and is the potential source with the greatest possibility of causing global imbalance in the entire link. Verify whether bottleneck propagation initiated by a high-risk node can directly or indirectly cover all other nodes in the link. The verification result is either "covers" or "does not cover," specifically including: Identify nodes with high transmission risk and define them as transmission initiation nodes. Simultaneously extract all nodes in the dependency chain to form a complete list of link nodes. Based on the microservice topology graph, starting from the transmission initiation node, and following the unidirectional dependency direction of the microservice business flow, we identify all downstream transmission paths that can be extended when the node initiates bottleneck transmission. The paths only include downstream nodes with direct and indirect dependencies, without tracing back to upstream nodes. All downstream nodes reached by the starting node in the statistically analyzed transmission path are merged to form a node reach set, which includes the transmission starting node itself and all downstream reach nodes. The node reach set is compared with the total list of link nodes: if the node reach set completely includes all nodes in the total list of link nodes, it is directly determined that the high transmission risk node can cover all other nodes in the link; otherwise, it is directly determined that the node cannot be covered. If a high-risk node is verified to be able to cover all other nodes in the link, then the chain-level warning for that dependent chain is directly determined to be triggered; otherwise, the chain-level warning for that dependent chain is directly determined not to be triggered. Upon triggering a chain-level alert, the level is immediately locked, and subsequent dependency-level and basic-level checks will not be performed. If no chain-level alert is triggered, the dependency-level check procedure will proceed, which includes: Retrieve the dependency propagation threshold and the corresponding load propagation impact value of all single-hop links from P to the next directly connected node Q in the current dependency chain. Filter out single-hop links PQ that have not triggered any single-node anomalies. If the load propagation impact value is ≥ the corresponding dependency propagation threshold, it is determined that a dependency-level warning has been triggered, the level is locked, and subsequent judgments are terminated. Otherwise, continue to execute the basic-level judgment. The PQ single-hop link that did not trigger any single-node anomalies refers to the fact that the core resource level indicators of both the upstream node P and the directly connected downstream node Q did not exceed the corresponding indicator thresholds. The specific operation for performing basic-level judgment is as follows: collect the real-time value of the core resource level of each node in the dependency chain. If the real-time value of a certain core resource level indicator of any single node is greater than or equal to the corresponding indicator threshold, then a basic-level warning is triggered; otherwise, the warning is not executed. Based on the triggered warning level, corresponding cloud resource elastic scheduling policies are executed, specifically including: If it is a basic-level early warning, the following scheduling strategy will be executed: For abnormal nodes, vertical scaling up or down will be automatically triggered, and the core resources of the node will be bound to the highest priority, limiting the resource usage ratio of non-core businesses to ≤5%; A basic-level warning indicates that a single node is overloaded or idle, but has not triggered a risk of transmission through the link. In this case, vertical scaling is the best way to break through the bottleneck of a single node. Compared with horizontal scaling, vertical scaling does not require adjusting the load balancing strategy or data synchronization, and can increase the computing power or storage limit of a single node in seconds. Vertical scaling can release redundant resources in time after the node recovers to normal, avoiding waste of cloud resources. If it is a dependency-level warning, the following scheduling strategy will be executed: For upstream node P, its thread pool capacity will be increased to improve request processing capacity; for downstream node Q, the number of instances will be temporarily increased to distribute the load transmitted by node P. The core bottleneck of upstream node P is insufficient request processing concurrency: the thread pool capacity determines the number of requests that the node can process at the same time. Expanding the thread pool can improve the request processing efficiency of P and prevent requests from piling up and being transmitted to Q in batches. The core bottleneck of downstream node Q is insufficient instance carrying capacity: temporarily expanding the number of instances can distribute the load transmitted by P, avoid overloading a single instance, and the temporary expansion can be reduced after the risk is eliminated, thus reducing resource costs. If it is a chain-level alert, the following scheduling strategy will be executed: For the cloud resource cluster where the current dependent chain is located, trigger the global resource pool expansion, increase the resource quota of the chain by 50%, and configure the core hub node in the chain to resource exclusive mode, prohibiting services outside the chain from occupying its resources. In chain-level risks, the resource status of the core hub node directly determines the operational stability of the link. Configuring a resource exclusive mode for it can prevent services outside the link from occupying the core hub node's resources, ensuring that the core hub node's resources are used entirely for the current link. Enable link-level resource isolation to physically isolate the resource pools of the current dependent chain from other unrelated chains, thus preventing the cross-propagation of risks.

[0021] As a third embodiment of this application, this embodiment further discloses a method for calculating the transmission coefficient of node resource bottlenecks based on embodiments one and two, the specific content of which includes: Based on the microservice topology graph, extract two core dimensions of data for the target node: The node's in-degree X and out-degree Y are defined as follows: the node's in-degree X represents the total number of upstream dependent nodes pointing to that node, and the node's out-degree Y represents the total number of downstream dependent nodes pointing to that node. The number of sub-links directly associated with this node, M, and the total number of sub-links N contained in the entire dependency chain; The core degree is calculated as follows: [(X+Y) / (Average in-degree of all nodes in the link + Average out-degree of all nodes in the link)] × (M / N), where [(X+Y) / (Average in-degree of all nodes in the link + Average out-degree of all nodes in the link)] measures the connection density of the target node in the link. A ratio greater than 1 indicates that the number of connections of the target node is higher than the average level of the link. (M / N) measures the coverage of the target node's sub-links in the link. The closer the ratio is to 1, the more complete the sub-links supported by the node. The number M of sub-links directly associated with the node represents the number of all sub-links in the topology graph that are directly bound to the target node and belong to the current entire dependency chain, with the target node as the core. It includes two types of sub-links: ① Sub-links with the target node as the upstream: the target node is the starting end and points to the sub-link formed by its directly connected downstream node; ② Sub-links with the target node as the downstream: the target node is the receiving end and its directly connected upstream node points to the sub-link formed by it. The sub-link is a segment between nodes in the dependency chain, and it is the smallest unit of the entire dependency chain. For example, the complete dependency chain structure is: User order placement service → Order verification service → [Payment service; Inventory deduction service → Logistics generation service]; it can be broken down into sub-links: User order placement service → Order verification service, Order verification service → Payment service, Order verification service → Inventory deduction service, Inventory deduction service → Logistics generation service; therefore, the total number of sub-links N in the entire dependency chain is 4; the number of sub-links M directly associated with the target node's order verification service is 3. Analyze the interaction protocol and intermediate component type between the target node and all downstream directly dependent nodes, record the interaction latency T, and determine whether there are buffer components, such as message queues, caches, and gateways. If they exist, record them as 1; otherwise, record them as 0. The interaction delay T represents the average time from when the upstream request is sent to when the downstream response is received. Calculate the single coupling degree = 1 - (T / D) × K, where D is the average interaction latency of the link, that is, the arithmetic mean of the interaction latency of all sub-links within the single complete microservice dependency chain to be analyzed; K is the buffer component correction factor, which is 1 when it does not exist, and belongs to (0,1) when it exists. Obtaining coupling degree = , where C i W represents the coupling degree between the target node and the i-th downstream node. i Let be the business weight of the i-th downstream node, and ; In a microservice dependency chain, the business importance of downstream nodes varies: the coupling degree of core nodes (such as payment services and inventory deduction services) directly determines the risk of the entire chain, while the coupling degree of non-core nodes (such as log services and monitoring services) has a minimal impact on the chain. Using weighted averages can highlight the coupling characteristics of core nodes and prevent non-core nodes from lowering the coupling degree of core nodes. Computational resource bottleneck transmission coefficient = coreity × coupling degree; The higher the coreness, the closer the node is to the hub in the link, and the stronger its bottleneck transmission capability. This value is the static basis of transmission capability. On the other hand, the higher the coupling, the closer the node is to the downstream, that is, the higher the bottleneck transmission efficiency. This value is the dynamic adjustment of transmission capability.

[0022] Some of the data in the above formulas are numerical calculations with dimensions removed, and the contents not described in detail in this specification are all prior art known to those skilled in the art.

[0023] The above embodiments are only used to illustrate the technical methods 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 methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A dynamic scheduling method for cloud resources based on microservice dependencies, characterized in that, include: S1. Based on the call logs, service registry data and resource monitoring data of the microservice architecture, the explicit call dependencies and implicit data dependencies between microservices are automatically sorted out to generate a complete microservice topology map. Then, each independent dependency chain is decomposed from it, core resource level indicators are configured for the corresponding nodes in each dependency chain, and the resource bottleneck transmission coefficient is calculated. The resource bottleneck transmission coefficient is the product of the node core degree and the coupling degree. S2. Through a distributed monitoring engine, the core resource level indicators and resource bottleneck transmission coefficients of each node in the dependency chain are collected and synchronized in real time, and the impact of changes in the resource status of upstream nodes on the load transmission of downstream nodes is calculated. S3. Based on the core resource level indicators, resource bottleneck transmission coefficients, and load transmission impact values ​​of each node in the dependency chain, a three-level early warning is executed according to priority rules, and the corresponding cloud resource dynamic scheduling strategy is executed according to the triggered early warning level. The three-level early warning is specifically chain-level early warning, dependency-level early warning, and basic-level early warning.

2. The cloud resource dynamic scheduling method based on microservice dependency relationships according to claim 1, characterized in that, The specific steps for constructing a microservice topology graph are as follows: The distributed data acquisition engine captures three types of data in real time: microservice call logs, service registry registration information, and resource monitoring data streams. Based on distributed tracing technology, the collected call logs are correlated and analyzed. By tracing the ID, the complete call chain of a single business request is linked together, and the explicit dependencies of direct calls between microservices are marked. Based on data flow analysis technology, we trace the data transmission path between microservices and mark implicit dependencies between microservices that are not directly called but have data interaction. Clearly define the unidirectional transmission direction and association form of all dependencies. The association form includes synchronous and asynchronous. Synchronous corresponds to explicit dependencies between microservices, and asynchronous corresponds to implicit dependencies between microservices. Using microservice nodes as vertices and identified dependencies as directed edges, a microservice topology graph is constructed using a graph database or graph computing engine, clearly labeling the name, service type, and association form of each directed edge.

3. The cloud resource dynamic scheduling method based on microservice dependencies according to claim 1, characterized in that, The core resource level indicators specifically include CPU utilization, memory usage, thread pool load, interface response latency, and request concurrency.

4. The cloud resource dynamic scheduling method based on microservice dependencies according to claim 1, characterized in that, The specific steps for calculating node coreness are as follows: Based on the microservice topology graph, extract two core dimensions of data for the target node: the node's in-degree X and out-degree Y; the number of sub-links directly associated with the node M; and the total number of sub-links N contained in the entire dependency chain. Calculate the core degree = [(X+Y) / (average in-degree of all nodes in the link + average out-degree of all nodes in the link)] × (M / N), where [(X+Y) / (average in-degree of all nodes in the link + average out-degree of all nodes in the link)].

5. The cloud resource dynamic scheduling method based on microservice dependencies according to claim 1, characterized in that, The specific steps for calculating the coupling degree are as follows: Analyze the interaction protocol and intermediate component type between the target node and all downstream directly dependent nodes, record the interaction latency T, and determine whether there is a buffer component. If there is, record it as 1; otherwise, record it as 0. The interaction delay T represents the average time from when the upstream request is sent to when the downstream response is received. Calculate the single coupling degree = 1 - (T / D) × K, where D is the average interaction delay of the link, and K is the buffer component correction factor, which is 1 when it does not exist and ∈ (0,1) when it exists. Obtaining coupling degree = , where C i W represents the coupling degree between the target node and the i-th downstream node. i Let be the business weight of the i-th downstream node, and .

6. The cloud resource dynamic scheduling method based on microservice dependencies according to claim 1, characterized in that, The calculation of the impact of upstream node resource status changes on load propagation in downstream nodes specifically includes: The core resource type of P is obtained based on the dependency interaction triggering logic between upstream node P and directly connected downstream node Q. The baseline value S of node P for this core resource type was collected. base Current real-time value S now Calculate the magnitude of resource changes Its value range is [0,1], and if it exceeds the range, the boundary value is directly taken; Based on the correlation form of the directed edges P and Q, the conduction attenuation coefficient Assign values: If the directed edge association is synchronous, then Take 1; if the directed edge association is asynchronous, then Take U, where U∈(0,1); Calculate the load transmission impact of P on Q = resource change magnitude × Conduction attenuation coefficient .

7. The cloud resource dynamic scheduling method based on microservice dependencies according to claim 6, characterized in that, Based on the dependency interaction triggering logic between upstream node P and directly connected downstream node Q, the core resource types of P are specifically as follows: if P and Q have a request-call type interaction, then the request concurrency is taken as the core resource type; if P and Q have a computing power processing type interaction, then the CPU utilization rate is taken as the core resource type; if P and Q have a data storage type interaction, then the memory occupancy rate is taken as the core resource type; if P and Q have a task queuing type interaction, then the thread pool load is taken as the core resource type.

8. The cloud resource dynamic scheduling method based on microservice dependencies according to claim 1, characterized in that, The specific steps for executing a Level 3 alert according to priority rules are as follows: The three levels of alerts are prioritized as follows: chain-level alert > dependency-level alert > basic-level alert. Chain-level alerts are executed first, which includes: extracting the resource bottleneck transmission coefficient of all dependent nodes in the dependency chain, defining the node with the largest resource bottleneck transmission coefficient as a high-risk node in the chain; verifying whether the bottleneck transmission initiated by the high-risk node can directly or indirectly cover all other nodes in the chain, with the verification result being either "covers" or "does not"; if the verification result is that it can cover all other nodes in the chain, then the dependency chain is directly determined to have triggered a chain-level alert; otherwise, the dependency chain is directly determined not to have triggered a chain-level alert. Once a chain-level alert is triggered, that level is immediately locked, and subsequent dependency-level and basic-level checks will not be performed. Otherwise, a dependency-level check will be performed, which includes: Retrieve the dependency propagation thresholds and corresponding load propagation impact values ​​for all single-hop links from P to the next directly connected node Q in the current dependency chain. Filter out single-hop links PQ that have not triggered any single-node anomalies. If their load propagation impact value is ≥ the corresponding dependency propagation threshold, a dependency-level warning is triggered, the level is locked, and the basic-level judgment is terminated. Otherwise, perform the basic-level judgment, which includes: Collect real-time values ​​of core resource levels of each node in the dependency chain. If the real-time value of a certain core resource level indicator of any single node is greater than or equal to the corresponding indicator threshold, a basic-level warning is triggered; otherwise, the warning is not executed. The PQ single-hop link that does not trigger any single-node anomalies refers to the fact that the core resource level indicators of both the upstream node P and the directly connected downstream node Q do not exceed the corresponding indicator thresholds.

9. The cloud resource dynamic scheduling method based on microservice dependencies according to claim 8, characterized in that, The specific steps to verify whether bottleneck propagation initiated by a high-risk node can cover all other nodes in the link are as follows: Identify nodes with high transmission risk and define them as transmission initiation nodes. Simultaneously extract all nodes in the dependency chain to form a complete list of link nodes. Based on the microservice topology graph, starting from the transmission initiation node, and following the unidirectional dependency direction of the microservice business flow, we can identify all downstream transmission paths that can be extended when the node initiates bottleneck transmission. All downstream nodes reached by the starting node in the statistically analyzed transmission path are merged to form a node reach set, which includes the transmission starting node itself and all downstream reach nodes. The node reach set is compared with the total list of link nodes: if the node reach set completely includes all nodes in the total list of link nodes, it is directly determined that the high transmission risk node can cover all other nodes in the link; otherwise, it is determined that it cannot be covered.

10. The cloud resource dynamic scheduling method based on microservice dependencies according to claim 1, characterized in that, Based on the triggered warning level, corresponding dynamic cloud resource scheduling strategies are executed, including: If it is a basic-level early warning, the following scheduling strategy will be executed: For abnormal nodes, vertical scaling up or down will be automatically triggered, and the core resources of the node will be bound to the highest priority, limiting the resource usage ratio of non-core businesses to ≤5%; If it is a dependency-level warning, the following scheduling strategy will be executed: For upstream node P, its thread pool capacity will be increased to improve request processing capacity; for downstream node Q, the number of instances will be temporarily increased to distribute the load transmitted by node P. If it is a chain-level alert, the following scheduling strategy will be executed: For the cloud resource cluster where the current dependent chain is located, trigger the global resource pool expansion, increase the resource quota of the link by 50%, configure the core hub node in the link to resource exclusive mode, prohibit services outside the link from occupying its resources, and at the same time, start link-level resource isolation to physically isolate the current dependent chain from the resource pools of other unrelated links.

Images