A micro-service concurrent scheduling method and system based on DAG driving

Abstract

The application relates to the technical field of electronic data processing, and discloses a micro-service concurrent scheduling method and system based on DAG driving, which comprises the following steps: obtaining a directed acyclic graph, identifying strong dependence edges and weak dependence edges, topologically layering the directed acyclic graph, and calculating a global parallel degree factor; determining a prediction range, analyzing nodes in a subsequent main service layer in the prediction range, and generating a predictive resource demand vector; determining target numbers of various service instances in a warm-up pool; when a health degree attenuation value is lower than an activity threshold value, marking an idle instance as a state to be refreshed; calculating scheduling affinity degrees of each matching pair, selecting a matching pair with the highest affinity degree to execute a task; if execution time consumption exceeds a statistical benchmark, recording the type of a service node and a timeout range as a path blocking event; and updating a historical path blocking degree, which is used for feedback regulation of the target number of the subsequent warm-up pool. The application can match a task to an optimal execution instance, and improves scheduling decision quality.

Description

Technical Field

[0001] This invention relates to the field of electronic data processing technology, and specifically to a microservice concurrent scheduling method and system based on DAG-driven architecture. Background Technology

[0002] In modern architectures, complex business processes are often broken down into a series of collaborative microservices whose call relationships form a directed acyclic graph (DAG). However, existing schedulers often fail to effectively distinguish between strong dependencies and parallelizable weak dependencies on the critical path when parsing the DAG, thus failing to fully explore the inherent parallel potential of the workflow.

[0003] In terms of resource management, the size of the preheating pool is usually set solely based on historical load averages. This static strategy leads to a "cold start" delay when new or infrequent service requests suddenly appear in the workflow because there are no available instances in the pool; conversely, maintaining a large number of instances for a long time to cope with peak loads will result in serious resource waste.

[0004] At the scheduling decision level, existing strategies are too simplistic, mostly based solely on basic resource metrics such as CPU and memory. This ignores key performance factors such as data locality, the instance's actual historical load, and its health status. This lack of consideration often leads to suboptimal scheduling decisions, potentially resulting in unnecessary data network overhead or misallocation of tasks to underperforming instances.

[0005] More importantly, existing systems generally lack continuous tracking of the actual execution effect of tasks after scheduling decisions are made, such as whether timeouts or abnormal delays occur. The system cannot learn from these path blocking events, and therefore cannot dynamically adjust resource management strategies or optimize scheduling algorithms, resulting in a sluggish response to performance bottlenecks and difficulty in achieving continuous performance improvement. Summary of the Invention

[0006] This invention provides a microservice concurrent scheduling method and system based on DAG to solve the problem in the prior art that it is difficult to match tasks to the optimal execution instance, resulting in low scheduling decision quality.

[0007] In a first aspect, the DAG-driven microservice concurrent scheduling method of the present invention includes the following steps:

[0008] Obtain a directed acyclic graph (DAG) representing the microservice call chain, and identify strong and weak dependency edges. Based on the strong dependency edges, perform topological layering on the DAG to obtain the main service layers. Calculate the global parallelism factor of the DAG based on the ratio of weak to strong dependency edges and the maximum node width of each main service layer. Determine the prediction range of the currently executing main service layer based on the global parallelism factor, analyze the nodes in subsequent main service layers within the prediction range, and generate a predictive resource demand vector containing future service types and expected loads. Combine the predictive resource demand vector with historical path blocking rates to determine the target number of various service instances in the preheating pool. When an idle instance in the preheating pool is not selected in a continuous scheduling cycle, the number of instances not selected is determined based on the number of times the instance was not selected. The health decay value is calculated by weighting the number of idle instances and the idle time. When the health decay value is lower than the activity threshold, the idle instance is marked as pending refresh. When scheduling service nodes, matching pairs are built between the service node and all available instances in the preheating pool that are not pending refresh. The health decay value is used as a penalty, and the scheduling affinity of each matching pair is calculated by combining the cache location of the data required by the service and the historical load of the instance. The matching pair with the highest affinity is selected to execute the task. When the service node executes, if the execution time exceeds the statistical benchmark, the type of the service node and the timeout range are recorded as a path blocking event. The accumulated path blocking events update the historical path blocking degree of the corresponding service type, which is used to adjust the target number of subsequent preheating pools.

[0009] Preferably, the calculation of the global parallelism factor of the directed acyclic graph based on the ratio of weakly dependent edges to strongly dependent edges and the maximum node width of each main service layer includes:

[0010] Count the number of all weakly dependent edges in a directed acyclic graph. The number of all strongly dependent edges The ratio is calculated using the following formula. , ;

[0011] Iterate through all main service layers, obtain the number of nodes in each main service layer, and record the maximum value as the maximum node width. The global parallelism factor is calculated using the following formula. :

[0012] ;in, and Preset weights.

[0013] Preferably, determining the prediction range of the main service layer to be executed based on the global parallelism factor includes:

[0014] The global parallelism factor P is rounded up to obtain the prediction layer number L; the L consecutive main service layers following the current main service layer to be executed are determined as the prediction range.

[0015] Preferably, the step of determining the target number of various service instances in the preheating pool by combining the predictive resource demand vector and historical path congestion includes:

[0016] For each service type i in the predictive resource demand vector, obtain the baseline number of instances required for the expected load. ; Query the historical path blocking rate corresponding to the service type. The target quantity of the service type in the preheating pool is calculated using the following formula. And round the calculation result up:

[0017] .

[0018] Preferably, the step of calculating the health decay value based on the weighted sum of the number of times not selected and the idle time includes:

[0019] Get the number of consecutive times an idle instance has not been selected since the last scheduling, C; get the idle time T of an idle instance since the last task execution ended; calculate the health decay value D using the following formula:

[0020] ;in, The weighting coefficient is the preset number of consecutive times C is not selected. The weighting coefficients are the preset idle time T. This is a preset time normalization constant.

[0021] Preferably, the step of using the health decay value as a penalty term, and combining it with the cache location of the data required by the service and the historical load of the instance to calculate the scheduling affinity of each matching pair includes:

[0022] The system assesses the cache location of the data required by the service node and the physical machine where the instance resides. If the data is local, then the cache matching component... It should be 100, otherwise =0; Obtain the instance's average CPU utilization L over a past period, and calculate the load component representing available resources using the following formula. :

[0023] ;

[0024] Using the health decay value D as a penalty, the scheduling affinity A is calculated using the following formula:

[0025] ;in , and Preset weights.

[0026] Preferably, the statistical benchmark is the 95th percentile of the time taken for the past N successful executions of the corresponding service type.

[0027] Preferably, the timeout range is calculated using the following formula:

[0028] ;in, For the timeout range, The actual execution time, This serves as the statistical benchmark.

[0029] Preferably, the cumulative path blocking event update corresponds to the historical path blocking degree of the service type, including:

[0030] The historical path congestion level is updated using the exponential moving average method, and the update formula is as follows:

[0031] ;

[0032] in, The updated historical path congestion level. M represents the historical path congestion level before the update, and M represents the timeout magnitude of the most recent record. This is the preset smoothing factor.

[0033] Secondly, the DAG-driven microservice concurrent scheduling system of the present invention includes a memory and a processor. The memory stores computer instructions, and when the processor executes the computer instructions, it implements the above-mentioned DAG-driven microservice concurrent scheduling method.

[0034] The beneficial effects of this invention are as follows: By distinguishing between strong and weak dependencies and performing topological layering on the directed acyclic graph of the microservice call chain, this invention obtains the parallel structure of the workflow and, based on a predictive analysis mechanism, can predict the resource requirements of subsequent service nodes. This allows the size setting of the preheating pool to reduce service cold start latency caused by insufficient instance preparation. In the scheduling decision phase, this invention integrates instance idle health, data cache location, and historical load status to construct a multi-dimensional affinity calculation model, ensuring that service nodes can be matched with the optimal execution instance, thereby reducing data transmission overhead, achieving load distribution, and improving the execution efficiency of a single task. Furthermore, by continuously observing service execution time and recording blocking events, a performance feedback path is established, which can identify bottleneck services affecting the overall process efficiency and use the results to guide the allocation of corresponding resources in the preheating pool, forming a resource correction mechanism that helps to continuously alleviate performance bottlenecks. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating the DAG-driven microservice concurrency scheduling method provided in an embodiment of the present invention. Detailed Implementation

[0036] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0037] like Figure 1 As shown, an embodiment of the DAG-driven microservice concurrency scheduling method provided by the present invention includes the following steps:

[0038] S1. Obtain the directed acyclic graph (DAG) representing the microservice call chain and identify strong and weak dependency edges. Based on the strong dependency edges, perform topological layering on the DAG to obtain the main service layer. Calculate the global parallelism factor of the DAG based on the ratio of weak to strong dependency edges and the maximum node width of each main service layer. Determine the prediction range of the current main service layer to be executed based on the global parallelism factor, parse the nodes in the subsequent main service layers within the prediction range, and generate a predictive resource requirement vector containing future service types and expected loads.

[0039] Specifically, the process receives a workflow defined in JSON or YAML format, parses it to generate a directed acyclic graph (DAG) data structure consisting of nodes and edges. Then, it iterates through each node in the graph. If a node has multiple out-degree edges, these edges are defined as weak dependencies, indicating that subsequent nodes can be executed in parallel; if a node has only one out-degree edge, it is defined as a strong dependency, representing a strict sequential relationship. All strong dependencies are retained, and the graph is topologically sorted to assign nodes to different main service layers. Specifically, all nodes with an in-degree of zero are assigned to the first main service layer. After processing, new nodes with an in-degree of zero are assigned to the next layer, and so on, until all nodes are layered.

[0040] Then, the total number of weakly dependent edges and the total number of strongly dependent edges in the graph are compared, and the ratio is calculated. Simultaneously, the layer with the most nodes among all main service layers is identified, and its node count is recorded as the maximum node width. The global parallelism factor is calculated using a preset formula. Assuming that the scheduler is currently preparing to schedule nodes in the third main service layer, and the calculated global parallelism factor is 2, the scheduler will define the fourth and fifth main service layers as the prediction range. Finally, by traversing all service nodes within these two layers, the number of nodes for each service type is counted, generating a predictive resource demand vector. The predictive resource demand vector clarifies the types and quantities of service instances required in the future; for example, service A requires 8 instances, and service B requires 5 instances. The expected load for each node is assumed to be 1 unit by default.

[0041] S2, combining the predictive resource demand vector and historical path congestion, determine the target number of various service instances in the preheating pool; when an idle instance in the preheating pool is not selected in a continuous scheduling cycle, calculate the health decay value based on the weighted sum of the number of times it was not selected and the idle time; when the health decay value is lower than the activity threshold, mark the idle instance as pending refresh.

[0042] In an optional embodiment, determining the target number of various service instances in the preheating pool by combining the predictive resource demand vector with historical path congestion includes:

[0043] For each service type i in the predictive resource demand vector, obtain the baseline number of instances required for the expected load. ; Query the historical path blocking rate corresponding to the service type. The target quantity of the service type in the preheating pool is calculated using the following formula. And round the calculation result up:

[0044] .

[0045] For example, suppose that based on task analysis within the predicted range, services A and B are required. The baseline number of instances required for the expected load of service A is 4; the baseline number of instances required for the expected load of service B is 2. Simultaneously, query the historical path blocking rate of services A and B. Assume that service A, due to its reliance on external data sources, has historically experienced frequent delays, and its historical path blocking rate is... A value of 0.25 indicates an average performance bottleneck risk of 25%; while Service B is a stable, computationally intensive service with a historical path blocking rate. The value is 0.05. Then, the target quantity for each service is calculated using the above formula, resulting in the target quantity for service A. The target number of service B is 5; the target number of service B is calculated. The result is 2.1. After rounding up the calculation result, it is finally determined that 5 instances of service A and 3 instances of service B need to be prepared in the preheating pool.

[0046] Meanwhile, monitor idle instances in the preheating pool. Assume an idle service A instance has not been selected for five consecutive scheduling cycles, and its cumulative idle time has reached 600 seconds. The health decay value is calculated as: number of times not selected. 0.5+ Idle Time 0.1, and the calculated health decay value is 62.5 according to the formula.

[0047] S3, when scheduling service nodes, construct matching pairs for service nodes with all available instances in the preheating pool that are not in a state of waiting to be refreshed. Use the health decay value as a penalty, and combine the cache location of the data required by the service and the historical load of the instance to calculate the scheduling affinity of each matching pair. Select the matching pair with the highest affinity to execute the task.

[0048] When a transcoding service node that needs to process video files (e.g., video.mp4) needs to be scheduled, it finds two available transcoding instances in the preheating pool. and For example The physical machine it resides on has cached video.mp4, with a data location score of 10; the average CPU usage over the past five minutes was 20%, with a load score of 8; and the health decay value is 5. For this instance... The physical machine has no data cache, resulting in a data location score of 0; it has a high historical load, resulting in a load score of 4; and its health decay value is 2. Scheduling affinity is calculated using the following formula:

[0049] Data location score + load score 0.8 - Health decay value 0.5.

