A serverless computing application execution method and system based on application control state management

Abstract

The application provides a serverless computing application execution method and system based on application control state management, including: a serverless computing platform acquires a serverless computing application, a cloud function of the serverless computing application realizes a control state management function by introducing a control state management library; a control state object is created according to a function using an application programming interface provided by the control state management library, a globally unique string is created for the control state object as an object reference of the control state object; a target function corresponding to a function name is started by using the application programming interface to input the function name and the object reference, and the object reference is passed as a parameter, so that the target function shares the control state object; until the user code of the serverless computing application is completely executed, an execution result of the serverless computing application is obtained.

Description

Technical Field

[0001] This invention relates to the field of application state management technology in serverless computing, and in particular to a method and system for managing the control state of serverless applications. Background Technology

[0002] Serverless computing is rapidly developing as a new cloud computing model. Currently, Function as a Service (FaaS) is the primary form of providing serverless computing services. Users developing applications on a serverless computing platform only need to write a cloud function (user code) in any high-level programming language, configure events to trigger the cloud function, and then utilize cloud resources to run their applications. All other tedious tasks (such as server configuration, load balancing, scaling, and application deployment) are handled by the platform. Using a serverless computing platform, developers can write a function in different programming languages, upload the function to the cloud, and obtain a calling interface to remotely invoke the function at will. With its simple programming model, rich cloud resource services, and low-cost pay-as-you-go pricing, serverless has become an important form of cloud computing service.

[0003] Serverless computing platforms provide developers with server configurations and computing resources, and can elastically scale functions based on real-time application load. Existing serverless elastic scaling relies on the separation of compute and storage. Because existing serverless computing lacks systematic state management capabilities, serverless functions must be stateless. Statelessness means that state cannot be shared between each call to a serverless function; users must store the state required by the function (such as persistent data, messages used for collaboration between functions, and intermediate results of function execution) in an external storage service.

[0004] In serverless application computing, there is a special type of state—the control state. This includes messages sent between serverless functions, mutexes used for multi-function synchronization, and shared objects that require frequent read and write operations. Unlike other states, due to specific consistency and performance requirements, the use of the control state requires special semantic support from the serverless platform; while other states primarily serve the application's business needs and do not require interaction with the platform.

[0005] Currently, serverless systems lack efficient state management mechanisms and typically rely on external storage for access management of all states. This presents a series of challenges when implementing applications that require state control on serverless platforms:

[0006] (1) Performance of control state access is difficult to guarantee. Control state has latency-sensitive computational characteristics, and external storage services usually have higher access latency, making it difficult to support fine-grained, high-frequency access to control state. This has a significant impact on the performance of serverless applications that rely heavily on control state collaboration.

[0007] (2) Consistency requirements for control state access are difficult to guarantee. Control state has diverse consistency requirements, which are difficult to meet directly by general external storage services. Users need to configure multiple storage services for control objects with different consistency and performance requirements and manage them manually, which is very difficult.

[0008] (3) Automatic scaling of the control state is difficult to achieve. The concurrency of serverless functions may grow to a large value in a short period of time, while the storage system usually does not have the corresponding automatic scaling capability, thus becoming the performance bottleneck of the entire system and affecting the application computing performance. Summary of the Invention

[0009] The purpose of this invention is to address the diverse consistency requirements, programming difficulties, and performance issues of serverless applications involving multi-function collaboration. This invention provides programming interfaces suitable for different collaboration scenarios, simplifying the development of serverless applications with excellent performance. Based on this system, application developers do not need to build and maintain external storage themselves; they only need to focus on the messages passed and shared objects that need to be used in inter-function collaboration, enabling them to easily build serverless applications that rely on state management, such as distributed consensus algorithms or distributed database systems.

[0010] To address the shortcomings of existing technologies, this invention proposes a serverless computing application execution method based on application control state management, including:

[0011] Step 1: The serverless computing platform obtains the serverless computing application to be executed. The serverless application includes at least one cloud function. The cloud function implements control state management function by introducing a control state management program library. The control state management program library starts the control state management client.

[0012] Step 2: The control state management client uses the application programming interface provided by the control state management library to create a control state object according to the function, and creates a globally unique string for the control state object as an object reference for the control state object;

[0013] Step 3: The control state management client uses the application programming interface to pass in the function name and the object reference, starts the target function corresponding to the function name, and passes the object reference as a parameter so that the target function can share the control state object;

