Dynamic identification method and system for implicit Serverless function workflow

Abstract

This paper proposes a dynamic recognition method and system for implicit Serverless function workflows. By analyzing the requirements of Serverless function workflow hosting services and the programming characteristics of implicit workflows, this system supports information merging and deduplication of existing high-similarity models after multiple recognition operations, incrementally maintaining and updating the workflow structure, and reducing recognition duplication and error rates. The corresponding recognition results can be persistently stored and can provide support for other functional services such as scheduling and monitoring in the Serverless function computing platform.

Description

Technical Field

[0001] The present invention relates to the technical field of function workflow identification in serverless computing, and in particular to a dynamic identification method and system for implicit Serverless function workflows. Background Art

[0002] The Serverless computing platform shields the underlying servers and is a type of cloud computing. The Serverless Function Workflow service, built on Serverless Function Computing, organizes individual Serverless functions into specific orchestration processes (such as DAG graphs) based on business needs and hosts them on the Serverless computing platform. This effectively reduces the complexity of building computing applications such as big data and artificial intelligence, and has become a key service in cloud computing.

[0003] Currently, serverless function workflows are often built using orchestration tools built into serverless computing platforms (such as FaaS). Therefore, information such as their topology is explicitly visible to the serverless computing platform. Related orchestration tools include workflow programming languages ​​and libraries, such as AWS Step Functions' States Language and the OpenFaaSFaas-Flow programming library. Developers write workflow definition scripts or programs according to corresponding rules and syntax and submit them to the serverless computing platform for parsing. The platform then instantiates and runs the workflow on demand based on the described program structure, and can perform process tracking and optimization during execution.

[0004] However, this approach significantly limits developers' use of serverless computing platforms. First, the workflow methods defined by various serverless computing platforms vary widely, making programs implemented based on them difficult to migrate and upgrade. Second, the workflow models supported are limited, and supporting new models requires customized runtime support at the platform level, which hinders the implementation of complex program structures and limits user programming flexibility.

[0005] Therefore, developers often choose to implicitly (customize) build their desired Serverless function workflows. Instead of directly using the orchestration tools provided by the platform, they organize program logic based solely on Serverless function call instructions, creating workflow programs that are not directly perceived by the platform. This provides greater flexibility in program construction and simplifies program semantics, facilitating development and maintenance.

[0006] However, for these customized Serverless function workflows, the computing platform cannot directly access key program information, such as the workflow structure and function dependencies. This makes it difficult to provide efficient runtime optimization support, such as affinity scheduling, data prefetching, and observability. Consequently, developers cannot fully host their programs on the computing platform and still incur significant costs in maintaining implicit Serverless function workflows. This problem has yet to be effectively addressed.

[0007] To address this issue, serverless function computing platforms need to identify implicit serverless function workflows and provide more in-depth managed services based on their key information. Key information in implicit serverless function workflows is hard-coded. Because function source files can be modified dynamically and only certain logical branches in the workflow are executed during runtime, the dynamic nature of serverless function workflows can interfere with the accuracy of existing recognition results. Due to these issues, serverless computing platforms cannot directly and efficiently extract and parse this information. Identifying implicit serverless function workflows requires new technological innovations. Summary of the Invention

[0008] In serverless computing platforms, the topology of implicit serverless function workflows cannot be effectively identified, making it difficult for the platform to provide in-depth service support for their operation. This paper proposes a dynamic identification method for implicit serverless function workflows, including a general iterative serverless function workflow identification framework and a dynamic workflow identification model based on function call relationships. This method can achieve efficient identification of the topology of implicit serverless function workflows.

[0009] Specifically, to address the shortcomings of existing technologies, this paper proposes a dynamic identification method for implicit Serverless function workflows, which includes:

[0010] Step 1: Compare the implicit Serverless function workflow sequence to be executed with the existing function workflow sequence on the Serverless computing platform to determine whether the function workflow sequence updates the function source file. If so, execute Step 2. Otherwise, the Serverless computing platform runs the current workflow model to obtain the execution result of the implicit Serverless function workflow sequence.

[0011] Step 2: Extract the function call relationship from the function workflow sequence and determine whether to update the function call relationship. If so, execute step 3. Otherwise, the Serverless computing platform runs the current workflow model to obtain the execution result of the implicit Serverless function workflow sequence.

