Lightweight function running method and system for server-unaware computing scenarios

Abstract

The application provides a lightweight function running method and system for a server-unaware computing scene, and the method comprises the following steps: providing a communication primitive for fast cold start of an isolated environment and high-performance intermediate data transmission; for a server-unaware function computing workflow scene, a runtime is provided as a new software stack architecture; the function and the underlying runtime relied by the function are all deployed in the same CPU privilege level and address space for cold start operation; a library operating system with a workflow granularity is used to provide underlying runtime services for the function, and a memory-safe language is used to provide memory isolation and sharing; and an on-demand loading mechanism is implemented for the library operating system. The application solves the technical problems of slow cold start of an isolated environment, poor intermediate data transmission performance, large cold start range and high cost, and poor flexibility of memory isolation and sharing.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, specifically to function runtime in server-insensitive computing scenarios. Background Technology

[0002] In recent years, serverless computing has become an increasingly popular cloud computing development paradigm due to its advantages such as high abstraction of resources and programming, on-demand billing, and dynamic scaling. Similar to traditional cloud computing services, current serverless computing platforms must also ensure isolation between the workloads of different tenants. The current mainstream solution is to encapsulate functions based on virtual machines and containers, and then use frameworks such as OpenFaaS for workflow orchestration. For example, the existing invention patent application document CN114691299A, entitled "An Edge Computing Resource Management System Based on Serverless," includes: a Center Serverless for managing Serverless applications and triggers, creating and executing Serverless applications on the central node; an Edge Serverless for executing Serverless applications on the edge side and monitoring node resource status, transferring requests to the central node when resources are insufficient; an edge event trigger for acquiring edge events and sending event information to a message queue upon reaching the trigger condition; a Kata Container for strong isolation of user applications, ensuring that user applications do not interfere with each other during runtime; and a multi-architecture Runtime environment that automatically selects the matching architecture when running on different architecture runtimes, achieving architecture-agnostic integration at the user layer. And the existing invention patent application document CN114385362A, entitled "A Multi-Transport Robot Scheduling Method Based on Cloud-Edge Computing," describes a method that includes: each robot connecting to an edge computing server via wireless communication technology; the edge computing server requesting a cloud computing server; the edge computing server instantiating the multi-transport robot task scheduling problem into a colored traveling salesman problem (TSP) model and requesting the TSP solution service from the cloud computing server using an HTTP service, which is encapsulated in a container on the cloud computing server; the cloud computing server executing a parallel TSP solution algorithm after receiving the scheduling request and sending the multi-robot task scheduling result to the edge computing server via the HTTP protocol; and the edge computing server executing a multi-robot path planning algorithm and sending the obtained shortest path to each robot after receiving the multi-robot task scheduling result. However, the aforementioned existing deployment architecture creates an inefficient and heavy function software stack that needs to traverse multiple different privilege levels and address spaces, leading to reduced function execution efficiency. Cold start events triggered by external function call events or internal communication events caused by intermediate data transfer in the workflow are amplified by the virtualization layer in this software stack, ultimately accumulating into end-to-end latency for the user load. Because functions typically have short lifecycles, these overheads are not negligible. For example, the cold start time of a secure container like gVisor or a microvirtual machine like Firecracker is at least 100ms, exceeding the execution time of 75% of the functions in the data published by Huawei Cloud.In addition, a Google report stated that the overhead of data transfer between services accounts for 25% of CPU cycles in data centers. Therefore, addressing the issues of cold starts and excessive data transfer overhead in current platform function runtime environments is a significant challenge in the field of server-insensitive computing.

[0003] Existing work attempts to alleviate the above overhead in two ways: (1) Thread-level function abstraction, which refers to using threads within a process to run different functions in the workflow and passing intermediate data through function calls of threads to replace inter-process communication. (2) Lightweight operating system, which is a method of deploying user function code and the operating system services it depends on at the same privilege level. For example, in the Unikernel architecture, the library operating system replaces the Linux kernel in the virtual machine, and function calls can replace system calls, thereby accelerating the running speed of the program. However, the above solutions still cannot completely eliminate the privilege level barrier between user functions, the virtualization layer and the operating system module, and context switching is still required to achieve interaction between these components.

[0004] In summary, existing technologies suffer from technical problems such as slow cold start in isolated environments, poor intermediate data transfer performance, large cold start range and high cost, and poor flexibility in memory isolation and sharing. Summary of the Invention