[0014] Step 4: Repeat steps 2 and 3 until the serverless computing application finishes execution. Save the current control state object as the execution result, and the control state management library closes the control state management client.

[0015] The serverless computing application execution method based on application control state management includes a serverless computing platform running a daemon process for the running instance of the function. The daemon process is used to execute user code when a function reference request arrives. The lifecycle of the control state management client is consistent with that of the daemon process. The control state management client stores a reference to the control state object and the identifier of the function call.

[0016] The serverless computing application execution method based on application control state management includes a control state object comprising a basic data object, a conflict-free copy object, and a mutex.

[0017] This basic data object includes floating-point numbers and strings. Any function holding a reference to its object can read and write this basic data object. Write conflicts are handled using a last-write-wins strategy, where each holder's copy of the object will be updated asynchronously for the winning write operation.

[0018] This conflict-free copy object includes counters, lists, and text objects. All operations on this conflict-free copy object are interchangeable. Any function holding a reference to its object can read and write the conflict-free copy object without write conflicts. Each holder's copy of the object will asynchronously update all operations on the same conflict-free copy object.

[0019] The mutex is a locked floating-point number and a string. A function can only read from or write to the mutex after it holds the mutex lock.

[0020] The serverless computing application execution method based on application control state management, wherein the control state management client stores the call identifiers of the functions of the control state management function, and each call of the function generates a globally unique identifier to distinguish different calls of the same function;

[0021] Furthermore, all functions that share the same control state object form a fully connected network through the control state management client, accessing the control state object in a decentralized manner.

[0022] This invention also proposes a serverless computing application execution system based on application control state management, including:

[0023] The initial module is used to send serverless computing applications to the serverless computing platform. The serverless applications include at least one cloud function, which implements control state management functions by introducing a control state management library, which starts a control state management client.

[0024] The module is created to enable the control state management client to create control state objects using the application programming interface provided by the control state management library according to the function. A globally unique string is created for the control state object as an object reference for the control state object.

[0025] The transmission module is used to enable the control state management client to use the application programming interface to pass in the function name and the object reference, start the target function corresponding to the function name, and pass the object reference as a parameter so that the target function can share the control state object;

[0026] The execution module is used to repeat the creation module and the transmission module until the serverless computing application has finished executing. After that, the current control state object is saved as the execution result, and the control state management program library closes the control state management client.

[0027] The serverless computing application execution method based on application control state management includes a serverless computing platform running a daemon process for the running instance of the function. The daemon process is used to execute user code when a function reference request arrives. The lifecycle of the control state management client is consistent with that of the daemon process. The control state management client stores a reference to the control state object and the function call identifier.

[0028] The serverless computing application execution method based on application control state management includes a control state object comprising a basic data object, a conflict-free copy object, and a mutex.

[0029] This basic data object includes floating-point numbers and strings. Any function holding a reference to its object can read and write this basic data object. Write conflicts are handled using a last-write-wins strategy, where each holder's copy of the object will be updated asynchronously for the winning write operation.

[0030] This conflict-free copy object includes counters, lists, and text objects. All operations on this conflict-free copy object are interchangeable. Any function holding a reference to its object can read and write the conflict-free copy object without write conflicts. Each holder's copy of the object will asynchronously update all operations on the same conflict-free copy object.

[0031] The mutex is a locked floating-point number and a string. A function can only read from or write to the mutex after it holds the mutex lock.

[0032] The serverless computing application execution method based on application control state management, wherein the control state management client stores the call identifiers of the functions of the control state management function, and each call of the function generates a globally unique identifier to distinguish different calls of the same function;

[0033] Furthermore, all functions that share the same control state object form a fully connected network through the control state management client, accessing the control state object in a decentralized manner.

[0034] The present invention also proposes a storage medium for storing programs that execute any of the serverless computing application execution methods based on application control state management.

[0035] The present invention also proposes a client for any of the serverless computing application execution systems based on application control state management.

[0036] As can be seen from the above solutions, the advantages of the present invention are:

[0037] 1. Control state objects with multiple consistency guarantees simplify the development of serverless applications. Different types of serverless applications have different requirements for state consistency during construction. Manually configuring multiple distributed databases with different consistency guarantees is very complex and difficult to manage. This invention provides a minimalist programming interface for fine-grained, frequently accessed, and latency-sensitive objects, greatly simplifying the development of serverless applications that require multi-function collaboration.

