Micro-service scheduling method, system and device and readable storage medium

Abstract

The invention provides a micro-service scheduling method, system and device and a readable storage medium. The method specifically comprises the following steps: collecting communication flow among micro-services, and constructing a micro-service topological graph; generating a plurality of micro-service chains based on the micro-service topological graph, wherein each micro-service chain takes the entrance micro-service as a starting point and comprises a complete calling path in one micro-service topological graph; based on a preset reinforcement learning model, an optimal micro-service chain deployment strategy is generated, the micro-service chain deployment strategy comprises the optimal edge node for deploying each micro-service chain, and a reward value of the reinforcement learning model is configured to be a linear combination of cross-machine communication overhead when different deployment strategies are applied and resource utilization rate after the micro-service chains are deployed. Compared with the prior art, the method has the advantages that the application topology is decomposed into a plurality of complete calling paths by dividing the micro-service chains, so that the micro-service chains of the same request are distributed on the same node, the cross-machine flow is reduced fundamentally, and load balancing and improvement of the resource utilization rate are realized.

Description

Technical Field

[0001] This invention belongs to the field of edge computing technology, specifically relating to a microservice scheduling method, system, device, and readable storage medium. Background Technology

[0002] With the rapid development of IoT and 5G technologies, edge computing, as an emerging computing paradigm, effectively solves the high latency problem caused by cloud processing by pushing cloud computing capabilities to the network edge. Meanwhile, microservice architecture, with its fine-grained, modular, and independently deployable characteristics, is widely used in edge computing environments.

[0003] Edge cloud environments are characterized by significant heterogeneity and dynamism. First, heterogeneity manifests in the substantial differences in computing power, storage resources, and network conditions among edge nodes, while user access habits also vary across different geographical regions. Second, dynamism is reflected in the fluctuations in user request patterns over time and the constantly changing network latency between nodes, making it difficult for static microservice deployment strategies to maintain high-quality service.

[0004] However, existing technologies still have problems such as not fully considering the geographical distribution characteristics of edge nodes, resulting in large cross-node communication overhead; lack of effective adaptation mechanisms to the dynamics of the edge environment; often ignoring other key service quality factors when optimizing a single indicator; and static deployment strategies being difficult to adapt to the continuous changes in the edge environment, leading to a decline in service quality.

[0005] Therefore, to address the aforementioned technical issues, it is necessary to provide a microservice scheduling method, system, device, and readable storage medium.

[0006] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0007] The purpose of this invention is to provide a microservice scheduling method, system, device, and readable storage medium, which are used to reduce cross-node traffic and improve service performance in edge scenarios.

[0008] To achieve the above objectives, a specific embodiment of the present invention provides the following technical solution:

[0009] In a first aspect, the present invention provides a microservice scheduling method, comprising:

[0010] Collect communication traffic between various microservices and construct a microservice topology graph;

[0011] Multiple microservice chains are generated based on the microservice topology graph. Each microservice chain starts from the entry microservice and contains a complete call path in the microservice topology graph.

[0012] Based on a preset reinforcement learning model, an optimal microservice chain deployment strategy is generated. The microservice chain deployment strategy includes deploying the optimal edge node for each microservice chain. The reward value of the reinforcement learning model is configured as a linear combination of the cross-machine communication overhead when applying different deployment strategies and the resource utilization rate after deploying the microservice chain.

[0013] In one or more embodiments of the present invention, multiple microservice chains are generated based on the microservice topology graph, including:

[0014] Starting from each entry microservice, recursively visit adjacent microservice nodes, following the call relationship path until reaching the terminated microservice that no longer calls other microservices;

[0015] Extract each complete call path from the entry microservice to the termination microservice as a microservice chain;

[0016] If, during the traversal process, different upstream microservices call the same downstream microservice, then the downstream microservice is shared by multiple microservice chains, and the microservices with shared relationships are marked in the formed microservice chains.

[0017] In one or more embodiments of the present invention, the method further includes:

[0018] Monitor the performance metrics of each edge node and determine whether the value of each performance metric falls within a preset threshold range; the performance metrics include the request frequency, response latency, and P98 data of each request for the corresponding edge node.