[0005] The technical problem to be solved by this invention is: how to solve the technical problems of slow cold start in isolated environments, poor intermediate data transfer performance, large cold start range and high cost, and poor flexibility of memory isolation and sharing in the prior art.

[0006] This invention solves the above-mentioned technical problems by employing the following technical solution: a lightweight function execution method for server-insensitive computing scenarios includes:

[0007] S1. For server-insensitive computing scenarios, a lightweight function runtime is set up to obtain the software stack structure. Using the lightweight function runtime method, all components of the software stack structure are aggregated into the same CPU privilege level and address space to obtain cold start and intermediate data transfer communication primitives. Among them, the standard library layer ms_std, the kernel function layer mslibos, and the global runtime layer msvisor are set up.

[0008] S2. Deploy the lightweight function and the underlying runtime that the lightweight function depends on to the same CPU privilege level and address space for cold boot operations;

[0009] S3. Utilize a pre-built workflow granularity library operating system to provide corresponding low-level runtime services for lightweight functions, use a memory-safe language for memory isolation and sharing operations, obtain a threat model based on Software Fault Isolation (SFI), use the Safe Rust language to provide tenants with mutually isolated function execution environments, and obtain executable file images from a pre-built cloud platform, which is a trusted mutation environment.

[0010] S4. For the library operating system, an on-demand loading mechanism is introduced to dynamically bind the processing functions called by the library operating system during runtime. A function layer and a workflow layer are designed to perform function binding operations based on the executable file image.

[0011] This invention proposes a lightweight function runtime for server-insensitive computing scenarios, providing communication primitives for fast cold start in isolated environments and high-performance intermediate data transfer.

[0012] This invention utilizes a workflow-level library operating system to provide low-level runtime services for functions, while leveraging a memory-safe language to offer flexible memory isolation and sharing. To further mitigate cold-start overhead, this invention implements an on-demand loading mechanism for the library operating system.

[0013] In a more specific technical solution, S1 includes:

[0014] S11. Utilize the standard library layer ms_std to generate and provide a programming interface layer to send intercepted system call requests to the library operating system;

[0015] S12. Using the kernel functional layer mslibos, allocate an instance of the library operating system for each function workflow, perform modular design of the library operating system to obtain the library operating system module, which is then called by the standard library layer ms_std.

[0016] S13. Utilize the global runtime layer msvisor to listen for external call events, instantiate and specify user functions according to the workflow configuration file, and track and obtain associated host resources during workflow execution.

[0017] In more specific technical solutions, the lightweight function execution methods in S1 include:

[0018] S11' Obtain and bind the workflow to the preset HTTP endpoints according to the global runtime, and expose them externally;

[0019] S12' When an external processor receives a workflow invocation event, the global runtime is set to the isolation domain corresponding to the current workflow instantiation;

[0020] S13': Derive a new thread and jump to the entry point of the user function, and continue running until the user function calls the system call interface of the library operating system module that has not yet been initialized;

[0021] S14' Utilize the standard library of user functions to notify the global runtime through a pre-defined interface for on-demand loading, and obtain the function address of the system call interface alloc_buffer() to allocate a buffer to the user function and pass intermediate data;

[0022] S15' causes the next user function to execute S11' through S14' until acquire_buffer() is called to obtain a reference to the buffer and perform zero-copy read operations on the intermediate data.

[0023] Compared to existing technologies, the runtime proposed in this invention is a novel software stack architecture specifically designed for server-insensitive function computation workflow scenarios. By deploying all functions and their underlying runtime dependencies within the same CPU privilege level and address space, the scope of cold starts is reduced and costly data copying is avoided.

[0024] In a more specific technical solution, in S12', the workflow instance is abstracted to obtain an isolation domain. All entities required to run the current workflow are associated with the isolation domain. These entities include user functions, library operating system, memory partitions, and other system resources.

[0025] In a more specific technical solution, an isolation domain is constructed based on the number of workflow instances running simultaneously on a single node, the workflow holding library operating system instance, and user functions.

[0026] In a more specific technical solution, within the isolation domain, user functions are determined based on user source code, component data from the cloud service provider is obtained, and the Software Fault Isolation Function (SFI) is provided using the Rust language to control the isolation domain.

[0027] In a more specific technical solution, within S3, a Rust compilation toolchain is set up in a trusted compilation environment. The Rust compilation toolchain includes: the core library; setting constraints on user-uploaded data; and removing unsafe code blocks from user functions.

