A micro-service topology-aware container dynamic scheduling method and system

Abstract

The embodiment of the application discloses a kind of based on microservice topology perception's container dynamic scheduling method and system;Method includes: real-time acquisition microservice call data and microservice load data;Based on microservice call data constructs microservice topology graph;Using clustering algorithm, microservice load data is characterized and classified, and microservice clustering feature is obtained;Based on microservice topology graph, microservice cascading load conduction analysis and prediction are carried out, and load variation trend is obtained;Based on microservice topology graph, microservice clustering feature and load variation trend, container dynamic scheduling is carried out, and dynamic scheduling result is obtained.The application has the following advantages: 1, significantly reduce cross-node communication overhead, improve service call success rate;2, improve cluster global utilization rate;3, avoid container mixed department interference, improve microservice running stability;4, can be seamlessly integrated with existing cluster, strong compatibility, low deployment cost, can be widely applied to various microservice container cluster scenarios.

Description

Technical Field

[0001] This invention relates to the fields of cloud-native and DevOps technologies, specifically to a container dynamic scheduling method and system based on microservice topology awareness. Background Technology

[0002] With the rapid development of cloud-native technologies, microservice architecture has become the mainstream architecture pattern for enterprise distributed applications. Container technology, as the core carrier of microservices, directly determines the operating performance, resource utilization, and business service quality of microservice clusters through its scheduling efficiency and rationality. Currently, container scheduling is based on the Kubernetes native scheduler, and various heuristic scheduling and multi-objective scheduling schemes have been derived. These can be broadly classified into three categories: Kubernetes native static rule scheduling, traditional single-objective heuristic scheduling, and preliminary microservice-aware scheduling (only collecting basic resource indicators).

[0003] The core logic of existing container scheduling solutions is "to use a single container as an independent scheduling unit". Based on the container's own CPU and memory resource request values, node allocation is completed in two stages: filtering and scoring. Essentially, it is a resource matching and scheduling solution for isolated containers, and does not deeply integrate the core features of microservice architecture.

[0004] The core flaw in existing technologies is the severe lack of microservice awareness capabilities, specifically manifested in the following three points. These flaws are interconnected, forming a vicious cycle that seriously affects the operational stability and resource utilization efficiency of microservice clusters:

[0005] (1) Lack of microservice dependency topology awareness: Existing scheduling schemes only schedule nodes for individual Pod containers, treating containers as isolated computing units. They fail to parse key information such as call dependencies between microservices, upstream and downstream link topology, service call frequency, and communication traffic volume, and do not build a microservice dependency model. During scheduling, it is easy to scatter and deploy strongly dependent upstream and downstream services to distant nodes. There is no service affinity binding logic, which leads to a surge in cross-node network communication overhead, link cascading delays, and even service call timeouts and service avalanches.

[0006] (2) Insufficient awareness of the differentiated load characteristics of microservices: Microservices have obvious type differences, which can be divided into CPU-intensive (such as computing services), IO-intensive (such as storage / gateway services), network-intensive (such as interface services), and memory-intensive (such as caching services). The load fluctuation patterns, resource bottlenecks, and QoS requirements of different types of microservices are completely different. The existing solution adopts a unified and fixed resource quota and scheduling weight, without distinguishing the dynamic resource requirements of microservice types. The static configuration cannot be adaptively adjusted with changes in business traffic and load, resulting in some service resources being over-provisioned and idle, and some service resources being insufficient and competing for resources, and severe competition for resources among mixed-deployment nodes.

[0007] (3) Lack of awareness of cascading load propagation in microservices: Microservice traffic has significant cascading characteristics, meaning that an increase in traffic to an upstream service (such as a gateway) will directly lead to a synchronous increase in the load of all related downstream services (such as business services and database services). Existing scheduling schemes only monitor the real-time load of a single container and lack global link traffic prediction and cascading load awareness capabilities. They only passively trigger scaling or scheduling after a single service becomes overloaded, resulting in severe lag in scheduling and scaling. After the upstream service is scaled up, the downstream service is still in a bottleneck state, forming a link-level bottleneck. Under sudden traffic surges, this can easily lead to service avalanches and frequent SLA defaults. Summary of the Invention

