Asynchronous task orchestration method, system, device and storage medium of directed acyclic graph

Abstract

The application provides a directed acyclic graph asynchronous task arrangement method, system, device and storage medium, the method comprises the steps of: abstracting a plurality of executable task units into DAG nodes, and defining the dependency relationship between the nodes through a declarative configuration; an executor collects all nodes and their dependency declarations, constructs a complete DAG graph structure and performs cyclic dependency detection; identifying root nodes and end nodes based on the DAG graph; starting from each end node, using a bidirectional recursive algorithm to construct the asynchronous task flow basic topology corresponding to each end node, and maintaining a cache mapping of the constructed nodes in the recursive process to reuse the constructed predecessor subgraph topology; based on the constructed asynchronous task flow basic topology, using the operators of an asynchronous responsive framework to construct an asynchronous execution flow; and finally aggregating the asynchronous execution flows corresponding to all end nodes and returning them. The application can realize declarative asynchronous task arrangement, automatically deduce the optimal execution link, significantly reduce maintenance costs and improve development efficiency.

Description

Technical Field

[0001] This invention relates to the field of distributed service invocation, and more specifically, to a method, system, device, and storage medium for asynchronous task orchestration of directed acyclic graphs. Background Technology

[0002] In Service-Oriented Architecture (SOA) and microservice architectures, a complete business request typically requires backend services to sequentially or in parallel call dozens of downstream SOA interfaces, database DAO (Data Access Object) operations, and several business logic computation nodes. These nodes have complex dependencies: some nodes can only initiate a call after their predecessor nodes return results, while independent nodes can execute in parallel. This complex service call dependency places extremely high demands on the system's orchestration capabilities and execution efficiency.

[0003] The common implementation solutions in the industry currently include the following categories: (1) Scheme based on callback or Future chaining.

[0004] Developers manually concatenate asynchronous streams in the order of invocation using `CompletableFuture.thenCompose / thenCombine` or RxJava's `flatMap / zip` operators. The drawbacks of this approach are: strong coupling between orchestration logic and business logic, hidden dependencies within nested callbacks, and significant modifications to the call chain required when adding or adjusting dependencies in business nodes, resulting in high maintenance costs. As the business scales, the nested callback hierarchy can reach five levels or more, drastically reducing code readability, a phenomenon known in the industry as "Callback Hell." Furthermore, manually controlling concurrency requires developers to have a deep understanding of the underlying thread pool mechanism; adjustments to concurrency strategies often involve substantial modifications to core orchestration code, leading to high change risks and significant regression testing costs.

[0005] (2) Solutions based on general workflow engines (such as Activiti, Camunda, etc.).

[0006] This approach defines processes using BPMN (Business Process Model and Notation) and drives execution via an engine. While focused on workflow scenarios with long transactions and manual nodes, it suffers from issues such as overly heavy engines, high scheduling latency, and high integration costs with internal SOA / RPC (Remote Procedure Call) frameworks for millisecond-level, high-concurrency online request chains. Specifically, general-purpose workflow engines typically rely on relational databases for state persistence, involving database read / write operations for each task scheduling, resulting in latency in the tens of milliseconds range, which is insufficient to meet the millisecond-level response time requirements of online transaction systems. Furthermore, these engines were not designed for microservice call scenarios and lack native support for distributed system governance capabilities such as service-level timeouts, circuit breakers, and degradation, leading to high integration costs.

[0007] (3) Schemes based on distributed task scheduling platforms (such as XXL-JOB, Elastic-Job, etc.).

[0008] These solutions focus on the scheduling and execution of timed tasks and are geared towards offline batch processing scenarios. They are weak in the ability to dynamically orchestrate and aggregate results in real-time online request chains and cannot meet the needs of online businesses for dynamic routing and conditional branching at the request level.

[0009] Existing technologies generally suffer from high orchestration coupling, deep execution chains, and weak node-level dynamic governance capabilities, making it difficult to meet the comprehensive requirements of online transaction systems for high concurrency, low latency, observability, configurability, and visualization. Therefore, there is an urgent need for an asynchronous task orchestration scheme that can achieve declarative orchestration, automatically derive the optimal execution chain, and support dynamic governance in complex service dependency scenarios.

[0010] In view of this, the present invention provides an asynchronous task orchestration method, system, device and storage medium for directed acyclic graphs. Summary of the Invention

[0011] To address the problems in existing technologies, the present invention aims to provide an asynchronous task orchestration method, system, device, and storage medium for directed acyclic graphs. This invention overcomes the difficulties of existing technologies and enables the executor to automatically deduce and construct the optimal execution chain by managing the call relationships between interfaces through declarative dependency configuration. This decouples service call logic from business logic and improves the maintainability, scalability, and observability of the system.

[0012] Embodiments of the present invention provide an asynchronous task orchestration method for a directed acyclic graph, comprising the following steps: S110. Abstract the multiple executable task units that need to be executed into nodes in a directed acyclic graph. Each node corresponds to an independent task or logical unit and has a unique node identifier. Define the dependency relationship between nodes through declarative configuration. Each node declares a list of identifiers of its predecessor nodes. S120. The executor collects all nodes and their dependency declarations, constructs a complete directed acyclic graph data structure, and performs circular dependency detection on the directed acyclic graph. If a cycle is detected in the graph, the execution is terminated and a circular dependency exception is thrown. The list of node identifiers that form the cycle is returned. S130. Identify the root node and the end node based on the directed acyclic graph, wherein the root node is a node with an in-degree of zero and the end node is a node with an out-degree of zero. S140. Starting from each of the terminal nodes, a bidirectional recursive algorithm is used to construct the basic topology of the asynchronous task flow corresponding to each terminal node. The bidirectional recursive algorithm includes an upward recursive process and a downward recursive process: In the upward recursive process, for the node to be processed, the executor recursively processes all predecessor nodes of the node, ensuring that all predecessor nodes in the topology are constructed before the current node, and identifies the local root node of the local subgraph corresponding to the current terminal node; In the downward recursive process, the executor starts from the identified global root node or the local root node identified in the upward recursive process, recursively traverses all successor nodes, and maintains the cache mapping of the constructed nodes in the recursive process, recording the basic topology of the asynchronous task flow corresponding to each node; Using the cache mapping, the topology of the constructed predecessor subgraph is reused in the construction process of different terminal node paths, avoiding repeated recursion on the same predecessor subgraph, thereby reusing the basic topology of the asynchronous task flow; The basic topology of the asynchronous task flow serves as the basic topology structure for the subsequent execution flow construction. S150. Based on the established asynchronous task flow topology, the executor constructs an asynchronous execution flow using operators of the asynchronous reactive framework according to the dependencies between nodes. For nodes with dependencies, the executor uses chaining transformation operators to sequentially chain the asynchronous flow of the predecessor node with the task corresponding to the current node to achieve serial execution. For nodes without dependencies, the executor uses parallel combination operators to achieve concurrent execution. When a node depends on multiple predecessor nodes, the executor first combines the asynchronous flows of all predecessor nodes using parallel combination operators, and then triggers the execution of the task corresponding to the current node using chaining transformation operators. During execution, after the tasks corresponding to each node are completed, the executor immediately stores the task execution results in the global context that spans the entire execution lifecycle for subsequent dependent nodes to access and use. S160. The executor performs the final aggregation of the asynchronous execution flows corresponding to all end nodes: if there are multiple end nodes, the asynchronous execution flows are aggregated by the parallel combination operator; if there is only one end node, the asynchronous execution flow is directly returned as the complete execution result.