[0019] If not, then the microservice chain deployment strategy is re-obtained based on the reinforcement learning model, and rescheduling is triggered for microservice chains whose deployment strategies have changed.

[0020] In response to the rescheduling instruction, the microservice chains that need to be rescheduled are grouped according to their respective requests. Within each group, the microservice chains are sorted according to their interruption time. The rescheduling decision with the shortest interruption time is removed in turn until a rescheduling strategy with an estimated cost lower than the preset upper limit is output.

[0021] In one or more embodiments of the present invention, the method further includes:

[0022] Construct a reinforcement learning model and initialize the experience replay buffer, target network, and policy network;

[0023] Update network latency and request frequency parameters, execute the microservice chain deployment strategy, and calculate the reward value;

[0024] At preset intervals, the parameters of the reinforcement learning model are updated based on the deployment strategy and the corresponding reward value.

[0025] In one or more embodiments of the present invention, the calculation formula for the cross-machine communication overhead is as follows:

[0026]

[0027]

[0028] Among them, let As an indicator variable, when the microservice chain Deployed in base stations The value is 1 if it is true, and 0 otherwise. Represents edge nodes and The distance between them; For signal propagation speed, for Uplink bandwidth, For the chain Ingress microservices and downstream microservices The amount of data transmitted in a single communication between them; Indicates the request type At the edge node The number of requests per second.

[0029] In one or more embodiments of the present invention, the formula for calculating the resource utilization rate is as follows:

[0030]

[0031] Among them, point Upper The total amount of this type of resource is For any microservice Its impact on the first The demand for such resources is ;

[0032] In one or more embodiments of the present invention, the reward value for the microservice chain deployed on the first edge node is:

[0033]

[0034]

[0035]

[0036] in, , For preset weight values, For cross-machine communication overhead; The load pressure on the node. It is a constant greater than 1.

[0037] Secondly, the present invention provides a microservice scheduling system, comprising:

[0038] The module is used to collect communication traffic between various microservices and build a microservice topology graph;

[0039] The generation module is used to generate multiple microservice chains based on the microservice topology graph. Each microservice chain starts from the entry microservice and contains a complete call path in the microservice topology graph.

[0040] The deployment module is used to generate an optimal microservice chain deployment strategy based on a preset reinforcement learning model. The microservice chain deployment strategy includes deploying the optimal edge node for each microservice chain. The reward value of the reinforcement learning model is configured as a linear combination of the cross-machine communication overhead when applying different deployment strategies and the resource utilization rate after deploying the microservice chain.

[0041] Thirdly, the present invention provides a computer device comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the microservice scheduling method by executing the computer instructions.

[0042] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the microservice scheduling method described above.

[0043] Compared with existing technologies, the microservice scheduling method provided by this invention decomposes the application topology into multiple complete call paths by dividing the microservice chain, so that the microservice chains of the same request are distributed on the same node as much as possible, which fundamentally reduces cross-machine traffic. At the same time, the reward function jointly optimizes traffic and node pressure, thereby achieving load balancing and improved resource utilization. In addition, through a service quality-sensitive dynamic rescheduling mechanism, the system can periodically monitor indicators such as P98 latency and trigger minimum overhead redeployment, so that the solution can continuously adapt to the dynamic changes of the edge environment, significantly improving the stability of service quality and operational efficiency. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is a schematic diagram illustrating an implementation scenario of the microservice scheduling method in one embodiment of the present invention;

[0046] Figure 2 This is a flowchart of a microservice scheduling method in one embodiment of the present invention;

[0047] Figure 3 This is a structural block diagram of a microservice scheduling system according to another embodiment of the present invention;

[0048] Figure 4 This is a structural block diagram of an electronic device according to one embodiment of the present invention;

[0049] Figure 5 This is a schematic diagram of a microservice topology in a specific embodiment of the present invention;

[0050] Figure 6 This is a schematic diagram of microservice chain partitioning in a specific embodiment of the present invention;

[0051] Figure 7 This is a schematic diagram of the microservice scheduling algorithm based on Dueling DQN in one embodiment of the present invention. Detailed Implementation

[0052] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0053] Unless otherwise expressly stated, throughout the specification and claims, the term "comprising" or its variations such as "including" or "comprises" shall be understood to include the stated elements or components without excluding other elements or other components.