[0008] In view of the deficiencies of the prior art mentioned in the background, the purpose of this invention is to provide a container dynamic scheduling method and system based on microservice topology awareness.

[0009] To achieve the above objectives, in a first aspect, embodiments of the present invention provide a container dynamic scheduling method based on microservice topology awareness, comprising:

[0010] Real-time collection of microservice call data and microservice load data; the microservice call data includes the call relationship between microservices, call frequency, communication data volume and call latency; the microservice load data includes the CPU utilization, memory utilization, disk I / O throughput, network bandwidth utilization, request concurrency and queue length of each microservice.

[0011] Construct a microservice topology graph based on the microservice call data;

[0012] Clustering algorithms are used to identify and classify the microservice load data to obtain microservice clustering features.

[0013] Based on the microservice topology diagram, perform microservice cascading load transmission analysis and prediction to obtain load change trends;

[0014] Based on the microservice topology, microservice clustering characteristics, and load change trends, container dynamic scheduling is performed to obtain dynamic scheduling results.

[0015] As a specific implementation of this application, constructing a microservice topology graph based on the microservice call data is as follows:

[0016] Construct a microservice topology graph using microservices as nodes and the call relationships between microservices as directed edges.

[0017] As a specific implementation of this application, the microservice clustering features are obtained as follows:

[0018] The CPU utilization, memory utilization, disk I / O throughput, and network bandwidth utilization in the microservice load data are used as clustering indicators.

[0019] Based on the clustering index, the K-means algorithm is used to identify and classify the microservice load data to obtain microservice clustering features; the microservice clustering features include CPU-intensive, IO-intensive, network-intensive, and memory-intensive.

[0020] As a specific implementation of this application, the load change trend is obtained as follows:

[0021] Based on the microservice topology graph, the two microservices corresponding to the directed edges with weights greater than a preset value are identified as a strongly dependent service group.

[0022] Collect historical load data of the highly dependent server group, and calculate the cascading load transmission coefficient λ based on the historical load data;

[0023] The historical load data and LSTM model are used to predict the peak traffic of microservices and obtain the traffic prediction results.

[0024] By combining the transmission coefficient λ and the traffic prediction results, the load change trend of downstream related services is predicted.

[0025] As a specific implementation of this application, the dynamic scheduling result is as follows:

[0026] For service groups with strong dependencies, prioritize scheduling upstream and downstream services to the same node, the same rack, or nearby nodes;

[0027] Based on the aforementioned microservice clustering characteristics, high IO / high network intensive services and CPU intensive services are deployed in an anti-affinity manner;

[0028] Based on the load change trend, the containers of the bottleneck service are scheduled to low-load nodes before the traffic peak arrives.

[0029] As a preferred implementation of this application, after obtaining the dynamic scheduling result, the method further includes feeding back and optimizing the dynamic scheduling result, specifically:

[0030] Real-time collection of current microservice performance metrics after dynamic scheduling and historical microservice performance metrics before dynamic scheduling;

[0031] The current microservice operation metrics are compared with historical microservice operation metrics to obtain the scheduling optimization effect;

[0032] Based on the scheduling optimization effect, the weights of the directed edges in the microservice topology graph are dynamically adjusted.

[0033] Secondly, embodiments of this application also provide a container dynamic scheduling system based on microservice topology awareness, including:

[0034] The data acquisition unit is used to collect microservice call data and microservice load data in real time.

[0035] A topology building unit is used to build a microservice topology graph based on the microservice call data.

[0036] The feature recognition unit is used to perform feature recognition and classification on the microservice load data using a clustering algorithm to obtain microservice clustering features;