[0038] 2. Significantly improves the performance and scalability of serverless applications. Previously, when serverless applications involved multi-function collaboration, all shared states or intermediate results of function execution had to be stored in external storage services. This involved traversing the network layer, incurring latency overhead, and the lack of flexibility in scaling external storage services, easily becoming a performance bottleneck. The decentralized implementation places business logic closer to the function, reducing overall latency; the computational load for controlling state management can scale automatically along with the function, preventing it from becoming a performance bottleneck. Attached Figure Description

[0039] Figure 1 System architecture diagram;

[0040] Figure 2 Flowchart of client startup steps;

[0041] Figure 3 Flowchart for handling write conflicts for basic data objects;

[0042] Figure 4 Flowchart for merging operations on conflict-free copy objects;

[0043] Figure 5 Flowchart for concurrent modification of mutexes;

[0044] Figure 6 A flowchart illustrating the steps involved in using the method. Detailed Implementation

[0045] This invention proposes a decentralized method for managing the control state of serverless applications. By improving the serverless computing platform, the platform addresses the diverse consistency requirements, programming difficulties, and performance issues associated with function collaboration in serverless applications. This invention provides serverless applications with fine-grained, high-frequency access, and low-latency control state management capabilities, improving the performance of multi-function collaborative serverless applications and simplifying the development of function collaboration. Key technical points of this invention include:

[0046] Key Point 1: Control State Underlying Data Model. This invention proposes a control state underlying data model. This model abstracts and defines the programming interface for the control state of Serverless applications. To provide a simple and easy-to-use programming interface, this invention first defines three different types of control state objects: basic data objects, conflict-free replication objects, and mutexes. These three objects have different consistency guarantees and performance characteristics. When programming, users can import the corresponding library into the code of a function, then use the library to create objects and share them with other functions. Using control state objects, users do not need to manually manage multiple consistency guarantees in the database, reducing the operational burden. Users do not need to worry about the management of control state when developing Serverless applications.

[0047] Key Point 2: Synchronization Protocol for Control States. This invention proposes a synchronization protocol for control states. The three types of control state objects have different consistency and performance requirements, thus necessitating different implementation methods. The synchronization protocol describes the synchronization process for these three control state objects, including concurrent modification of basic data objects (last writer wins strategy), operation merging process for conflict-free replicated objects, and serial modification process for mutexes. The synchronization protocol for control states is implemented in a decentralized state management system.

[0048] Key Point 3: Decentralized Control State Management System. This invention proposes a decentralized control state management system. Based on a serverless function execution environment, this system allows collaborative functions to access and maintain control state without a central node, eliminating the need for explicit point-to-point communication at the business layer. All functions sharing a common control state object form a small, fully connected network through the control state management client. For example, when functions A, B, and C share the same control state object, such as a basic data object x, if A modifies the value of x, it needs to synchronize the new value with B and C. This process is accomplished through message passing. The client analyzes the user code's specific operations on the control object and selects different connection modes based on the object type, such as fan-out, publish-subscribe, or request-response. While a decentralized implementation is significantly more complex than a centralized one, it scales well and achieves excellent performance. It supports highly elastic control state management for serverless applications.

[0049] To make the above features and effects of the present invention clearer and easier to understand, specific embodiments are described below, and detailed descriptions are provided in conjunction with the accompanying drawings.

[0050] The specific implementation of this invention includes building a serverless application control state management system, performing control state management, and building a control state management client.

[0051] 1. Build a serverless application control and status management system

[0052] The system architecture proposed in this invention is as follows: Figure 1 As shown, the system consists of a function execution environment, a control state management client, and a global function addressing component embedded in the serverless platform. The function execution environment includes a daemon process and user code. The user code implements the application's business logic, while the daemon process executes the user code on the serverless platform and monitors the execution process. The user code or daemon process collaborates with the control state management client, which includes: 1) APIs for creating and manipulating control state objects; 2) function call APIs; and 3) a local function instance addressing component. Addressing function instances requires the joint efforts of the local function instance addressing component of the control state management client and the global function addressing component embedded in the serverless platform.

[0053] 2. Build a control state management client

[0054] During control state access management, the control state management client performs differentiated management operations around three types of control state objects. Furthermore, the startup process of the control state management client includes... Figure 2 The following steps are described:

[0055] (1) The control state management client stores the call identifier of the function that needs to control state management: invoke(function, arguments)->id. Each function call generates a globally unique identifier, and different calls to the same function will have different identifiers. That is, the identifier may be generated by the caller, such as when called through a client; or it may not be generated by the caller, but by the client of the callee, such as when the call comes from an external call, like an HTTP request. The generation of an identifier for each call is to distinguish different calls to the same function.

[0056] (2) Each function execution instance requires only one control state management client. To reduce cold start latency, the serverless platform runs a daemon process on the function execution instance (e.g., container, virtual machine). This daemon process also acts as a small reverse proxy server, used to execute user code when a function call request arrives. The lifecycle of the control state management client is consistent with that of the daemon process. When a new function call occurs in a running instance where the daemon process has already been started, a separate client will not be started; the function will reuse the existing client.

[0057] 3. Implement the synchronization protocol for control state objects.

[0058] When users need to use the library API to create control state objects, there are three categories: basic data objects, conflict-free replicated objects, and mutexes. Different objects have different consistency guarantees and operation interfaces, used for the following three different collaboration scenarios:

[0059] (1) Basic data objects include floating-point numbers and strings, which are the two most commonly used and general types of data objects. Basic data objects can be read and written by any function that holds a reference to them. When concurrent writes occur, this system uses a last-write-wins strategy to handle conflicts; each holder's copy of the object will asynchronously update the winning write operation to achieve eventual consistency. Basic data objects are often used to directly store the state of some simple shared data. The holder is the function that holds the basic data object.

[0060] As an example, Figure 3This demonstrates the write conflict handling process for a basic data object. Functions A and B share a basic data object x and collaborate through their respective control states, managing clients A and B. Functions A and B concurrently write to the shared object x, writing values ​​of 1 and 2 respectively, accompanied by timestamps t1 and t2. Subsequently, the clients communicate with each other to update the value of x. The update occurs asynchronously; the function receives a successful update response, but the client believes the value of x is not yet updated until all copies are updated. A write conflict occurs when the client receives an update value from another client during this process. The clients handle write conflicts by comparing the timestamps t1 and t2. Since timestamps contain globally unique random numbers in addition to local time information, t1 and t2 will never be exactly equal. The client chooses to set the value of x to the write value with the larger timestamp; in this example, t1 is greater than t2. Therefore, both clients A and B eventually update x to 1, achieving eventual consistency.

[0061] (2) Conflict-free copied objects include counters that can be incremented or decremented, lists that can have elements inserted or deleted at any position, and text objects that can have characters inserted or deleted at any position. All operations on conflict-free copied objects are commutative and can be read and written by any function that holds a reference to them, but without write conflicts. Conflict-free copied objects also provide eventual consistency; each holder's copy of the object will asynchronously update all operations on that object. Conflict-free copied objects are commonly used for collaborative editing across multiple clients or for text synchronization in chat systems.

[0062] As an example, Figure 4 This demonstrates the process of merging operations in conflict-free object replication. Functions A and B share a single counter object, `counter`, which can only be incremented, decremented, and read. The initial value of `counter` is 0. Functions A and B concurrently modify the `counter` object, incrementing it by 1 and then by 2, respectively. Subsequently, clients A and B communicate with each other, passing the update operations to the `counter` object. The increment and decrement operations are commutative; their order does not affect the final value of the object. Therefore, both update operations take effect, and both clients A and B update `counter` to 3, achieving eventual consistency.

[0063] (3) Mutexes also include floating-point numbers and strings. The difference is that a function must successfully acquire the mutex lock before it can read or write the locked object. Mutexes guarantee linear consistency and provide the simplest function synchronization and mutual exclusion capabilities. Mutexes are typically used in applications with extremely high correctness requirements to completely prevent multiple functions from concurrently modifying the same object.

[0064] As an example, Figure 5This demonstrates the process of two functions attempting to modify a mutex simultaneously. The mutex lock information is stored only on one client; in this example, the lock information for `x` is stored only on client A. Function A must acquire the mutex lock before accessing `x`. Once function A successfully acquires the mutex lock, any other attempt to access the mutex lock will fail. Therefore, before function A releases the lock, only function A can access `x`; other clients' reads of `x` depend on client A, achieving linear consistency.

[0065] 4. Construct a two-level function addressing service