[0012] Step 3: Identify the workflow of the function call relationship as the current workflow, and determine whether there is a historical data stream in the workflow database of the Serverless computing platform whose similarity with the current workflow is greater than a threshold. If so, merge the current workflow with the historical data stream to obtain an updated data stream, replace the historical data stream, and store it in the workflow database; otherwise, store the current workflow as an updated data stream in the workflow database; update the workflow model of the Serverless computing platform with the updated data stream, and run the workflow model on the Serverless computing platform to obtain the execution result of the implicit Serverless function workflow sequence.

[0013] The dynamic identification method for implicit Serverless function workflows, wherein step 2 includes: the Serverless computing platform compiles the implicit Serverless function workflow program, packages it into a container, and distributes the container to the corresponding function call processing to obtain the execution result of the implicit Serverless function workflow program.

[0014] The dynamic identification method for implicit Serverless function workflows, wherein step 2 includes: filtering the function call relationships extracted from the function workflow sequence to remove duplicate function call relationships.

[0015] The dynamic identification method for implicit Serverless function workflows, wherein step 2 includes: determining whether the function call relationship exists in the workflow database; if so, the function call relationship is not updated; otherwise, the function call relationship needs to be updated.

[0016] This paper also proposes a dynamic identification system for implicit Serverless function workflows, which includes:

[0017] The initialization module compares the implicit Serverless function workflow sequence to be executed with the existing function workflow sequence on the Serverless computing platform to determine whether the function workflow sequence updates the function source file. If so, the first judgment module is called. Otherwise, the Serverless computing platform runs the current workflow model to obtain the execution result of the implicit Serverless function workflow sequence.

[0018] The first judgment module is used to extract the function call relationship from the function workflow sequence and determine whether to update the function call relationship. If so, the second judgment module is called. Otherwise, the Serverless computing platform runs the current workflow model to obtain the execution result of the implicit Serverless function workflow sequence.

[0019] The second judgment module is used to identify the workflow of the function call relationship as the current workflow, and determine whether there is a historical data stream in the workflow database of the Serverless computing platform with a similarity greater than a threshold with the current workflow. If so, the current workflow is merged with the historical data stream to obtain an updated data stream, which replaces the historical data stream and is merged and stored in the workflow database; otherwise, the current workflow is stored in the workflow database as an updated data stream; the workflow model of the Serverless computing platform is updated with the updated data stream, and the Serverless computing platform runs the workflow model to obtain the execution result of the implicit Serverless function workflow sequence.

[0020] The dynamic identification system for implicit Serverless function workflows, wherein the first judgment module is used for the Serverless computing platform to compile the implicit Serverless function workflow program, package it into a container, and distribute the container to the corresponding function call processing to obtain the execution result of the implicit Serverless function workflow program.

[0021] The dynamic identification method for implicit Serverless function workflows, wherein the first judgment module is used to filter the function call relationships extracted from the function workflow sequence to remove duplicate function call relationships.

[0022] The dynamic identification method for implicit Serverless function workflows, wherein the first judgment module is used to determine whether the function call relationship exists in the workflow database. If so, the function call relationship is not updated; otherwise, the function call relationship needs to be updated.

[0023] The present invention also proposes a storage medium for storing a program for executing any one of the dynamic identification methods for implicit Serverless function workflows.

[0024] The present invention also proposes a client for any of the above-mentioned dynamic identification systems for implicit Serverless function workflows.

[0025] It can be seen from the above scheme that the advantages of the present invention are:

[0026] The present invention can effectively solve the recognition problem of implicit Serverless function workflows, and the recognition accuracy can reach 100% after multiple iterations; the recognition overhead can achieve millisecond-level processing, which can effectively support real-time recognition needs.

[0027] In summary, the present invention has good accuracy and real-time performance in identifying implicit Serverless function workflows and has good usability. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 This is a graph showing the recognition accuracy effect;

[0029] Figure 2 To identify the effect of average delay, a graph is presented;

[0030] Figure 3 Dynamically identify the framework structure diagram for Serverless function workflow;

[0031] Figure 4 Incremental update process diagram for performing workflow identification for dynamic identification models;

[0032] Figure 5 Identify a flow chart for a workflow oriented towards function source file updates;

[0033] Figure 6 Identify flow graphs for workflows oriented towards function call logs;

[0034] Figure 7 Identify flow graphs for function dispatch-driven workflows. DETAILED DESCRIPTION