[0037] The cascaded load prediction unit is used to perform cascaded load propagation analysis and prediction of microservices based on the microservice topology diagram, and to obtain the load change trend.

[0038] The dynamic scheduling unit is used to dynamically schedule containers based on the microservice topology, microservice clustering characteristics, and load change trends, and obtain dynamic scheduling results.

[0039] As a specific implementation of this application, the microservice load data includes the CPU utilization, memory utilization, disk I / O throughput, network bandwidth utilization, request concurrency, and queue length of each microservice; the feature recognition unit is specifically used for:

[0040] The CPU utilization, memory utilization, disk I / O throughput, and network bandwidth utilization in the microservice load data are used as clustering indicators.

[0041] Based on the clustering index, the K-means algorithm is used to identify and classify the microservice load data to obtain microservice clustering features; the microservice clustering features include CPU-intensive, IO-intensive, network-intensive, and memory-intensive.

[0042] As one specific implementation of this application, the cascaded load prediction unit is specifically used for:

[0043] Based on the microservice topology graph, the two microservices corresponding to the directed edges with weights greater than a preset value are identified as a strongly dependent service group.

[0044] Collect historical load data of the highly dependent server group, and calculate the cascading load transmission coefficient λ based on the historical load data;

[0045] The historical load data and LSTM model are used to predict the peak traffic of microservices and obtain the traffic prediction results.

[0046] By combining the transmission coefficient λ and the traffic prediction results, the load change trend of downstream related services is predicted.

[0047] As one specific implementation of this application, the dynamic scheduling unit is specifically used for:

[0048] For service groups with strong dependencies, prioritize scheduling upstream and downstream services to the same node, the same rack, or nearby nodes;

[0049] Based on the aforementioned microservice clustering characteristics, high IO / high network intensive services and CPU intensive services are deployed in an anti-affinity manner;

[0050] Based on the load change trend, the containers of the bottleneck service are scheduled to low-load nodes before the traffic peak arrives.

[0051] Implementing embodiments of the present invention provides a container dynamic scheduling scheme based on microservice topology awareness, with the following advantages:

[0052] (1) It can realize accurate perception and dynamic modeling of microservice dependency topology. Through strong affinity scheduling, it deploys strongly dependent services nearby, which significantly reduces cross-node communication overhead, reduces link cascading latency, improves service call success rate, and avoids service avalanche.

[0053] (2) It can accurately identify the differentiated load characteristics of microservices, realize the adaptive adjustment of scheduling strategies and resource configuration, avoid resource over-provisioning and idleness and under-provisioning and improve the overall resource utilization of the cluster;

[0054] (3) Perceive the load propagation effect of microservice cascading and combine it with time-series prediction to realize pre-scheduling, solve the scheduling lag problem from the root, effectively cope with sudden traffic, and ensure the stability of microservice SLA;

[0055] (4) Through multi-level affinity scheduling and anti-affinity scheduling, container mixed-location interference is avoided, microservice operation stability is improved, and manual operation and maintenance costs are reduced.

[0056] (5) The system can be seamlessly integrated with existing Kubernetes clusters, with strong compatibility and low deployment cost. It can be widely used in various microservice container cluster scenarios and has strong practicality and promotion value. Attached Figure Description

[0057] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below.

[0058] Figure 1 This is a flowchart of a container dynamic scheduling method based on microservice topology awareness provided in an embodiment of the present invention;

[0059] Figure 2 This is a structural diagram of a container dynamic scheduling system based on microservice topology awareness provided in an embodiment of the present invention. Detailed Implementation

[0060] 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, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0062] Please refer to Figure 1 This invention provides a container dynamic scheduling method based on microservice topology awareness, which may include the following steps:

[0063] S1 collects microservice call data and microservice load data in real time.