[0013] Preferably, in step S110, the executor further performs condition skipping and process interruption judgments for each node; the condition skipping judgment is used to determine whether to skip the execution of the task corresponding to the current node based on the current state of the global context during runtime; the process interruption judgment is used to determine whether to interrupt the execution of the tasks corresponding to all subsequent nodes based on the execution result after the task corresponding to the current node has been executed.

[0014] Preferably, in step S110, the executor further extends the node interface of each node based on the routing condition method; the routing condition method is used to dynamically determine the actual execution path of the task corresponding to the current node according to the current state of the global context at runtime; when a node has multiple optional successor node branches, the executor executes the routing condition method to obtain the branch identifier of the current request, and only includes the successor nodes of matching branches into the directed acyclic graph subgraph of the current request, while the unmatched branch nodes are marked as skipped in the current request and do not participate in the construction of the execution flow; the condition judgment node itself is modeled as a directed acyclic graph node and supports concurrent execution with the executable task unit.

[0015] Preferably, after step S120 and before step S130, the method further includes a step of marking hotspot paths and preloading the directed acyclic graph based on historical execution data: The executor collects the historical call frequency and average time consumption of each node within a preset time window, and identifies hot nodes and hot paths within the actual execution subgraph range corresponding to the current request based on the collected data. The hot path is the path from the root node to the end node where the weighted comprehensive score of the historical call frequency and average time consumption of each node exceeds a preset threshold. The preset threshold is dynamically calculated by the executor based on the statistical distribution of historical data or issued by an external configuration center. For the hot nodes, the executor pre-initializes the node's connection pool and metadata cache before constructing the asynchronous execution flow; For the hot path, after the asynchronous execution flow is constructed and before the execution of the task corresponding to the root node begins, the executor sends a probe request to the downstream node in the hot path in advance to warm up the local cache of the downstream service, and dynamically adjusts the sending rate of the probe request according to the response delay of the downstream service.

[0016] Preferably, in step S140, during the bidirectional recursive construction process, the executor maintains a subgraph fingerprint index. When recursively constructing a predecessor subgraph, the executor first calculates the fingerprint of the subgraph and queries the subgraph fingerprint index. If a subgraph with the same fingerprint has already been constructed, the executor directly reuses the asynchronous task flow base topology already constructed for that subgraph and does not recursively construct the duplicate part. At the same time, the execution results of each node corresponding to the already constructed asynchronous task flow base topology are written into the result field indexed by the corresponding node identifier in the global context. All end nodes that depend on the common subgraph read the same result data through the global context.

[0017] Preferably, in step S150, each node is configured with a timeout threshold and a fallback method during declaration; the executor sets an independent timeout timer for the task corresponding to each node when constructing the asynchronous stream corresponding to the node; when the task corresponding to the node times out or throws an exception, the executor captures the exception and records it in the global context, and determines whether the node has configured a fallback method: If a fallback method is configured, the executor will execute the fallback logic and return the default result; If no fallback method is configured, the executor determines whether the node is located on the critical path from the root node to any end node. The critical path refers to the path consisting of all nodes that must be passed through in all paths from any global root node to any end node. If so, the executor cancels all unfinished asynchronous streams of end nodes and returns quickly upon failure. Otherwise, the executor marks the node's status as timed out and skips it, the node's result field is marked as unavailable in the global context, and the executor continues to execute the tasks corresponding to other nodes.

[0018] Preferably, after step S160, the method further includes an execution result verification step and a difference compensation step: The execution result verification step includes: the executor comparing the aggregated execution result with a preset expected result template, the expected result template containing data type verification rules and business rationality verification rules for the result fields of each end node, the business rationality verification rules including numerical range verification, enumeration value verification, and non-empty verification; if the verification passes, the executor returns the result to the caller; if the verification fails, the executor identifies the end nodes that fail the verification and initiates the differential compensation process; The differentiated compensation process includes: for nodes marked as unavailable due to timeout skipping but located on non-critical paths, the executor initiates asynchronous retry of the task corresponding to the node while returning the final aggregated execution result to the caller, and provides the retry result to the caller through a callback mechanism or independent query interface; for nodes skipped due to condition skipping judgment but determined to be actually required to be executed according to the mandatory dependency flag marked in the expected result template, the executor re-triggers the execution flow of the task corresponding to the node; the executor performs graded handling of exceptions during the compensation execution process, retrying retryable exceptions according to the exponential backoff strategy, and recording compensation failure logs and sending alarm notifications through message queues for non-retryable exceptions.

[0019] Embodiments of the present invention also provide an asynchronous task orchestration system for directed acyclic graphs (DAGs) to implement the above-described asynchronous task orchestration method for DAGs. The asynchronous task orchestration system for DAGs includes: The node declaration module abstracts multiple executable task units that need to be executed into nodes in a directed acyclic graph. Each node corresponds to an independent task or logical unit and has a unique node identifier. The dependencies between nodes are defined through declarative configuration, and each node declares a list of identifiers of its dependent predecessor nodes. The node identification module collects all nodes and their dependency declarations, constructs a complete directed acyclic graph data structure, and performs circular dependency detection on the directed acyclic graph. If a cycle is detected in the graph, execution is terminated and a circular dependency exception is thrown, and a list of node identifiers that form the cycle is returned. The node classification module identifies the root node and the end node based on the directed acyclic graph. The root node is a node with an in-degree of zero, and the end node is a node with an out-degree of zero. The bidirectional recursive module starts from each of the terminal nodes and uses a bidirectional recursive algorithm to construct the basic topology of the asynchronous task flow corresponding to each terminal node. The bidirectional recursive algorithm includes an upward recursive process and a downward recursive process: In the upward recursive process, for the node to be processed, the executor recursively processes all predecessor nodes of the node, ensuring that all predecessor nodes in the topology are constructed before the current node, and identifies the local root node of the local subgraph corresponding to the current terminal node; In the downward recursive process, the executor starts from the identified global root node or the local root node identified in the upward recursive process, recursively traverses all successor nodes, and maintains a cache mapping of the constructed nodes during the recursion process, recording the basic topology of the asynchronous task flow corresponding to each node; Using the cache mapping, the topology of the constructed predecessor subgraph is reused in the construction process of different terminal node paths, avoiding repeated recursion on the same predecessor subgraph, thereby reusing the basic topology of the asynchronous task flow; The basic topology of the asynchronous task flow serves as the basic topology structure for the subsequent execution flow construction. The basic topology module, based on the pre-built asynchronous task flow topology, uses operators of the asynchronous reactive framework to construct asynchronous execution flows according to the dependencies between nodes. For nodes with dependencies, the executor uses chained transformation operators to sequentially chain the asynchronous flows of predecessor nodes with the tasks corresponding to the current node to achieve serial execution. For nodes without dependencies, the executor uses parallel combination operators to achieve concurrent execution. When a node depends on multiple predecessor nodes, the executor first combines the asynchronous flows of all predecessor nodes using parallel combination operators, and then triggers the execution of the task corresponding to the current node using chained transformation operators. During execution, after the tasks corresponding to each node are completed, the executor immediately stores the task execution results in the global context that spans the entire execution lifecycle for subsequent dependent nodes to access. The final aggregation module aggregates all asynchronous execution flows corresponding to the end nodes: if there are multiple end nodes, the asynchronous execution flows are aggregated using parallel combination operators; if there is only one end node, the asynchronous execution flow is directly returned as the complete execution result.

[0020] Embodiments of the present invention also provide an asynchronous task orchestration device for a directed acyclic graph, comprising: processor; A memory in which executable instructions of the processor are stored; The processor is configured to perform the steps of the above-described asynchronous task orchestration method for directed acyclic graphs by executing the executable instructions.

