Workflow updating method and device, electronic equipment and storage medium

Abstract

The invention discloses a workflow updating method and device, electronic equipment and a storage medium, and belongs to the technical field of computers, and the workflow updating method comprises the steps that a target DAG workflow definition file of a current version issued by a cloud is received, and different workflow definition files correspond to different types of workflow templates; when it is detected that the cloud modifies the target DAG workflow definition file, a modification instruction set carrying a digital signature and issued by the cloud is received, and the modification instruction set is obtained after codes for modifying the target DAG workflow definition file are coded; verifying the digital signature; if the verification succeeds, updating the target DAG workflow definition file of the current version to a target DAG workflow definition file of a new version through a modification instruction set; if verification fails, the target DAG workflow definition file of the previous version of the target DAG workflow definition file of the current version is obtained from the cloud, so that network overhead is reduced, workflow updating safety is guaranteed, and meanwhile the high availability requirement is met.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a workflow update method, apparatus, electronic device and storage medium. Background Technology

[0002] Current workflow orchestration systems generally employ a declarative management paradigm. Specifically, operations personnel or developers need to pre-write a complete configuration file in another markup language (YAML, Ain't Markup Language). This file statically defines all components, execution steps, dependencies, and expected final state of the entire workflow or application. This configuration file is then fully distributed to the orchestration system's control center. When iterating workflow versions, a "container image rolling upgrade" strategy is typically used, gradually replacing older container instances with newer container images to ensure uninterrupted service during upgrades.

[0003] However, the above method has the following drawbacks: First, the distributed static configuration files are large in size, and rolling upgrades require frequent retrieval of huge container images, resulting in huge network overhead and making it difficult to adapt to narrowband edge scenarios. Second, the update process, from the transmission of configuration files to the retrieval of new version container images, relies on network communication, which provides an opportunity for "man-in-the-middle attacks" and leads to security risks in the update process. Finally, when rolling upgrades fail, manual rollback is usually required for recovery, which is time-consuming and cannot meet the needs of rapid system response. Summary of the Invention

[0004] The purpose of this application is to provide a workflow update method, apparatus, electronic device, and storage medium to solve the problems of high network overhead, security risks, and long time consumption in current workflow updates, which cannot meet the needs of rapid system response.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a workflow update method applied to an edge plugin, the method comprising: Receive the target DAG workflow definition file of the current version from the cloud; If the cloud detects that the target DAG workflow definition file has been modified, a set of modification instructions carrying a digital signature is received from the cloud. The set of modification instructions is obtained by encoding the code that modifies the target DAG workflow definition file. Verify the digital signature; If the verification is successful, the target DAG workflow definition file of the current version will be updated to the target DAG workflow definition file of the new version using the modified instruction set. If verification fails, retrieve the previous version of the target DAG workflow definition file from the cloud.

[0006] Optionally, verifying the digital signature includes: Obtain the cryptographic random number carried by the modified instruction set; Obtain the historical set of modification instructions issued by the previous version of the target DAG workflow definition file based on the current version of the target DAG workflow definition file; Extract the historical cryptographic random numbers carried in the historical modification instruction set; If the cryptographic random number is greater than the historical cryptographic random number, then the digital signature is verified.

[0007] Optionally, after updating the current version of the target DAG workflow definition file to the new version of the target DAG workflow definition file using the modification instruction set, the method further includes: Determine the original working environment of the target DAG workflow definition file of the current version, and execute the original workflow execution request of the target DAG workflow definition file of the current version. Create a shadow instance working environment that is isolated from the original working environment; The new version of the target DAG workflow definition file was tested in the shadow instance working environment, and the test results were obtained. The test results are used to achieve hot updates of the target DAG workflow definition file from the current version to the new version.

[0008] Optionally, the step of hot-updating the target DAG workflow definition file from the current version to the new version based on the test results includes: If the test result is passed, then upon receiving a new workflow execution request, the new workflow execution request will be routed to the shadow instance working environment, while the original workflow execution request will continue to be executed in the original working environment. If the original workflow execution request is detected to have been completed, the original working environment is recycled.

[0009] Secondly, this application provides a workflow update method applied in the cloud, the method comprising: Distribute the target DAG workflow definition file for the current version to the edge plugin; If a modification to the target DAG workflow definition file of the current version is detected, obtain the code that modified the target DAG workflow definition file of the current version; The code that modifies the target DAG workflow definition file of the current version is encoded into a set of modification instructions; After digitally signing the modified instruction set, it is sent to the edge plugin so that the edge plugin can verify the digital signature. After successful verification, the current version of the target DAG workflow definition file is updated to the new version of the target DAG workflow definition file through the modified instruction set. If verification fails, the target DAG workflow definition file of the previous version will be issued to replace the target DAG workflow definition file of the current version.

[0010] Optionally, before sending the target DAG workflow definition file of the current version to the edge plugin, the following steps are also included: Generate a persistent version tree for the target DAG workflow definition file; Determine the initial version of the target DAG workflow definition file; A root node is generated on the target persistent version tree based on the initial version of the target DAG workflow definition file. The root node includes an immutable snapshot of the initial version of the workflow definition file and an initialization sequence of modification instructions.

[0011] Optionally, after generating the root node on the target persistent version tree based on the target DAG workflow definition file of the initial version, the method further includes: If a modification to the initial version of the target DAG workflow definition file is detected, the code that modified the initial version of the target DAG workflow definition file is obtained; The code that modifies the target DAG workflow definition file of the initial version is encoded into a target modification instruction set; Receive the next version of the target DAG workflow definition file uploaded by the edge plugin, which is generated based on the initial version of the target DAG workflow definition file based on the target modification instruction set; The target modification instruction set is added to the initialized modification instruction sequence to obtain a new modification instruction sequence; A first new node is generated after the root node of the target persistent version tree based on the target DAG workflow definition file of the next version. The first new node includes an immutable snapshot of the target DAG workflow definition file of the next version and the new modification instruction sequence.

[0012] Optionally, the target persistent version tree includes several nodes, which are in a linear sequential relationship or a tree branching relationship. Different nodes include immutable snapshots of different versions of the target DAG workflow definition file and different modification instruction sequences, and the modification instruction sequence includes several modification instruction sets.

[0013] Optionally, after generating the target persistent version tree corresponding to the target DAG workflow definition file, the method further includes: If the nodes are in a linear order, then identify the end node of the target persistent version tree, and determine that the end node includes an immutable snapshot of the target DAG workflow definition file of the first version and a first modification instruction sequence; If a modification to the target DAG workflow definition file of the first version is detected, the code that modified the target DAG workflow definition file of the first version is obtained; The code that modifies the target DAG workflow definition file of the first version is encoded into the first modification instruction set; The edge plugin uploads a second version of the target DAG workflow definition file generated based on the first modification instruction set. The second version of the target DAG workflow definition file is obtained by modifying the first version of the target DAG workflow definition file. A second new node is generated after the end node of the target persistent version tree, and the generation time of the second new node is determined; Add a first set of modification instructions to the first sequence of modification instructions to generate a second sequence of modification instructions; The immutable snapshot of the target DAG workflow definition file of the second version, the second modification instruction sequence, and the generation time point of the second new node are stored in the second new node.

[0014] Optionally, after generating the target persistent version tree corresponding to the target DAG workflow definition file, the method further includes: If the nodes are in a tree-like branching relationship, then the parent node of the target persistent version tree is identified based on the tree-like branching relationship; For any given parent node, identify the total number of child nodes that reference that parent node; Store the total quantity into the parent node.

[0015] Optionally, before obtaining the code to modify the target DAG workflow definition file of the current version, the method further includes: Identify the target node in the target persistent version tree corresponding to the target DAG workflow definition file of the current version; If both the cloud and edge plugins are detected to have modified the target DAG workflow definition file of the current version, a vector clock detection is used to determine whether there is a modification conflict. If there are modification conflicts, the modification priority of the cloud and the edge plugins will be determined based on a preset merging strategy; Based on the modification priority, a main branch node and a parallel branch node are created at the target node.

[0016] Thirdly, embodiments of this application provide a workflow update apparatus applied to an edge plugin, the apparatus comprising: The first receiving module is used to receive the target DAG workflow definition file of the current version sent from the cloud; The second receiving module is used to receive a set of modification instructions carrying a digital signature sent from the cloud when it is detected that the target DAG workflow definition file has been modified in the cloud. The set of modification instructions is obtained by encoding the code that modifies the target DAG workflow definition file. A verification module is used to verify the digital signature; The update module is used to update the current version of the target DAG workflow definition file to the new version of the target DAG workflow definition file through the modification instruction set if the verification is successful. The first acquisition module is used to retrieve the previous version of the target DAG workflow definition file from the cloud if the verification fails.

[0017] Fourthly, this application provides a workflow update apparatus applied in the cloud, the apparatus comprising: The first distribution module is used to distribute the target DAG workflow definition file of the current version to the edge plugin; The second acquisition module is used to acquire the code that modifies the target DAG workflow definition file of the current version when it is detected that a modification has been made to the target DAG workflow definition file of the current version. The first encoding module is used to encode the code that modifies the target DAG workflow definition file of the current version into a set of modification instructions; The second distribution module is used to digitally sign the modification instruction set and then distribute it to the edge plugin so that the edge plugin can verify the digital signature. After successful verification, the edge plugin will update the current version of the target DAG workflow definition file to the new version of the target DAG workflow definition file by modifying the instruction set. The third distribution module is used to distribute the target DAG workflow definition file of the previous version to replace the target DAG workflow definition file of the current version after verification failure.

[0018] Fifthly, this application provides an electronic device, including: a transceiver, a memory, a processor, and a program stored in the memory and executable on the processor; The processor is used to read the program in the memory to implement any of the workflow update methods described above.

[0019] Sixthly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform any of the workflow update methods described above.

[0020] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the workflow update method as described above.

[0021] In this application, the system receives the current version of the target DAG workflow definition file from the cloud. Upon detecting modifications to the target DAG workflow definition file from the cloud, it receives a set of modification instructions with a digital signature from the cloud. This set of instructions is derived by encoding the code that modifies the target DAG workflow definition file. By receiving the modification instruction set, it is no longer necessary to distribute the full static configuration file or pull and start a completely new container instance. Only a "patching" update of the existing workflow definition is required, achieving finer-grained control, significantly reducing network overhead, increasing update speed, and minimizing network resource consumption. Adapting to narrowband edge scenarios, digital signature verification ensures the integrity and authenticity of the instruction set, preventing tampering during transmission and guaranteeing the security of workflow updates. If verification is successful, the current version of the target DAG workflow definition file is updated to the new version by modifying the instruction set. If verification fails, the previous version of the target DAG workflow definition file is retrieved from the cloud, enabling rapid self-healing from faults without relying on manual rollback, shortening system downtime and meeting the requirements for rapid system response. Attached Figure Description

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

[0023] Figure 1This is a flowchart of the steps of a workflow update method provided in this application; Figure 2 This is a flowchart of another workflow update method provided in this application; Figure 3 This is a schematic diagram illustrating an application scenario of a workflow update method provided in this application; Figure 4 This is a structural diagram of a workflow update device provided in this application; Figure 5 This is a structural diagram of another workflow update device provided in this application; Figure 6 This is a structural diagram of an electronic device provided in this application. Detailed Implementation

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

[0025] Existing workflow orchestration systems, such as Argo and Temporal, generally use static YAML (Ain't Markup Language) full deployment or container image rolling upgrades for workflow updates. However, these methods have the following drawbacks: First, full deployment means that no matter how minor the change (e.g., modifying only a configuration parameter), the entire application or configuration file needs to be transmitted from the cloud to the edge node, resulting in duplicate transmission of unchanged content and significant waste of network bandwidth. Second, the data transmission from the cloud server to the edge device in the update chain requires traversing complex public or private network paths, which are vulnerable to attack without protection. Finally, when rolling upgrades fail, manual rollback is usually required for recovery, which is time-consuming and cannot meet the system's need for rapid response. Based on these problems, this application proposes a workflow update method. (Refer to...) Figure 1 , Figure 1 This is a flowchart of the steps of a workflow update method provided in this application, applied to edge plugins, such as... Figure 1 As shown, the method may include: Step 101: Receive the target DAG workflow definition file of the current version from the cloud.

[0026] The target Directed Acyclic Graph (DAG) workflow definition file in this embodiment is a "task execution blueprint" that clearly defines which tasks to be executed (corresponding to nodes in the graph), the dependencies and order relationships between tasks (corresponding to directed edges in the graph), and the specific details of each task (e.g., which API to call, which script to run, what parameters are required, etc.). Different workflow definition files correspond to different types of workflow templates. Based on the target DAG workflow definition file, the workflow executed by the current edge plugin can be determined.

[0027] In this embodiment, the target DAG workflow definition file is typically stored in the cloud. A persistent version tree is set up in the cloud, with one persistent version tree corresponding to each DAG workflow definition file. Different nodes in the version tree are used to store immutable snapshots and modification instruction sequences of different versions of the DAG workflow definition file. Therefore, the nodes in the version tree can be called version nodes. Based on immutable snapshots, the complete content of a certain version can be quickly obtained, resulting in high read efficiency. The modification instruction sequence of each version node stores the differences between that version and its parent version. If there are multiple versions, it is necessary to start from the parent version, obtain the modification instruction sets of each version, arrange these modification instruction sets in order, and determine the modification instruction sequence of that version node. For example, there is a version node A. Updating from the parent version to version node A requires going through version nodes B and C. The parent version changes to version node B first, and at this time, modification instruction set 1 is obtained based on the version difference. Version node B changes to version node C, and at this time, modification instruction set 2 is obtained based on the version difference. Version node C changes to version node A, and at this time, modification instruction set 3 is obtained based on the version difference. At this time, the modification instruction sequence of version node A is [modification instruction set 1, modification instruction set 2, modification instruction set 3].

[0028] Based on user needs, the required version can be obtained from the persistent version tree corresponding to the target DAG workflow definition file, and used as the current version for distribution to the edge plugin. Typically, the latest version is obtained, and this application does not impose specific limitations on this.

[0029] Step 102: If the cloud detects that the target DAG workflow definition file has been modified, receive the modification instruction set carrying a digital signature issued by the cloud. The modification instruction set is obtained by encoding the code that modifies the target DAG workflow definition file.

[0030] In this embodiment, the detection of cloud modifications to the target DAG workflow definition file can be achieved through either an active push mode or a passive pull mode. In active push mode, once the cloud determines that a new version of the target DAG workflow definition file has appeared, it will proactively notify the edge plugin that the target DAG workflow definition has been updated. In passive pull mode, the edge plugin periodically queries the cloud to check if the target DAG workflow definition file has been modified; if modifications are found, an update process is triggered.

[0031] The modification instruction set in this application is a differential patch that updates the current version of the target DAG workflow definition file, not the entire file. When the cloud encodes the modified code content into a modification instruction set conforming to RFC6902 (pseudocode representation: JSONPatch), it first parses the current version of the target DAG workflow definition file into an in-memory, structured object model. Similarly, it parses the new version of the target DAG workflow definition file into the same object model. These two structured object models are compared to generate a structured difference description. This structured difference description (which already conforms to the semantics of JSON Patch) is serialized into a standard JSON string for network transmission. This serialized standard JSON string is the modification instruction set.

[0032] Before issuing modification instruction sets, the cloud platform needs to apply a cryptographically secure hash algorithm to the "modification instruction sets" (original data) to convert them into a fixed-length, unique "digital fingerprint," i.e., hash value A, ensuring data integrity. Then, the hash value is digitally signed using a private key maintained by the cloud platform, fundamentally preventing man-in-the-middle attacks and malicious code injection, making it a crucial step in ensuring operational security.

[0033] Step 103: Verify the digital signature.

[0034] In this embodiment, when the edge plugin verifies the digital signature of the modification instruction set, it first verifies the cryptographic random number nonce carried in the modification instruction set, and then retrieves the historical cryptographic random number carried by the last successfully applied modification instruction set from local storage. This historical cryptographic random number represents the sequence number last_nonce of the "latest version" in the edge plugin's perception. If nonce > last_nonce, it means that the obtained modification instruction set is a new, sequentially arriving update, and it is allowed to enter the digital signature verification stage. If nonce ≤ last_nonce, it means that the obtained modification instruction set is an expired or maliciously repeatedly sent old instruction set, and it will refuse to enter the digital signature verification stage. It should be understood that, in order to achieve the above principle, it is necessary to stipulate that the cryptographic random numbers carried by the modification instruction sets generated based on different versions of the target DAG workflow definition file are generated in a monotonically increasing manner. Therefore, step 103 specifically includes the following sub-steps: Sub-step 1031: Obtain the cryptographic random number carried by the modified instruction set.

[0035] Sub-step 1032: Obtain the historical modification instruction set issued by the previous version of the target DAG workflow definition file based on the current version of the target DAG workflow definition file.

[0036] Sub-step 1033: Extract the historical cryptographic random number carried by the historical modification instruction set.

[0037] Sub-step 1034: If the cryptographic random number is greater than the historical cryptographic random number, then verify the digital signature.

[0038] The above steps construct an efficient replay attack defense layer by introducing a monotonically increasing cryptographic random number as the sequence number. Before performing resource-intensive digital signature verification, it first conducts a lightweight "freshness" check, ensuring that only updated instructions can proceed to the subsequent verification process. This not only effectively prevents attackers from repeatedly sending old, legitimate instructions to disrupt the system, but also optimizes resource utilization and improves the efficiency and robustness of the overall security verification process.

[0039] When verifying digital signatures, a trusted public key needs to be securely stored or configured in advance on the edge plugin side. This public key corresponds to the private key used for signing in the cloud. The edge plugin uses the public key to decrypt the received digital signature, obtaining hash value B. Hash value B is compared with hash value A. If they match, the verification passes; otherwise, the verification fails, and the modification instruction set is deemed invalid. Other verification methods can also be set to verify the legality of the modification instruction set, such as verifying the edge plugin's TPM PCR value to determine if the edge plugin itself is in normal condition. This application will not elaborate further on these methods.

[0040] Step 104: If the verification is successful, update the current version of the target DAG workflow definition file to the new version of the target DAG workflow definition file by modifying the instruction set.

[0041] In this embodiment, when updating the version, the target DAG workflow definition file is modified by modifying the instruction set, avoiding the full distribution of configuration files and the resulting consumption of network resources. Furthermore, when updating the version of the target DAG workflow definition file, this embodiment first determines the original working environment of the current version of the target DAG workflow definition file, including its resource consumption, execution time, and output results. Simultaneously, real traffic (workflow execution requests) is captured as test input. Then, a replica environment (i.e., a shadow instance working environment) is created that is completely isolated from the production environment but has the same configuration. This replica environment is invisible to users and does not directly affect online business. This ensures that the testing process does not pollute production data or cause production environment failures. The new version of the DAG is then deployed to the shadow instance working environment, and the previously captured real traffic is copied (or the same historical workflow execution requests are used to drive its operation). By comparing the processing results and performance indicators (such as execution time, error rate, and resource utilization) of the new version and the current version, test results are obtained. If the test results meet expectations (such as correct functionality, improved or unchanged performance, and no new errors), the new version is hot-updated to the new production version. Based on the above description, the specific steps include: Determine the original working environment of the target DAG workflow definition file for the current version, and execute the original workflow execution request for the target DAG workflow definition file for the current version. Create a shadow instance working environment that is isolated from the original working environment; The new version of the target DAG workflow definition file was tested in the shadow instance working environment, and the test results were obtained. The test results enable hot updates of the target DAG workflow definition file from the current version to the new version.

[0042] The above steps, employing a "shadow deployment" model, construct a secure testing zone isolated from the production environment, thereby achieving lossless and full-scale simulation verification of the new version's DAG workflow definition file. This method minimizes the risks of version updates, allowing for thorough evaluation of the new version's performance and stability under real traffic and conditions. A smooth hot update is only performed after verification, fundamentally avoiding online failures and service interruptions that could result from direct updates, significantly improving the reliability of the release process and system availability.

[0043] It's important to note that during hot updates, if the test passes, new user traffic (new workflow execution requests) will be imported into the new version. The old version (the original working environment) won't be immediately shut down; instead, the old and new versions will run in parallel for a period. Users won't experience any interruption. Furthermore, if previously undetected issues are discovered during the import of new traffic into the new environment, a rollback can be performed very quickly and at low cost—simply rerouting the new requests back to the old, stable original environment, with minimal loss. Once it's confirmed that all legacy tasks in the original working environment have naturally completed, they are shut down and recycled, avoiding potential data inconsistencies or business failures that could result from forcibly terminating running tasks. Based on the above, the steps for implementing hot updates include: If the test result is passed, when a new workflow execution request is received, the new workflow execution request will be routed to the shadow instance working environment, while the original workflow execution request will continue to be executed in the original working environment. If the original workflow execution request is detected to have been completed, the original working environment is recycled.

[0044] The above steps achieve true zero downtime and smooth migration during service updates, maximizing business continuity, providing a safe rollback window for potential problems, and ensuring data integrity by only reclaiming resources after all old tasks are completed. This is a key link in risk control and user experience assurance throughout the entire hot update process.

[0045] Step 105: If verification fails, retrieve the previous version of the target DAG workflow definition file from the cloud.

[0046] This application embodiment establishes a persistent version tree for the target DAG workflow definition file in the cloud. If digital signature verification fails, it indicates a potential supply chain attack or man-in-the-middle attack. This means the attacker may have infiltrated the cloud or intercepted data during network transmission. In this case, the attacker might provide a malicious new version, or a malicious current version. Therefore, neither the new nor the current version of the target DAG workflow definition file can be accepted. To continue workflow execution, a rollback is performed using the persistent version tree to directly retrieve the previous version of the target DAG workflow definition file. This approach reduces the need for manual intervention, automatically recovers from a failed security incident, and improves operational efficiency and system resilience.

[0047] In this application, the system receives the current version of the target DAG workflow definition file from the cloud. Upon detecting modifications to the target DAG workflow definition file from the cloud, it receives a set of modification instructions with a digital signature from the cloud. This set of instructions is derived by encoding the code that modifies the target DAG workflow definition file. By receiving the modification instruction set, it is no longer necessary to distribute the full static configuration file or pull and start a completely new container instance. Only a "patching" update of the existing workflow definition is required, achieving finer-grained control, significantly reducing network overhead, increasing update speed, and minimizing network resource consumption. Adapting to narrowband edge scenarios, digital signature verification ensures the integrity and authenticity of the instruction set, preventing tampering during transmission and guaranteeing the security of workflow updates. If verification is successful, the current version of the target DAG workflow definition file is updated to the new version by modifying the instruction set. If verification fails, the previous version of the target DAG workflow definition file is retrieved from the cloud, enabling rapid self-healing from faults without relying on manual rollback, shortening system downtime and meeting the requirements for rapid system response.

[0048] Reference Figure 2 , Figure 2 This is a flowchart of another workflow update method provided in this application, applied in the cloud, such as... Figure 2 As shown, the method may include: Step 201: Deploy the target DAG workflow definition file of the current version to the edge plugin.

[0049] This application's embodiments can also be applied to the cloud. The cloud stores multiple versions of the target DAG workflow definition file, including historical versions and the latest version. The cloud stores immutable snapshots of different versions of the target DAG workflow definition file into different version nodes of the corresponding persistent version tree. Then, based on user needs, the required version can be retrieved from the persistent version tree corresponding to the target DAG workflow definition file as the current version distributed to the edge plugin. Typically, the latest version is retrieved, and this application does not specifically limit this.

[0050] This application embodiment creates a persistent version tree based on the target DAG workflow definition file. Different types of target DAG workflow definition files correspond to different persistent version trees. A persistent version tree in this application embodiment may include several nodes, with a linear sequential relationship or a tree-like branching relationship between nodes. Different nodes include immutable snapshots of different versions of the target DAG workflow definition file and different modification instruction sequences. The modification instruction sequence includes several modification instruction sets.

[0051] Therefore, in this embodiment, after creating a persistent version tree based on the target DAG workflow definition file, the initial version of the target DAG workflow definition file is first determined. Based on this version of the target DAG workflow definition file, the root node of the persistent version tree is generated. The root node is a specific, immutable node in the version tree, storing an immutable snapshot of the initial version of the target DAG workflow definition file (the complete content of the initial version file). This immutable snapshot is permanently fixed, ensuring that the initial state can always be accurately retrieved regardless of future changes. This is the foundation of version reliability. Then, an empty sequence of modification instructions is initialized and stored in the root node. According to the above, the steps for creating the root node include: Generate a persistent version tree for the target DAG workflow definition file; Determine the initial version of the target DAG workflow definition file; A root node is generated on the target persistent version tree based on the initial version of the target DAG workflow definition file. The root node includes an immutable snapshot of the initial version of the workflow definition file and an initial sequence of modification instructions.

[0052] The steps described above, by creating an independent version tree for the DAG workflow definition file, explicitly setting the initial version, and embedding its immutable snapshot and initialization instruction sequence in the root node, collectively build a solid foundation for a version management system. This approach ensures that all changes throughout the file's lifecycle have a definite, permanently traceable, and unique starting point, providing the most fundamental guarantee for subsequent accurate version rollback, change auditing, and reliable collaborative editing. It embodies the core principles of integrity, isolation, and traceability in version control.

[0053] It should be noted that after creating the target persistent version tree, multiple version nodes will be generated in the target persistent version tree based on multiple version updates to the target DAG workflow definition file. This embodiment uses the first node generated after the root node as an example for detailed explanation. Because the node stores an immutable snapshot and modification instruction sequence of the target DAG workflow definition file, it is necessary to first determine the immutable snapshot of the target DAG workflow definition file that the node needs to store. Therefore, the target modification instruction set is first determined. Based on the modified target modification instruction set, the initial version of the target DAG workflow definition file is modified to obtain the next version of the target DAG workflow definition file corresponding to the node. Simultaneously, the target modification instruction set is added to the initialized modification instruction sequence to obtain the new modification instruction sequence corresponding to the node. The specific steps include: If modifications to the initial version of the target DAG workflow definition file are detected, obtain the code that modified the initial version of the target DAG workflow definition file; The code that modifies the initial version of the target DAG workflow definition file is encoded into a target modification instruction set; Receive the next version of the target DAG workflow definition file uploaded by the edge plugin, which is the initial version of the target DAG workflow definition file generated based on the target modification instruction set; Add the target modification instruction set to the initialized modification instruction sequence to obtain the new modification instruction sequence; Based on the target DAG workflow definition file of the next version, a first new node is generated after the root node of the target persistent version tree. The first new node includes an immutable snapshot of the target DAG workflow definition file of the next version and a new sequence of modification instructions.

[0054] The above steps, by encoding code modifications into a standard instruction set and simultaneously saving version snapshots and accumulated modification instruction sequences, achieve both the integrity of version information and the efficiency of operations. This design preserves an immutable snapshot of the final state of each version for direct access, while maintaining a clear and traceable evolution path from the initial version to the current version, consisting of all modification instructions. This perfectly balances the immediacy of version retrieval with the derivability of version history analysis, laying a solid foundation for advanced features such as precise rollback, difference comparison, and collaborative development.

[0055] The above steps are illustrated using the first node generated after the root node as an example. Since the relationship between nodes can be linear or tree-like, the following explanation will use a linear relationship as an example to further illustrate the generation of nodes in the version tree. The specific steps include: If the relationship between nodes is linear, then identify the end node of the target persistent version tree, and determine the immutable snapshot of the first version of the target DAG workflow definition file and the first modification instruction sequence included in the end node; If a modification to the target DAG workflow definition file of the first version is detected, obtain the code that modified the target DAG workflow definition file of the first version; The code that modifies the target DAG workflow definition file of the first version is encoded into the first set of modification instructions; Receive the second version of the target DAG workflow definition file uploaded by the edge plugin, which is generated based on the first modification instruction set. The second version of the target DAG workflow definition file is obtained by modifying the first version of the target DAG workflow definition file. Generate a second new node after the end node of the target persistent version tree, and determine the generation time of the second new node; Add a first set of modification instructions to the first sequence of modification instructions to generate a second sequence of modification instructions; The immutable snapshot of the second version of the target DAG workflow definition file, the second modification instruction sequence, and the generation time of the second new node are stored in the second new node.

[0056] The above steps maintain a linear version evolution chain, dynamically adding new nodes after the end node, and synchronously updating immutable snapshots and accumulated modification instruction sequences, thus achieving strict order and complete traceability of version history. This design not only ensures that every change from the initial version to the latest version is accurately recorded and solidified, but also provides a clear timeline for version evolution through time point marking. Therefore, while taking into account version retrieval efficiency and storage optimization (based on instruction sequences), it provides a complete data foundation that is both logical and temporal for version rollback, audit analysis, and fault location.

[0057] It should be understood that if the relationship between nodes is a tree-like branching relationship, then between nodes with parent-child relationships, the parent node can be compared to the terminal node, and the child node can be compared to the second new node generated after the terminal node. A parent node can have multiple child nodes, and different modifications to the parent node can generate different child nodes. However, the basis for modifying these child nodes is the same: all are based on modifications to the target DAG workflow definition file within the parent node.

[0058] In addition, when this application embodiment determines that the nodes in the version tree have a tree-like branching relationship, it indicates that a parent node (i.e., a certain commit version) can be referenced by multiple child nodes (i.e., different subsequent modifications based on that version), thus forming a branch. At this time, by calculating the total number of child nodes referencing a certain parent node (including all direct and indirect descendants), the "popularity" or "importance" of the parent node's branch is quantified, and this information is stored in the parent node. The steps involved include: If the relationship between nodes is a tree-like branching relationship, then the parent node of the target persistent version tree is identified based on the tree-like branching relationship; For any given parent node, identify the total number of child nodes that reference the parent node; Store the total quantity in the parent node.

[0059] The above steps transform the dynamic, recursively computed tree relationships into static, quickly accessible metadata within the nodes by actively identifying the parent nodes of branches and materializing the reference counts of their child nodes. This greatly optimizes the query efficiency for version tree topologies and provides a crucial performance foundation for advanced operations such as garbage collection (prioritizing the retention of highly referenced nodes), branch visualization (quickly identifying the trunk and important branches), and merging strategy analysis.

[0060] It should be understood that a counter can also be set directly within the parent node. When a new node is detected referencing a parent node, the counter within that parent node will be incremented by 1.

[0061] In addition, this application embodiment also specifies that an index can be set in the version tree to support rollback by time interval. The nodes of the version tree support both AOT and JIT modes, and the JSON Patch can carry new WASM bytecode fragments to achieve operator-level hot upgrades.

[0062] Step 202: If a modification to the target DAG workflow definition file of the current version is detected, obtain the code that modified the target DAG workflow definition file of the current version.

[0063] This application embodiment sets up a conflict resolution mechanism. When the cloud and edge plugins are detected modifying the same node, vector clock detection is used to track the modification timing of the node. By comparing the partial order relationship of the vector clocks, it is determined whether a conflict exists. If the order of modification cannot be determined, it is determined to be a conflict. At this time, a parallel version tree branch is created to retain the conflicting version and avoid data loss. The specific steps include: Identify the target node in the target persistent version tree corresponding to the target DAG workflow definition file of the current version; If both the cloud and edge plugins are detected to have modified the target DAG workflow definition file of the current version, vector clock detection is used to determine whether there is a modification conflict. If there are modification conflicts, the modification priority of cloud and edge plugins will be determined based on the preset merging strategy; Create a main branch node and a parallel branch node at the target node based on the modification priority.

[0064] The preset merge strategy can be a manual merge strategy or a semantic merge strategy. The manual merge strategy is based on manually determining the modification priority, while the semantic merge strategy determines the modification priority through the mathematical merge rules of CRDTs. For modifications with high priority, a main branch node is created at the target node, serving as the trunk of the version tree; the modification is directly adopted, ensuring the continuous progress of the main process. For modifications with low priority, a parallel branch node is created at the target node, preserving complete data and context for subsequent possible viewing, backtracking, or selective merging.

[0065] The above steps, by combining precise conflict detection of vector clocks with a preset authoritative merging strategy, can not only intelligently diagnose real logical conflicts in distributed editing scenarios, but also preserve all parallel modification efforts by creating a structure of main branches and parallel branches, ensuring that the main development process is not blocked. Thus, while resolving version divergences, it minimizes the loss of work and maintains the integrity and traceability of version history.

[0066] Step 203: Encode the code that modifies the target DAG workflow definition file of the current version into a set of modification instructions.

[0067] In this embodiment, the cloud will encode the code that modifies the target DAG workflow definition file of the current version into a modification instruction set conforming to RFC6902. The pseudocode representation is JSONPatch.

[0068] Step 204: After digitally signing the modified instruction set, it is sent to the edge plugin so that the edge plugin can verify the digital signature. After successful verification, the current version of the target DAG workflow definition file is updated to the new version of the target DAG workflow definition file by modifying the instruction set.

[0069] In this embodiment, the cloud applies a cryptographically secure hash algorithm to the "modification instruction set" (original data) to be distributed, converting it into a fixed-length, unique "digital fingerprint," i.e., hash value A, ensuring data integrity. Then, the hash value is digitally signed using a private key maintained by the cloud itself. Finally, it is distributed to the edge plugin.

[0070] Step 205: After verification fails, issue the target DAG workflow definition file of the previous version to replace the target DAG workflow definition file of the current version.

[0071] When the edge plugin in this embodiment fails to verify the digital signature, it sends a verification failure message to the cloud. At this time, the cloud searches the target persistent version tree based on the target DAG workflow definition file of the current version, finds the corresponding node, and then obtains the target DAG workflow definition file of the previous version based on the modification instruction sequence in the node. The obtained target DAG workflow definition file of the previous version is then re-sent to the edge plugin. This rollback method can greatly reduce the time consumption.

[0072] In this application, by issuing modification instruction sets, it is no longer necessary to issue a full set of static configuration files, nor is it necessary to pull and start a completely new container instance. Only existing workflow definitions need to be updated in a "patching" manner, which achieves finer-grained control, greatly reduces network overhead, updates faster, and consumes less network resources. It is perfectly adapted to narrowband edge scenarios. If verification fails, the previous version of the target DAG workflow definition file of the current version is issued, which realizes rapid self-healing of faults without relying on manual rollback for recovery, shortens system downtime, and can meet the requirements of rapid system response.

[0073] Based on the above steps, it can be seen that the workflow update method of this application embodiment is applicable to scenarios including edge plugins, gateways, and the cloud, such as... Figure 3As shown, the edge plugin includes a signature verification module, a shadow instance module, and an atomic switching module. The signature verification module verifies digital signatures. The shadow instance module creates a shadow instance working environment isolated from the original working environment. The atomic switching module, upon receiving a new workflow execution request, routes the request to the shadow instance working environment while simultaneously controlling the execution of the original workflow execution request to continue in the original working environment; upon detecting the completion of the original workflow execution request, it reclaims the original working environment. The cloud includes a persistent version tree, a digital signature module, a modification instruction set generation module, and a modification code generation module. The digital signature module digitally signs the modification instruction set. The modification code generation module generates modification code based on the detected modifications to the target DAG workflow definition file of the current version. The modification instruction set generation module encodes the modification code that modifies the target DAG workflow definition file of the current version into a modification instruction set.

[0074] Figure 4 This is a structural diagram of a workflow update device provided in this application, applied to an edge plugin. The device may include: The first receiving module 301 is used to receive the target DAG workflow definition file of the current version sent from the cloud.

[0075] The second receiving module 302 is used to receive a set of modification instructions carrying a digital signature sent from the cloud when it is detected that the target DAG workflow definition file has been modified in the cloud. The set of modification instructions is obtained by encoding the code that modifies the target DAG workflow definition file.

[0076] Verification module 303 is used to verify digital signatures.

[0077] Update module 304 is used to update the current version of the target DAG workflow definition file to the new version of the target DAG workflow definition file by modifying the instruction set if the verification is successful.

[0078] The first acquisition module 305 is used to retrieve the previous version of the target DAG workflow definition file from the cloud if the verification fails.

[0079] Optionally, the verification module 303 includes: The first acquisition submodule is used to acquire the cryptographic random number carried by the modification instruction set.

[0080] The second acquisition submodule is used to acquire the historical modification instruction set issued by the previous version of the target DAG workflow definition file based on the current version of the target DAG workflow definition file.

[0081] The extraction submodule is used to extract historical cryptographic random numbers carried in the historical modification instruction set.

[0082] The verification submodule is used to verify the digital signature if the cryptographic random number is greater than the historical cryptographic random number.

[0083] Optionally, the workflow update apparatus also includes: The first determination module is used to determine the original working environment of the target DAG workflow definition file of the current version, and to execute the original workflow execution request of the target DAG workflow definition file of the current version.

[0084] Create a module to create a shadow instance working environment that is isolated from the original working environment.

[0085] The testing module is used to test the new version of the target DAG workflow definition file in the shadow instance working environment and obtain the test results.

[0086] The hot update module is used to hot update the target DAG workflow definition file from the current version to the new version based on test results.

[0087] Optional hot update modules include: The control submodule is used to route the new workflow execution request to the shadow instance working environment when a new workflow execution request is received, if the test result is passed, while controlling the original workflow execution request to continue to be executed in the original working environment.

[0088] The recycling submodule is used to reclaim the original working environment when the original workflow execution request is detected to have been completed.

[0089] In this application, the system receives the current version of the target DAG workflow definition file from the cloud. Upon detecting modifications to the target DAG workflow definition file from the cloud, it receives a set of modification instructions with a digital signature from the cloud. This set of instructions is derived by encoding the code that modifies the target DAG workflow definition file. By receiving the modification instruction set, it is no longer necessary to distribute the full static configuration file or pull and start a completely new container instance. Only a "patching" update of the existing workflow definition is required, achieving finer-grained control, significantly reducing network overhead, increasing update speed, and minimizing network resource consumption. Adapting to narrowband edge scenarios, digital signature verification ensures the integrity and authenticity of the instruction set, preventing tampering during transmission and guaranteeing the security of workflow updates. If verification is successful, the current version of the target DAG workflow definition file is updated to the new version by modifying the instruction set. If verification fails, the previous version of the target DAG workflow definition file is retrieved from the cloud, enabling rapid self-healing from faults without relying on manual rollback, shortening system downtime and meeting the requirements for rapid system response.

[0090] Figure 5 This is a structural diagram of another workflow update device provided in this application, applied in the cloud. The device may include: The first distribution module 401 is used to distribute the target DAG workflow definition file of the current version to the edge plugin.

[0091] The second acquisition module 402 is used to acquire the code that modifies the target DAG workflow definition file in the current version when a modification to the target DAG workflow definition file in the current version is detected.

[0092] The first encoding module 403 is used to encode the code that modifies the target DAG workflow definition file of the current version into a set of modification instructions.

[0093] The second distribution module 404 is used to digitally sign the modified instruction set and then distribute it to the edge plugin so that the edge plugin can verify the digital signature. After successful verification, the current version of the target DAG workflow definition file is updated to the new version of the target DAG workflow definition file by modifying the instruction set.

[0094] The third distribution module 405 is used to distribute the target DAG workflow definition file of the previous version to replace the target DAG workflow definition file of the current version after verification failure.

[0095] Optionally, the workflow update apparatus also includes: The first generation module is used to generate a persistent version tree for the target DAG workflow definition file.

[0096] The second determination module is used to determine the initial version of the target DAG workflow definition file.

[0097] The second generation module is used to generate a root node on the target persistent version tree based on the initial version of the target DAG workflow definition file. The root node includes an immutable snapshot of the initial version of the workflow definition file and an initialization sequence of modification instructions.

[0098] The third acquisition module is used to acquire the code that modified the target DAG workflow definition file in the initial version when it is detected that a modification has been made to the target DAG workflow definition file in the initial version.

[0099] The second encoding module is used to encode the code that modifies the target DAG workflow definition file of the initial version into a target modification instruction set.

[0100] The third receiving module is used to receive the next version of the target DAG workflow definition file uploaded by the edge plugin, which is the initial version of the target DAG workflow definition file generated based on the target modification instruction set.

[0101] The add module is used to add the target modification instruction set to the initialized modification instruction sequence to obtain a new modification instruction sequence.

[0102] The third generation module is used to generate the first new node after the root node of the target persistent version tree based on the target DAG workflow definition file of the next version. The first new node includes an immutable snapshot of the target DAG workflow definition file of the next version and a new sequence of modification instructions.

[0103] Optionally, the target persistent version tree includes several nodes, with a linear or tree-like branching relationship between the nodes. Different nodes include immutable snapshots of different versions of the target DAG workflow definition file and different modification instruction sequences. The modification instruction sequence includes several modification instruction sets.

[0104] The first node identification module is used to identify the end node of the target persistent version tree if the relationship between nodes is linear, and to determine that the end node includes the immutable snapshot of the target DAG workflow definition file of the first version and the first modification instruction sequence.

[0105] The fourth acquisition module is used to acquire the code that modified the target DAG workflow definition file of the first version when it is detected that a modification has been made to the target DAG workflow definition file of the first version.

[0106] The third encoding module is used to encode the code that modifies the target DAG workflow definition file of the first version into the first modification instruction set.

[0107] The fourth receiving module is used to receive the second version of the target DAG workflow definition file uploaded by the edge plugin, which is generated based on the first modification instruction set. The second version of the target DAG workflow definition file is obtained by modifying the first version of the target DAG workflow definition file.

[0108] The third determining module is used to generate a second new node after the end node of the target persistent version tree and to determine the generation time of the second new node.

[0109] The fourth generation module is used to add the first modification instruction set to the first modification instruction sequence and generate the second modification instruction sequence.

[0110] The first storage module is used to store the immutable snapshot of the second version of the target DAG workflow definition file, the second modification instruction sequence, and the generation time point of the second new node into the second new node.

[0111] The second node identification module is used to identify the parent node of the target persistent version tree based on the tree branching relationship if the nodes are in a tree-like branching relationship.

[0112] The quantity identification module is used to identify the total number of child nodes that reference any parent node.

[0113] The second storage module is used to store the total quantity into the parent node.

[0114] The third node identification module is used to identify the target node in the target persistent version tree corresponding to the target DAG workflow definition file of the current version.

[0115] The judgment module is used to determine whether there is a modification conflict when both the cloud and edge plugins have modified the target DAG workflow definition file of the current version.

[0116] The fourth determination module is used to determine the modification priority of cloud and edge plugins based on a preset merging strategy if modification conflicts exist.

[0117] The node creation module is used to create main branch nodes and parallel branch nodes at the target node based on the modification priority.

[0118] In this application, by issuing modification instruction sets, it is no longer necessary to issue a full set of static configuration files, nor is it necessary to pull and start a completely new container instance. Only existing workflow definitions need to be updated in a "patching" manner, which achieves finer-grained control, greatly reduces network overhead, updates faster, and consumes less network resources. It is perfectly adapted to narrowband edge scenarios. If verification fails, the previous version of the target DAG workflow definition file of the current version is issued, which realizes rapid self-healing of faults without relying on manual rollback for recovery, shortens system downtime, and can meet the requirements of rapid system response.

[0119] This application also provides an electronic device, such as Figure 6 As shown, it includes a processor 501, a communication interface 502, a memory 503, and a communication bus 504, wherein the processor 501, the communication interface 502, and the memory 503 communicate with each other through the communication bus 504. Memory 503 is used to store computer programs; When the processor 501 executes the program stored in the memory 503, it implements the steps in the workflow update method as described in any of the above embodiments of this application.

[0120] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into a physical address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0121] The communication interface is used for communication between the aforementioned terminal and other devices.

[0122] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0123] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0124] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the workflow update method as described in any of the above embodiments of this application.