[0054] Please refer to Figure 1The diagram shows an application scenario of the microservice scheduling method provided by the present invention under one embodiment. The scenario specifically includes: a service registration center 101, a microservice chain partitioning module 102, a microservice chain scheduling module 103, and a service quality sensitive dynamic microservice chain scheduling module 104.

[0055] It should be noted that communication connections are established between the service registration center 101, the microservice chain partitioning module 102, the microservice chain scheduling module 103, and the service quality-sensitive dynamic microservice chain scheduling module 104. The communication network derived from the above communication connections can include various connection types, including but not limited to: wired connections, wireless connections, or fiber optic cable connections, etc. Furthermore, this communication network can be a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), or any combination of the three.

[0056] Specifically, the service registry 101 is used to receive complete service component information submitted by application providers. The service component information may include at least: (1) a unique identification code representing the application identity; (2) a structural diagram indicating the association method and startup order of each internal functional module; and (3) a set of files and parameter configuration instructions required for program operation. After receiving the data package, the service registry 101 can perform integrity verification on the data package, and then automatically push the updated configuration information to all associated computing nodes in real time through the intelligent scheduling system, ensuring that server groups in different regions can obtain the latest service information in a timely manner.

[0057] The core idea of ​​the microservice partitioning module 102 is to divide the application into multiple microservice chains based on the application's request type to support microservice scheduling. The microservice partitioning module 102 consists of two parts: first, it collects the application's internal communication topology in real time based on traffic probes; then, it traverses and partitions the application architecture to generate multiple microservice chains. Each microservice chain has its own memory usage and CPU time slice usage information, and adjacent nodes in the microservice chain have data volume information.

[0058] The microservice chain scheduling module 103 is the core module of this invention. This module schedules each microservice chain obtained by the microservice chain partitioning module, using the microservice chain as the smallest unit of scheduling. It finds the most suitable deployment server for each microservice chain, fundamentally solving cross-machine traffic between microservices and thus improving the overall service quality of the application. In an exemplary embodiment, this module can define the microservice chain scheduling problem as a Markov decision process and solve the Markov decision process based on the Dueling DQN reinforcement learning algorithm.

[0059] The service quality-sensitive dynamic microservice chain scheduling module 104 is used to implement three functions, including environmental information monitoring, rescheduling, and minimizing deployment overhead. By dynamically monitoring the environmental status information of the edge cloud, it aims to improve service quality through microservice chain redeployment while minimizing redeployment overhead.

[0060] It should be noted that the present invention can also be configured with a user terminal, which can provide users with custom parameters required to implement the microservice scheduling method of the present invention. Furthermore, the user terminal can be equipped with computer software programs that match the microservice scheduling method provided by this invention; the user terminal can be, but is not limited to, portable electronic devices or wearable electronic devices such as desktop computers (PCs), smartphones, handheld computers, tablet computers, personal digital assistants (PDAs), etc., and the embodiments of the present invention do not impose any limitations on the above.

[0061] It should also be noted that the microservice scheduling method of this embodiment can be applied to the microservice scheduling system of this embodiment. This microservice scheduling system can be configured on a terminal. The terminal can include, but is not limited to, PCs (Personal Computers), PDAs (Tablet Computers), smartphones, smart wearable devices, etc.

[0062] Please refer to Figure 2 The diagram shown illustrates a microservice scheduling process according to an embodiment of the present invention. This microservice scheduling method specifically includes the following steps:

[0063] S201: Collect communication traffic between various microservices and construct a microservice topology diagram;

[0064] In this invention, microservices, as a core architectural concept, refer to a software architecture style that breaks down a monolithic application into a series of small, loosely coupled, and functionally independent service units. Each microservice carries specific business capabilities, manifested as a fine-grained functional module, and enjoys its own independent process space. This independence allows each microservice to be developed, deployed, elastically scaled, and its technology stack selected and maintained independently. In the edge cloud scenario focused on by this invention, microservices constitute the basic functional units and scheduling entities for application deployment and operation.

[0065] It is important to note that in edge computing environments, the independence and lightweight nature of microservices allow them to be flexibly and distributed across heterogeneous edge computing nodes, fully leveraging the differences and diversity in computing power, storage resources, and geographical location within edge infrastructure. Each microservice explicitly defines its runtime resource requirements in its deployment description; key metrics typically include, but are not limited to, CPU time slice usage and memory usage. These resource requirements are the fundamental basis for precise scheduling and resource allocation.