[0021] Embodiments of the present invention also provide a computer-readable storage medium for storing a program that, when executed, implements the steps of the above-described asynchronous task orchestration method for directed acyclic graphs.

[0022] The purpose of this invention is to provide an asynchronous task orchestration method, system, device, and storage medium for directed acyclic graphs. It can automatically deduce and construct the optimal execution chain by managing the call relationship between interfaces through declarative dependency configuration, thereby decoupling service call logic from business logic and improving the maintainability, scalability, and observability of the system. Attached Figure Description

[0023] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0024] Figure 1 This is a flowchart of the asynchronous task orchestration method for directed acyclic graphs of the present invention.

[0025] Figure 2 This is a schematic diagram of the overall architecture of the asynchronous task orchestration and execution method based on directed acyclic graphs that implements the present invention.

[0026] Figure 3 This is a schematic diagram of the execution flow of the asynchronous task orchestration and execution method based on a directed acyclic graph according to the present invention.

[0027] Figure 4 This is a schematic diagram illustrating the process of aggregating the asynchronous execution flows corresponding to all end nodes in implementing the asynchronous task orchestration and execution method based on directed acyclic graphs of the present invention.

[0028] Figure 5 This invention relates to a directed acyclic graph-based asynchronous task orchestration and execution system that enables rapid location, performance analysis, and visualization of dependencies.

[0029] Figure 6 This is a system architecture diagram of the asynchronous task orchestration system based on a directed acyclic graph of the present invention.

[0030] Figure 7 This is a schematic diagram of the structure of the asynchronous task orchestration device with directed acyclic graph of the present invention.

[0031] Figure 8 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention. Detailed Implementation

[0032] The following specific examples illustrate the implementation methods of this application. Those skilled in the art can easily understand the other advantages and effects of this application from the content disclosed herein. This application can also be implemented or applied through other different specific embodiments, and various details in this application can be modified or changed according to different viewpoints and application systems without departing from the spirit of this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0033] The embodiments of this application will now be described in detail with reference to the accompanying drawings, so that those skilled in the art can easily implement the application. This application may be embodied in many different forms and is not limited to the embodiments described herein.

[0034] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics represented in connection with that embodiment or example, which are included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics represented may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate different embodiments or examples represented in this application, as well as features of different embodiments or examples.

[0035] Figure 1 This is a flowchart of the asynchronous task orchestration method for directed acyclic graphs according to the present invention. For example... Figure 1 As shown, the asynchronous task orchestration method for directed acyclic graphs of the present invention includes the following steps: S110. The multiple executable task units that need to be executed are abstracted into nodes in a directed acyclic graph (hereinafter referred to as "DAG"). Each node corresponds to an independent task or logical unit and has a unique node identifier. The dependency relationship between each node is defined through declarative configuration. Each node declares the list of identifiers of its predecessor nodes. S120. The executor collects all nodes and their dependency declarations, constructs a complete directed acyclic graph data structure, and performs circular dependency detection on the directed acyclic graph. If a cycle is detected in the graph, execution is terminated and a circular dependency exception is thrown. The list of node identifiers that form the cycle is returned. S130. Identify the root node and the end node based on the directed acyclic graph. The root node is the node with an in-degree of zero, and the end node is the node with an out-degree of zero. S140. Starting from each terminal node, a bidirectional recursive algorithm is used to construct the basic topology of the asynchronous task flow corresponding to each terminal node. The bidirectional recursive algorithm includes an upward recursive process and a downward recursive process: In the upward recursive process, for the current node to be processed, the executor recursively processes all predecessor nodes of the node, ensuring that all predecessor nodes in the topology are constructed before the current node, and identifies the local root node of the local subgraph corresponding to the current terminal node; In the downward recursive process, the executor starts from the identified global root node or the local root node identified by the upward recursive process, recursively traverses all successor nodes, and maintains the cache mapping of the constructed nodes during the recursion process, recording the basic topology of the asynchronous task flow corresponding to each node; Using the cache mapping, the topology of the constructed predecessor subgraph is reused in the construction process of different terminal node paths, avoiding repeated recursion on the same predecessor subgraph, thereby reusing the basic topology of the asynchronous task flow; The basic topology of the asynchronous task flow serves as the basic topology structure for the subsequent execution flow construction. S150. Based on the established asynchronous task flow topology, the executor constructs an asynchronous execution flow using operators of the asynchronous reactive framework according to the dependencies between nodes. For nodes with dependencies, the executor uses chaining transformation operators to sequentially chain the asynchronous flow of the predecessor node with the task corresponding to the current node to achieve serial execution. For nodes without dependencies, the executor uses parallel combination operators to achieve concurrent execution. When a node depends on multiple predecessor nodes, the executor first combines the asynchronous flows of all predecessor nodes using parallel combination operators, and then triggers the execution of the task corresponding to the current node using chaining transformation operators. During execution, after the tasks corresponding to each node are completed, the executor immediately stores the task execution results in the global context that spans the entire execution lifecycle for subsequent dependent nodes to access and use. S160. The executor performs the final aggregation of the asynchronous execution flows corresponding to all end nodes: if there are multiple end nodes, the asynchronous execution flows are aggregated by the parallel combination operator; if there is only one end node, the asynchronous execution flow is directly returned as the complete execution result.

[0036] This invention completely decouples business logic from orchestration logic through declarative configuration. In practical applications, developers first define the dependencies of each service node through enumeration or configuration files. For example, the order service node declares that it does not depend on any predecessor node, while the coupon service node declares that it depends on the order service node. The executor collects all node declarations at startup, constructs a complete DAG graph data structure using an adjacency list, and performs loop detection using a depth-first search algorithm. If a loop is detected, the executor accurately returns a list of node identifiers forming the loop, facilitating quick location of configuration errors by developers. During the execution phase, the executor starts from the last node and automatically derives the optimal execution path using a bidirectional recursive algorithm. For nodes without dependencies, parallel execution is automatically implemented; for nodes with dependencies, serial waiting is automatically implemented. This method allows developers to focus only on the business logic implementation of the nodes themselves, without needing to worry about the call order and concurrency control between nodes, significantly reducing coding complexity and the probability of errors. The technical effect of this embodiment is that it reduces nearly 2,000 lines of nested callback code in the traditional hard-coded orchestration method to dozens of lines of flat dependency declaration, which significantly improves code readability and maintainability. At the same time, the optimal concurrency strategy automatically derived by the executor can make full use of system resources and shorten the average response time of the interface by about 30% to 50%.

[0037] In a preferred embodiment, in step S110, the executor also performs condition skipping and process interruption checks on each node. In real-world business scenarios, condition skipping checks have wide-ranging applications. For example, in an order query chain, if the context identifies the user as a regular member, the execution of the "Luxury Benefits Query" node is skipped to avoid unnecessary service calls. This check logic is implemented through the `doSkip` method of the node, which receives the global context as a parameter and returns a boolean value indicating whether to skip the current node. Process interruption checks are suitable for scenarios requiring early termination. For example, when a high-risk operation is detected at a risk control verification node, the `doInterrupt` method returns true, and the executor immediately interrupts the execution of all subsequent nodes, quickly returning a failure result to avoid invalid service calls and resource waste. The technical effect of this embodiment is that it extracts the business rule-driven conditional logic from scattered business code to unified management at the node level, achieving dynamic tailoring of the execution flow. It flexibly adapts to different business scenarios without modifying the DAG graph structure. Simultaneously, the process interruption mechanism effectively avoids invalid resource consumption in high-risk scenarios, improving system security and resource utilization efficiency.

