Lightweight function operation method and system oriented to server non-perceptual computing scene

Abstract

The invention provides a lightweight function operation method and system oriented to a server perception-free computing scene. The method comprises the following steps: providing a communication primitive for rapid cold start and high-performance intermediate data transmission of an isolated environment; for a workflow scene without perceptual function calculation of a server, providing a novel software stack architecture during operation; a function and a bottom layer on which the function depends during operation are all deployed in the same CPU privilege level and address space for cold start operation; a library operating system of workflow granularity is used for providing bottom layer runtime service for functions, and meanwhile, a memory security language is used for providing memory isolation and sharing; and realizing an on-demand loading mechanism for the library operating system. The technical problems of slow cold start in an isolation environment, poor intermediate data transmission performance, large cold start range, high cost and poor memory isolation and sharing flexibility are solved.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to function runtime in a server-unaware computing scenario. Background Art

[0002] In recent years, server-aware 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 expansion. Similar to traditional cloud computing services, current server-aware computing platforms must also ensure the isolation of 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 "A Serverless-based Edge Computing Resource Management System" with publication number CN114691299A, the existing method includes: Center Serverless is used to manage Serverless applications and triggers, create and execute Serverless applications on the central node; Edge Serverless is used to execute Serverless applications on the edge side, monitor node resource status, and transfer requests to the central node when resources are insufficient; Edge event triggers are used to obtain edge events, and send event information to the message queue after the trigger condition is met; Kata Container security containers are used to strongly isolate user applications so that each user application does not interfere with each other during runtime; Multi-architecture Runtime environment, automatically selects the matching architecture when running in different architecture Runtimes, and realizes architecture awareness at the user level. And the existing invention patent application document "A multi-carrying robot scheduling method based on cloud-edge computing" with publication number CN114385362A, the existing method includes: each robot is connected to the edge computing server through wireless communication technology, and the edge computing server requests the cloud computing server; the edge computing server instantiates the multi-carrying robot task scheduling problem into a colored traveling salesman problem model, and uses HTTP service to request the colored traveling salesman problem solving service of the cloud computing server, which is encapsulated in a container on the cloud computing server; after receiving the scheduling request, the cloud computing server executes the parallel colored traveling salesman problem solving algorithm, and sends the multi-robot task scheduling result to the edge computing server through the HTTP protocol; after receiving the multi-robot task scheduling result, the edge computing server executes the multi-robot path planning algorithm and sends the obtained shortest path to each robot. However, the aforementioned existing deployment architecture forms an inefficient and overweight function software stack that needs to cross multiple different privilege levels and address spaces, thereby reducing the execution efficiency of the function. Cold start events triggered by external function call events or internal communication events caused by the transfer of intermediate data in the workflow will be amplified by the virtualization layer in this software stack, and eventually accumulate to the end-to-end delay of the user load. Since functions usually have a short life cycle, these overheads cannot be ignored. For example, the cold start time of the secure container gVisor or the micro virtual machine Firecracker takes at least 100ms, which exceeds the execution time of 75% of the functions in the data published by Huawei Cloud.In addition, a report from Google stated that the overhead of data transfer between services accounts for 25% of the CPU cycles in the data center. Therefore, how to solve the problem of cold start and high data transfer overhead of the current platform function runtime base is an important challenge in the field of server-aware computing.