[0125] This application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps in the workflow update method as described in any of the above embodiments of this application.

[0126] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0127] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other device. The structure required to construct such a system is obvious from the above description. Furthermore, this application is not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0128] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0129] Similarly, it should be understood that, in order to simplify this application and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together into a single embodiment, figure, or description thereof. However, this method of disclosure should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0130] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature serving the same, equivalent, or similar purpose.

[0131] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the sequencing device according to this application. This application can also be implemented as a device or apparatus program for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can take the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0132] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0133] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0134] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

[0135] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0136] It should be noted that the various data-related processes in the embodiments of this application are carried out in compliance with the relevant data protection laws and policies of the country where the location is located, and with the authorization granted by the owner of the corresponding device.

Claims

1. A workflow updating method characterized by, The method applied to an edge plug-in comprises: receiving a target DAG workflow definition file of a current version issued by a cloud; in a case where it is detected that the target DAG workflow definition file is modified by the cloud, receiving a modification instruction set carrying a digital signature issued by the cloud, the modification instruction set being obtained by encoding a code for modifying the target DAG workflow definition file; verifying the digital signature; if the verification is successful, updating the target DAG workflow definition file of the current version to a target DAG workflow definition file of a new version through the modification instruction set; if the verification fails, obtaining a target DAG workflow definition file of a previous version of the target DAG workflow definition file of the current version from the cloud.