[0038] In a preferred embodiment, in step S110, the executor further extends the node interface of each node based on the routing condition method. This routing condition method, `getRouteCondition`, returns a branch identifier based on the current state of the runtime global context, and the executor dynamically determines the actual execution path of the current node accordingly. A typical application scenario is multi-channel order processing: the order processing node has two optional successor branches, "APP channel" and "H5 channel," corresponding to different subsequent processing flows. At runtime, the executor obtains the branch identifier based on the channel source in the context, only including the successor nodes of matching branches in the DAG subgraph of the current request, and marking non-matching branch nodes as skipped. Crucially, the condition judgment node itself is also modeled as a lightweight DAG node, which can be executed concurrently with downstream service call nodes, meaning that condition judgment does not block the initiation of parallel tasks. The technical effect of this embodiment is that it enables the same dependency configuration to serve multiple business scenarios, dynamically prunes the execution graph through context awareness, avoids maintaining an independent orchestration configuration for each scenario, and significantly reduces the risk of configuration explosion. In scenarios such as A / B testing, canary releases, and multi-channel adaptation, this mechanism can significantly reduce the number of configurations and maintenance costs. Tests have shown that in complex scenarios supporting three channels and five A / B test groups, the number of configurations is reduced by approximately 75%.

[0039] In a preferred embodiment, after step S120 and before step S130, a step of marking and preloading hotspot paths in the DAG graph based on historical execution data is included. The executor collects the historical call frequency and average latency of each node within a preset time window, and identifies hotspot nodes and hotspot paths through a weighted comprehensive scoring algorithm. Specifically, the executor maintains the call count and average response time of each node in the last 5 minutes using a sliding window method, calculates a comprehensive score with a call frequency weight of 0.4 and an average latency weight of 0.6, and marks nodes with scores exceeding a dynamic threshold as hotspot nodes. For hotspot nodes, the executor pre-initializes their connection pool and metadata cache before constructing the asynchronous execution flow to avoid cold start overhead during the first call. For hotspot paths, the executor sends probe requests to downstream nodes in the hotspot path in advance to warm up the local cache of downstream services while executing the root node task or before, and dynamically adjusts the sending rate of probe requests according to the response latency of downstream services. The technical advantages of this embodiment are as follows: By using a historical data-driven preloading mechanism, the cold start overhead on hot paths is removed from the critical path of request execution, further reducing the response time of hot requests by approximately 15% to 25%. Simultaneously, the dynamically adjusted probe request sending rate avoids the impact of preloaded traffic on downstream services, demonstrating the system's adaptive capabilities. In high-concurrency scenarios, this mechanism can significantly improve the system's throughput and stability.

[0040] In a preferred embodiment, during the bidirectional recursive construction process in step S140, the executor maintains a subgraph fingerprint index to achieve subgraph sharing and result reuse. In complex DAG scenarios, multiple end nodes often share the same set of common predecessor subgraphs. For example, in a hotel details query chain, the two end nodes, "Price Information Query" and "Promotional Activity Query," may share a subgraph composed of two predecessor nodes, "Hotel Basic Information Query" and "User Membership Level Query." When the executor recursively constructs this predecessor subgraph, it calculates the fingerprint of the subgraph. The fingerprint is generated by concatenating and hashing the identifiers of all nodes in the subgraph after topological sorting. If a subgraph with the same fingerprint is found to have already been constructed, its already constructed asynchronous task flow basic topology is directly reused, and the duplicate part is not recursively constructed. At the same time, the execution result of the shared subgraph is written to the result field indexed by the corresponding node identifier in the global context. The technical advantages of this embodiment are as follows: In complex DAG scenarios with multiple exits and aggregation points, it can effectively reduce the number of times nodes are repeatedly executed. Tests have shown that it can reduce redundant SOA calls by approximately 30% to 40% in the entire order chain scenario, significantly alleviating the pressure on downstream systems. Simultaneously, the shared result writing mechanism ensures that all end nodes relying on this common subgraph read the same result data through the global context, guaranteeing result consistency and avoiding data inconsistency issues that may arise from multiple executions.

[0041] In a preferred embodiment, each node in step S150 is configured with a timeout threshold and a fallback method during declaration. When constructing the asynchronous stream corresponding to a node, the executor sets an independent timeout timer for each task corresponding to that node, with timeout control granularity precise at the node level rather than the entire link level. When a node task times out or throws an exception, the executor first catches the exception and records it in the global context, then determines whether the node has a fallback method configured. If a fallback method is configured, the executor executes the fallback logic and returns a default result, such as returning a default anonymous user profile when the "User Profile Query" node times out. If no fallback method is configured, the executor further determines whether the node is located on the critical path from the root node to any end node. The determination of the critical path is based on whether a node in the DAG graph is located at the intersection of all paths from the root to the end. If a node is on the critical path, its timeout will cause the entire link to become unavailable. In this case, the executor actively cancels all unfinished asynchronous flows of the last node and returns quickly upon failure. If a non-critical path node times out, such as the "Recommended Product Query" node, the executor marks its status as timed out and skips it. The result field of this node is marked as unavailable in the global context, and the execution of tasks corresponding to other nodes continues. The technical effect of this embodiment is that it completely decouples timeout control and degradation decision-making from the business code and centralizes them at the engine layer, achieving fine-grained management of timeout configuration. The differentiated handling strategy for critical and non-critical paths ensures that failures of core dependencies can quickly fail and return, while failures of non-core dependencies will not propagate to the entire link, effectively preventing cascading failures and improving the overall availability and resilience of the system.

[0042] In a preferred embodiment, step S160 is followed by an execution result verification step and a differential compensation step. In the execution result verification step, the executor compares the aggregated execution result with a preset expected result template. This template includes data type verification rules and business rationality verification rules for the result fields of each terminal node. Data type verification ensures that the returned result is consistent with the expected type. Business rationality verification includes numerical range verification, enumeration value verification, and non-empty verification. If all verifications pass, the executor returns the result normally to the caller. If any terminal node fails verification, the executor identifies the terminal node that failed verification and initiates the differential compensation process. The differential compensation process adopts different compensation strategies based on different failure reasons: for nodes marked as unavailable due to timeout skipping but located on non-critical paths, the executor initiates an asynchronous retry of the node task while returning the aggregated result. The retry result is provided to the caller through a callback mechanism or an independent query interface, achieving an optimized experience of "fast return of main result + asynchronous push of supplementary result". For nodes skipped due to conditional skip checks but deemed necessary for execution based on the mandatory dependency flags in the expected result template, the executor re-triggers the execution flow for those nodes. The executor handles exceptions during the compensation execution process in a tiered manner. For retryable exceptions such as network timeouts and temporary service unavailability, retrying follows an exponential backoff strategy. For non-retryable exceptions such as data format errors, a compensation failure log is recorded and an alarm notification is sent via a message queue. The technical effect of this embodiment is that, through the execution result verification mechanism, it ensures that the data returned to the caller meets expectations in terms of type and business logic, avoiding business anomalies caused by data quality issues. The differentiated compensation mechanism adopts differentiated recovery strategies based on the cause of failure, repairing defective data in non-critical paths as much as possible while ensuring rapid response of the main link, downgrading some failure scenarios from "complete failure" to "partial success," significantly improving user experience and business success rate. Testing shows that this mechanism can reduce the overall request failure rate caused by non-critical dependency failures by approximately 60%.