[0035] This paper proposes a dynamic identification method for implicit Serverless function workflows. By analyzing the requirements for Serverless function workflow hosting services and the programming characteristics of implicit workflows, this paper proposes an iterative Serverless function workflow identification framework (referred to as the identification framework) and a Serverless dynamic identification model for function call relationships (referred to as the identification model) based on two key system interaction points: function program submission and function call execution.

[0036] The recognition framework supports dynamic expansion of workflow recognition services based on the Serverless Function Compute platform. Its architecture comprises an interface layer, an analysis and processing layer, and a data model layer. The framework provides static and dynamic analysis engines for two key interaction points. Each engine includes two key steps in its processing flow: extracting function call relationships and identifying function workflow topology structures. The former is based on analyzing static function source files or dynamic function call information.

[0037] Each step can be integrated and expanded through plug-in algorithms: for function call relationship extraction, the engine supports static semantic analysis based on Serverless function source files and runtime dynamic analysis of function call logs; for function workflow topology identification, the engine supports incremental recognition updates based on the recognition model. To address the dynamic nature of workflow expression, the recognition model combines function call parsing and incremental function workflow correction. After each recognition operation, it supports information merging and deduplication of existing high-similarity models, incrementally maintaining workflow structure updates, and reducing recognition duplication and error rates. The corresponding recognition results can be persistently stored and can provide support for other functional services such as scheduling and monitoring on the Serverless function computing platform.

[0038] In order to make the above features and effects of the present invention more clearly understood, embodiments are given below and described in detail with reference to the accompanying drawings.

[0039] The present invention includes the following key technical points:

[0040] Key Point 1: Iterative Serverless Function Workflow Identification Framework. The iterative Serverless Function Workflow Identification Framework (referred to as the Identification Framework) is the foundational framework supporting the method described in this paper. Focusing on two key interaction points in the Serverless Function Workflow system (function program submission and function call execution) and key interaction information, the Identification Framework provides organizational management capabilities for workflow identification and processing, supporting incremental workflow identification in an iterative manner. The Identification Framework is architecturally divided into three layers: the interface layer, the analysis and processing layer, and the data model layer.

[0041] The core functions of the analysis and processing layer support the extraction of function call relationships and the identification and updating of function workflow topology structures. In terms of extraction and identification and updating, the framework provides a plug-in extension mechanism for the dynamic workflow identification model based on function call relationships, allowing for corresponding algorithm adaptation for different scenarios. In terms of call relationship extraction, the method mainly analyzes the function information submitted by the computing platform and identifies the call relationships expressed therein. It supports the integration and switching of static semantic analysis methods for Serverless function source files, and runtime dynamic identification methods for function calls. In terms of workflow topology identification and updating, online and offline analysis of the model topology is performed based on the call relationship, the existing workflow topology is updated incrementally through the identification model, and the identification results are persistently stored.

[0042] The Serverless function workflow recognition framework can be integrated with the Serverless function computing platform in an internal or bypass form. It has high scalability and the processing process is not affected by the specific workflow structure. The recognition accuracy of implicit Serverless function workflows increases with the number of iterations and can eventually reach 100%. Figure 1 The figure shows the changes in recognition accuracy obtained from the tests of five workflow use cases. Each use case achieved 100% topology structure recognition after multiple iterations.

[0043] Key Point 2: Dynamic Workflow Identification Model Based on Function Call Relationships. This dynamic workflow identification model based on function call relationships (referred to as the identification model) is the fundamental data model that supports the Serverless function workflow dynamic identification framework. It supports iterative and incremental expansion of function workflow topology information and, through similarity analysis, supports the merging and deduplication of duplicate models, reducing the repetition rate of the final identification model during updates.

[0044] The recognition model describes the program structure of function workflows based on a graph model, using vertices to represent Serverless functions and lines to represent function call relationships. Within the recognition framework, iterative recognition behavior can be modeled as incremental updates to the graph. When a recognition request is received, the analyzed function call relationships are filtered using a function call filter to avoid repeated recognition of the same call relationships within the same workflow and reduce unnecessary recognition load. Cuckoo Filter is used for filter selection. Next, correlation analysis is performed, and function workflows with a high correlation to the current function call relationship are updated. Subsequently, similarity analysis is performed, using similarity calculation and threshold judgment to merge and deduplicate highly similar function workflows.