[0064] Among them, microservice call data includes, but is not limited to, inter-service call relationships, call frequency, communication data volume, call latency, timeout count, etc.; microservice load data includes CPU utilization, memory utilization, disk I / O, network bandwidth, request concurrency, queue length, etc. of each microservice.

[0065] In this embodiment, an Istio service mesh is deployed in a Kubernetes cluster, injecting a Sidecar proxy into each microservice to collect data such as call relationships, call frequency, communication data volume, and call latency between microservices. Prometheus is deployed, and metric collection rules for nodes, containers, and microservices are configured to collect load data such as CPU, memory, IO, and network, with a collection frequency set to 10 seconds per collection. The data is stored in the Prometheus time-series database, and data visualization is achieved through Grafana.

[0066] S2, construct a microservice topology graph based on the microservice call data.

[0067] In practice, a microservice topology graph is constructed using microservices as nodes and the call relationships between microservices as directed edges.

[0068] The weight of each directed edge. ; f i,j For microservices i arrive j The frequency of calls per unit of time, d i,j For microservices i arrivej Average communication data volume s i,j For microservices i arrive j The call latency, r i,j For microservices i microservices j The strength of dependence, a、b、c、d It is an adaptive weighting factor, and a+b+c+d= 1.

[0069] Furthermore, the microservice topology graph can be updated in real time: when the microservice call relationships and call frequencies change, the existence status and weight values ​​of directed edges are automatically updated to ensure that the dependency topology is consistent with the actual business links. At the same time, based on the dependency graph, strong dependency service groups (service pairs with weight W ≥ 0.7) and weak dependency service groups (weight W < 0.3) are identified to provide a basis for subsequent scheduling.

[0070] For example, using 15 microservices as nodes, directed edges are drawn according to the call relationship, such as: gateway service → user service → order service → payment service → inventory service, forming a complete dependency chain;

[0071] Calculate the weight W of each directed edge and set adaptive weight factors: α=0.3, β=0.3, γ=0.2, δ=0.2. For example, if the call frequency from the gateway service to the user service is 100 times / second, the communication data volume is 10KB / time, the latency sensitivity is 0.8, and the dependency strength is 1.0, then the weight W=0.3×100 + 0.3×10 + 0.2×0.8 + 0.2×1.0=33.36, which is identified as a strongly dependent service group.

[0072] Set weight thresholds: W≥0.7 for strong dependent service groups, W<0.3 for weak dependent service groups, and update the dependency graph in real time (once every 30 seconds).

[0073] S3. A clustering algorithm is used to identify and classify the microservice load data to obtain microservice clustering features.

[0074] In practice, the CPU utilization, memory utilization, disk I / O throughput, and network bandwidth utilization in the microservice load data are used as clustering indicators.

[0075] Based on the clustering index, the K-means algorithm is used to identify and classify the microservice load data to obtain microservice clustering features; the microservice clustering features include CPU-intensive, IO-intensive, network-intensive, and memory-intensive.

[0076] Furthermore, it can record the load fluctuation patterns of various microservices, providing a basis for subsequent resource allocation and scheduling weight adjustments. For example, the gateway service (network-intensive) has a network bandwidth utilization rate of over 80% during peak hours (9:00-12:00, 14:00-18:00) and a utilization rate of less than 20% during off-peak hours (early morning).

[0077] S4. Based on the microservice topology diagram, perform microservice cascading load transmission analysis and prediction to obtain the load change trend.

[0078] In practice, step S4 includes:

[0079] Based on the microservice topology graph, the two microservices corresponding to the directed edges with weights greater than a preset value are identified as a strongly dependent service group.

[0080] Historical load data of the highly dependent server group is collected, and the cascading load propagation coefficient λ is calculated based on the historical load data. This propagation coefficient refers to the proportion by which the load of the downstream service increases for every 10% increase in upstream service traffic; for example, if the gateway service (upstream) traffic increases by 10% and the user service (downstream) load increases by 8%, then the propagation coefficient λ is... 网关,用户 =0.8;