[0043] Figure 2 This is a schematic diagram of the overall architecture of the asynchronous task orchestration and execution method based on directed acyclic graphs that implements the present invention. Figure 3 This is a schematic diagram of the execution flow of the asynchronous task orchestration and execution method based on a directed acyclic graph according to the present invention. Figure 4 This is a schematic diagram illustrating the process of aggregating the asynchronous execution flows corresponding to all end nodes in implementing the asynchronous task orchestration and execution method based on directed acyclic graphs of the present invention. Figure 5 This invention relates to a directed acyclic graph-based asynchronous task orchestration and execution system that enables rapid location, performance analysis, and visualization of dependencies. (Reference) Figures 1 to 5 As shown, taking the order details query scenario as an example, the specific implementation process of this invention will be described in detail: 1. System Overall Architecture This invention is based on a reactive programming framework (such as RxJava and its encapsulation framework AsfSingle). The system consists of six core modules: a node declaration module, a node identification module, a node classification module, a bidirectional recursion module, a basic topology module, and a final aggregation module. The overall architecture is as follows: Figure 2 As shown, the modules work together to complete the entire process from node registration to the return of execution results.

[0044] 2. Task Node Modeling and Dependency Declaration

[0045] First, the multiple executable task units to be executed are abstracted as nodes in a directed acyclic graph. Each node corresponds to an independent task or logical unit and has a unique node identifier. In the order details query scenario of this embodiment, it is necessary to obtain basic order information, price information, user information, and available coupon information.

[0046] In the specific implementation, the Node interface is defined as the top-level interface for all nodes, and this interface contains the following core methods: getId(): Returns a unique identifier string for the node, which is referenced by other nodes in the dependency configuration.

[0047] getDependencies(): Returns a list of predecessor node identifiers that the current node depends on. An empty list indicates that the node is the root node.

[0048] getStream(ctx): Returns the asynchronous task stream corresponding to the node. The specific task execution logic is implemented in this method, such as calling downstream SOA services.

[0049] processResult(ctx, result): Processes the execution result of the node task, usually used to store the result in the context.

[0050] doSkip(ctx): Determines whether to skip the execution of the current node based on the context. If it returns true, the node will not be executed.

[0051] doInterrupt(ctx): Determines whether the entire process is interrupted after the current node is executed. If it returns true, all subsequent unexecuted nodes will be terminated.

[0052] Node types include service call nodes, which encapsulate request construction methods, response type mapping methods, and service method identifiers, and are used to uniformly handle calls to downstream SOA services.

[0053] Dependencies between nodes are defined through declarative configuration, with each node declaring a list of identifiers of its dependent predecessor nodes. In this embodiment, the dependency declarations are as follows: Order service node (serviceA): The dependency list is empty, and it is the root node.

[0054] Price service node (serviceB): The dependency list is empty, and it is the root node.

[0055] User service node (serviceC): The dependency list is empty, and it is the root node.

[0056] Coupon service node (serviceD): The dependency list is ["serviceA"], which depends on basic order information.

[0057] 3. DAG Graph Construction and Validity Verification

[0058] The executor collects all nodes and their dependency declarations, constructing a complete directed acyclic graph (DAG) data structure. Specifically, the executor maintains two core mapping structures: `NODE_MAP` (a mapping from `nodeId` to `Node` instances) and `DEPENDENCY_MAP` (a mapping from a node to its list of predecessor nodes). During construction, the executor also constructs a reverse dependency mapping `SUCCESSOR_MAP` (a mapping from a node to its list of successor nodes) to support subsequent top-down recursive traversal.

[0059] The executor performs circular dependency detection on the constructed graph. If a cycle is detected in the graph, execution terminates and a circular dependency exception is thrown, returning a list of node identifiers that form the cycle. Circular dependency detection uses a Depth-First Search (DFS) based algorithm, maintaining a recursive stack to track nodes on the current access path. If a successor node of the current node is already in the recursive stack, a cycle is determined to exist.

[0060] 4. Hotspot path marking and preloading

[0061] After the DAG graph is constructed and circular dependency detection passes, the executor marks and preloads hotspot paths in the DAG graph based on historical execution data. The executor collects the historical call frequency and average execution time of each node within a preset time window (e.g., the most recent 5 minutes). In this embodiment, the system maintains a sliding window statistics array, recording the number of calls per second and the average response time of each node in the past 300 seconds, in seconds.

[0062] The executor calculates a weighted composite score for each node based on the collected data, with a weight of 0.4 for call frequency and 0.6 for average execution time. Nodes with scores exceeding a preset threshold are marked as hot nodes. A hot path is defined as a path from the root node to the end node where the weighted composite score of historical call frequency and average execution time exceeds the preset threshold. The preset threshold is dynamically calculated by the executor based on the statistical distribution of historical data (e.g., taking the 80th percentile of the composite score of all nodes) or issued by an external configuration center.

[0063] For nodes marked as hotspots, the executor pre-initializes the node's connection pool and metadata cache before constructing the asynchronous execution flow. For example, if "Order Service" is marked as a hotspot node, the executor establishes a connection with Order Service in advance and loads the necessary metadata.

[0064] For marked hot paths, the executor sends probe requests to downstream nodes along the hot path in advance to warm up the local cache of downstream services, either before or after constructing the asynchronous execution flow and starting to execute the task corresponding to the root node. For example, if the path from "User Service" to "Coupon Service" is a hot path, the executor sends a probe request to the coupon service in advance while the user service node is executing. The executor dynamically adjusts the sending rate of probe requests based on the response latency of downstream services: when the response latency of downstream services rises above a threshold, the executor reduces the sending frequency of probe requests; when the response of downstream services stabilizes, the executor gradually restores the frequency of probe requests.

[0065] 5. Root and End Node Identification

[0066] Based on the constructed DAG graph structure, the executor identifies two special types of nodes: root nodes and terminal nodes. Root nodes are nodes with an in-degree of zero, meaning they have no predecessor dependencies and can be executed independently and in parallel. Terminal nodes are nodes with an out-degree of zero, meaning they are not depended upon by any other nodes and are the final output nodes of the execution chain.

[0067] In this embodiment, the order service node (serviceA), the price service node (serviceB), and the user service node (serviceC) are all root nodes, and they can execute in parallel. The coupon service node (serviceD) is the terminal node, which depends on serviceA.

[0068] 6. Constructing asynchronous call chains using bidirectional recursion

[0069] Starting from each terminal node, a bidirectional recursive algorithm is used to construct the basic topology of the asynchronous task flow corresponding to each terminal node. This step is one of the core innovations of this invention.

[0070] A bidirectional recursive algorithm includes an upward recursive process and a downward recursive process: During the upward recursion, for the currently pending node, the executor recursively processes all its predecessor nodes, ensuring that all predecessor nodes in the topology are constructed before the current node. Specifically, the executor calls the `buildStreamForNode` method to process the current node: if the node is already in the cache mapping `STREAM_MAP`, the cached stream is returned directly; otherwise, `buildStreamForNode` is recursively called to process all predecessor nodes, and then the stream for the current node is constructed based on the number of predecessor nodes.

[0071] During the downward recursion, the executor starts from the identified global root node or the local root node identified during the upward recursion and recursively traverses all successor nodes. Downward recursion ensures that no node in the DAG is missed, and a caching mechanism is used to avoid duplicate processing.

[0072] Throughout the recursive process, the executor maintains a cache map STREAM_MAP of the constructed nodes, recording the basic topology of the asynchronous task flow corresponding to each node. Using this cache map, the topology of the constructed predecessor subgraph is reused during the construction of different end node paths, avoiding repeated recursion on the same predecessor subgraph.