[0045] The workflow dynamic recognition model based on function call relations can complete the relevant processing of a single function call recognition task in real time and has high availability. Figure 2 The recognition overhead statistics obtained from testing five workflow use cases are shown, with the average latency controlled within 30ms.

[0046] The implementation of this invention is based on an iterative Serverless function workflow recognition framework. It internally integrates a dynamic workflow recognition model based on function call relationships and externally integrates key Serverless computing processes, including workflow recognition for function source files, workflow recognition for function call logs, and workflow recognition driven by function scheduling. The implementation method is now described in detail:

[0047] 1. Building an Iterative Serverless Function Workflow Identification Framework

[0048] The iterative Serverless function workflow recognition framework supports recognition and post-recognition observation in terms of functionality. It includes three core layers: recognition interface layer, analysis and processing layer, and data model layer. Figure 3 The hierarchical structure of the recognition framework allows it to be implemented in various forms, such as a programming library, an internal module, or an independent service.

[0049] The recognition interface layer provides access to recognition and post-recognition observation functions, supporting both synchronous and asynchronous interface access. The corresponding recognition interface provides a semantics-oriented static analysis interface and a function call-oriented dynamic analysis interface. The static analysis interface receives function source file data (customized Serverless function workflow sequence) as input, while the dynamic analysis interface receives function call request information as input. Both output function workflow recognition results. The corresponding observation interface receives function call request information as input and outputs updated observation data structures. The recognition interface layer forwards processing requests to the analysis and processing layer module for specific processing. Function call request information is issued by each function when calling other functions, and is called in the form of HTTP, RPC, etc.

[0050] The analysis and processing layer provides the actual functional management of identification. The identification and processing of workflow topology includes two steps: extraction of function call relationships and identification and update operations of workflow topology structure. The framework can support the identification requirements of two key system interaction moments: function program submission and function call operation. In addition to the two interaction moments, the computing platform can also call the corresponding interface to perform non-real-time identification processing. The framework has built a semantic-oriented static analysis engine and a function call-oriented dynamic analysis engine. Different specific algorithms can be configured in a plug-in manner within the engine, and analysis and calculation can be carried out locally or in a mode compatible with other computing platforms. Within each engine, the organization is based on the two steps of function call relationship extraction and workflow topology structure identification and update:

[0051] 1) Function call relationship extraction. Function call relationships are analyzed based on information such as source files or call logs provided by the computing platform, from which specific function call relationship tuples are extracted. Depending on the interaction time and input information, various static semantic analysis methods or runtime dynamic analysis methods can be used. Analysis methods can be configured and integrated via plug-ins, and function call relationship information can be output. Static semantic analysis methods can use compilation-level analysis algorithms such as lexical analysis and syntax analysis. Runtime dynamic analysis algorithms can use online or offline function call log analysis algorithms, clustering algorithms based on function call request IDs, etc.

[0052] 2) Workflow topology identification and update. Workflow topology update is performed based on call relationships and in conjunction with a dynamic recognition model. Based on the function call relationship extraction, the dynamic recognition model uses function workflow topology analysis methods, such as clustering algorithms based on function call request IDs, to identify and update the function workflow topology structure. This is then incrementally updated within the dynamic model. The framework dynamically updates the workflow model's persistent data based on relevant analysis modes (e.g., online, offline) and analysis methods.

[0053] The data model layer provides support for workflow topology structure identification and update operations in the analysis and processing layer. The data model layer defines a dynamic workflow identification model based on function call relationships.

[0054] 2. Build a dynamic workflow recognition model based on function call relationships in the framework

[0055] A dynamic workflow recognition model based on function call key abstracts the topology of function workflows, including defining their data structure and access and update methods, to enable efficient, incremental maintenance. This recognition model supports iterative and incremental expansion of function workflow topology information and, through similarity analysis, supports merging and deduplication of duplicate models, reducing the repetition rate of the final recognition model during updates.

[0056] At the data model level, it describes the program structure of function workflows based on a graph model, with vertices representing Serverless functions and lines representing function call relationships. Within the recognition framework, iterative recognition can be modeled as incremental updates to the graph. When a recognition request is received, the analyzed function call relationships are filtered using a function call filter to avoid repeated recognition of the same call relationships within the same workflow and reduce unnecessary recognition load. Cuckoo Filter is used for filter selection. Next, a correlation analysis is performed, and function workflows with a high correlation to the current function call relationship are updated. During the update, similarity analysis is performed, using similarity calculation and threshold judgment to merge and deduplicate highly similar function workflows. If there are no related or highly similar function workflows, they are marked as new function workflows. The data model layer provides a persistence interface for connecting to external storage.