[0028] In a more specific technical solution, S4 utilizes a function layer to track the interfaces of the library operating system that a single function instance has bound to. When a function instance calls a kernel service, under the constraints of Safe Rust, it goes through the interface of the standard library layer. The standard library layer checks whether it has registered the function address entries of the downstream module. If not, it enters the workflow layer.

[0029] Compared to existing technologies, this invention can reduce the cold start time of server-insensitive computation functions to approximately 1ms. By utilizing dedicated communication primitives for intermediate data transmission, the latency for synchronous switching of upstream and downstream functions on the same node is only about 35μs. For parallel sorting computation tasks with 100MB of input data, this invention can reduce the overall end-to-end runtime by 90% on the same node.

[0030] In a more specific technical solution, in S4, the workflow layer is used to save all loaded library operating system modules in the current workflow; the standard library layer ms_std exits to the global runtime layer msvisor by calling a specific interface; the global runtime layer msvisor is used to determine the relationship between the interface to be called and the library operating system module, in order to check whether the library operating system module exists in the isolation domain; if so, the function address is retrieved from the function instance of the library operating system module; if not, the operating system module is instantiated from the executable file image.

[0031] In more specific technical solutions, lightweight function execution systems for server-insensitive computing scenarios include:

[0032] The module for obtaining communication primitives is designed for server-insensitive computing scenarios. It sets up a lightweight function runtime to obtain the software stack structure and uses the lightweight function runtime method to aggregate all components of the software stack structure into the same CPU privilege level and address space to obtain cold start and intermediate data transfer communication primitives. It sets up the standard library layer ms_std, the kernel function layer mslibos, and the global runtime layer msvisor.

[0033] The lightweight function and underlying runtime deployment module is used to deploy the lightweight function and the underlying runtime that the lightweight function depends on to the same CPU privilege level and address space for cold boot operations.

[0034] The isolated function execution environment setting module is used to provide corresponding low-level runtime services for lightweight functions by utilizing the pre-built workflow granularity library operating system. It uses memory-safe language to perform memory isolation and sharing operations, obtains threat models based on Software Fault Isolation (SFI), and uses the safe Rust language to provide tenants with mutually isolated function execution environments. It obtains executable file images from the pre-built cloud platform's trusted mutation environment. The isolated function execution environment setting module is connected to the lightweight function and low-level runtime deployment module and the communication primitive acquisition module.

[0035] The on-demand loading module is designed to target the library operating system by introducing an on-demand loading mechanism. During runtime, it dynamically binds the processing functions called by the library operating system. It designs a function layer and a workflow layer, performs function binding operations based on the executable file image, and connects the on-demand loading module with the isolated function execution environment setting module and the communication primitive acquisition module.

[0036] The present invention has the following advantages over the prior art:

[0037] This invention proposes a lightweight function runtime for server-insensitive computing scenarios, providing communication primitives for fast cold start in isolated environments and high-performance intermediate data transfer.

[0038] This invention utilizes a workflow-level library operating system to provide low-level runtime services for functions, while leveraging a memory-safe language to offer flexible memory isolation and sharing. To further mitigate cold-start overhead, this invention implements an on-demand loading mechanism for the library operating system.

[0039] Compared to existing technologies, the runtime proposed in this invention is a novel software stack architecture specifically designed for server-insensitive function computation workflow scenarios. By deploying all functions and their underlying runtime dependencies within the same CPU privilege level and address space, the scope of cold starts is reduced and costly data copying is avoided.

[0040] Compared to existing technologies, this invention can reduce the cold start time of server-insensitive computation functions to approximately 1ms. By utilizing dedicated communication primitives for intermediate data transmission, the latency for synchronous switching of upstream and downstream functions on the same node is only about 35μs. For parallel sorting computation tasks with 100MB of input data, this invention can reduce the overall end-to-end runtime by 90% on the same node.

[0041] This invention solves the technical problems of slow cold start in isolated environments, poor intermediate data transfer performance, large cold start range and high cost, and poor flexibility of memory isolation and sharing in the prior art. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the basic steps of the lightweight function execution method for server-insensitive computing scenarios in Embodiment 1 of the present invention;

[0043] Figure 2 This is a schematic diagram of a lightweight function execution system architecture for server-insensitive computing scenarios according to Embodiment 1 of the present invention;

[0044] Figure 3 This is a schematic diagram of the library operating system loading on demand in Embodiment 1 of the present invention. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0046] Example 1