[0073] In addition, the executor maintains a subgraph fingerprint index. When recursively constructing a predecessor subgraph, the executor first calculates the fingerprint of the subgraph (generated by concatenating and hashing the identifiers of all nodes in the subgraph after topological sorting) and queries the subgraph fingerprint index. If a subgraph with the same fingerprint has already been constructed, the executor directly reuses the asynchronous task flow base topology already constructed for that subgraph, without recursively constructing the duplicate parts. Simultaneously, the execution results of each node corresponding to the already constructed asynchronous task flow base topology are written to the result field indexed by the corresponding node identifier in the global context. All end nodes that depend on this common subgraph read the same result data through the global context.

[0074] In this embodiment, if multiple end nodes share the same set of predecessor subgraphs, the executor avoids duplicate execution through a subgraph sharing mechanism. Specifically, assuming there is another end node, "Promotion Activity Query," that also depends on "Order Service" and "User Service," when the executor constructs the flow of "Promotion Activity Query," it detects that the fingerprint of its predecessor subgraph is the same as the fingerprint of the predecessor subgraph of "Coupon Service," and directly reuses the already constructed flow, without repeatedly calling the Order Service and User Service.

[0075] 7. Building an execution flow based on an asynchronous reactive framework

[0076] Based on the established asynchronous task flow topology, the executor constructs an asynchronous execution flow using operators from the asynchronous reactive framework, according to the dependencies between nodes.

[0077] For nodes with dependencies, the executor uses the flatMap operator to sequentially chain the asynchronous stream of the predecessor node with the task corresponding to the current node to achieve serial execution. In this embodiment, the coupon service node (serviceD) depends on the order service node (serviceA). The executor uses flatMap to chain the asynchronous stream of serviceA with the task of serviceD: after serviceA completes its execution, its result is passed to serviceD as input.

[0078] For nodes that are independent of each other, the executor uses the parallel combination operator (zip) to achieve concurrent execution. In this embodiment, the order service node (serviceA), the price service node (serviceB), and the user service node (serviceC) are independent of each other, and the executor uses zip to combine their asynchronous streams in parallel.

[0079] When a node depends on multiple predecessor nodes, the executor first combines the asynchronous streams of all predecessor nodes using the parallel combination operator, and then triggers the execution of the task corresponding to the current node using the chained transformation operator. For example, if node E depends on both node A and node B, the executor first uses `zip` to combine the streams of A and B, and then triggers E's task using `flatMap`.

[0080] During execution, once the tasks corresponding to each node are completed, the executor immediately stores the task execution results in the global context (Context) that spans the entire execution lifecycle, for subsequent dependent nodes to access. The Context is a thread-safe data container implemented using ConcurrentHashMap, supporting efficient data sharing between different nodes.

[0081] Simultaneously, each node is configured with a timeout threshold and a fallback method during declaration. When constructing the asynchronous stream corresponding to a node, the executor sets an independent timeout timer for each task. When a task corresponding to a node times out or throws an exception, the executor catches the exception and records it in the global context. It then determines whether the node has a fallback method configured: if so, the executor executes the fallback logic and returns the default result; if not, the executor checks if the node is on the critical path from the root node to any end node. If so, the executor cancels all unfinished asynchronous streams of end nodes and returns quickly upon failure; otherwise, the executor marks the node's state as timed out and skipped, the node's result field is marked as unavailable in the global context, and the executor continues executing tasks corresponding to other nodes.

[0082] 8. End-node stream aggregation and result return

[0083] The executor performs a final aggregation of the asynchronous execution flows corresponding to all end nodes: if there are multiple end nodes, the asynchronous execution flows are aggregated using the parallel combination operator; if there is only one end node, the asynchronous execution flow is directly returned as the complete execution result.

[0084] In this embodiment, the coupon service node (serviceD) is the only end node, and the executor directly returns its corresponding asynchronous stream. If there are multiple end nodes, such as "price information query" and "promotional activity query" being end nodes, the executor uses zip to combine the two and then returns them.

[0085] 9. Execution result verification and differential compensation

[0086] After step S160, the executor performs a result verification step. The executor compares the aggregated execution result with a preset expected result template. The expected result template contains data type verification rules and business rationality verification rules for the result fields of each terminal node. The business rationality verification rules include numerical range verification, enumeration value verification, and non-empty verification.

[0087] In the order details query scenario of this embodiment, the expected result template requires that the "Coupon List" field is not empty, the "Order Amount" field is a positive number, and the "User Level" field is one of the preset enumerated values. If all validations pass, the executor will return the result to the caller normally.

[0088] If the verification fails, the actuator identifies the failing end node and initiates the differential compensation process. The differential compensation process includes: (1) For nodes that are marked as unavailable due to timeout skipping but are located on non-critical paths, the executor will initiate asynchronous retry of the task corresponding to the node while returning the final aggregated execution result to the caller. For example, if the "Recommended Product Query" node times out and is skipped, the executor will return the main result of the order details while asynchronously retrying the node and providing the retry result to the caller through a callback mechanism.

[0089] (2) For nodes that are skipped due to conditional skipping but are determined to be actually required to be executed according to the mandatory dependency flag marked in the expected result template, the executor will re-trigger the execution flow of the task corresponding to that node. For example, if "coupon list" is marked as a mandatory dependency in the expected result template, but the node is skipped due to conditional skipping, the executor will re-trigger its execution.

[0090] The executor handles exceptions during the compensation process in a tiered manner: for retryable exceptions (such as network timeouts or temporary service unavailability), retries are performed according to an exponential backoff strategy (e.g., an initial delay of 100ms, followed by subsequent delays of 200ms, 400ms, and 800ms); for non-retryable exceptions (such as incorrect data format or invalid parameters), compensation failure logs are recorded and alarm notifications are sent through a message queue to facilitate timely intervention by operations and maintenance personnel.

[0091] Through the above complete implementation scheme, the present invention realizes the fully automated orchestration and execution of the entire process from node declaration, DAG graph construction, hotspot path preloading, root and terminal node identification, bidirectional recursive construction of asynchronous call chain, execution flow construction based on reactive framework, terminal node flow aggregation to execution result verification and differential compensation, which fully demonstrates the significant advantages of the present invention in simplifying development, improving efficiency, and enhancing system robustness and observability.

[0092] Figure 6 This is the overall system architecture diagram of the browser connector service in the asynchronous task orchestration system of the directed acyclic graph of this invention. For example... Figure 6 As shown, the asynchronous task orchestration system 5 based on a directed acyclic graph of the present invention includes: The node declaration module 51 abstracts multiple executable task units that need to be executed into nodes in a directed acyclic graph. Each node corresponds to an independent task or logical unit and has a unique node identifier. The dependencies between nodes are defined through declarative configuration, and each node declares a list of identifiers of its predecessor nodes.

[0093] The node identification module 52 collects all nodes and their dependency declarations, constructs a complete directed acyclic graph data structure, and performs circular dependency detection on the directed acyclic graph. If a cycle is detected in the graph, execution is terminated and a circular dependency exception is thrown, and a list of node identifiers that form the cycle is returned.

[0094] The node classification module 53 identifies the root node and the end node based on the directed acyclic graph. The root node is the node with an in-degree of zero, and the end node is the node with an out-degree of zero.

[0095] The bidirectional recursive module 54 starts from each terminal node and uses a bidirectional recursive algorithm to construct the basic topology of the asynchronous task flow corresponding to each terminal node. The bidirectional recursive algorithm includes an upward recursive process and a downward recursive process: In the upward recursive process, for the node to be processed, the executor recursively processes all predecessor nodes of the node, ensuring that all predecessor nodes in the topology are constructed before the current node, and identifies the local root node of the local subgraph corresponding to the current terminal node; In the downward recursive process, the executor starts from the identified global root node or the local root node identified in the upward recursive process, recursively traverses all successor nodes, and maintains the cache mapping of the constructed nodes in the recursive process, recording the basic topology of the asynchronous task flow corresponding to each node; Using the cache mapping, the topology of the constructed predecessor subgraph is reused in the construction process of different terminal node paths, avoiding repeated recursion on the same predecessor subgraph, thereby reusing the basic topology of the asynchronous task flow; The basic topology of the asynchronous task flow serves as the basic topology structure for the subsequent execution flow construction.