[0057] The dynamic recognition model performs the workflow recognition process as follows Figure 4 As shown, it can support recognition processing after static and dynamic call relationship extraction, which mainly includes three steps:

[0058] Step 1: Filter function call relationships. Filter repeated call relationships in function calls to avoid repeated calculations.

[0059] Step 2: Function workflow relevance calculation. Analyze the workflows associated with the current function call and analyze and calculate the best matching workflow. Then, perform similarity calculation based on the best matching workflow.

[0060] Relevance calculation involves finding the most relevant workflow from the previously identified workflows and updating the call relationships. Similarity calculation compares the new relationships obtained in the previous step with existing relationships, as duplicates may exist and are deleted if found.

[0061] Step 3: Calculate function workflow similarity. If a function call results in an update to the function workflow, perform a similarity comparison on the updated workflow to eliminate duplicate workflow models. If the workflow found in Step 2 does not contain the function call relationship in Step 1, it needs to be updated.

[0062] Step 4: Incrementally update the function workflow by adding the corresponding function call relationship to the old workflow. Perform deduplication and merging operations on the updated function workflow. Replace the old workflow with the new call workflow. Because there may be many similar workflows, you need to find the one that best matches the current call relationship.

[0063] 3. Improve workflow by identifying workflows for function source files

[0064] The workflow identification process of function source file update describes the system workflow of the present invention supporting the function program submission time, such as Figure 5 The processing mainly includes three stages:

[0065] Phase 1: Function Update Request Phase. The computing platform submits a recognition request to the framework based on the function update request. For example, if a user modifies the program code, it must be re-uploaded to the computing platform. The computing platform will treat this as an update request and update the program code. Subsequent program runs will use the updated program.

[0066] Step 1-1: Compare the newly uploaded function with the original platform content to determine whether the function source file is updated. If not, processing ends. The computing platform compiles the uploaded program, packages it into a container, and then distributes it to the corresponding function call processing according to the requested content.

[0067] Step 1-2: If source file updates are included, execute the framework static analysis interface.

[0068] Phase 2: Identification based on static analysis: The identification framework will perform static analysis and identify the workflow topology based on the results.

[0069] Step 2-1: Use static analysis to determine whether there are any function call relationship updates in the source file. If no updates are found, the process ends.

[0070] Step 2-2: incrementally update the extracted function call relationship through the dynamic recognition model.

[0071] Step 2-3: Persist the updated function workflow topology.

[0072] Phase 3: Notify the computing platform to update its computing status. If the updating platform is currently performing other computations that depend on the currently updated workflow, it needs to be updated accordingly.

[0073] The computing platform loads the topology of the function workflow during runtime, so any updates require the updated content. This topology helps the computing platform optimize scheduling, storage, and other management. For example, programs can be deployed in advance based on the topology to reduce response latency.

[0074] 4. Improve workflow by identifying workflows for function call logs

[0075] The workflow identification process for function call logs describes the system workflow of the present invention supporting function call runtime, such as Figure 6 The processing mainly includes three stages:

[0076] Phase 1: Function update request phase. Synchronous and asynchronous recognition requests can be executed.

[0077] Step 1-1: Determine whether to perform real-time workflow recognition. If real-time recognition is not required, store the call log in the offline data warehouse for analysis during batch processing, ending the current processing.

[0078] Step 1-2: Perform workflow matching analysis for a real-time call request or a call request in batch processing.

[0079] Phase 2: Workflow update analysis phase: Determine whether the workflow topology needs to be updated.

[0080] Step 2-1: Combine the recognition model to determine whether the current call request has any updates in the matching workflow. If not, the process ends.

[0081] Step 2-2: If there is an update, perform an incremental update operation.

[0082] Step 2-3: Persist the updated function workflow topology.

[0083] Phase 3: Notify the computing platform to update its computing status.

[0084] 5. Build a function scheduling driven workflow recognition workflow

[0085] The workflow identification process driven by function scheduling is as follows Figure 7 As shown, it supports the use of workflow models at the time of function scheduling, so that function scheduling can perform calculations such as scheduling optimization based on the latest workflow topology.

[0086] The following is a system embodiment corresponding to the above method embodiment. This embodiment can be implemented in conjunction with the above embodiment. The relevant technical details mentioned in the above embodiment are still valid in this embodiment and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiment.