[0066] Furthermore, the communication traffic in this invention can refer to the total amount of network data transmitted between microservice instances during application operation to complete business collaboration. It is a multi-dimensional quantitative concept, specifically including but not limited to: call frequency, data payload, and network latency. Call frequency refers to the number of requests between microservices per unit time; data payload refers to the actual amount of data transmitted during each call, including request parameters, response results, and additional overhead from serialization / deserialization; network latency refers to the network transmission time from when a request is sent to when a response is received.

[0067] By continuously collecting and monitoring the communication traffic between the aforementioned microservices, the system can accurately depict and reveal the dynamic and actual mutual calling relationships and data interaction patterns of each microservice during runtime. Based on this calling relationship network and its interaction characteristics formed among all microservices in the application, an abstract graph structure model can be constructed, namely the microservice topology graph described in this invention.

[0068] This topology graph is essentially a highly visual abstraction of the entire complex application architecture and its runtime behavior. In the graph, nodes represent individual microservice instances, and their weights indicate the resource consumption of that service (e.g., CPU, memory). Directed edges represent the call dependencies between microservices, and edge weights can be quantified using metrics such as normalized average communication traffic, call latency, or frequency. This topology can be formally expressed using mathematical models such as adjacency matrices or probabilistic graphs, or it can be intuitively displayed through a graphical interface. Specific embodiments of this invention do not limit the implementation method. This microservice topology graph provides a crucial data foundation and structural input for subsequent microservice chain partitioning and intelligent scheduling decisions.

[0069] In one exemplary implementation, the system can integrate existing distributed link traffic detection tools, such as a Service Mesh-based Sidecar proxy or an APM application performance monitoring probe. By periodically monitoring the network interactions between microservices in a monolithic deployment mode, communication traffic data is collected. Through aggregation and statistical analysis of this data, the system can calculate the average communication traffic between any two microservices and construct a digital application topology matrix based on this.

[0070] In this application topology matrix, each row and column index corresponds to a microservice, and the directed edges in the matrix represent the calling relationships between microservices. The edge weights are normalized results of the average communication traffic between corresponding microservice pairs, which helps eliminate differences in units and facilitates subsequent quantitative analysis and comparison. Meanwhile, the nodes in the matrix represent individual microservice entities, and each node is accompanied by corresponding weight information. These weights describe the key resource requirements of the microservice during runtime, mainly including runtime memory usage and CPU time slice utilization. Constructing this application topology matrix based on real-time traffic data provides an accurate and quantitative data foundation for subsequent automatic microservice chain partitioning and resource-aware scheduling decisions.

[0071] S202: Generate multiple microservice chains based on the microservice topology graph, each microservice chain starting from the entry microservice and containing a complete call path in the microservice topology graph;

[0072] In one embodiment of the present invention, a microservice chain can be defined as an ordered set of microservices with continuous call relationships, where each chain represents the execution path of a complete business request in the system. The microservice topology of the entire application can be regarded as the union of these microservice chains, with each chain representing a connected subgraph in the topology.

[0073] Based on the above definition, the process of generating multiple microservice chains according to the microservice topology graph can specifically include the following steps: starting from each entry microservice, a recursive algorithm is used to visit the downstream microservice nodes that it directly calls in the topology graph layer by layer. This process continues along the path formed by the call relationships until a terminating microservice is reached that no longer calls other microservices. The system will extract each complete call path from the entry microservice to the terminating microservice and formally define it as an independent microservice chain. The entry microservice can be the initial service that receives external requests.

[0074] For ease of understanding, such as Figure 5The diagram shown in the specific embodiment illustrates a microservice topology, illustrating an application instance containing 17 microservices. The application's sole entry point microservice is named "Frontend." Using the above partitioning method, the entire application is precisely decomposed into 9 independent microservice chains, such as... Figure 6 As shown. It's worth noting that the starting node of each microservice chain is a "frontend" service; simultaneously, because the microservice "lookup" is depended on by multiple upstream paths, it appears in three different microservice chains, specifically including:

[0075] Chain 1: "Frontend" → "Search" → "Geographic Location" → "Geographic Location Database"

[0076] Chain 2: "Frontend" → "Search" → "Rate" → "Rate Database"

[0077] Chain 3: "Frontend" → "Lookup" → "Speed" → "Speed ​​Cache"

[0078] Understandably, to ensure the integrity of each microservice chain in terms of business logic and scheduling, its head node can be the application's entry microservice. When multiple upstream microservices in the system call the same downstream microservice, i.e., when there is a shared dependency, that downstream microservice will appear in multiple microservice chains simultaneously. From another perspective, the microservice sharing mechanism means that a specific downstream microservice can be referenced by multiple microservice chains. During chain generation, the system will specially mark such microservices with shared relationships to provide crucial information for subsequent deployment optimization.

[0079] S203: Generate the optimal microservice chain deployment strategy based on a pre-set reinforcement learning model;

[0080] It's important to note that the significant latency issue in edge service response times in existing technologies stems from the inherent resource constraints of edge computing architectures. Specifically, individual edge nodes face significant limitations in computing power, storage capacity, and other resources, typically insufficient to support all service components of a complete application. Therefore, in practice, applications are usually deployed in a distributed manner across an edge cloud environment comprised of multiple edge nodes. While this distributed architecture addresses the resource shortage problem, it introduces new performance bottlenecks: when a business request requires calls to multiple microservices, if these services are deployed on different nodes, cross-node remote calls inevitably occur during request processing. Since edge network environments generally suffer from bandwidth limitations, high latency fluctuations, and poor stability, and the volume of data exchanged between microservices is often substantial, the network transmission latency generated by this cross-node communication becomes significant, thus becoming a major component of the overall request response latency.

[0081] To fundamentally alleviate the aforementioned problems, this invention aims to centrally deploy microservices belonging to the same microservice chain on the same edge node as much as possible. This deployment strategy aims to transform inter-service calls into intra-node communication, thereby minimizing dependence on edge links and reducing latency introduced by network transmission. To scientifically evaluate and guide this deployment process, this invention further trains a reinforcement learning model based on reward values ​​to generate the optimal deployment strategy. This reward value comprehensively represents the immediate system benefits generated after deploying a microservice chain to a specific edge node, and its calculation incorporates multiple key performance indicators, such as the degree of reduction in cross-node traffic and the optimization of node resource utilization. Through this quantifiable feedback mechanism, the system can construct a targeted and sensitive deployment strategy and continuously optimize and dynamically adjust the deployment scheme during actual scheduling.

[0082] That is, before performing actual microservice scheduling, the process includes building a reinforcement learning model and initializing the parameters of the reinforcement learning model; updating network latency and request frequency parameters based on a preset training dataset, executing the microservice chain deployment strategy in the preset training dataset and calculating the reward value; and updating the parameters of the reinforcement learning model every preset interval based on the deployment strategy and the corresponding reward value.

[0083] Specifically, the microservice chain deployment strategy includes deploying the optimal edge node for each microservice chain; the reward value of the reinforcement learning model is configured as a linear combination of the cross-machine communication overhead when applying different deployment strategies and the resource utilization after deploying the microservice chain. Communication overhead may include request transmission latency and request propagation latency. Propagation latency is determined by the link distance and the signal propagation speed on the link, while transmission latency is determined by network bandwidth and the amount of data transmitted. When upstream and downstream microservices in the call chain are located on the same edge node, this invention ignores their propagation latency and transmission latency.

[0084] In one embodiment, the formula for calculating the cross-machine communication overhead can be:

[0085]

[0086]

[0087] Among them, let As an indicator variable, when the microservice chain Deployed in base stations The value is 1 if it is true, and 0 otherwise. Represents edge nodes and The distance between them; For signal propagation speed, for Uplink bandwidth, For the chain Ingress microservices and downstream microservices The amount of data transmitted in a single communication between them; Indicates the request type At the edge node The number of requests per second.

[0088] It should also be noted that node pressure is reflected in the utilization of various resources on that node. When deploying microservices, it is necessary to ensure that the pressure on all nodes is consistent. When the pressure on a node is too high, the service performance on that node will degrade. Each node has multiple types of resources, and each microservice has multiple resource requests. Based on this, the formula for calculating resource utilization can be:

[0089]

[0090] Among them, point Upper The total amount of this type of resource is For any microservice Its impact on the first The demand for such resources is ;

[0091] The reward value for the microservice chain deployed on the first edge node can be:

[0092]

[0093]

[0094]

[0095] in, , For preset weight values, For cross-machine communication overhead; This represents the load pressure on the node.

[0096] As mentioned above, the reward value serves as a quantitative guide for system optimization, precisely representing the immediate performance gains obtained after executing a specific deployment action. Based on this mechanism, the system can adjust model parameters according to the reward value and the corresponding deployment plan, thereby achieving joint optimization of cross-node traffic and resource load.

[0097] Specifically, the model training of this invention may include: In each training iteration, the system first simulates the dynamic changes of the edge cloud environment, that is, updates the network latency between nodes and the frequency of user requests in each region, and constructs an initial environment state accordingly. Subsequently, the model performs sequential decision-making in units of a complete application deployment cycle: starting from the initial state, it sequentially selects deployment nodes for each microservice chain to be scheduled, until all chains have completed deployment arrangements. Since the global value of a single deployment can only be accurately evaluated after the entire application deployment is completed, at the end of the entire iteration, the system will calculate the overall reward value of this round based on the cross-node traffic and node load balancing generated by the final deployment scheme through a preset multi-objective reward function, and back-allocate this reward to each specific deployment step in this iteration.

[0098] During training, the algorithm periodically extracts a batch of historical state transition data from the experience replay buffer, i.e., the record of state-action-reward-new state. It updates the parameters of the policy network by calculating the temporal difference error between the predicted Q value and the target Q value and minimizing this error. At the same time, by periodically synchronizing the policy network parameters to the target network, the stability of the training process is ensured. Ultimately, the model learns to make optimal scheduling decisions that can simultaneously optimize network traffic and resource load in dynamic and complex edge environments.

[0099] To further enhance the adaptability and intelligence of the scheduling strategy, in one embodiment of the present invention, taking DuelingDQN as an example, specifically as follows: Figure 7 The diagram illustrates the microservice scheduling algorithm based on Dueling DQN, illustrating the training process of the scheduling model. The training process includes the following steps: First, initializing the key components required for training, including the Transition Buffer, Target Network, and Policy Network. At the beginning of each training iteration, dynamically simulating real-time changes in the edge environment, updating parameters such as network latency and request frequency of each node, and initializing the environment state accordingly. At the end of the entire iteration, the system uniformly calculates the overall reward value for that round and inversely distributes this reward value to each decision step in the current iteration as a feedback signal for its temporal difference learning. During the algorithm iteration process, the parameter update frequency is set: after each C-step decision, a batch of historical state transition data is randomly sampled from the Transition Buffer to update the parameters θ of the Policy Network; subsequently, the Policy Network parameters are periodically synchronized to the Target Network to update its parameters θ. - This is to enhance training stability.

[0100] After training the Dueling DQN model, the resulting model parameter file is deployed to the central master server. The master server loads this parameter file upon startup to build a runtime model usable for inference. Each time the microservice scheduling module is invoked, the system collects real-time environmental data, including request frequency, resource utilization, and network latency between nodes, and inputs this data into the model. The microservice scheduling module encapsulates and parses the deployment actions output by the model, generating executable microservice scheduling decisions. Finally, the master server broadcasts the scheduling results to all relevant nodes in the edge cloud, enabling unified dynamic deployment and adjustment of services.

[0101] It's important to note that during the final resource scheduling and deployment phase, when multiple microservice chains are scheduled to the same physical node, and these chains contain the same microservice, the system will perform a microservice merging operation. This means that only one instance of the microservice will be deployed on that node for all related chains to share. This mechanism effectively avoids the problem of redundant microservice replicas on the same node, significantly saving computing resources and reducing runtime complexity and memory overhead.

[0102] It should be further noted that edge cloud environments exhibit significant dynamic characteristics. For example, network latency between nodes fluctuates due to link load or topology changes, and the frequency of user requests to various services also changes dynamically over time. These continuously changing environmental factors may cause the original static deployment strategy to gradually become ineffective, leading to problems such as increased service response latency and overall performance degradation. To address this challenge, in an exemplary embodiment of the present invention, the system is specifically configured with an intelligent redeployment mechanism. The specific workflow of this mechanism is as follows:

[0103] Upon system startup, the dynamic microservice chain scheduling module is automatically activated and continuously monitors key runtime metrics of each edge node, including request frequency, network latency, and the P98 response time for each request. P98 represents the 98th percentile, indicating that 98% of request response times are below this value, effectively reflecting long-tail latency. The system iterates through all P98 data, comparing each value with a user-defined threshold. If any P98 value exceeds the set threshold, the microservice chain scheduling module is triggered to recalculate. This module integrates the current request frequency and network latency status to output an optimal scheduling scheme adapted to the new environment.

[0104] The system then compares the new scheduling scheme with the existing scheme in actual operation. If they match, the current deployment is still optimal and no redeployment is needed; if there are differences, a deployment overhead minimization process is initiated to minimize the service interruption caused by redeployment.

[0105] The deployment cost minimization technique first estimates the total deployment cost of executing all rescheduling decisions, with average service downtime as the core metric. If the estimated cost is below a set threshold, the rescheduling solution is directly adopted; if it exceeds the threshold, an optimization process is initiated: the system groups the microservice chains to be rescheduled according to their request types, and within each group, they are sorted in ascending order based on the estimated service downtime of each chain. Then, based on a greedy strategy, the rescheduling decision that causes the least service downtime is sequentially removed from each group. Each removal recalculates the total deployment cost of the remaining decisions until the total cost falls below the threshold. This process effectively controls redeployment costs while ensuring service quality.

[0106] This rescheduling module continuously senses the environmental status and dynamically triggers the redeployment of the microservice chain. This not only effectively improves the system's adaptability to dynamic changes in the edge environment, but also achieves an important balance between optimizing service performance and ensuring service continuity by introducing a deployment overhead minimization mechanism.

[0107] Please refer to Figure 3 As shown, based on the same inventive concept as the aforementioned microservice scheduling method, one embodiment of the present invention provides a microservice scheduling system 300, including: a construction module 301, a generation module 302, and a deployment module 303.

[0108] Specifically, module 301 is used to collect communication traffic between various microservices and construct a microservice topology diagram;

[0109] The generation module 302 is used to generate multiple microservice chains based on the microservice topology graph. Each microservice chain starts from the entry microservice and contains a complete call path in the microservice topology graph.

[0110] The deployment module 303 is used to generate an optimal microservice chain deployment strategy based on a preset reinforcement learning model. The microservice chain deployment strategy includes deploying the optimal edge node for each microservice chain. The reward value of the reinforcement learning model is configured as a linear combination of the cross-machine communication overhead when applying different deployment strategies and the resource utilization rate after deploying the microservice chain.

[0111] Please refer to Figure 4As shown, embodiments of the present invention also provide an electronic device 400, which includes at least one processor 401, a memory 402 (e.g., non-volatile memory), a memory 403, and a communication interface 404, wherein the at least one processor 401, the memory 402, the memory 403, and the communication interface 404 are connected together via an internal bus 405. The at least one processor 401 is used to invoke at least one program instruction stored or encoded in the memory 402, causing the at least one processor 401 to perform various operations and functions of the microservice scheduling methods described in the various embodiments of this specification.

[0112] In the embodiments of this specification, electronic device 400 may include, but is not limited to: personal computer, server computer, workstation, desktop computer, laptop computer, notebook computer, mobile electronic device, smartphone, tablet computer, cellular phone, personal digital assistant (PDA), handheld device, messaging device, wearable electronic device, consumer electronic device, etc.

[0113] This invention also provides a computer-readable medium carrying computer-executable instructions. When executed by a processor, these instructions can be used to implement various operations and functions of the microservice scheduling methods described in the various embodiments of this specification.

[0114] The computer-readable medium in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0115] In this invention, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wireline, optical fiber, RF, etc., or any suitable combination thereof.