[0003] Some existing work attempts to alleviate the above overhead from two aspects: (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 thread function calls instead of inter-process communication. (2) Lightweight operating system, a method that deploys 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 can replace system calls with function calls, thereby speeding up the running speed of the program. However, the above solutions still cannot completely eliminate the privilege level barriers between user functions, the virtualization layer, and the operating system module. Context switching is required to achieve interaction between these components.

[0004] In summary, the existing technology has technical problems such as slow cold start in the isolated environment, poor intermediate data transmission performance, large cold start range and high cost, and poor flexibility of memory isolation and sharing. Summary of the invention

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

[0006] The present invention adopts the following technical solutions to solve the above technical problems: a lightweight function running method for server-unaware computing scenarios includes:

[0007] S1. For server-unaware computing scenarios, set up lightweight function runtime, obtain the software stack structure, and use the lightweight function running method to aggregate all components of the software stack structure to the same CPU privilege level and address space to obtain cold start and intermediate data transfer communication primitives, among which the standard library layer ms_std, the kernel function layer mslibos, and the global runtime layer msvisor are set;

[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 start operations;

[0009] S3. Use the preset workflow granularity library operating system to provide corresponding services for the underlying runtime for lightweight functions, use memory safety language to perform memory isolation and sharing operations, obtain threat models based on software fault isolation SFI, use safe Rust language to provide tenants with mutually isolated function execution environments, and obtain executable file images from the preset cloud platform 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 operation, design the function layer and workflow layer, and perform function binding operations according to the executable file image.

[0011] The present invention proposes a lightweight function runtime for server-unaware computing scenarios, which provides communication primitives for fast cold start in an isolated environment and high-performance intermediate data transmission.

[0012] The present invention uses a library operating system with workflow granularity to provide underlying runtime services for functions, and uses a memory-safe language to provide flexible memory isolation and sharing. In order to further alleviate cold start overhead, the present invention implements an on-demand loading mechanism for the library operating system.

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

[0014] S11, using the standard library layer ms_std to generate and provide a programming interface layer to send the intercepted system call request to the library operating system;

[0015] S12, using the kernel function layer mslibos, allocating an instance of the library operating system to each function workflow, performing modular design on the library operating system, and obtaining a library operating system module for calling by the standard library layer ms_std;

[0016] S13. Using the global runtime layer msvisor, monitor external call events, perform instantiation and specification according to the workflow configuration file, obtain user functions, and track and obtain associated host resources during the workflow operation.

[0017] In a more specific technical solution, the lightweight function operation method in S1 includes:

[0018] S11', obtain and bind the workflow to the preset HTTP endpoint according to the global runtime, and expose it externally;

[0019] S12', when the external processor receives a workflow call 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 to run until the user function calls the system call interface of the library operating system module that has not yet been initialized;

[0021] S14', using the standard library of the user function, notifying the global runtime through the preset interface to load on demand, and obtaining the function address of the system call interface alloc_buffer() to allocate a buffer to the user function and pass intermediate data;

[0022] S15', making the next user function execute S11' to S14' until calling acquire_buffer() to obtain a buffer reference and implement a zero-copy read operation on the intermediate data.

[0023] Compared with the prior art, the runtime proposed in this invention is a new software stack architecture specially proposed for workflow scenarios of server-unaware function computing. By deploying all functions and the underlying runtime they depend on at the same CPU privilege level and address space, the cold start range can be reduced and expensive data copying can be avoided.

[0024] In a more specific technical solution, in S12', an abstract operation is performed on the workflow instance to obtain an isolation domain, and all entities required to run the current workflow are associated with the isolation domain, where the entities include: user functions, library operating systems, 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, in the isolation domain, the user function is determined according to the user source code, the component data of the cloud service provider is obtained, and the Rust language is used to provide software fault isolation SFI to control the isolation domain.

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

[0028] In a more specific technical solution, in S4, the function layer is used to track the interface of the library operating system that has been bound to a single function instance. When the function instance calls the kernel service, under the constraints of safe Rust, the interface of the standard library layer is passed. The standard library layer checks whether the function address entry of the downstream module has been registered internally. If not, it enters the workflow layer.

[0029] Compared with the existing technology, the present invention can shorten the cold start time of the server-unaware computing function to about 1ms, and use the communication primitives dedicated to intermediate data transmission to achieve the delay of synchronous switching of upstream and downstream functions on the same node with only about 35μs. For parallel sorting computing tasks with 100MB of input data, the present invention can reduce the overall end-to-end running time 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 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 a more specific technical solution, the lightweight function running system for server-unaware computing scenarios includes:

[0032] The communication primitive acquisition module is used to set up lightweight function runtime for server-unaware computing scenarios, obtain the software stack structure, and use the lightweight function running method to aggregate all components of the software stack structure to the same CPU privilege level and address space to obtain cold start and intermediate data transfer communication primitives, among which the standard library layer ms_std, the kernel function layer mslibos, and the global runtime layer msvisor are set;

[0033] Lightweight function and underlying runtime deployment module, used to deploy lightweight functions and the underlying runtime that lightweight functions depend on to the same CPU privilege level and address space for cold start operations;

[0034] The isolated function execution environment setting module is used to use the preset workflow granularity library operating system to provide corresponding services of the underlying runtime for lightweight functions, use memory safety language to perform memory isolation operations and sharing operations, obtain threat models based on software fault isolation SFI, and use safe Rust language to provide tenants with mutually isolated function execution environments. The preset cloud platform is a trusted mutation environment, and executable file images are obtained. The isolated function execution environment setting module is connected with the lightweight function and the underlying runtime deployment module and the communication primitive acquisition module;

[0035] The on-demand loading module is used to introduce an on-demand loading mechanism for the library operating system, dynamically bind the processing functions called by the library operating system during operation, design the function layer and workflow layer, perform function binding operations according to the executable file image, and connect the on-demand loading module with the isolation function execution environment setting module and the communication primitive acquisition module.

[0036] Compared with the prior art, the present invention has the following advantages:

[0037] The present invention proposes a lightweight function runtime for server-unaware computing scenarios, which provides communication primitives for fast cold start in an isolated environment and high-performance intermediate data transmission.

[0038] The present invention uses a library operating system with workflow granularity to provide underlying runtime services for functions, and uses a memory-safe language to provide flexible memory isolation and sharing. In order to further alleviate cold start overhead, the present invention implements an on-demand loading mechanism for the library operating system.

[0039] Compared with the prior art, the runtime proposed in this invention is a new software stack architecture specially proposed for workflow scenarios of server-unaware function computing. By deploying all functions and the underlying runtime they depend on at the same CPU privilege level and address space, the cold start range can be reduced and expensive data copying can be avoided.

[0040] Compared with the existing technology, the present invention can shorten the cold start time of the server-unaware computing function to about 1ms, and use the communication primitives dedicated to intermediate data transmission to achieve the delay of synchronous switching of upstream and downstream functions on the same node with only about 35μs. For parallel sorting computing tasks with 100MB of input data, the present invention can reduce the overall end-to-end running time by 90% on the same node.

[0041] The present invention solves the technical problems existing in the prior art of slow cold start in an isolated environment, poor intermediate data transmission performance, high cost of a large cold start range, and poor flexibility in memory isolation and sharing. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is a schematic diagram of the basic steps of a lightweight function running method for a server-unaware computing scenario according to Embodiment 1 of the present invention;

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

[0044] Figure 3 This is a schematic diagram of on-demand loading of the library operating system of Example 1 of the present invention. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in combination with the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0046] Example 1

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

[0048] S1, communication primitives that provide fast cold start and high-performance intermediate data transmission in an isolated environment;

[0049] like Figure 2 As shown, in this embodiment, a lightweight function runtime for server-unaware computing scenarios is proposed. The core idea of ​​this runtime is to aggregate all components of the software stack into the same CPU privilege level and address space, that is, within one process. Figure 1 The lightweight function running system for server-unaware computing scenarios includes but is 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 is responsible for providing 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, that is, each function workflow is assigned a separate library operating system instance, which is responsible for protecting the host kernel from attacks by malicious user loads. The library operating system in this embodiment is also designed in a modular form and can call each other through the standard library layer; the global runtime layer is responsible for monitoring external call events, instantiating specified user functions and library operating system modules according to the workflow configuration file, and tracking related host resources during the workflow operation, such as network devices and file system images.

[0051] See also Figure 1, during the execution of the lightweight function running method for server-unaware 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 derives a new thread and jumps to the entry point of the user function, and then runs normally until the function tries 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 on demand through a specific interface, and obtain the function address to call the interface alloc_buffer(), which can allocate a buffer for the function to pass intermediate data; in the subsequent running stage 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 achieving zero-copy intermediate data reading⑤.

[0052] In this embodiment, the aforementioned isolation domain is an abstraction of a workflow instance, which is used to logically associate all entities required to run this workflow, including but 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, which means that N workflow instances can be run simultaneously on a node, and each workflow holds a separate library operating system instance and M user functions. Through the isolation domain, different functions in the same workflow can share specific system resources, such as files. In contrast, user functions of different workflows cannot access each other's files across isolation domains because related system calls are processed by different library operating system instances.

[0053] In this embodiment, for any isolation domain, only user functions are derived from the source code uploaded by the user; all other components are provided by the cloud service provider. Traditional solutions usually use hardware-based isolation technology to distinguish different permissions. This embodiment relies on the software fault isolation SFI provided by the Rust language to ensure the effectiveness of the isolation domain. The architecture in this embodiment emphasizes that all components are deployed in the same address space. Therefore, if the user function can access arbitrary memory data, jump to any code address, or embed assembly code, it will easily destroy the isolation domain. Therefore, this system requires that user functions be restricted to safe Rust to prevent potential unsafe behavior.

[0054] S2, for the workflow scenario of server-unaware function computing, a runtime is proposed as a new software stack architecture;

[0055] S3, by deploying all functions and the underlying runtimes that the functions depend on at the same CPU privilege level and address space, for cold start operations;

[0056] S4. Use the library operating system with workflow granularity to provide underlying runtime services for functions, and use 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 is based on software fault isolation (SFI), that is, the safe Rust language to provide isolated function execution environments for different tenants. This constraint mainly acts on the compile time. In order to prevent users from bypassing this compile time check, it is necessary to ensure that all executable file images come from the trusted compilation environment provided by the cloud platform. The trusted compilation environment needs to meet 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 dependent libraries that have not been platform-verified and ported.

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

[0061] When the above assumptions are met, this solution can ensure that under the constraints of safe Rust, attackers cannot directly dereference raw pointers or read / tamper with memory areas that do not belong to them. At the same time, they cannot tamper with control flow and directly interact with the host kernel through raw pointers and embedded assembly language. Since the library operating system is also written in Rust, it is also subject to the constraints of the safeRust language. 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 the subsequent continuous iterative development, the scale of the library operating system will gradually increase, resulting in an increase in cold start time and memory usage. At this time, the customization and out-of-the-box use of the library operating system cannot be taken into account at the same time. In order to break the above contradiction, the on-demand loading mechanism is introduced. The core principle is to dynamically bind the processing function of the system call during operation. In order to achieve this goal, two layers of system call processing function binding are involved.

[0064] See also Figure 3 , the function layer in the aforementioned on-demand loading mechanism is used to track 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 been registered internally. If not, it enters the workflow layer.

[0065] The workflow layer in the aforementioned on-demand loading mechanism saves all loaded library operating system modules in this workflow. ms_std exits to the global runtime by calling a specific interface. The global runtime msvisor first determines which library operating system module the interface to be called belongs to, and then checks whether 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, the present invention proposes a lightweight function runtime for server-unaware computing scenarios, which provides communication primitives for fast cold start in an isolated environment and high-performance intermediate data transmission.

[0067] The present invention uses a library operating system with workflow granularity to provide underlying runtime services for functions, and uses a memory-safe language to provide flexible memory isolation and sharing. In order to further alleviate cold start overhead, the present invention implements an on-demand loading mechanism for the library operating system.

[0068] Compared with the prior art, the runtime proposed in this invention is a new software stack architecture specially proposed for workflow scenarios of server-unaware function computing. By deploying all functions and the underlying runtime they depend on at the same CPU privilege level and address space, the cold start range can be reduced and expensive data copying can be avoided.

[0069] Compared with the existing technology, the present invention can shorten the cold start time of the server-unaware computing function to about 1ms, and use the communication primitives dedicated to intermediate data transmission to achieve the delay of synchronous switching of upstream and downstream functions on the same node with only about 35μs. For parallel sorting computing tasks with 100MB of input data, the present invention can reduce the overall end-to-end running time by 90% on the same node.

[0070] The present invention solves the technical problems existing in the prior art of slow cold start in an isolated environment, poor intermediate data transmission performance, high cost of a large cold start range, and poor flexibility in memory isolation and sharing.

[0071] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A lightweight function running method for server-unaware computing scenarios. It is characterized in that The method comprises: S1. For server-unaware computing scenarios, set a lightweight function runtime, obtain a software stack structure, and use a lightweight function runtime method to aggregate all components of the software stack structure to the same CPU privilege level and address space to obtain cold start and intermediate data transfer communication primitives, wherein the standard library layer ms_std, the kernel function layer mslibos, and the global runtime layer msvisor are set; S2. Deploy the lightweight function and the underlying runtime on which the lightweight function depends to the same CPU privilege level and address space for cold start operation; S3. Use the preset workflow granularity library operating system to provide the corresponding service of the underlying runtime for the lightweight function, use the memory safety language to perform memory isolation and sharing operations, obtain the threat model based on software fault isolation SFI, use the safe Rust language to provide tenants with a mutually isolated function execution environment, and obtain the executable file image from the preset cloud platform which is a trusted variation environment; 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 operation, design the function layer and the workflow layer, and perform function binding operations according to the executable file image.

2. According to claim 1, the lightweight function running method for server-unaware computing scenarios, It is characterized in that The S1 includes: S11, using the standard library layer ms_std to generate and provide a programming interface layer to send the intercepted system call request to the library operating system; S12, using the kernel function layer mslibos, allocating an instance of a library operating system to each function workflow, performing modular design on the library operating system, and obtaining a library operating system module for calling by the standard library layer ms_std; S13, using the global runtime layer msvisor to monitor external call events, perform instantiation and specification according to the workflow configuration file, obtain user functions, and track and obtain associated host resources during the workflow operation.

3. According to claim 1, the lightweight function running method for server-unaware computing scenarios, It is characterized in that The lightweight function running method in S1 includes: S11', obtain and bind the workflow to the preset HTTP endpoint according to the global runtime, and expose it externally; S12', when the external processor receives a workflow call event, setting the global runtime to the isolation domain corresponding to the current workflow instantiation; S13', deriving a new thread and jumping to the entry point of the user function, and continuing to run until the user function calls the system call interface of the library operating system module that has not yet been initialized; S14', using the standard library of the user function to notify the global runtime through a preset interface to load on demand, and obtain the function address of the system call interface alloc_buffer() to allocate a buffer to the user function and transfer intermediate data; S15', making the next user function execute S11' to S14' until calling acquire_buffer() to obtain a buffer reference and implement a zero-copy read operation on the intermediate data.

4. According to claim 3, the lightweight function running method for server-unaware computing scenarios, It is characterized in that In S12', an abstract operation is performed on the workflow instance to obtain the isolation domain, and all entities required to run the current workflow are associated with the isolation domain, wherein the entities include: user functions, library operating system, memory partitions and other system resources.

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

6. According to claim 4, the lightweight function running method for server-unaware computing scenarios, It is characterized in that In the isolation domain, the user function is determined according to the user source code, the component data of the cloud service provider is obtained, and the Rust language is used to provide software fault isolation SFI to control the isolation domain.

7. According to claim 1, the lightweight function running method for server-unaware computing scenarios, It is characterized in that In S3, in the trusted compilation environment, a Rust compilation tool chain is set, and the Rust compilation tool chain includes: a core library; setting user upload data constraints; and removing unsafe code blocks in the code of the user function.

8. According to claim 1, the lightweight function running method for server-unaware computing scenarios, It is characterized in that In S4, the function layer is used to track the interface of the library operating system that has been bound to a single function instance. When the function instance calls the kernel service, under the constraints of safe Rust, the interface of the standard library layer is passed through. The standard library layer checks whether the function address entry of the downstream module has been registered within itself. If not, it enters the workflow layer.

9. According to claim 1, the lightweight function running method for server-unaware computing scenarios, It is characterized in that 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 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.

10. A lightweight function running system for server-unaware computing scenarios. It is characterized in that The system comprises: The communication primitive acquisition module is used to set a lightweight function runtime for server-unaware computing scenarios, obtain the software stack structure, and use the lightweight function running method to aggregate all components of the software stack structure to the same CPU privilege level and address space to obtain cold start and intermediate data transfer communication primitives, wherein the standard library layer ms_std, the kernel function layer mslibos, and the global runtime layer msvisor are set; A lightweight function and underlying runtime deployment module, used to deploy lightweight functions and the underlying runtime that the lightweight functions depend on to the same CPU privilege level and address space for cold start operations; An isolated function execution environment setting module is used to use a preset workflow granularity library operating system to provide the corresponding service of the underlying runtime for the lightweight function, use a memory safety language to perform memory isolation operations and sharing operations, obtain a threat model based on software fault isolation SFI, and use the safe Rust language to provide tenants with a mutually isolated function execution environment. The preset cloud platform is a trusted variation environment to obtain an executable file image. The isolated function execution environment setting module is connected to the lightweight function and the underlying runtime deployment module and the transmission communication primitive acquisition module; The on-demand loading module is used to introduce an on-demand loading mechanism for the library operating system, dynamically bind the processing functions called by the library operating system during operation, design the function layer and the workflow layer, and perform function binding operations according to the executable file image. The on-demand loading module is connected to the isolation function execution environment setting module and the communication primitive acquisition module.

Images