[0047] like Figure 1 As shown, the lightweight function execution method for server-insensitive computing scenarios provided by this invention includes the following basic steps:

[0048] S1 provides communication primitives for fast cold start and high-performance intermediate data transfer in isolated environments;

[0049] like Figure 2 As shown, this embodiment proposes a lightweight function runtime for server-insensitive computing scenarios. The core idea of ​​this runtime is to aggregate all components of the software stack within the same CPU privilege level and address space, i.e., within a single process. See also... Figure 1 Lightweight function execution systems for server-insensitive computing scenarios include, but are not limited to: the standard library layer ms_std, the kernel function layer mslibos, and the global runtime layer msvisor.

[0050] In this embodiment, the standard library layer provides users with a programming interface layer similar to the standard library to intercept system call requests to the library operating system; the kernel function layer, where each function workflow is assigned a separate library operating system instance, is responsible for protecting the host kernel from attacks by malicious user payloads. The library operating system in this embodiment is also designed to be modular, allowing them to call each other through the standard library layer; the global runtime layer is responsible for listening to external call events, instantiating specified user functions and library operating system modules according to the workflow configuration file, and tracking relevant host resources during workflow execution, such as network devices and file system images.

[0051] See Figure 1In the execution of the lightweight function execution method for server-insensitive computing scenarios, the global runtime binds the workflow to a specific HTTP endpoint and exposes it to the outside world. When an external processor receives a workflow call event①, the global runtime instantiates the corresponding isolation domain for the workflow. The system spawns a new thread and jumps to the entry point of the user function, and then runs normally until the function attempts to call the system call interface of the library operating system module that has not yet been initialized②. The standard library in the function will notify the global runtime to load it on demand through a specific interface and obtain the function address of the interface alloc_buffer() to be called. This interface alloc_buffer() can allocate a buffer for the function to pass intermediate data. In the subsequent execution phase of the workflow, the second user function also undergoes a similar execution process until it calls acquire_buffer()④ to obtain a reference to the buffer, thereby realizing zero-copy intermediate data reading⑤.

[0052] In this embodiment, the aforementioned isolation domain is an abstraction of a workflow instance, used to logically associate all entities required to run this workflow. These entities include, but are not limited to, user functions, library operating systems, memory partitions, and other system resources. In this embodiment, the construction of the isolation domain follows the MNN-1 principle, meaning that N workflow instances can run simultaneously on a single node, each workflow holding a separate library operating system instance and M user functions. Through the isolation domain, different functions within the same workflow can share specific system resources, such as files. Conversely, user functions from different workflows cannot access each other's files across isolation domains because related system calls are handled by different library operating system instances.

[0053] In this embodiment, for any isolation domain, only user functions originate from user-uploaded source code; all other components are provided by the cloud service provider. Traditional solutions typically utilize hardware-based isolation techniques to differentiate between different permissions. This embodiment relies on Software Fault Isolation (SFI) provided by the Rust language to ensure the effectiveness of isolation domains. The architecture in this embodiment emphasizes that all components are deployed within the same address space; therefore, user functions that can access arbitrary memory data, jump to arbitrary code addresses, or embed assembly code can easily compromise isolation domains. Therefore, this system requires user functions to be restricted to Safe Rust to prevent potentially unsafe behavior.

[0054] S2. For the workflow scenario of server-insensitive function computation, a new software stack architecture is proposed for runtime.

[0055] S3. By deploying all functions and the underlying runtime environments they depend on in the same CPU privilege level and address space, cold boot operations are enabled.

[0056] S4. Utilize workflow-level library operating systems to provide low-level runtime services for functions, while using memory-safe languages ​​to provide memory isolation and sharing;

[0057] This embodiment provides a threat model that does not rely on privilege levels and address spaces, but rather on Software Fault Isolation (SFI), i.e., the safe Rust language, to provide isolated function execution environments for different tenants. This constraint primarily applies at compile time. To prevent users from bypassing this compile-time check, it must be ensured that all executable file images originate from a trusted compilation environment provided by the cloud platform. A trusted compilation environment must satisfy the following assumptions:

[0058] (1) The Rust compilation toolchain, including its core library, is correctly designed and implemented.

[0059] (2) Users cannot directly upload executable binary files or use third-party dependency libraries that have not been verified and ported by the platform.

[0060] (3) Ensure that user function code does not contain any unsafe code blocks.

