Responsive Serverless function arrangement and operation device

Abstract

The invention discloses a response type Serverless function arrangement and operation device. The response type Serverless function arrangement and operation device comprises a declarative Serverless function arrangement device and a response type Serverless function flow operation device. The declarative Serverless function arrangement device abstracts data into Lambda items and nodes by providing a declarative function arrangement interface, and the device compiles Serverless function arrangement into a static graph; the response type Serverless function operation device carries out topological sorting on the static graph, analyzes independence between data and parallelism of an arrangement function, and executes the static graph in a response type operation and parallel calculation mode. According to the invention, a functional programming method and parallel optimization of Serverless function arrangement can be realized.

Description

Technical Field

[0001] The present invention relates to a responsive Serverless function orchestration and operation device, belonging to the technical field of cloud computing. Background Art

[0002] Serverless computing is an emerging cloud computing method that proposes a concept of serverless awareness, that is, developers only need to submit resources to the Serverless cloud computing platform, and do not need to worry about the server's operating status and resource usage. They only need to access resources through the interface provided. FaaS, function as a service, is a service provision method. Its idea is to use functions as services and expose interfaces to the outside world. Users can access functions through interfaces and obtain the results returned by function calculations. The combination of Serverless computing and FaaS is called Serverless function computing.

[0003] When a computing task is more complex, a single Serverless function is limited by the maximum computing time provided by the platform and cannot complete the more complex computing task. It is necessary to use multiple deployed Serverless functions for orchestration computing. Serverless function orchestration refers to the process in which a user defines a process in which multiple Serverless functions work together to complete a complex task. Serverless functions are orchestrated into a function flow to execute tasks. In order to achieve efficient operation of function flows, many existing inventions optimize the execution of function orchestration in various ways.

[0004] According to an IBM paper, Serverless function orchestration needs to meet three paradigms: 1) Function calls must be black-box calls, which means that function flows cannot be optimized by optimizing already deployed Serverless functions; 2) Function flow calls are a type of function calls, which means that calling a function flow should have the same semantics as calling a function. Furthermore, a function flow can be nested inside another function flow; 3) Function flow calls need to avoid double billing. A function flow will wait for results when calling other functions. The final running time is twice the execution time of all called functions plus the time of the function flow itself. Avoiding double billing means avoiding meaningless waiting time for function flows.

[0005] Generally speaking, the existing Serverless function orchestration lacks a declarative function orchestration method. The Serverless function orchestration of some Serverless computing platform vendors is expressed in YAML format. For example, Alibaba Cloud's CloudFlow product provides a set of DSLs based on YAML to orchestrate various Serverless functions. The disadvantage of this method is that the learning cost of DSL-based function orchestration is too high and it is difficult to debug; Microsoft's DurableFunction allows users to call Serverless functions through interfaces through imperative programming, rather than declaratively; IBM's Openwhisk controls the logical order of the running of Serverless function flows through operators. This method is essentially still imperative function programming, with program control structure as the core.

[0006] Generally speaking, the existing Serverless function orchestration lacks a responsive running form, and most function orchestrations lack automatic parallel execution. Microsoft's Durable Function is an orchestration function implemented through a recording and playback mechanism. When it calls other Serverless functions, the orchestration function will be destroyed. When the called function sends an event back, the function will be restarted again according to the event. This execution method will waste resources on the overhead of constantly restarting instances, and when the workflow is too long, constant playback will also cause a certain amount of computing time waste; Alibaba Cloud's CloudFlow implements program parallelization through user-declared parallel and branch structures, and the undeclared parallel parts will be executed in serial mode. Summary of the invention

[0007] Purpose of the invention: In view of the problems and shortcomings existing in the prior art, the present invention provides a Serverless function orchestration device based on a declarative orchestration interface and running in a responsive manner, so as to achieve parallel optimization of Serverless function orchestration execution.

[0008] Technical solution: A responsive Serverless function orchestration and operation device, including a declarative Serverless function orchestration device and a responsive Serverless function flow operation device. The declarative Serverless function orchestration device abstracts data into Lambda items and nodes by providing a declarative function orchestration interface, and the device compiles the Serverless function orchestration into a static graph; the responsive Serverless function operation device topologically sorts the static graph, analyzes the independence between data and the parallelism of the orchestration function, and executes the static graph through responsive operation and parallel computing.