[0050] Calculated instance The scheduling affinity is 13.9, for example... The scheduling affinity is 2.2. Due to the instance... The instance with the highest scheduling affinity was selected. Perform this transcoding task.

[0051] S4. When a service node is executed, if the execution time exceeds the statistical benchmark, the type of the service node and the timeout range are recorded as a path blocking event. The accumulated path blocking events update the historical path blocking degree of the corresponding service type, which is used to adjust the target number of subsequent preheating pools.

[0052] In an optional embodiment, the statistical benchmark is the 95th percentile of the time taken for the past N successful executions of the corresponding service type.

[0053] The timeout range is calculated using the following formula:

[0054] ;in, For the timeout range, The actual execution time, This serves as the statistical benchmark.

[0055] Specifically, a historical list of execution times is maintained for each service type (e.g., image recognition service), such as the execution times of the last 200 successful executions. To calculate the statistical benchmark, these 200 execution times are sorted, and the 95th percentile value is taken. Assuming the 190th value, or the 95th percentile, is 500ms after sorting, then the statistical benchmark for the current image recognition service is... The timeframe is 500ms. This statistical benchmark is more representative of the upper limit of performance under normal conditions than the average, while effectively filtering out the interference of a few extreme outliers.

[0056] Record the actual execution time after a new image recognition task is completed. The timeout was 650ms. Since 650ms exceeded the statistical benchmark of 500ms, this was determined to be an abnormal timeout. The timeout margin M was then calculated to be 0.3. Next, a path blocking event was recorded, including the following information: service type: image recognition; timeout margin: 0.3.

[0057] In an optional embodiment, the cumulative path blocking event updates the historical path blocking degree corresponding to the service type, including:

[0058] The historical path congestion level is updated using the exponential moving average method, and the update formula is as follows:

[0059] ;

[0060] in, The updated historical path congestion level. M represents the historical path congestion level before the update, and M represents the timeout magnitude of the most recent record. This is the preset smoothing factor.

[0061] Specifically, a historical path congestion level is maintained for each service type. Taking image recognition service as an example, assume... It is 0.12. The value is 0.05. This means that during updates, new events account for only 5% of the weight, while historical data accounts for 95%. This exponential moving average method effectively prevents single, drastic performance fluctuations from dominating long-term performance evaluations, resulting in a more stable metric response. (Calculated according to the update formula...) The new value of 0.129 will replace the old value of 0.12 and become the latest performance status indicator of the image recognition service. It will be used in the calculation of the target number of the preheating pool in the next scheduling cycle, thereby increasing the reserved amount of transcoding service instances.

[0062] In an optional embodiment, calculating the global parallelism factor of the directed acyclic graph based on the ratio of weakly dependent edges to strongly dependent edges and the maximum node width of each main service layer includes:

[0063] Count the number of all weakly dependent edges in a directed acyclic graph. The number of all strongly dependent edges The ratio is calculated using the following formula. , ;

[0064] Iterate through all main service layers, obtain the number of nodes in each main service layer, and record the maximum value as the maximum node width. The global parallelism factor is calculated using the following formula. :

[0065] ;in, and Preset weights.

[0066] Specifically, the entire directed acyclic graph is analyzed to identify and count two types of dependencies. For example, a graph may contain 10 strong dependency edges (representing services must be executed strictly sequentially) and 30 weak dependency edges (representing services can be executed in a pipelined or partially parallel manner). In this case, It is 30. The calculated ratio R is 3, which is 10. A higher ratio initially indicates good parallelization of the graph. Assume the graph is divided into four main service layers, each containing 2, 5, 4, and 1 service nodes respectively. After traversing these layers, determine... Set to 5. It is 0.7. The value is 0.3, and the global parallelism factor P is calculated to be approximately 2.874 according to the formula.

[0067] In an optional embodiment, determining the prediction range of the main service layer to be executed based on the global parallelism factor includes:

[0068] The global parallelism factor P is rounded up to obtain the prediction layer number L; the L consecutive main service layers following the current main service layer to be executed are determined as the prediction range.

[0069] The calculated global parallelism factor is transformed into a discrete and operable prediction layer number. The prediction layer number determines the scope of future tasks that resource preheating needs to cover. For example, if the calculated global parallelism factor P is 2.874, rounding up yields a prediction layer number L = 3. Rounding up ensures that at least the scope indicated by the global parallelism factor is covered. Assuming a service node currently executing at the 2nd level of the main service layer is being executed, based on the calculated prediction layer number L equal to 3, the subsequent three main service layers—the 3rd, 4th, and 5th layers—are collectively defined as the prediction scope for this resource preheating. The system will focus on all service nodes within these four levels, statistically analyzing their types and estimated loads to generate a specific predictive resource requirement list.