[0116] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0117] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus, systems, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0118] The foregoing description of specific exemplary embodiments of the invention is for illustrative and explanatory purposes. These descriptions are not intended to limit the invention to the precise forms disclosed, and it will be apparent that many changes and variations can be made in accordance with the foregoing teachings. The exemplary embodiments were chosen and described in order to explain the specific principles of the invention and its practical application, thereby enabling those skilled in the art to implement and utilize various different exemplary embodiments of the invention, as well as various different choices and variations. The scope of the invention is intended to be defined by the claims and their equivalents.

[0119] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0120] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A microservice scheduling method, characterized in that, include: Collect communication traffic between various microservices and construct a microservice topology graph; Multiple microservice chains are generated based on the microservice topology graph. Each microservice chain starts from the entry microservice and contains a complete call path in the microservice topology graph. Based on a preset reinforcement learning model, an optimal microservice chain deployment strategy is generated. The microservice chain deployment strategy includes deploying the optimal edge node for each microservice chain. The reward value of the reinforcement learning model is configured as a linear combination of the cross-machine communication overhead when applying different deployment strategies and the resource utilization rate after deploying the microservice chain.

2. The microservice scheduling method according to claim 1, characterized in that, Multiple microservice chains are generated based on the microservice topology graph, including: Starting from each entry microservice, recursively visit adjacent microservice nodes, following the call relationship path until reaching the terminated microservice that no longer calls other microservices; Extract each complete call path from the entry microservice to the termination microservice as a microservice chain; If, during the traversal process, different upstream microservices call the same downstream microservice, then the downstream microservice is shared by multiple microservice chains, and the microservices with shared relationships are marked in the formed microservice chains.

3. The microservice scheduling method according to claim 1, characterized in that, The method further includes: Monitor the performance metrics of each edge node and determine whether the value of each performance metric falls within a preset threshold range; the performance metrics include the request frequency, response latency, and P98 data of each request for the corresponding edge node. If not, then the microservice chain deployment strategy is re-obtained based on the reinforcement learning model, and rescheduling is triggered for microservice chains whose deployment strategies have changed. In response to the rescheduling instruction, the microservice chains that need to be rescheduled are grouped according to their respective requests. Within each group, the microservice chains are sorted according to their interruption time. The rescheduling decision with the shortest interruption time is removed in turn until a rescheduling strategy with an estimated cost lower than the preset upper limit is output.

4. The microservice scheduling method according to claim 1, characterized in that, The method further includes: Construct a reinforcement learning model and initialize the parameters of the reinforcement learning model; Based on a preset training dataset, update the network latency and request frequency parameters, execute the microservice chain deployment strategy in the preset training dataset, and calculate the reward value. At preset intervals, the parameters of the reinforcement learning model are updated based on the deployment strategy and the corresponding reward value.

5. The microservice scheduling method according to claim 4, characterized in that, The formula for calculating the cross-machine communication overhead is as follows: ； ； Among them, let As an indicator variable, when the microservice chain Deployed in base stations The value is 1 if it is true, and 0 otherwise. Represents edge nodes and The distance between them; For signal propagation speed, for Uplink bandwidth, For the chain Ingress microservices and downstream microservices The amount of data transmitted in a single communication between them; Indicates the request type At the edge node The number of requests per second.

6. The microservice scheduling method according to claim 4, characterized in that, The formula for calculating the resource utilization rate is as follows: ； Among them, point Upper The total amount of this type of resource is For any microservice Its impact on the first The demand for such resources is .

7. The microservice scheduling method according to claim 6, characterized in that, The reward value for the microservice chain deployed on the first edge node is: ； ； ； in, , For preset weight values, For cross-machine communication overhead; The load pressure on the node. It is a constant greater than 1.

8. A microservice scheduling system, characterized in that, include: The module is used to collect communication traffic between various microservices and build a microservice topology graph; The generation module is used to generate multiple microservice chains based on the microservice topology graph. Each microservice chain starts from the entry microservice and contains a complete call path in the microservice topology graph. The deployment module is used to generate an optimal microservice chain deployment strategy based on a preset reinforcement learning model. The microservice chain deployment strategy includes deploying the optimal edge node for each microservice chain. The reward value of the reinforcement learning model is configured as a linear combination of the cross-machine communication overhead when applying different deployment strategies and the resource utilization rate after deploying the microservice chain.

9. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the microservice scheduling method of any one of claims 1-7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the microservice scheduling method according to any one of claims 1-7.

Images