[0081] The historical load data and LSTM model are used to predict the peak traffic of microservices, and the traffic prediction results are obtained. For example, based on the historical traffic data of the past 10 days, it is predicted that a traffic peak will occur in the next 5 minutes, and the gateway service traffic will increase by 50%.

[0082] By combining the transmission coefficient λ and the traffic prediction results, the load change trend of downstream related services can be predicted; for example, if the gateway traffic increases by 50%, the user service load will increase by 40% and the order service load will increase by 32%, thus identifying potential bottlenecks in the order service in advance.

[0083] S5. Based on the microservice topology, microservice clustering characteristics, and load change trends, perform dynamic scheduling of containers to obtain dynamic scheduling results.

[0084] In practice, step S5 includes:

[0085] For highly dependent service groups, prioritize scheduling upstream and downstream services to the same node, the same rack, or nearby nodes (nodes with network latency of less than 5ms) to minimize cross-node communication overhead. If there are many containers in a highly dependent service group, they can be scheduled to the same node group to balance load.

[0086] Based on the microservice clustering characteristics, high IO / high network intensive services and CPU intensive services are deployed in an anti-affinity manner to avoid resource contention on the same node and neighbor interference effects.

[0087] Based on the load change trend, the containers of the bottleneck service are scheduled to low-load nodes before the traffic peak arrives, so as to avoid scheduling afterward.

[0088] S6, Feedback and optimization of the dynamic scheduling results.

[0089] In practice, step S6 includes:

[0090] Real-time collection of current microservice performance metrics after dynamic scheduling and historical microservice performance metrics before dynamic scheduling;

[0091] The current microservice operation metrics are compared with historical microservice operation metrics to obtain the scheduling optimization effect;

[0092] Based on the scheduling optimization effect, the weights of the directed edges in the microservice topology graph are dynamically adjusted.

[0093] For example, before scheduling, when highly dependent services were deployed across nodes, the average link latency was 25ms, the call success rate was 98.2%, and the cluster resource utilization rate was 65%.

[0094] After scheduling: services with strong dependencies are deployed nearby, the average link latency is reduced to 8ms, the call success rate is increased to 99.9%, the cluster resource utilization rate is increased to 82%, and the SLA compliance rate is 100%.

[0095] Based on the comparison results, the dependency graph weight factor was dynamically adjusted, and the weight of network-intensive services was adjusted from 0.3 to 0.4 to further optimize the scheduling effect.

[0096] As can be seen from the above description, the advantages of implementing the microservice topology-aware container dynamic scheduling scheme provided in this embodiment of the invention are as follows:

[0097] (1) It can realize accurate perception and dynamic modeling of microservice dependency topology. Through strong affinity scheduling, it deploys strongly dependent services nearby, which significantly reduces cross-node communication overhead, reduces link cascading latency, improves service call success rate, and avoids service avalanche.

[0098] (2) It can accurately identify the differentiated load characteristics of microservices, realize the adaptive adjustment of scheduling strategies and resource configuration, avoid resource over-provisioning and idleness and under-provisioning and improve the overall resource utilization of the cluster;

[0099] (3) Perceive the load propagation effect of microservice cascading and combine it with time-series prediction to realize pre-scheduling, solve the scheduling lag problem from the root, effectively cope with sudden traffic, and ensure the stability of microservice SLA;

[0100] (4) Through multi-level affinity scheduling and anti-affinity scheduling, container mixed-location interference is avoided, microservice operation stability is improved, and manual operation and maintenance costs are reduced.

[0101] (5) The system can be seamlessly integrated with existing Kubernetes clusters, with strong compatibility and low deployment cost. It can be widely used in various microservice container cluster scenarios and has strong practicality and promotion value.

[0102] Based on the same inventive concept, embodiments of the present invention provide a container dynamic scheduling system based on microservice topology awareness, comprising:

[0103] The data acquisition unit is used to collect microservice call data and microservice load data in real time.