2. The method of claim 1, wherein, The verifying the digital signature comprises: obtaining a cryptographic random number carried by the modification instruction set; obtaining a historical modification instruction set issued based on a target DAG workflow definition file of a previous version of the target DAG workflow definition file of the current version; extracting a historical cryptographic random number carried by the historical modification instruction set; if the cryptographic random number is greater than the historical cryptographic random number, verifying the digital signature.

3. The method of claim 1, wherein, After the target DAG workflow definition file of the current version is updated to the target DAG workflow definition file of the new version through the modification instruction set, the method further comprises: determining an original working environment of the target DAG workflow definition file of the current version, the target DAG workflow definition file of the current version executing an original workflow execution request; creating a shadow instance working environment isolated from the original working environment; testing the target DAG workflow definition file of the new version in the shadow instance working environment to obtain a test result; implementing a hot update of the target DAG workflow definition file from the current version to the new version through the test result.

4. The method of claim 3, wherein, The implementing the hot update of the target DAG workflow definition file from the current version to the new version through the test result comprises: if the test result is passed, in a case where a new workflow execution request is received, routing the new workflow execution request to the shadow instance working environment, while controlling the original workflow execution request to continue to be executed in the original working environment; in a case where it is detected that the original workflow execution request is executed, recycling the original working environment.