[0087] This paper also proposes a dynamic identification system for implicit Serverless function workflows, which includes:

[0088] The initialization module compares the implicit Serverless function workflow sequence to be executed with the existing function workflow sequence on the Serverless computing platform to determine whether the function workflow sequence updates the function source file. If so, the first judgment module is called. Otherwise, the Serverless computing platform runs the current workflow model to obtain the execution result of the implicit Serverless function workflow sequence.

[0089] The first judgment module is used to extract the function call relationship from the function workflow sequence and determine whether to update the function call relationship. If so, the second judgment module is called. Otherwise, the Serverless computing platform runs the current workflow model to obtain the execution result of the implicit Serverless function workflow sequence.

[0090] The second judgment module is used to identify the workflow of the function call relationship as the current workflow, and determine whether there is a historical data stream in the workflow database of the Serverless computing platform with a similarity greater than a threshold with the current workflow. If so, the current workflow is merged with the historical data stream to obtain an updated data stream, which replaces the historical data stream and is merged and stored in the workflow database; otherwise, the current workflow is stored in the workflow database as an updated data stream; the workflow model of the Serverless computing platform is updated with the updated data stream, and the Serverless computing platform runs the workflow model to obtain the execution result of the implicit Serverless function workflow sequence.

[0091] The dynamic identification system for implicit Serverless function workflows, wherein the first judgment module is used for the Serverless computing platform to compile the implicit Serverless function workflow program, package it into a container, and distribute the container to the corresponding function call processing to obtain the execution result of the implicit Serverless function workflow program.

[0092] The dynamic identification method for implicit Serverless function workflows, wherein the first judgment module is used to filter the function call relationships extracted from the function workflow sequence to remove duplicate function call relationships.

[0093] The dynamic identification method for implicit Serverless function workflows, wherein the first judgment module is used to determine whether the function call relationship exists in the workflow database. If so, the function call relationship is not updated; otherwise, the function call relationship needs to be updated.

[0094] The dynamic recognition system for implicit Serverless function workflows is described. The Serverless computing platform organizes and manages the workflow recognition process based on two key time points and key interaction information of Serverless function workflow interactions, and performs incremental workflow recognition in an iterative manner. The recognition framework is architecturally divided into three layers: the interface layer, the analysis and processing layer, and the data model layer.

[0095] The two key time points are the key interaction information when the function program is submitted and when the function is called and run. When the function program is submitted, the key interaction information is the updated function program source file; when the function is called and run, the key interaction information is the function call request information;

[0096] The Serverless computing platform also features a dynamic workflow recognition model based on function call relationships. This is the basic data model used to support the Serverless function workflow dynamic recognition framework. It supports iterative and incremental expansion of the topological structure information of the function workflow, and can support the merging and deduplication of duplicate models through similarity analysis, thereby reducing the repetition rate of the final recognition model during updates.

[0097] The present invention also proposes a storage medium for storing a program for executing any one of the dynamic identification methods for implicit Serverless function workflows.

[0098] The present invention also proposes a client for any of the above-mentioned dynamic identification systems for implicit Serverless function workflows.

Claims

1. A dynamic identification method for implicit Serverless function workflows, characterized by: include: Step 1: Compare the implicit Serverless function workflow sequence to be executed with the existing function workflow sequence on the Serverless computing platform to determine whether the function workflow sequence updates the function source file. If so, execute Step 2. Otherwise, the Serverless computing platform runs the current workflow model to obtain the execution result of the implicit Serverless function workflow sequence. Step 2: Extract the function call relationship from the function workflow sequence and determine whether to update the function call relationship. If so, execute step 3. Otherwise, the Serverless computing platform runs the current workflow model to obtain the execution result of the implicit Serverless function workflow sequence. Step 3: Identify the workflow associated with the function call and use it as the current workflow. Determine whether there is a historical data stream in the workflow database of the Serverless computing platform whose similarity to the current workflow exceeds a threshold. If so, merge the current workflow with the historical data stream to obtain an updated data stream, replace the historical data stream, and store it in the workflow database. Otherwise, store the current workflow as the updated data stream in the workflow database. The workflow model of the Serverless computing platform is updated with the updated data stream, and the Serverless computing platform runs the workflow model to obtain the execution result of the implicit Serverless function workflow sequence.