[0104] A topology building unit is used to build a microservice topology graph based on the microservice call data.

[0105] The feature recognition unit is used to perform feature recognition and classification on the microservice load data using a clustering algorithm to obtain microservice clustering features;

[0106] The cascaded load prediction unit is used to perform cascaded load propagation analysis and prediction of microservices based on the microservice topology diagram, and to obtain the load change trend.

[0107] The dynamic scheduling unit is used to dynamically schedule containers based on the microservice topology, microservice clustering characteristics, and load change trends, and obtain dynamic scheduling results.

[0108] An optimization unit is used to provide feedback and optimize the dynamic results.

[0109] In specific implementation, the microservice call data includes the call relationships between microservices, call frequency, communication data volume, and call latency; the topology construction unit is specifically used for:

[0110] Construct a microservice topology graph using microservices as nodes and the call relationships between microservices as directed edges;

[0111] The weight of each directed edge. ;

[0112] f i,j For microservices i arrive j The frequency of calls per unit of time, d i,j For microservices i arrive j Average communication data volume s i,j For microservices i arrive jThe call latency, r i,j For microservices i microservices j The strength of dependence, a、b、c、d It is an adaptive weighting factor, and a+b+c+d= 1.

[0113] In specific implementation, the microservice load data includes the CPU utilization, memory utilization, disk I / O throughput, network bandwidth utilization, request concurrency, and queue length of each microservice; the feature recognition unit is specifically used for:

[0114] The CPU utilization, memory utilization, disk I / O throughput, and network bandwidth utilization in the microservice load data are used as clustering indicators.

[0115] Based on the clustering index, the K-means algorithm is used to identify and classify the microservice load data to obtain microservice clustering features; the microservice clustering features include CPU-intensive, IO-intensive, network-intensive, and memory-intensive.

[0116] In specific implementation, the cascaded load prediction unit is used for:

[0117] Based on the microservice topology graph, the two microservices corresponding to the directed edges with weights greater than a preset value are identified as a strongly dependent service group.

[0118] Collect historical load data of the highly dependent server group, and calculate the cascading load transmission coefficient λ based on the historical load data;

[0119] The historical load data and LSTM model are used to predict the peak traffic of microservices and obtain the traffic prediction results.

[0120] By combining the transmission coefficient λ and the traffic prediction results, the load change trend of downstream related services is predicted.

[0121] In specific implementation, the dynamic scheduling unit is used for:

[0122] For service groups with strong dependencies, prioritize scheduling upstream and downstream services to the same node, the same rack, or nearby nodes;

[0123] Based on the aforementioned microservice clustering characteristics, high IO / high network intensive services and CPU intensive services are deployed in an anti-affinity manner;

[0124] Based on the load change trend, the containers of the bottleneck service are scheduled to low-load nodes before the traffic peak arrives.

[0125] In specific implementation, the optimization unit is used for:

[0126] Real-time collection of current microservice performance metrics after dynamic scheduling and historical microservice performance metrics before dynamic scheduling;

[0127] The current microservice operation metrics are compared with historical microservice operation metrics to obtain the scheduling optimization effect;

[0128] Based on the scheduling optimization effect, the weights of the directed edges in the microservice topology graph are dynamically adjusted.

[0129] It should be noted that the specific workflow of this embodiment is described in the foregoing method embodiment section, and will not be repeated here.

[0130] Furthermore, such as Figure 2 As shown, another embodiment of the present invention also provides a container dynamic scheduling system based on microservice topology awareness, which may include: one or more processors 101, one or more input devices 102, one or more output devices 103, and a memory 104. The processors 101, input devices 102, output devices 103, and memory 104 are interconnected via a bus 105. The memory 104 is used to store a computer program, the computer program including program instructions, and the processor 101 is configured to invoke the program instructions to execute the method described in the above method embodiment.