[0066] All operations on control state objects rely on inter-function communication. Communication between functions first requires determining the physical locations of the communicating parties, i.e., their IP addresses and port information; this process is called function addressing. The serverless platform and the control state management client constitute a two-level function addressing service, jointly maintaining the mapping relationship between functions and physical locations:

[0067] (1) When a function calls other functions through a library, the control state management client generates a globally unique identifier for that call. The addressing service saves the correspondence between this identifier and the physical location of the running instance of that call for later lookup.

[0068] (2) When a function performs control state collaboration operations through a library, the control state management client needs to communicate with other function instances according to the collaboration requirements. The client will automatically include the function name and identifier in the communication information.

[0069] (3) The control state management client finds the endpoint list of function instances maintained by the Serverless platform based on the function name, and finds the physical location of the function instance based on the identifier, thereby establishing a connection with the control state client held by the function instance and starting to transmit messages.

[0070] (4) After the function is executed, the correspondence between the instance and the physical location is deleted from the endpoint list maintained by the control state management client of the function execution environment and the Serverless platform.

[0071] 5. Use control status management

[0072] The above steps realize the control state management system, which through... Figure 6 The described steps use:

[0073] (1) Introduce the control state management library into the function code that needs to use the control state management function. The library will automatically start the control state management client.

[0074] (2) The function uses the API provided by the program library to create a control state object and obtains a reference to the control state object: createObject()->ref;

[0075] (3) When a function needs to collaborate with other functions, it can start other functions by passing the name of the called function and parameters through the API, and can pass a reference to the control state object as a parameter so that the called function can share the object;

[0076] (4) Repeat steps 2 and 3 until the user code has finished executing;

[0077] (5) The program library will automatically close the control status management client.

[0078] Taking a word counting application as an example, the main function splits the input text into lines and then launches multiple sub-functions. Each sub-function counts the words in each line and then updates the word count to a globally unified counter. In this example, the globally unified counter is created by the main function using a library, and its reference is a globally unique string. All sub-functions holding this reference can modify this dictionary as if it were a local data object. The created object can be one of the three control state objects mentioned above: a basic data object, a conflict-free copy object, or a mutex. In this example, since the word count only involves addition operations, a conflict-free copy object is the most suitable.

[0079] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments 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 embodiments.

[0080] This invention also proposes a serverless computing application execution system based on application control state management, including:

[0081] The initial module is used to send serverless computing applications to the serverless computing platform. The serverless applications include at least one cloud function, which implements control state management functions by introducing a control state management library, which starts a control state management client.

[0082] The module is created to enable the control state management client to create control state objects using the application programming interface provided by the control state management library according to the function. A globally unique string is created for the control state object as an object reference for the control state object.

[0083] The transmission module is used to enable the control state management client to use the application programming interface to pass in the function name and the object reference, start the target function corresponding to the function name, and pass the object reference as a parameter so that the target function can share the control state object;

[0084] The execution module is used to repeat the creation module and the transmission module until the serverless computing application has finished executing. After that, the current control state object is saved as the execution result, and the control state management program library closes the control state management client.

[0085] The serverless computing application execution method based on application control state management includes a serverless computing platform running a daemon process for the running instance of the function. The daemon process is used to execute user code when a function reference request arrives. The lifecycle of the control state management client is consistent with that of the daemon process. The control state management client stores a reference to the control state object and the function call identifier.

[0086] The serverless computing application execution method based on application control state management includes a control state object comprising a basic data object, a conflict-free copy object, and a mutex.

[0087] This basic data object includes floating-point numbers and strings. Any function holding a reference to its object can read and write this basic data object. Write conflicts are handled using a last-write-wins strategy, where each holder's copy of the object will be updated asynchronously for the winning write operation.

[0088] This conflict-free copy object includes counters, lists, and text objects. All operations on this conflict-free copy object are interchangeable. Any function holding a reference to its object can read and write the conflict-free copy object without write conflicts. Each holder's copy of the object will asynchronously update all operations on the same conflict-free copy object.

[0089] The mutex is a locked floating-point number and a string. A function can only read from or write to the mutex after it holds the mutex lock.

[0090] The serverless computing application execution method based on application control state management, wherein the control state management client stores the call identifiers of the functions of the control state management function, and each call of the function generates a globally unique identifier to distinguish different calls of the same function;

[0091] Furthermore, all functions that share the same control state object form a fully connected network through the control state management client, accessing the control state object in a decentralized manner.