[0009] The orchestration device allows users to use the front-end language to write the flow form of data objects by providing SDK. This process is called declarative orchestration function flow. After the user submits the function flow written in the front-end language, the orchestration device abstracts the data objects written by the user into nodes. Each data object is maintained by a node. This process is called data abstraction into nodes. After that, the orchestration device associates the dependencies of the nodes and compiles them into a static graph. This process is called static graph compilation. Therefore, the orchestration device is mainly divided into the following steps: declarative orchestration function flow, data abstraction into nodes, and static graph compilation.

[0010] Declarative orchestration of function flow means that users use the declarative programming interface to write the processing workflow of each data in the user code with data as the center.

[0011] Data abstraction as nodes means that in the program, all data objects are regarded as lambda objects, and operations on lambda objects will be lazily applied to real data objects. Lambda items are maintained through data nodes, and the conversion process of lambda items is maintained by control nodes. Therefore, data abstraction as nodes is to abstract data into the relationship between data nodes and control nodes, and both data nodes and control nodes are transparent to users.

[0012] The data node maintains a lambda item, which includes two states: ready state and not ready state. If the lambda item already has a real value, it is in the ready state. If the lambda item has no real value, it is not ready. The control node maintains a function, which should be expressed in the following form λx.f(x), indicating a function that receives a parameter as an input parameter, which includes two states: computable state and uncomputable state. When all the input parameters of the function maintained by the control node have real values, it is in the computable state, otherwise it is in the uncomputable state.

[0013] Data nodes and control nodes have a mutually dependent relationship. A data node may send data to zero or more control nodes, and these control nodes become the successors of the data node, and the data node becomes the dependency of these control nodes. A data node depends on a control node, that is, the value of the data node needs to be calculated by the function maintained by the control node, and the data node becomes the successor of the control node. The dependency relationship between data nodes and control nodes meets the following specifications: a data node has at most one control node as its predecessor, and may have multiple successors; a control node can have any number of data nodes as its predecessor, and at most one successor data node; data nodes are not connected to each other, and control nodes are not connected to each other.

[0014] Static graph compilation refers to the process in which the function calls contained in the user-defined function flow during the compilation process are not actually called, but recorded, implemented lazy operations, and finally form a static graph. The compilation process includes two processes: lazy execution and pre-execution compilation.

[0015] Lazy execution means that the intermediate data generated by the Serverless orchestration function during its operation is represented by lambda items. When the orchestration function calls other Serverless functions or performs operations on lambda items, it does not wait for the execution result of the function, but maintains a reference to the result through the lambda item.

[0016] Pre-execution compilation: The operation on the lambda item in the orchestration function will be represented as the operation on the data maintained by it, and a control node will be generated to record the operation record on the lambda item, and the corresponding control node will be generated. The specific process is as follows: a) Generate data nodes through input parameters: When a user calls a function or operates a lambda item, its input parameters will be converted into lambda items, and data nodes will be obtained or generated; b) Call function to generate control nodes: All lambda conversion processes in the orchestration function can be converted into functions. When the user modifies the data through function calls or directly acts on the lambda item, the call or modification operation will be converted into a function, which generates a control node, which depends on the data node described in step a); c) Generate data nodes through output parameters: The return value of the control node described in step b) is a lambda item, and the data node of the lambda item is generated, and the data node is used as the successor node of the control node in step b), and the lambda is returned to the user.

[0017] The running device is mainly implemented in the following steps: topological sorting, responsive execution, and parallel computing.

[0018] The process of topological sorting is to analyze which nodes in the current task graph state are already computable or ready, add the computable or ready nodes to the task queue, obtain the nodes in the task queue continuously, obtain the subsequent nodes of the nodes, and send messages to them. If the successor node also reaches a computable or ready state, the successor node is added to the topological sort.

[0019] Responsive execution is the subsequent step of topological sorting. When a data node is ready, it will send real-value information to the successor control node it points to. In essence, the real-value information is the calling parameter of the function. After receiving the information, the control node adds the calling parameter to its own parameter value. The process can be expressed as (λxy.xy)a=λy.ay. After applying the parameters, it will determine whether its own parameter conditions meet the computable conditions. If the calculation conditions are met, the execution of the control node is triggered. a represents the actual parameter, y represents the formal parameter, and the equation represents a function that receives two parameters xy. At the same time, it receives an a as the actual parameter to replace x, which becomes only a y as a parameter, and then the function content already has a instead of x.