[0061] When the above assumptions are met, this scheme guarantees that, under the constraints of Safe Rust, attackers cannot directly dereference raw pointers or read / modify memory regions that do not belong to them. They also cannot tamper with control flow or directly interact with the host kernel via raw pointers and embedded assembly language. Since the library operating system is also written in Rust, it is also subject to the constraints of Safe Rust. Therefore, if an attacker crashes the library operating system, it will not affect other isolated domains.

[0062] S5. Implement an on-demand loading mechanism for the library operating system;

[0063] like Figure 3 As shown in this embodiment, in the on-demand loading mechanism, with subsequent iterative development, the size of the library operating system will gradually increase, leading to a corresponding increase in cold start time and memory usage. At this point, the customization and out-of-the-box functionality of the library operating system cannot be simultaneously achieved. To overcome this contradiction, an on-demand loading mechanism is introduced. The core principle is to dynamically bind system call handling functions during runtime. Achieving this involves two layers of system call handling function binding.

[0064] See Figure 3 The function layer in the aforementioned on-demand loading mechanism tracks which interfaces of the library operating system a single function instance has been bound to. When a function needs to call a kernel service, under the constraints of Safe Rust, it must first go through the interface provided by the standard library layer. The standard library layer checks whether the function address entry of the downstream module has already been registered. If not, it proceeds to the workflow layer.

[0065] The workflow layer in the aforementioned on-demand loading mechanism stores all loaded library and operating system modules within this workflow. `ms_std` exits to the global runtime by calling a specific interface. The global runtime `msvisor` first determines which library or operating system module the required interface belongs to, and then checks if this module exists in the isolation domain. If it exists, the function address is retrieved from the module instance; otherwise, the module is instantiated from the image.

[0066] In summary, this invention proposes a lightweight function runtime for server-insensitive computing scenarios, providing communication primitives for fast cold start in isolated environments and high-performance intermediate data transfer.

[0067] This invention utilizes a workflow-level library operating system to provide low-level runtime services for functions, while leveraging a memory-safe language to offer flexible memory isolation and sharing. To further mitigate cold-start overhead, this invention implements an on-demand loading mechanism for the library operating system.

[0068] Compared to existing technologies, the runtime proposed in this invention is a novel software stack architecture specifically designed for server-insensitive function computation workflow scenarios. By deploying all functions and their underlying runtime dependencies within the same CPU privilege level and address space, the scope of cold starts is reduced and costly data copying is avoided.

[0069] Compared to existing technologies, this invention can reduce the cold start time of server-insensitive computation functions to approximately 1ms. By utilizing dedicated communication primitives for intermediate data transmission, the latency for synchronous switching of upstream and downstream functions on the same node is only about 35μs. For parallel sorting computation tasks with 100MB of input data, this invention can reduce the overall end-to-end runtime by 90% on the same node.

[0070] This invention solves the technical problems of slow cold start in isolated environments, poor intermediate data transfer performance, large cold start range and high cost, and poor flexibility of memory isolation and sharing in the prior art.

[0071] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A lightweight function execution method for server-insensitive computing scenarios, characterized in that, The method includes: S1. For server-insensitive computing scenarios, a lightweight function runtime is set up to obtain the software stack structure. Using the lightweight function runtime method, all components of the software stack structure are aggregated into the same CPU privilege level and address space to obtain cold start and intermediate data transfer communication primitives. Among them, the standard library layer ms_std, the kernel function layer mslibos, and the global runtime layer msvisor are set. The lightweight function execution methods in S1 include: S11' Obtain and bind the workflow to the preset HTTP endpoints according to the global runtime, and expose them externally; S12' When an external processor receives a workflow invocation event, the global runtime instantiates the corresponding isolation domain for that workflow; S13': Derive a new thread and jump to the entry point of the user function, and continue running until the user function calls the system call interface of the library operating system module that has not yet been initialized; S14' Utilizing the standard library of the user functions, notify the global runtime through a preset interface to perform on-demand loading and obtain the system call interface. alloc_buffer() The function address is used to allocate a buffer to the user function and pass intermediate data; S15' causes the next user function to execute S11' through S14' until the call... acquire_buffer() To obtain a buffer reference, a zero-copy read operation is performed on the intermediate data; S2. Deploy the lightweight function and the underlying runtime that the lightweight function depends on to the same CPU privilege level and address space for cold boot operation; S3. Utilize a pre-built workflow granularity library operating system to provide the corresponding underlying runtime services for the lightweight functions, use a memory-safe language to perform memory isolation and sharing operations, obtain a threat model based on Software Fault Isolation (SFI), use the Safe Rust language to provide tenants with mutually isolated function execution environments, and obtain executable file images from the trusted mutation environment of the pre-built cloud platform. S4. For the library operating system, an on-demand loading mechanism is introduced to dynamically bind the processing functions called by the library operating system during runtime. A function layer and a workflow layer are designed to perform function binding operations based on the executable file image. In S4, the function layer is used to track the interface of the library operating system that a single function instance has been bound to. When the function instance calls the kernel service, under the constraint of safe Rust, it goes through the interface of the standard library layer. The standard library layer checks whether it has registered the function address entry of the downstream module. If not, it enters the workflow layer. The workflow layer is used to save all loaded library operating system modules in the current workflow.