[0096] The basic topology module 55, based on the constructed asynchronous task flow topology, uses operators of the asynchronous reactive framework to construct asynchronous execution flows according to the dependencies between nodes. For nodes with dependencies, the executor uses chained transformation operators to sequentially chain the asynchronous flows of predecessor nodes with the tasks corresponding to the current node to achieve serial execution. For nodes without dependencies, the executor uses parallel combination operators to achieve concurrent execution. When a node depends on multiple predecessor nodes, the executor first combines the asynchronous flows of all predecessor nodes using parallel combination operators, and then triggers the execution of the task corresponding to the current node using chained transformation operators. During execution, after the tasks corresponding to each node are completed, the executor immediately stores the task execution results in the global context that spans the entire execution lifecycle for subsequent dependent nodes to access.

[0097] The final aggregation module 56 performs the final aggregation of all asynchronous execution flows corresponding to the end nodes: if there are multiple end nodes, the asynchronous execution flows are aggregated by parallel combination operators; if there is only one end node, the asynchronous execution flow is directly returned as the complete execution result.

[0098] In summary, the directed acyclic graph asynchronous task orchestration system of the present invention can automatically deduce and construct the optimal execution link by managing the calling relationship between interfaces through declarative dependency configuration, thereby decoupling the service call logic from the business logic and improving the maintainability, scalability and observability of the system.

[0099] This invention also provides an asynchronous task orchestration apparatus for a directed acyclic graph, including a processor and a memory storing executable instructions for the processor. The processor is configured to execute steps of an asynchronous task orchestration method for a directed acyclic graph via executing the executable instructions.

[0100] As shown above, the asynchronous task orchestration device of the directed acyclic graph of the present invention in this embodiment can automatically deduce and construct the optimal execution link by the executor through the call relationship between the declarative dependency configuration management interface, thereby decoupling the service call logic from the business logic and improving the maintainability, scalability and observability of the system.

[0101] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "platform."

[0102] Figure 7 This is a schematic diagram of the asynchronous task orchestration device based on a directed acyclic graph of the present invention. See below for reference. Figure 7 To describe an electronic device 600 according to this embodiment of the present invention. Figure 7 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0103] like Figure 7 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different platform components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0104] The storage unit stores program code, which can be executed by the processing unit 610 to perform the steps described in the method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 610 can perform actions such as... Figure 1 The steps are shown in the figure.

[0105] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include read-only memory (ROM) 6203.

[0106] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0107] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0108] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0109] This invention also provides a computer-readable storage medium for storing a program, which, when executed, implements the steps of an asynchronous task orchestration method for a directed acyclic graph. In some possible implementations, various aspects of this invention can also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the above-described method section of this specification according to various exemplary embodiments of the invention.

[0110] As shown above, the asynchronous task orchestration system of the directed acyclic graph of the present invention in this embodiment can automatically deduce and construct the optimal execution link by the executor through the call relationship between the declarative dependency configuration management interface, thereby decoupling the service call logic from the business logic and improving the maintainability, scalability and observability of the system.

[0111] Figure 8 This is a schematic diagram of the structure of the computer-readable storage medium of the present invention. (Reference) Figure 8As shown, a program product 800 for implementing the above-described method according to an embodiment of the present invention is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0112] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may 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 readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, 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 devices, magnetic storage devices, or any suitable combination thereof.

[0113] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0114] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0115] In summary, the purpose of this invention is to provide an asynchronous task orchestration method, system, device, and storage medium for directed acyclic graphs. This method can manage the calling relationships between interfaces through declarative dependency configuration, and the executor can automatically deduce and construct the optimal execution chain, thereby decoupling service call logic from business logic and improving the maintainability, scalability, and observability of the system.

[0116] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. An asynchronous task orchestration method for a directed acyclic graph, characterized in that, Includes the following steps: S110. Abstract the multiple executable task units that need to be executed into nodes in a directed acyclic graph. Each node corresponds to an independent task or logical unit and has a unique node identifier. Define the dependency relationship between nodes through declarative configuration. Each node declares a list of identifiers of its predecessor nodes. S120. The executor collects all nodes and their dependency declarations, constructs a complete directed acyclic graph data structure, and performs circular dependency detection on the directed acyclic graph. If a cycle is detected in the graph, the execution is terminated and a circular dependency exception is thrown. The list of node identifiers that form the cycle is returned. S130. Identify the root node and the end node based on the directed acyclic graph, wherein the root node is a node with an in-degree of zero and the end node is a node with an out-degree of zero. S140. Starting from each of the terminal nodes, a bidirectional recursive algorithm is used to construct the basic topology of the asynchronous task flow corresponding to each terminal node. The bidirectional recursive algorithm includes an upward recursive process and a downward recursive process: In the upward recursive process, for the node to be processed, the executor recursively processes all predecessor nodes of the node, ensuring that all predecessor nodes in the topology are constructed before the current node, and identifies the local root node of the local subgraph corresponding to the current terminal node; In the downward recursive process, the executor starts from the identified global root node or the local root node identified in the upward recursive process, recursively traverses all successor nodes, and maintains the cache mapping of the constructed nodes in the recursive process, recording the basic topology of the asynchronous task flow corresponding to each node; Using the cache mapping, the topology of the constructed predecessor subgraph is reused in the construction process of different terminal node paths, avoiding repeated recursion on the same predecessor subgraph, thereby reusing the basic topology of the asynchronous task flow; The basic topology of the asynchronous task flow serves as the basic topology structure for the subsequent execution flow construction. S150. Based on the established asynchronous task flow topology, the executor constructs an asynchronous execution flow using operators of the asynchronous reactive framework according to the dependencies between nodes. For nodes with dependencies, the executor uses chaining transformation operators to sequentially chain the asynchronous flows of predecessor nodes with the tasks corresponding to the current node to achieve serial execution. For nodes without dependencies, the executor uses parallel combination operators to achieve concurrent execution. When a node depends on multiple predecessor nodes, the executor first combines the asynchronous flows of all predecessor nodes using parallel combination operators, and then triggers the execution of the task corresponding to the current node using chaining transformation operators. During execution, once the tasks corresponding to each node are completed, the executor immediately stores the task execution results in the global context that spans the entire execution lifecycle, for subsequent dependent nodes to access and use. S160. The executor performs the final aggregation of the asynchronous execution flows corresponding to all end nodes: if there are multiple end nodes, the asynchronous execution flows are aggregated by the parallel combination operator. If there is only one end node, the asynchronous execution flow will be returned as the complete execution result.

2. The asynchronous task orchestration method for directed acyclic graphs as described in claim 1, characterized in that, In step S110, the executor also performs condition skipping and process interruption checks on each node; the condition skipping check is used to determine whether to skip the execution of the task corresponding to the current node based on the current state of the global context during runtime. The process interruption judgment is used to determine whether to interrupt the execution of tasks corresponding to all subsequent nodes after the task corresponding to the current node has been completed, based on the execution result.