[0020] Parallel computing includes two aspects. On the one hand, it is data parallelism. When the data in a data node is aggregated in the form of a list by multiple lambda items, and the processing method for the data node is MapReduce type, this device will automatically generate a control node for each data, and concurrently apply the function in the control node to each data item, and finally aggregate the results; on the other hand, it is task parallelism. When multiple control nodes are in a computable state, that is, the data nodes they depend on are independent of each other, these control nodes can be calculated in parallel.

[0021] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0022] First, users can more naturally express the data flow processing flow by defining function flows based on declaratively orchestrated interfaces, which is more natural to express through the idea of ​​functional programming. Second, static graph compilation facilitates the execution optimization of function flows. By pre-executing function flows to obtain static graphs, data dependencies on the static graphs can be analyzed, and control nodes without dependencies can be optimized in parallel. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 A diagram showing the relationship between data nodes and control nodes in the embodiment;

[0024] Figure 2 This is a diagram of the optimization process of a static graph formed by data nodes and control nodes in the embodiment, wherein the control nodes in the same dotted box can be calculated in parallel;

[0025] Figure 3 A diagram showing the process of compiling the function arrangement code into a static graph in the embodiment;

[0026] Figure 4 Schematic diagram of the device of the embodiment. DETAILED DESCRIPTION

[0027] The present invention is further explained below in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and are not used to limit the scope of the present invention. After reading the present invention, various equivalent forms of modifications to the present invention by those skilled in the art all fall within the scope defined by the claims attached to this application.

[0028] A responsive Serverless function orchestration and operation device comprises a declarative Serverless function orchestration device and a responsive Serverless function flow operation device. The declarative Serverless function orchestration device abstracts data into Lambda items and nodes by providing a declarative function orchestration interface, and the device compiles the Serverless function orchestration into a static graph; the responsive Serverless function operation device topologically sorts the static graph, analyzes the independence between data and the parallelism of the orchestration function, and executes the static graph by responsive operation and parallel computing.

[0029] The SDK provides a declarative Serverless function orchestration interface. The following are the specific implementation steps:

[0030] Step 1: Define the Serverless function and Serverless function flow. The specific implementation steps are as follows:

[0031] 11. Implement the @function and @workflow interfaces through decorators. @function converts the defined function F into (λfx.f(x))F= β λx.F(x), where x represents the runtime interface of the Serverless function, which is used to control the behavior of the Serverless function. At the same time, the interface can specify a name through a parameter, indicating the remote service address of the function; @workflow converts the defined function G into (λfx.f(x))G= β The static graph shown in λx.G(x) shows that x represents the runtime interface of the Serverless function flow.

[0032] 12. Unified runtime interface implementation. The unified runtime interface of the serverless function should include the following functions: obtaining input and output, and synchronously and asynchronously calling other functions. All functions will be implemented through this unified runtime interface. The definition of the serverless function is def f(frt), and the definition of the serverless function flow is defworkflow(wf).

[0033] 13. Expose the service externally. By exposing the Serverless function or Serverless function flow defined above as a handler, the Serverless platform can be called. The service only needs to receive an event structure as an input parameter to trigger the execution of the Serverless function flow through the handler (event) method.

[0034] Step 2: Front-end interface implementation. Users use the defined declarative programming interface to define the Serverless function flow. The specific implementation is as follows:

[0035] 21. Input interface implementation. The input interface of the function flow can be obtained through wf in def workflow(wf), where wf.input can obtain the input parameters of the function;

[0036] 22. Call interface implementation. The calling process of the workflow can be defined through wf in def workflow(wf). wf.call means calling a remote Serverless function. The name of the Serverless function is passed in as the function index, followed by a parameter list to indicate the input parameters of the calling function. wf.func means calling a local function. The local function pointer is directly passed in as the function index, followed by a parameter list to indicate the input parameters.

[0037] Step 3: Implementation of the data abstraction process. This process will introduce the implementation of Lambda class, data node, and control node. The specific steps are as follows:

[0038] 31. Implementation of Lambda class. The constructor of Lambda class is a default constructor. When a parameter value is passed into it, the Lambda class is a lambda item with a real value. All operation methods will be rewritten in Lambda class, such as addition, subtraction, multiplication and division of integers, and value operation of dictionaries. In this way, the operation of Lambda class can be made lazy.