2. The method for dynamic identification of implicit Serverless function workflows according to claim 1, characterized in that: Step 2 includes: the Serverless computing platform compiles the implicit Serverless function workflow program, packages it into a container, and instantiates the function container for processing the corresponding function call request to obtain the execution result of the implicit Serverless function workflow program.

3. The dynamic identification method for implicit Serverless function workflows according to claim 1 is characterized in that: Step 2 includes: filtering the function call relationships extracted from the function workflow sequence to remove duplicate function call relationships; determining whether the function call relationship exists in the workflow database, if so, not updating the function call relationship, otherwise updating the function call relationship.

4. The dynamic identification method for implicit Serverless function workflows according to claim 1 is characterized in that: The serverless computing platform also organizes and manages the workflow identification process based on two key time points and key interaction information of serverless function workflow interactions, and performs incremental workflow identification in an iterative manner. The identification framework is architecturally divided into three layers: the interface layer, the analysis and processing layer, and the data model layer. The two key time points are the key interaction information when the function program is submitted and when the function is called and run. When the function program is submitted, the key interaction information is the updated function program source file; when the function is called and run, the key interaction information is the function call request information; The Serverless computing platform also features a dynamic workflow recognition model based on function call relationships. This is the basic data model used to support the Serverless function workflow dynamic recognition framework. It supports iterative and incremental expansion of the topological structure information of the function workflow, and can support the merging and deduplication of duplicate models through similarity analysis, thereby reducing the repetition rate of the final recognition model during updates.

5. A dynamic identification system for implicit Serverless function workflows, characterized by: include: The initialization module compares the implicit Serverless function workflow sequence to be executed with the existing function workflow sequence on the Serverless computing platform to determine whether the function workflow sequence updates the function source file. If so, the first judgment module is called. Otherwise, the Serverless computing platform runs the current workflow model to obtain the execution result of the implicit Serverless function workflow sequence. The first judgment module is used to extract the function call relationship from the function workflow sequence and determine whether to update the function call relationship. If so, the second judgment module is called. Otherwise, the Serverless computing platform runs the current workflow model to obtain the execution result of the implicit Serverless function workflow sequence. The second judgment module is used to identify the workflow of the function call relationship as the current workflow and determine whether there is a historical data flow with a similarity greater than a threshold with the current workflow in the workflow database of the serverless computing platform. If so, the current workflow is merged with the historical data flow to obtain an updated data flow, which replaces the historical data flow and is stored in the workflow database. Otherwise, the current workflow is stored in the workflow database as the updated data flow. The workflow model of the Serverless computing platform is updated with the updated data stream, and the Serverless computing platform runs the workflow model to obtain the execution result of the implicit Serverless function workflow sequence.

6. The dynamic identification system for implicit Serverless function workflows according to claim 5 is characterized in that: The first judgment module is used by the Serverless computing platform to compile the implicit Serverless function workflow program, package it into a container, and distribute the container to the corresponding function call processing to obtain the execution result of the implicit Serverless function workflow program.

7. The method for dynamic identification of implicit Serverless function workflows according to claim 5, characterized in that: The first judgment module is used to filter the function call relationship extracted from the function workflow sequence and remove duplicate function call relationships; determine whether the function call relationship exists in the workflow database, if so, the function call relationship is not updated, otherwise the function call relationship needs to be updated.

8. The dynamic identification system for implicit Serverless function workflows according to claim 5, characterized in that: The serverless computing platform organizes and manages the workflow identification process based on two key time points and key interaction information of serverless function workflow interactions, and performs incremental workflow identification in an iterative manner. The identification framework is architecturally divided into three layers: the interface layer, the analysis and processing layer, and the data model layer. The two key time points are the key interaction information when the function program is submitted and when the function is called and run. When the function program is submitted, the key interaction information is the updated function program source file; when the function is called and run, the key interaction information is the function call request information; The Serverless computing platform also features a dynamic workflow recognition model based on function call relationships. This is the basic data model used to support the Serverless function workflow dynamic recognition framework. It supports iterative and incremental expansion of the topological structure information of the function workflow, and can support the merging and deduplication of duplicate models through similarity analysis, thereby reducing the repetition rate of the final recognition model during updates.

9. A storage medium for storing a program for executing any one of the dynamic identification methods for implicit Serverless function workflows as described in claims 1 to 4.

10. A client for use in any one of claims 5 to 8 in a dynamic identification system for implicit Serverless function workflows.

Images