5. A workflow updating method characterized by, The method applied to the cloud comprises: issuing a target DAG workflow definition file of a current version to an edge plug-in; in a case where it is detected that the target DAG workflow definition file of the current version is modified, obtaining a code for modifying the target DAG workflow definition file of the current version; encoding the code for modifying the target DAG workflow definition file of the current version into a modification instruction set; After the modification instruction set is digitally signed, it is sent to the edge plug-in to enable the edge plug-in to verify the digital signature, and after successful verification, the current version of the target DAG workflow definition file is updated to the new version of the target DAG workflow definition file through the modification instruction set; After verification fails, the last version of the target DAG workflow definition file is sent to replace the current version of the target DAG workflow definition file.

6. The method of claim 5, wherein, Before the current version of the target DAG workflow definition file is sent to the edge plug-in, it further includes: A target persistent version tree is generated for the target DAG workflow definition file; An initial version of the target DAG workflow definition file is determined; A root node is generated on the target persistent version tree according to the initial version of the target DAG workflow definition file, and the root node includes an immutable snapshot of the initial version of the workflow definition file and an initialized modification instruction sequence.

7. The method of claim 6, wherein, After the root node is generated on the target persistent version tree according to the initial version of the target DAG workflow definition file, it further includes: In the case of detecting modification to the initial version of the target DAG workflow definition file, the code for modifying the initial version of the target DAG workflow definition file is obtained; The code for modifying the initial version of the target DAG workflow definition file is encoded into a target modification instruction set; The next version of the target DAG workflow definition file of the initial version of the target DAG workflow definition file generated based on the target modification instruction set uploaded by the edge plug-in is received; The target modification instruction set is added to the initialized modification instruction sequence to obtain a new modification instruction sequence; A first new node is generated after the root node of the target persistent version tree according to the next version of the target DAG workflow definition file, and the first new node includes an immutable snapshot of the next version of the target DAG workflow definition file and the new modification instruction sequence.