[0070] In an optional embodiment, the step of calculating the health decay value based on the weighted sum of the number of times not selected and the idle time includes:

[0071] Get the number of consecutive times an idle instance has not been selected since the last scheduling, C; get the idle time T of an idle instance since the last task execution ended; calculate the health decay value D using the following formula:

[0072] ;in, The weighting coefficient is the preset number of consecutive times C is not selected. The weighting coefficients are the preset idle time T. This is a preset time normalization constant.

[0073] For example, the status of each idle instance in the preheating pool is continuously monitored. Taking instance A as an example, assuming it is not selected in three consecutive scheduling decisions due to its affinity being lower than other instances, its consecutive non-selection count C is 3. Meanwhile, this instance last completed a task 900 seconds ago, so its current idle time T is 900 seconds. Preset parameters are used to calculate the health decay value, and the settings are... It is 1.5. =1, The time interval is 600 seconds. Based on the formula above, the health decay value D for instance A is calculated to be 6. Assuming the activity threshold is set to 5, since instance A's health decay value of 6 is higher than the activity threshold of 5, it indicates that its condition is good and it can continue to participate in scheduling. If there is another instance B, whose calculated health decay value is 4, which is lower than the threshold of 5, then instance B will be marked as pending refresh.

[0074] In an optional embodiment, the step of using the health decay value as a penalty and combining it with the cache location of the data required by the service and the historical load of the instance to calculate the scheduling affinity of each matching pair includes:

[0075] The system assesses the cache location of the data required by the service node and the physical machine where the instance resides. If the data is local, then the cache matching component... It should be 100, otherwise =0; Obtain the instance's average CPU utilization L over a past period, and calculate the load component representing available resources using the following formula. :

[0076] ;

[0077] Using the health decay value D as a penalty, the scheduling affinity A is calculated using the following formula:

[0078] ;in , and Preset weights.

[0079] For example, suppose a data processing service node needs to be scheduled, and there are currently two candidate instances, instance X and instance Y. (Setting...) It is 0.6. It is 0.3. The value is 0.1. For instance X, the data required by the service happens to be on the physical machine where instance X resides, therefore the cache match component of instance X is 0.1. The value is 100; the average CPU utilization L of instance X over a period of time is 0.4, therefore the load component is... Its health decay value D is 2, and its value is 60. For instance Y, if the data it needs is not local and requires network transmission, then its... The value is 0; assuming that the CPU utilization L of instance Y over a past period was 0.1, then its The value is 90; assuming the health decay value D of instance Y is 15. According to the above formula, the scheduling affinity of instance X is calculated to be 77.8, and the scheduling affinity of instance Y is 25.5. Since the scheduling affinity of instance X is higher than that of instance Y, instance X is selected to execute the service.

[0080] The implementation principle of the DAG-driven microservice concurrent scheduling method in this invention is as follows: This invention distinguishes between strong and weak dependencies and performs topological layering on the DAG of the microservice call chain to accurately identify the parallel structure of the workflow and establishes a predictive analysis mechanism to accurately predict the resource requirements of subsequent service nodes. This method makes the size setting of the preheating pool more intelligent and can effectively reduce the service cold start delay caused by insufficient instance preparation. In the scheduling decision stage, this invention constructs a multi-dimensional affinity calculation model. This model comprehensively considers the idle health of instances, data cache location, and historical load status to ensure that service nodes can always be matched with the optimal execution instance, thereby significantly reducing data transmission overhead, optimizing load balancing, and improving the execution efficiency of a single task. In addition, this invention also establishes a closed-loop performance feedback path. Through continuous observation of service execution time and detailed recording of blocking events, the system can automatically identify bottleneck services affecting process efficiency and provide real-time feedback of the analysis results to dynamically guide the allocation of corresponding resources in the preheating pool. This forms an adaptive resource correction mechanism that helps to continuously alleviate and eliminate performance bottlenecks.

[0081] An embodiment of the DAG-driven microservice concurrent scheduling system provided by the present invention includes a memory and a processor. The memory stores computer instructions, and when the processor executes the computer instructions, it implements the DAG-driven microservice concurrent scheduling method in the above embodiment.