[0131] It should be understood that, in this embodiment of the invention, the processor 101 may be a central processing unit (CPU), but it may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0132] Input device 102 may include a keyboard, etc., and output device 103 may include a display (LCD, etc.), a speaker, etc.

[0133] The memory 104 may include read-only memory and random access memory, and provides instructions and data to the processor 101. A portion of the memory 104 may also include non-volatile random access memory. For example, the memory 104 may also store device type information.

[0134] In specific implementations, the processor 101, input device 102, and output device 103 described in the embodiments of the present invention can execute the implementation methods described in the embodiments of the container dynamic scheduling method based on microservice topology awareness provided in the embodiments of the present invention, which will not be repeated here.

[0135] Accordingly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, implement the above-described microservice topology-aware container dynamic scheduling method.

[0136] The computer-readable storage medium can be an internal storage unit of the system described in any of the foregoing embodiments, such as the system's hard disk or memory. The computer-readable storage medium can also be an external storage device of the system, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the system. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0137] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0138] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices or units, or may be electrical, mechanical or other forms of connection.

[0139] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0140] Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units can be implemented in hardware or as software functional units. When using each module, user information is collected and stored only with the user's full authorization and in compliance with relevant laws and regulations, protecting the security and privacy of user data, and strictly prohibiting unauthorized access; data processing will be conducted within the scope stipulated by law and will not exceed the purpose and scope authorized by the user; at the same time, users have the rights to access, correct, delete, restrict processing, and refuse their personal data; and must strictly comply with applicable laws and regulations and conduct compliance reviews.

[0141] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0142] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A container dynamic scheduling method based on microservice topology awareness, characterized in that, include: Real-time collection of microservice call data and microservice load data; Construct a microservice topology graph based on the microservice call data; Clustering algorithms are used to identify and classify the microservice load data to obtain microservice clustering features. Based on the microservice topology diagram, perform microservice cascading load transmission analysis and prediction to obtain load change trends; Based on the microservice topology, microservice clustering characteristics, and load change trends, container dynamic scheduling is performed to obtain dynamic scheduling results.

2. The container dynamic scheduling method as described in claim 1, characterized in that, The microservice call data includes the call relationship between microservices, call frequency, communication data volume and call latency; the microservice load data includes the CPU utilization, memory utilization, disk I / O throughput, network bandwidth utilization, request concurrency and queue length of each microservice.

3. The container dynamic scheduling method as described in claim 2, characterized in that, The microservice topology graph is constructed based on the aforementioned microservice call data as follows: Construct a microservice topology graph using microservices as nodes and the call relationships between microservices as directed edges; The weight of each directed edge. ; f i,j For microservices i arrive j The frequency of calls per unit of time, d i,j For microservices i arrive j Average communication data volume s i,j For microservices i arrive j The call latency, r i,j For microservices i microservices j The strength of dependence, α, β, γ, δ It is an adaptive weighting factor, and α+β+γ+δ= 1.

4. The container dynamic scheduling method as described in claim 2, characterized in that, The specific microservice clustering features obtained are as follows: The CPU utilization, memory utilization, disk I / O throughput, and network bandwidth utilization in the microservice load data are used as clustering indicators. Based on the clustering index, the K-means algorithm is used to identify and classify the microservice load data to obtain microservice clustering features; The microservice clustering characteristics include CPU-intensive, I / O-intensive, network-intensive, and memory-intensive.

5. The container dynamic scheduling method as described in claim 3, characterized in that, The specific load change trend is as follows: Based on the microservice topology graph, the two microservices corresponding to the directed edges with weights greater than a preset value are identified as a strongly dependent service group. Collect historical load data of the highly dependent server group, and calculate the cascading load transmission coefficient λ based on the historical load data; The historical load data and LSTM model are used to predict the peak traffic of microservices and obtain the traffic prediction results. By combining the transmission coefficient λ and the traffic prediction results, the load change trend of downstream related services is predicted.