8. The method of claim 6, wherein, The target persistent version tree includes a plurality of nodes, and the nodes are in a linear sequential relationship or a tree branch relationship, and different nodes include immutable snapshots of different versions of the target DAG workflow definition file and different modification instruction sequences, and the modification instruction sequence includes a plurality of modification instruction sets.

9. The method of claim 8, wherein, After the target persistent version tree corresponding to the target DAG workflow definition file is generated, it further includes: If the nodes are in a linear sequential relationship, the end node of the target persistent version tree is identified, and it is determined that the end node includes an immutable snapshot of the first version of the target DAG workflow definition file and a first modification instruction sequence; In the case of detecting modification to the first version of the target DAG workflow definition file, the code for modifying the first version of the target DAG workflow definition file is obtained; The code for modifying the first version of the target DAG workflow definition file is encoded into a first modification instruction set; receiving a second version of the target DAG workflow definition file generated based on the first modification instruction set uploaded by the edge plugin, the second version of the target DAG workflow definition file being obtained by modifying the first version of the target DAG workflow definition file; generating a second new node after the end node of the target persistent version tree, and determining a generation time point of the second new node; adding a first modification instruction set in the first modification instruction sequence to generate a second modification instruction sequence; storing the immutable snapshot of the second version of the target DAG workflow definition file, the second modification instruction sequence, and the generation time point of the second new node into the second new node.