[0082] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for concurrent scheduling of microservices based on DAG-driven, characterized in that, The method comprises the following steps: acquiring a directed acyclic graph representing a microservice call chain, identifying strong dependency edges and weak dependency edges, including: traversing each node in the graph, if a node has multiple out-degree edges, then these edges are defined as weak dependency edges, indicating that the subsequent nodes can be executed in parallel; if the node has only one out-degree edge, it is defined as a strong dependency edge, representing a strict serial relationship; Topologically layering the directed acyclic graph based on strong dependence edges to obtain a main service layer; calculating a global parallelism factor of the directed acyclic graph based on a ratio of weak dependence edges to strong dependence edges and a maximum node width of each main service layer, including: counting a number of all weak dependence edges in the directed acyclic graph and a number of all strong dependence edges , calculating the ratio by the following formula , ; traversing all the main service layers to obtain a number of nodes of each main service layer and recording a maximum value thereof as the maximum node width ; calculating the global parallelism factor by the following formula : , and being a preset weight determining the prediction range of the current main service layer to be executed according to the global parallelism factor, parsing the nodes in the subsequent main service layer in the prediction range, generating a predictive resource demand vector containing future service types and expected loads; combining the predictive resource demand vector and the historical path blocking degree to determine the target number of each type of service instance in the warm pool; when the idle instance in the warm pool is not selected in the continuous scheduling period, calculating the health decay value according to the weighted sum of the number of times of not being selected and the idle time length, marking the idle instance as a to-be-refreshed state when the health decay value is lower than the activity threshold; when scheduling the service node, constructing a matching pair for the service node and all available and non-to-be-refreshed instances in the warm pool, taking the health decay value as a penalty term, and combining the cache location of the required data of the service and the historical load of the instance to calculate the scheduling affinity of each matching pair, and selecting the matching pair with the highest affinity to execute the task; when the service node is executed, if the execution time exceeds the statistical benchmark, record the type of the service node and the timeout amplitude as a path blocking event; accumulate the path blocking event to update the historical path blocking degree of the corresponding service type, which is used to feedback and adjust the target number of the subsequent warm pool. 2.The DAG-driven microservice concurrent scheduling method of claim 1, wherein, The method comprises the following steps: rounding up the global parallelism factor P to obtain the prediction layer number L; and determining the continuous L main service layers after the current main service layer to be executed as the prediction range. 3.The DAG-driven microservice concurrent scheduling method of claim 1, wherein, The method comprises the following steps: For each service type i in the predictive resource demand vector, obtain the instance base number required by the expected load ; query the historical path blocking degree corresponding to the service type ; calculate the target number of the service type in the warm-up pool by the following formula , and round up the calculation result: 。 4. The method of claim 1, wherein, The method comprises the following steps: acquiring the number of continuous times of not being selected C of the idle instance since the last scheduling; acquiring the idle time length T of the idle instance from the end of the last task execution to the present; calculating the health decay value D through the following formula: ; wherein, is a weight coefficient of the preset continuous non-winning number of times C, is a weight coefficient of the preset idle time T, is a preset time normalization constant.

5. The method of claim 4, wherein, The method comprises the following steps: Assess the data required by the service node and the cache location of the physical machine where the instance is located. If the data is local, the cache matching degree component is 100, otherwise is 0; obtain the CPU average utilization L of the instance in the past period of time, and calculate the load component representing available resources by the following formula : ； taking the health decay value D as a penalty term, and calculating the scheduling affinity A through the following formula: ; wherein , and are preset weights.

6. The method of claim 1, wherein, The statistical benchmark is the 95th percentile of the past N successful execution time of the corresponding service type.

7. The DAG-driven microservice concurrent scheduling method according to claim 6, characterized in that, The timeout amplitude is calculated through the following formula: ; wherein, is the timeout magnitude, is the actual execution duration, is the statistical baseline.

8. The DAG-driven microservice concurrent scheduling method according to claim 7, characterized in that, The method comprises the following steps: updating the historical path blocking degree by using the exponential moving average method, and the updating formula is: ； wherein, is the updated historical path congestion, is the historical path congestion before the update, M is the timeout margin recorded last time, is a preset smoothing factor. 9.A system for concurrent scheduling of microservices based on DAG-driven, the system comprising: The device comprises a memory and a processor, the memory stores computer instructions, and the processor executes the computer instructions to implement the DAG-driven microservice concurrent scheduling method according to any one of claims 1-8.

Images