3. The asynchronous task orchestration method for directed acyclic graphs as described in claim 1, characterized in that, In step S110, the executor further extends the node interface of each node based on the routing condition method; the routing condition method is used to dynamically determine the actual execution path of the task corresponding to the current node according to the current state of the global context at runtime. When a node has multiple possible successor node branches, the executor executes the routing condition method to obtain the branch identifier of the current request, and only includes the successor nodes of matching branches into the directed acyclic graph subgraph of the current request. Unmatching branch nodes are marked as skipped in the current request and do not participate in the construction of the execution flow. The condition judgment node itself is modeled as a directed acyclic graph node and supports concurrent execution with the executable task unit.

4. The asynchronous task orchestration method for directed acyclic graphs as described in claim 1, characterized in that, After step S120 and before step S130, the method further includes a step of marking hotspot paths and preloading the directed acyclic graph based on historical execution data. The executor collects the historical call frequency and average time consumption of each node within a preset time window, and identifies hot nodes and hot paths within the actual execution subgraph range corresponding to the current request based on the collected data. The hot path is the path from the root node to the end node where the weighted comprehensive score of the historical call frequency and average time consumption of each node exceeds a preset threshold. The preset threshold is dynamically calculated by the executor based on the statistical distribution of historical data or issued by an external configuration center. For the hot nodes, the executor pre-initializes the node's connection pool and metadata cache before constructing the asynchronous execution flow; For the hot path, after the asynchronous execution flow is constructed and before the execution of the task corresponding to the root node begins, the executor sends a probe request to the downstream node in the hot path in advance to warm up the local cache of the downstream service, and dynamically adjusts the sending rate of the probe request according to the response delay of the downstream service.

5. The asynchronous task orchestration method for directed acyclic graphs as described in claim 1, characterized in that, In step S140, during the bidirectional recursive construction process, the executor maintains a subgraph fingerprint index. When recursively constructing a predecessor subgraph, the executor first calculates the fingerprint of the subgraph and queries the subgraph fingerprint index. If it finds that a subgraph with the same fingerprint has already been constructed, it directly reuses the asynchronous task flow base topology that has already been constructed for the subgraph and does not recursively construct the duplicate part. At the same time, the execution results of each node corresponding to the already constructed asynchronous task flow base topology are written into the result field indexed by the corresponding node identifier in the global context. All end nodes that depend on this common subgraph read the same result data through the global context.

6. The asynchronous task orchestration method for directed acyclic graphs as described in claim 2, characterized in that, In step S150, each node is declared with a timeout threshold and a fallback method configured; the executor sets an independent timeout timer for each task corresponding to a node when constructing the asynchronous stream corresponding to the node; when the task corresponding to a node times out or throws an exception, the executor captures the exception and records it in the global context, and determines whether the node has a fallback method configured. If a fallback method is configured, the executor will execute the fallback logic and return the default result; If no fallback method is configured, the executor determines whether the node is located on the critical path from the root node to any end node. The critical path refers to the path consisting of all nodes that must be passed through in all paths from any global root node to any end node. If so, the executor cancels all unfinished asynchronous streams of end nodes and returns quickly upon failure. Otherwise, the executor marks the node's status as timed out and skips it, the node's result field is marked as unavailable in the global context, and the executor continues to execute the tasks corresponding to other nodes.

7. The asynchronous task orchestration method for directed acyclic graphs as described in claim 6, characterized in that, Following step S160, the process further includes an execution result verification step and a difference compensation step: The execution result verification step includes: the executor comparing the aggregated execution result with a preset expected result template, the expected result template containing data type verification rules and business rationality verification rules for the result fields of each end node, the business rationality verification rules including numerical range verification, enumeration value verification, and non-empty verification; if the verification passes, the executor returns the result to the caller; if the verification fails, the executor identifies the end nodes that fail the verification and initiates the differential compensation process; The differentiated compensation process includes: for nodes marked as unavailable due to timeout skipping but located on non-critical paths, the executor initiates asynchronous retry of the task corresponding to the node while returning the final aggregated execution result to the caller, and provides the retry result to the caller through a callback mechanism or independent query interface; for nodes skipped due to condition skipping judgment but determined to be actually required to be executed according to the mandatory dependency flag marked in the expected result template, the executor re-triggers the execution flow of the task corresponding to the node; the executor performs graded handling of exceptions during the compensation execution process, retrying retryable exceptions according to the exponential backoff strategy, and recording compensation failure logs and sending alarm notifications through message queues for non-retryable exceptions.

8. An asynchronous task orchestration system for a directed acyclic graph, used to implement the asynchronous task orchestration method for a directed acyclic graph as described in any one of claims 1 to 7, characterized in that, include: The node declaration module abstracts multiple executable task units that need to be executed into nodes in a directed acyclic graph. Each node corresponds to an independent task or logical unit and has a unique node identifier. The dependencies between nodes are defined through declarative configuration, and each node declares a list of identifiers of its dependent predecessor nodes. The node identification module collects all nodes and their dependency declarations, constructs a complete directed acyclic graph data structure, and performs circular dependency detection on the directed acyclic graph. If a cycle is detected in the graph, execution is terminated and a circular dependency exception is thrown, and a list of node identifiers that form the cycle is returned. The node classification module identifies the root node and the end node based on the directed acyclic graph. The root node is a node with an in-degree of zero, and the end node is a node with an out-degree of zero. The bidirectional recursive module starts from each of the terminal nodes and uses a bidirectional recursive algorithm to construct the basic topology of the asynchronous task flow corresponding to each terminal node. The bidirectional recursive algorithm includes an upward recursive process and a downward recursive process: In the upward recursive process, for the node to be processed, the executor recursively processes all predecessor nodes of the node, ensuring that all predecessor nodes in the topology are constructed before the current node, and identifies the local root node of the local subgraph corresponding to the current terminal node; In the downward recursive process, the executor starts from the identified global root node or the local root node identified in the upward recursive process, recursively traverses all successor nodes, and maintains a cache mapping of the constructed nodes during the recursion process, recording the basic topology of the asynchronous task flow corresponding to each node; Using the cache mapping, the topology of the constructed predecessor subgraph is reused in the construction process of different terminal node paths, avoiding repeated recursion on the same predecessor subgraph, thereby reusing the basic topology of the asynchronous task flow; The basic topology of the asynchronous task flow serves as the basic topology structure for the subsequent execution flow construction. The basic topology module, based on the pre-built asynchronous task flow topology, uses operators of the asynchronous reactive framework to construct asynchronous execution flows according to the dependencies between nodes. For nodes with dependencies, the executor uses chaining transformation operators to sequentially chain the asynchronous flows of predecessor nodes with the tasks corresponding to the current node to achieve serial execution. For nodes without dependencies, the executor uses parallel combination operators to achieve concurrent execution. When a node depends on multiple predecessor nodes, the executor first combines the asynchronous flows of all predecessor nodes using parallel combination operators, and then triggers the execution of the task corresponding to the current node using chaining transformation operators. During execution, once the tasks corresponding to each node are completed, the executor immediately stores the task execution results in the global context that spans the entire execution lifecycle, for subsequent dependent nodes to access and use. The final aggregation module is where the executor performs the final aggregation of all asynchronous execution flows corresponding to the end nodes: if there are multiple end nodes, the asynchronous execution flows are aggregated using parallel combination operators; If there is only one end node, the asynchronous execution flow will be returned as the complete execution result.

9. An asynchronous task orchestration device for a directed acyclic graph, characterized in that, include: A processor; a memory storing executable instructions of the processor; wherein the processor is configured to perform the steps of the asynchronous task orchestration method for a directed acyclic graph as described in any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium for storing a program, characterized in that, When the program is executed by the processor, it implements the steps of the asynchronous task orchestration method for a directed acyclic graph as described in any one of claims 1 to 7.

Images