10. The method of claim 8, wherein, After the target DAG workflow definition file is generated to correspond to the target persistent version tree, the method further includes: if the nodes are in a tree branch relationship, identifying a parent node of the target persistent version tree based on the tree branch relationship; for any parent node, identifying a total number of child nodes that reference the parent node; storing the total number in the parent node.

11. The method of claim 6, wherein, Before the code that modifies the current version of the target DAG workflow definition file is obtained, the method further includes: identifying a target node of the current version of the target DAG workflow definition file in the target persistent version tree; in a case where it is detected that both the cloud and the edge plugin modify the current version of the target DAG workflow definition file, using a vector clock to detect whether there is a modification conflict; if there is a modification conflict, determining a modification priority of the cloud and the edge plugin based on a preset merging strategy; based on the modification priority, creating a main branch node and a parallel branch node at the target node.

12. A workflow updating apparatus characterized by comprising: The device applied to an edge plugin includes: a first receiving module configured to receive a current version of a target DAG workflow definition file issued by a cloud; a second receiving module configured to, in a case where it is detected that the cloud modifies the target DAG workflow definition file, receive a modification instruction set carrying a digital signature issued by the cloud, the modification instruction set being obtained by encoding a code that modifies the target DAG workflow definition file; a verification module configured to verify the digital signature; an updating module configured to, if the verification is successful, update the current version of the target DAG workflow definition file to a new version of the target DAG workflow definition file through the modification instruction set; a first obtaining module configured to, if the verification fails, obtain a previous version of the target DAG workflow definition file of the current version of the target DAG workflow definition file from the cloud.