2. The lightweight function execution method for server-insensitive computing scenarios according to claim 1, characterized in that, S1 includes: S11. Using the standard library layer ms_std, generate and provide a programming interface layer to send the intercepted system call request to the library operating system; S12. Using the kernel functional layer mslibos, allocate an instance of the library operating system for each function workflow, perform modular design on the library operating system to obtain a library operating system module for the standard library layer ms_std to call; S13. Using the global runtime layer msvisor, listen for external call events, instantiate and specify user functions according to the workflow configuration file, and track and obtain associated host resources during workflow execution.

3. The lightweight function execution method for server-insensitive computing scenarios according to claim 1, characterized in that, In step S12', the workflow instance is abstracted to obtain the isolation domain, and all entities required to run the current workflow are associated with the isolation domain. The entities include user functions, library operating system, memory partitions, and other system resources.

4. The lightweight function execution method for server-insensitive computing scenarios according to claim 3, characterized in that, The isolation domain is constructed based on the number of workflow instances running simultaneously on a single node, the workflow holding library operating system instance, and the user functions.

5. The lightweight function execution method for server-insensitive computing scenarios according to claim 3, characterized in that, Within the isolation domain, the user functions are determined based on the user's source code, component data from the cloud service provider is obtained, and Software Fault Isolation (SFI) is provided using the Rust language to control the isolation domain.

6. The lightweight function execution method for server-insensitive computing scenarios according to claim 1, characterized in that, In S3, within a trusted compilation environment, a Rust compilation toolchain is set up, which includes: a core library; setting constraints on user-uploaded data; and removing unsafe code blocks from user functions.

7. The lightweight function execution method for server-insensitive computing scenarios according to claim 1, characterized in that, In step S4, the standard library layer ms_std exits to the global runtime layer msvisor by calling a specific interface; the global runtime layer msvisor is used to determine the relationship between the interface to be called and the library operating system module, in order to check whether the library operating system module exists in the isolation domain; if so, the function address is retrieved from the function instance of the library operating system module; if not, the library operating system module is instantiated from the executable file image.

8. A lightweight function execution system for server-insensitive computing scenarios, used to execute the lightweight function execution method for server-insensitive computing scenarios as described in any one of claims 1 to 7, characterized in that, The system includes: The module for obtaining communication primitives is designed for server-insensitive computing scenarios. It sets up a lightweight function runtime to obtain the software stack structure and uses the lightweight function runtime method to aggregate all components of the software stack structure into the same CPU privilege level and address space to obtain cold start and intermediate data transfer communication primitives. The module sets up the standard library layer ms_std, the kernel function layer mslibos, and the global runtime layer msvisor. The lightweight function and underlying runtime deployment module is used to deploy the lightweight function and the underlying runtime that the lightweight function depends on to the same CPU privilege level and address space for cold boot operations. The isolated function execution environment setting module is used to provide the corresponding services of the underlying runtime for the lightweight function using a pre-built workflow granularity library operating system, to perform memory isolation and sharing operations using a memory-safe language, to obtain a threat model based on Software Fault Isolation (SFI), to provide tenants with mutually isolated function execution environments using the Safe Rust language, and to obtain executable file images from the trusted mutation environment of the pre-built cloud platform. The isolated function execution environment setting module is connected to the lightweight function and underlying runtime deployment module and the communication primitive acquisition module. The on-demand loading module is used to introduce an on-demand loading mechanism for the library operating system. During runtime, it dynamically binds the processing functions called by the library operating system. It designs a function layer and a workflow layer, and performs function binding operations based on the executable file image. The on-demand loading module is connected to the isolated function execution environment setting module and the communication primitive acquisition module.

Images