6. The container dynamic scheduling method as described in claim 5, characterized in that, The specific results of the dynamic scheduling are as follows: For service groups with strong dependencies, prioritize scheduling upstream and downstream services to the same node, the same rack, or nearby nodes; Based on the aforementioned microservice clustering characteristics, high IO / high network intensive services and CPU intensive services are deployed in an anti-affinity manner; Based on the load change trend, the containers of the bottleneck service are scheduled to low-load nodes before the traffic peak arrives.

7. The container dynamic scheduling method according to any one of claims 1-6, characterized in that, After obtaining the dynamic scheduling result, the method further includes feeding back and optimizing the dynamic scheduling result, specifically: Real-time collection of current microservice performance metrics after dynamic scheduling and historical microservice performance metrics before dynamic scheduling; The current microservice operation metrics are compared with historical microservice operation metrics to obtain the scheduling optimization effect; Based on the scheduling optimization effect, the weights of the directed edges in the microservice topology graph are dynamically adjusted.

8. A container dynamic scheduling system based on microservice topology awareness, characterized in that, include: The data acquisition unit is used to collect microservice call data and microservice load data in real time. A topology building unit is used to build a microservice topology graph based on the microservice call data. The feature recognition unit is used to perform feature recognition and classification on the microservice load data using a clustering algorithm to obtain microservice clustering features; The cascaded load prediction unit is used to perform cascaded load propagation analysis and prediction of microservices based on the microservice topology diagram, and to obtain the load change trend. The dynamic scheduling unit is used to dynamically schedule containers based on the microservice topology, microservice clustering characteristics, and load change trends, and obtain dynamic scheduling results.

9. The container dynamic scheduling system as described in claim 8, characterized in that, The microservice call data includes the call relationships between microservices, call frequency, communication data volume, and call latency; the topology construction unit is specifically used for: Construct a microservice topology graph using microservices as nodes and the call relationships between microservices as directed edges; The weight of each directed edge. ; f i,j For microservices i arrive j The frequency of calls per unit of time, d i,j For microservices i arrive j Average communication data volume s i,j For microservices i arrive j The call latency, r i,j For microservices i microservices j The strength of dependence, α, β, γ, δ It is an adaptive weighting factor, and α+β+γ+δ= 1.

10. The container dynamic scheduling system as described in claim 8, characterized in that, The microservice load data includes the CPU utilization, memory usage, disk I / O throughput, network bandwidth utilization, request concurrency, and queue length of each microservice; the feature recognition unit is specifically used for: The CPU utilization, memory utilization, disk I / O throughput, and network bandwidth utilization in the microservice load data are used as clustering indicators. Based on the clustering index, the K-means algorithm is used to identify and classify the microservice load data to obtain microservice clustering features; The microservice clustering characteristics include CPU-intensive, I / O-intensive, network-intensive, and memory-intensive.

11. The container dynamic scheduling system as described in any one of claims 8-10, characterized in that, The cascaded load prediction unit is specifically used for: Based on the microservice topology graph, the two microservices corresponding to the directed edges with weights greater than a preset value are identified as a strongly dependent service group. Collect historical load data of the highly dependent server group, and calculate the cascading load transmission coefficient λ based on the historical load data; The historical load data and LSTM model are used to predict the peak traffic of microservices and obtain the traffic prediction results. By combining the transmission coefficient λ and the traffic prediction results, the load change trend of downstream related services is predicted.

12. The container dynamic scheduling system as described in claim 11, characterized in that, The dynamic scheduling unit is specifically used for: For service groups with strong dependencies, prioritize scheduling upstream and downstream services to the same node, the same rack, or nearby nodes; Based on the aforementioned microservice clustering characteristics, high IO / high network intensive services and CPU intensive services are deployed in an anti-affinity manner; Based on the load change trend, the containers of the bottleneck service are scheduled to low-load nodes before the traffic peak arrives.

Images