13. A workflow updating apparatus characterized by comprising: The device applied to a cloud includes: a first issuing module configured to issue a current version of a target DAG workflow definition file to an edge plugin; a second obtaining module configured to, in a case where it is detected that the current version of the target DAG workflow definition file is modified, obtain a code that modifies the current version of the target DAG workflow definition file. The first encoding module is configured to encode the code for modifying the target DAG workflow definition file of the current version into a modification instruction set. The second delivery module is configured to deliver the modification instruction set after being digitally signed to the edge plug-in, so that the edge plug-in verifies the digital signature, and updates the target DAG workflow definition file of the current version into the target DAG workflow definition file of a new version through the modification instruction set after the verification is successful. The third delivery module is configured to deliver the target DAG workflow definition file of a previous version to replace the target DAG workflow definition file of the current version after the verification fails.

14. An electronic device, comprising: comprising: a transceiver, a memory, a processor, and a program stored in the memory and capable of running on the processor; the processor is configured to read the program in the memory to implement the steps in the workflow updating method according to any one of claims 1-4, or implement the steps in the workflow updating method according to any one of claims 5-11.

15. A readable storage medium for storing a program, characterized in that, the program stored in the memory is configured to be executed by the processor to implement the steps in the workflow updating method according to any one of claims 1-4, or implement the steps in the workflow updating method according to any one of claims 5-11.

Images