[0039] 32. Implementation of data nodes. Data nodes are constructed using a Lambda object as a constructor. During the construction process, the data node pointer of the aggregated Lambda object is pointed to itself to complete the binding of the data node and the Lambda object. Data nodes implement adding successor nodes, setting the interface of predecessor nodes, and obtaining the interfaces of successor nodes and predecessor nodes. Data nodes use a variable ready to indicate their ready state. When the value of ready is True, it means that the node is ready.

[0040] 33. Implementation of control nodes. The constructor of the control node receives a function as an input parameter. The control node implements the following interfaces: parameter definition interface, the control node can define the parameters it needs, indicating that when these parameters have real values, the control node is marked as computable; add predecessor data node and set successor data node interface, this interface indicates which data nodes the control node depends on and which control nodes will be generated; application parameter interface, this interface can realize parameter passing, the information passed includes parameter name and parameter value, the control node saves this part of information and passes it to the function it maintains as a real value for subsequent calculation.

[0041] Step 4: Implementation of static graph. This process implements the execution process of static graph. The specific implementation steps are as follows:

[0042] 41. Maintain a task queue and add all the ready data nodes and control nodes in the static graph to the task queue;

[0043] 42. Loop through the task queue to remove a node.

[0044] 43. If the node is a data node, the value of the node is passed to all subsequent control nodes.

[0045] 44. If the node is a control node, the function on the control node is asynchronously called and the parameter value maintained by the control node is passed in;

[0046] 45. When the node is a data node, if the control node has become computable when it is passed to the subsequent control node, it will be added to the task queue. If the node is a control node, the calculated data node will also be added to the task queue.

[0047] 46. ​​When all nodes have been calculated, obtain the data node marked as the function flow return value and use it as the return value of the static graph execution process.

[0048] Step 5: Implement the static graph compilation process. This process compiles the user-defined Serverless function flow into a static graph. During the compilation process, lazy calls to the function are implemented through pre-execution compilation, and finally compiled into a static graph. The specific implementation process is as follows:

[0049] 51. Compilation of function calls. When a function call is made, the function index and the function parameters passed in are compiled into a static graph subgraph as follows: a) Use the function index as an input parameter to construct a control node; b) Convert all the function input parameters into Lambda objects; c) For all Lambda objects, construct the corresponding data nodes, add the control node as the successor node of the data node, and add the data node as the predecessor node of the control node; d) Construct an empty Lambda object and its data nodes, set the successor node of the control node to the data node, and the predecessor node of the data node to the control node; e) Add all the above nodes to the static graph.

[0050] 52. Compilation of Lambda item operations. The Lambda class rewrites all Lambda item operations. The following takes the addition operation as an example to describe the compilation process: a) accept another parameter; b) construct the addition function λxy.x+y; c) generate data nodes and control nodes according to the steps similar to the previous function call compilation, and add them to the corresponding static graph.

Claims

1. A responsive Serverless function orchestration and operation device, characterized in that: It includes a declarative Serverless function orchestration device and a responsive Serverless function stream running device. The declarative Serverless function orchestration device abstracts data into Lambda items and nodes by providing a declarative function orchestration interface, and the device compiles the Serverless function orchestration into a static graph; the responsive Serverless function running device topologically sorts the static graph, analyzes the independence between data and the parallelism of the orchestration function, and executes the static graph through responsive running and parallel computing.

2. According to claim 1, the responsive Serverless function orchestration and operation device is characterized in that: The orchestration device allows users to use front-end languages ​​to write the flow form of data objects by providing SDK. This process is called declarative orchestration of function flow. After the user submits the function flow written in the front-end language, the orchestration device abstracts the data objects written by the user into nodes, and each data object is maintained by a node. This process is called data abstraction into nodes. Afterwards, the orchestration device associates the dependencies of the nodes and compiles them into a static graph. This process is called static graph compilation. Therefore, the orchestration device is mainly divided into the following steps: declarative orchestration of function flow, data abstraction into nodes, and static graph compilation.

3. According to claim 2, the responsive Serverless function orchestration and operation device is characterized in that: Declaratively orchestrate function flows: Orchestrate a Serverless function flow in a declarative way and define the processing flow of each data by passing operators. The data is abstracted into nodes: the device abstracts the data generated by the Serverless function orchestration in the future operation process through the lambda item, and the lambda item is maintained through the data node and the control node; The static graph compilation: compiles the static graph in a pre-execution manner, converting all data and functions into nodes on the graph.