[0092] The present invention also proposes a storage medium for storing programs that execute any of the serverless computing application execution methods based on application control state management.

[0093] The present invention also proposes a client for any of the serverless computing application execution systems based on application control state management.

Claims

1. A serverless computing application execution method based on application control state management, characterized in that, include: Step 1: The serverless computing platform obtains the serverless computing application to be executed. The serverless computing application includes at least one cloud function. The cloud function implements control state management function by introducing a control state management program library. The control state management program library starts the control state management client. Step 2: The control state management client uses the application programming interface provided by the control state management library to create a control state object based on the cloud function. A globally unique string is created for the control state object as an object reference for the control state object. The control state object includes a basic data object, a conflict-free copy object, and a mutex. The basic data objects include floating-point numbers and strings. Any function holding a reference to its object can read and write the basic data objects. Write conflicts are handled using a last-write-wins strategy, and each holder's copy of the object will asynchronously update the winning write operation. The conflict-free copy objects include counters, lists, and text objects. All operations on the conflict-free copy objects are interchangeable. Any function holding a reference to its object can read and write the conflict-free copy objects, but no write conflicts will occur. Each holder's copy of the object will asynchronously update all operations on the same conflict-free copy of the object; the mutex is a locked floating-point number and string, and a function can only read from or write to the mutex after it holds the mutex lock; Step 3: The control state management client uses the application programming interface to pass in the name of the function to be called and the object reference, starts the target function corresponding to the function name, and passes the object reference as a parameter so that the target function can share the control state object; Step 4: Repeat steps 2 and 3 until the serverless computing application finishes execution. Save the current control state object as the execution result, and the control state management library closes the control state management client.

2. The serverless computing application execution method based on application control state management as described in claim 1, characterized in that, The serverless computing platform runs a daemon process for the running instance of the cloud function. This daemon process is used to execute user code when a cloud function reference request arrives. The lifecycle of the control state management client is consistent with that of the daemon process. The control state management client stores a reference to the control state object and the identifier of the function call.

3. The serverless computing application execution method based on application control state management as described in claim 1, characterized in that, The control state management client stores the call identifiers of the functions that require control state management functions. Each call to a function generates a globally unique identifier to distinguish different calls to the same function.

4. A serverless computing application execution system based on application control state management, characterized in that, include: The initial module is used to send serverless computing applications to the serverless computing platform. The serverless computing applications include at least one cloud function, which implements control state management functions by introducing a control state management library, which starts a control state management client. The module is used to enable the control state management client to create control state objects using the application programming interface provided by the control state management library based on cloud functions. A globally unique string is created for each control state object as an object reference for that control state object. The control state object includes basic data objects, conflict-free copy objects, and mutexes. The transmission module enables the control state management client to use the application programming interface to pass in the name of the function to be called and the object reference, start the target function corresponding to the function name, and pass the object reference as a parameter so that the target function can share the control state object; The basic data objects include floating-point numbers and strings. Any function holding a reference to its object can read and write the basic data objects. Write conflicts are handled using a last-write-wins strategy, and each holder's copy of the object will asynchronously update the winning write operation. The conflict-free copy objects include counters, lists, and text objects. All operations on the conflict-free copy objects are interchangeable. Any function holding a reference to its object can read and write the conflict-free copy objects, but no write conflicts will occur. Each holder's copy of the object will asynchronously update all operations on the same conflict-free copy of the object; the mutex is a locked floating-point number and string, and a function can only read from or write to the mutex after it holds the mutex lock; The execution module is used to repeat the creation module and the transmission module until the serverless computing application has finished executing. After that, the current control state object is saved as the execution result, and the control state management program library closes the control state management client.

5. The serverless computing application execution system based on application control state management as described in claim 4, characterized in that, The serverless computing platform runs a daemon process for the running instance of the cloud function. This daemon process is used to execute user code when a cloud function reference request arrives. The lifecycle of the control state management client is consistent with that of the daemon process. The control state management client stores a reference to the control state object and the function call identifier.

6. The serverless computing application execution system based on application control state management as described in claim 4, characterized in that, The control state management client stores the call identifiers of the functions that require control state management functions. Each call to a function generates a globally unique identifier to distinguish different calls to the same function.

7. A storage medium for storing a program that executes the serverless computing application execution method based on application control state management as described in any one of claims 1 to 3.

8. A client for the serverless computing application execution system based on application control state management as described in any one of claims 4 to 6.

Images