4. According to claim 2, the responsive Serverless function orchestration and operation device is characterized in that: The data abstraction is realized as a node through the following steps: 101, lambda item abstract data: All variables in the orchestration function are represented by lambda items, which are abstractions of data generated during the function flow. Operations on lambda items will indirectly affect operations on variables represented by lambda.

102. Data node maintains lambda item: A lambda item is maintained by a data node. The data node has two states: ready state and not ready state. When the lambda item it maintains has a real value passed in, it is in the ready state; otherwise, it is in the not ready state.

103. Control node maintains lambda calculation: Function calculation of one or more lambda items is maintained by the control node. The control node contains two states: computable state and incomputable state. When the data nodes it depends on are all ready, it is in the computable state; otherwise, it is in the incomputable state.

5. According to claim 2, the responsive Serverless function orchestration and operation device is characterized in that: The static graph compilation process includes two processes: lazy execution and pre-execution compilation; 201, lazy execution: When the orchestration function calls other Serverless functions or performs operations on lambda items, it does not wait for the execution result of the function, but maintains the reference to the result through the lambda item; 202, pre-execution compilation: compile the static graph by pre-executing the code, perform a fake execution on the code, record the operations of all lambda items as operations on the data they maintain, and generate control nodes and data nodes.

6. According to claim 2, the responsive Serverless function orchestration and operation device is characterized in that: The data is abstracted into nodes, which contain the following relationships: (1) A data node may be provided to multiple control nodes, and the control nodes become the successors of the data nodes; (2) A control node will generate at most one data node, which is called the output of the control node; (3) A data node is generated by at most one control node. A control node can depend on multiple data nodes and can only generate at most one data node. (4) The alternating connection between control nodes and data nodes eventually forms a directed acyclic static graph.

7. The responsive Serverless function orchestration and operation device according to claim 5 is characterized in that: The specific process of the pre-execution compilation is as follows: Generate data nodes through input parameters: When a user calls a function or operates a lambda item, its input parameters are converted into lambda items and data nodes are obtained or generated; Calling a function to generate a control node: All lambda transformation processes in the orchestration function can be converted into functions. When a user modifies data by calling a function or directly acting on a lambda item, the call or modification operation will be converted into a function, which generates a control node that depends on the data node. Generate data nodes by outputting parameters: Generate a data node for the lambda item through the return value of the control node, use the data node as the successor node of the control node, and return the lambda to the user.

8. The responsive Serverless function orchestration and operation device according to claim 1, characterized in that: The operating device includes three parts: topological sorting, responsive execution, and parallel computing; the implementation of the three parts is as follows: Topological sorting: Use topological sorting to find out which data nodes or control nodes are ready. For nodes that are already in the ready state, add them to the task queue. During the graph calculation process, any ready node is added to the task queue. Responsive execution: The control node describes the dependency by the number of dependent data nodes. When receiving a notification from a ready data node, its dependency decreases. When all dependent data nodes are ready, the execution of the control node is triggered. The execution result is assigned to the subsequent data nodes, marking the subsequent data nodes as ready. Parallel computing: When a static graph contains multiple tasks that can theoretically be computed in parallel, the device optimizes the execution of the static graph through concurrent calls.

9. The responsive Serverless function orchestration and operation device according to claim 8, characterized in that: The responsive execution includes the following steps: 301, the device obtains a node from the task queue; 302, if the node is a data node, the value corresponding to the lambda item maintained by the node is transmitted to the subsequent control node, and if the subsequent control node becomes ready after the value is transmitted, the subsequent control node is added to the task queue; 303, if the lambda item maintained by the data node is a function, compile the function into a task subgraph, and add the nodes of the task subgraph to the node set of the current task graph; 303, if the node is a control node, the control node is calculated, the calculation result is assigned to its successor data node, the data node is marked as ready, and is added to the task queue; 304. Through the process described in step 303, the execution of multiple control nodes can be triggered simultaneously to achieve responsive parallel execution optimization.

10. The responsive Serverless function orchestration and operation device according to claim 8, characterized in that: The parallel computing includes data parallelism and task parallelism; Data parallelism: When multiple data nodes are aggregated into one data node and passed to a control node, the control node calculates the data in parallel and summarizes the results; Task parallelism: When the data that multiple functions depend on for calculation are independent, these tasks will be called simultaneously to achieve task parallelism.

Images