Method and system for running WASM application

Abstract

Provided are a method and system for running a WASM application. The method is applied to a cloud management platform, the cloud management platform is configured to manage infrastructure, the infrastructure comprises at least one cloud data center, each cloud data center among the at least one cloud data center is provided with a plurality of servers, and the cloud management platform supports a plurality of WASM runtimes. The method comprises: receiving an execution request of an application program (310); acquiring a WASM module of the application program (320); when a target WASM runtime is determined from among a plurality of WASM runtimes, the target WASM runtime supporting the WASM module (330); using the target WASM runtime to create a sandbox (340); and running the WASM module in the sandbox (350). The solutions in the embodiments facilitate an improvement in user development experience.

Description

Method and system for running WASM applications

[0001] This application claims priority to Chinese patent application No. 202311675427.7 filed with the State Intellectual Property Office of China on December 7, 2023, priority to Chinese patent application No. 202410190028.X filed with the State Intellectual Property Office of China on February 20, 2024 ...410190028.X filed with the State Intellectual Property Office of China on February 20, 2024, priority to Technical Field

[0002] The present application relates to the field of computer technology, and more specifically, to a method and system for running WASM applications. Background Art

[0003] WebAssembly (WASM) is a low-level bytecode that can run in browsers. Due to its lightweight, highly secure, and fast cold start, WASM has gradually expanded from the browser domain to cloud computing and edge computing. Application source code can be compiled into WASM modules, which are then executed by a WASM runtime in an embedded environment. In environments other than browsers, WASM modules must be executed by a WASM runtime that supports the WebAssembly system interface (WASI).

[0004] As an emerging technology, WASM is rapidly developing. The standards for WASM and WASI are still evolving, and multiple runtimes exist within the community. Different WASM runtimes differ in their support for WASI and implementation methods. For example, WASMEdge currently supports WASI for databases and sockets, providing network capabilities for accessing database backend resources and sending Hypertext Transfer Protocol (HTTP) requests, while other WASM runtimes do not yet offer these capabilities. This discrepancy impacts the user experience. For example, when developing a program, users must adjust their application implementation based on the capabilities provided by different WASM runtimes and their associated runtime platforms, making it difficult to focus on implementing business logic, thus impacting the user development experience. Furthermore, after selecting a WASM runtime and deploying an application to a platform that supports it, any subsequent adjustments or optimizations to the application require reconsidering the capabilities provided by different WASM runtimes and their associated runtime platforms. This significantly impacts user development efficiency and, further, the user experience.

[0005] Summary of the Invention

[0006] This application provides a method and system for running WASM applications, which is conducive to improving the user development experience.

[0007] In a first aspect, a method for running a WASM application is provided. The method is applied to a cloud management platform, and the cloud management platform is used to manage infrastructure. The infrastructure includes at least one cloud data center, and each cloud data center of the at least one cloud data center is provided with multiple servers. The cloud management platform supports multiple WASM runtimes. The method includes: receiving an execution request of an application; obtaining a WASM module of the application; determining a target WASM runtime from multiple WASM runtimes, where the target WASM runtime supports the WASM module; creating a sandbox using the target WASM runtime; and running the WASM module in the sandbox.

[0008] In an embodiment of the present application, the cloud management platform supports multiple WASM runtimes, that is, supports multiple heterogeneous WASM runtimes. After receiving a call request from an application, a sandbox can be created by the WASM runtime (i.e., the target WASM runtime) that supports the WASM module of the application to execute the application. This can shield the user from the differences in the underlying WASM runtime, so that the user does not need to pay attention to the type of the underlying WASM runtime during the application development process, and can focus on the business logic, thereby improving the user experience.

[0009] For example, the WASM module of the application can be provided by the user. For example, the user can provide a compiled WASM module to the cloud management platform.

[0010] Alternatively, the WASM module of an application can be compiled from the application's source code. For example, the user can provide the application's source code to the cloud management platform, which then compiles the application's source code to generate the corresponding WASM module.

[0011] The target WASM runtime supports WASM modules, that is, the WASM module can be run through the target WASM runtime.

[0012] In combination with the first aspect, in certain implementations of the first aspect, the WASI supported by the target WASM runtime includes WASI in the WASM module.

[0013] This enables support for WASM modules on the target WASM runtime.

[0014] In combination with the first aspect, in certain implementations of the first aspect, determining a target WASM runtime from multiple WASM runtimes includes: obtaining a mapping relationship between multiple WASM runtimes and WASM system interfaces WASI supported by the multiple WASM runtimes; extracting WASI in the WASM module; and determining one or more candidate WASM runtimes from the multiple WASM runtimes based on the mapping relationship, where the WASI supported by the one or more candidate WASM runtimes includes the WASI in the WASM module, and the one or more candidate WASM runtimes include the target WASM runtime.

[0015] In the solution of the embodiment of this application, the WASM runtime that supports the WASM module is determined based on the WASM used in the WASM module. In this way, the user only needs to provide the application source code or WASM module, and the platform automatically matches and uses the underlying WASM runtime, which helps to further improve the user experience.

[0016] In combination with the first aspect, in some implementations of the first aspect, extracting WASI from the WASM module includes: decompiling the WASM module into a WASM text format WAT file; and extracting WASI from the WASM module from the WAT file.

[0017] In the solution of the embodiment of the present application, a WAT ​​file can be obtained by decompiling the WASM module, and the WASI used in the WAT file can be extracted. The WAT file can be parsed, and it is relatively easy to extract information from the WAT file, which helps to reduce the difficulty of extracting WASI from the WASM module.

[0018] In combination with the first aspect, in certain implementations of the first aspect, determining a target WASM runtime from multiple WASM runtimes includes: controlling the display of multiple candidate configuration items, where the multiple candidate configuration items are used to indicate multiple WASM runtimes; receiving selection results for the multiple candidate configuration items; and determining the target WASM runtime based on the selection results.

[0019] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: loading a target WASI, where the target WASI is used to communicate with the external environment of the sandbox during the execution of the WASM module, and the target WASI is determined based on the WASI supported by the target WASM runtime.

[0020] For example, after determining the target WASM runtime, all WASIs supported by the target WASM runtime can be loaded. That is, the target WASI can include all WASIs supported by the target WASM runtime.

[0021] In combination with the first aspect, in certain implementations of the first aspect, the target WASI is obtained by performing at least one of adding, deleting, or modifying the WASI supported by the target WASM runtime.

[0022] In the solution of the embodiment of the present application, WASI can be loaded dynamically, so that the loaded WASI can be adjusted as needed, which is conducive to meeting the personalized needs of users and thus helps to improve user experience.

[0023] In a second aspect, a system for running WASM applications is provided. The system is applied to a cloud management platform, which is used to manage infrastructure. The infrastructure includes at least one cloud data center. Each cloud data center of the at least one cloud data center is equipped with multiple servers. The cloud management platform supports multiple WASM runtimes, including: a receiving module for receiving an execution request of an application; an acquisition module for obtaining a WASM module of an application; a processing module for determining a target WASM runtime from multiple WASM runtimes, where the target WASM runtime supports WASM modules; a creation module for creating a sandbox using the target WASM runtime; and a running module for running the WASM module in the sandbox.

[0024] In an embodiment of the present application, the cloud management platform supports multiple WASM runtimes, that is, supports multiple heterogeneous WASM runtimes. After receiving a call request from an application, a sandbox can be created by the WASM runtime (i.e., the target WASM runtime) that supports the WASM module of the application to execute the application. This can shield the user from the differences in the underlying WASM runtime, so that the user does not need to pay attention to the type of the underlying WASM runtime during the application development process, and can focus on the business logic, thereby improving the user experience.

[0025] In combination with the second aspect, in certain implementations of the second aspect, the processing module is specifically used to: obtain a mapping relationship between multiple WASM runtimes and WASM system interfaces WASI supported by the multiple WASM runtimes; extract WASI in the WASM module; and determine one or more candidate WASM runtimes from the multiple WASM runtimes based on the mapping relationship, where the WASI supported by the one or more candidate WASM runtimes includes the WASI in the WASM module, and the one or more candidate WASM runtimes includes the target WASM runtime.

[0026] In combination with the second aspect, in some implementations of the second aspect, the processing module is specifically used to: decompile the WASM module into a WASM text format WAT file; and extract WASI in the WASM module from the WAT file.

[0027] In combination with the second aspect, in certain implementations of the second aspect, the processing module is specifically used to: control the display of multiple candidate configuration items, where the multiple candidate configuration items are used to indicate multiple WASM runtimes; receive selection results for the multiple candidate configuration items; and determine the target WASM runtime based on the selection results.

[0028] In conjunction with the second aspect, in some implementations of the second aspect, the system further includes: a loading module, used to load a target WASI, where the target WASI is used to communicate with the external environment of the sandbox during the execution of the WASM module, and the target WASI is determined based on the WASI supported by the target WASM runtime.

[0029] In conjunction with the second aspect, in certain implementations of the second aspect, the target WASI is obtained by performing at least one of adding, deleting, or modifying the WASI supported by the target WASM runtime.

[0030] It should be understood that the expansion, limitation, explanation and description of the relevant content in the above-mentioned first aspect also apply to the same content in the second aspect.

[0031] In a third aspect, a computing device cluster is provided, comprising at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster performs the method of the first aspect or any implementation of the first aspect.

[0032] In a fourth aspect, a computer-readable medium is provided, comprising computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method in the first aspect or any one of the implementations of the first aspect.

[0033] In a fifth aspect, a computer program product comprising instructions is provided. When the instructions are executed by a computing device cluster, the computing device cluster executes the method in the first aspect or any one of the implementations of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 is a schematic diagram of two solutions for running WASM applications;

[0035] FIG2 is a schematic diagram of an application scenario of an embodiment of the present application;

[0036] FIG3 is a schematic flowchart of a method for running a WASM application according to an embodiment of the present application;

[0037] FIG4 is a schematic flowchart of another method for running a WASM application according to an embodiment of the present application;

[0038] FIG5 is a schematic diagram of a system architecture for running a WASM application according to an embodiment of the present application;

[0039] FIG6 is a schematic diagram of another system architecture for running WASM applications according to an embodiment of the present application;

[0040] FIG7 is a schematic block diagram of a system for running a WASM application according to an embodiment of the present application;

[0041] FIG8 is a schematic block diagram of a computing device according to an embodiment of the present application;

[0042] FIG9 is a schematic block diagram of a computing device cluster according to an embodiment of the present application;

[0043] FIG10 is a schematic block diagram of another computing device cluster according to an embodiment of the present application. DETAILED DESCRIPTION

[0044] The terms used in the following embodiments are for the purpose of describing specific embodiments only and are not intended to limit the present application. As used in the specification and appended claims of this application, the singular expressions "a," "an," and "the" are intended to include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one," "at least one," and "one or more" refer to one, two, or more. "First," "second," and various numerical designations are merely distinctions made for ease of description and are not intended to limit the scope of the embodiments of this application. "And / or" is used to describe the corresponding relationship between corresponding objects, indicating that three relationships can exist. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist, where A and B can be singular or plural. The character " / " generally indicates that the objects associated with each other are in an "or" relationship. The order of the sequence numbers of the processes below does not imply a sequence of execution. The execution order of each process should be determined by its function and inherent logic and should not constitute any limitation on the implementation process of the embodiments of this application. For example, in the embodiments of the present application, words such as "301", "401", and "501" are merely identifiers for the convenience of description and do not limit the order of executing the steps.

[0045] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. In this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described in this application as "exemplary" or "for example" should not be interpreted as being more preferred or more advantageous than other embodiments or design. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete way. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized. In the embodiments of the present application, descriptions such as "when...", "in the case of...", "if" and "if" all mean that the device will perform corresponding processing under certain objective circumstances, and do not limit the time, nor do they require the device to perform judgment actions when implemented, nor do they mean that there are other limitations.

[0046] In this application, "used to indicate" can include being used for direct indication and being used for indirect indication. When describing that a certain indication information is used to indicate A, it can include that the indication information directly indicates A or indirectly indicates A, and it does not mean that the indication information must carry A.

[0047] In order to help those skilled in the art better understand the technical solutions of the present application, some terms that may be involved in the embodiments of the present application are explained below.

[0048] (1)WASM:

[0049] WASM is a new bytecode format with the following advantages: strong portability, support for cross-platform deployment and execution; lightweight, small module size, and fast loading and cold start speeds. WASM is a compilation target for high-level languages. Currently, toolchains for languages ​​such as C, C++, Go, Rust, and Java can be used to compile code in various languages ​​into WASM modules, or .wasm files.

[0050] (2) WebAssembly text format (WAT):

[0051] WAT files follow the standard format defined by WASM. Compared to WASM module bytecode files, the readability and understandability of WAT files are greatly improved for developers. Conversion between WAT files and WASM modules can be achieved through the toolchain.

[0052] (3)WASI:

[0053] WASI is a standardized system interface based on the WASM standard. It provides a standardized environment for executing WASM programs outside of web browsers while ensuring code portability and security. Through WASI, WASM can access network, storage, and heterogeneous computing hardware resources on the host machine within a sandbox, greatly enhancing WASM's scalability and providing a richer range of application scenarios.

[0054] (4) Runtime:

[0055] The runtime typically includes a runtime system and a runtime environment, providing the environment for the program to run. The runtime includes memory management, variable access, parameter passing mechanisms, and interfaces with the operating system.

[0056] (5) Serverless computing (Serverless):

[0057] Serverless computing is a cloud computing model. Based on Platform as a Service (PaaS), serverless computing provides a microarchitecture where end customers do not need to deploy, configure, or manage servers. The cloud platform provides all the server services required to run the code, including elastic scaling of backend resources. Users pay per use. Serverless technology is considered the next generation of cloud computing.

[0058] (6) Function as a service (FaaS):

[0059] FaaS, also known as "Function as a Service," is a representative form of serverless services. FaaS allows developers to build, compute, run, and manage their own application packages in the form of functions, eliminating the need to maintain backend infrastructure. FaaS is an event-driven execution model that runs in stateless containers. Functions utilize the FaaS provider's services to manage server-side logic and state.

[0060] (7) Edge function as a service (EFaaS):

[0061] Edge Function as a Service (EFaaS) refers to the service model of Function as a Service (FaS) at the edge cloud. EFaaS allows users to write scripts and run customized code on edge nodes close to end users, implementing complex business logic. Similar to FaS, developers only need to write function code snippets without having to worry about maintaining the underlying infrastructure.

[0062] Docker and Kubernetes (K8s) provide developers with more agile and efficient R&D and delivery tools, laying the foundation for microservices and cloud-native development paradigms.

[0063] Docker and Kubernetes are widely used in serverless logic multi-tenancy scenarios. For example, Docker provides relatively isolated, independent operating environments and resources for different function instances, while Kubernetes orchestrates and manages massive user instances. However, in extreme business scenarios, this solution has the following drawbacks: The cold start time for creating user function instances through Kubernetes is long, resulting in increased scaling time for user function instances, making it difficult to cope with user business peaks and respond to user requests in a timely manner. In scenarios with extremely large instance sizes, Kubernetes clusters cannot efficiently manage massive instances, posing significant challenges to scheduling efficiency and system stability. Furthermore, in resource-constrained extreme environments such as edge computing and wearable devices, the additional overhead of Kubernetes and Docker makes this technical solution difficult to implement.

[0064] WASM, with its lightweight, secure, and fast cold-start features, is gradually expanding from the browser realm to cloud computing and edge computing, and is considered the next generation technology of Docker. For example, the lightweight isolation solution provided by WASM allows the platform to create more function instances on the same computing resources, and provides stronger security in multi-tenant scenarios. Furthermore, WASM's cold-start performance enables the platform to quickly scale user instances during peak business hours, ensuring timely response to user requests.

[0065] Figure 1 shows two scenarios for running WASM applications.

[0066] As shown in Figure 1 (a), the user can provide the JavaScript source code of the application (app) (the app.js file shown in Figure 1). The compilation and construction tool chain provided by the platform can package the source code and the JavaScript engine (the QuickJS engine shown in Figure 1) into the WASM binary file of the application, that is, the WASM module (the app.wasm file shown in Figure 1). The linker is part of the tool chain. The QuickJS engine can compile the source code into bytecode. As shown in Figure 1 (a), the app.wasm file includes bytecode and the JS engine application program interface (API). The WASM module compiled by the platform is then used to run the user's application.

[0067] As shown in Figure 1(b), users can write application source code in high-level languages ​​such as GO, Rust, C, or C++, compile the source code into a WASM module using the relevant compilation and construction tool chain, and then directly provide the WASM module to the platform. The platform uses the WASM module to run the user's application.

[0068] As shown in Figure 1, a WASM module runs in a WASM sandbox. The WASM runtime provides the QuickJS engine's capabilities in the form of a WASM module (such as QuickJS.wasm in Figure 1) to execute JavaScript code within the sandbox. Specifically, QuickJS.wasm contains the QuickJS interpreter, which can be used to execute JavaScript code.

[0069] Currently, different WASM runtimes vary in their support for WASI and implementation methods, significantly impacting the user experience. Furthermore, WASM-supporting platforms are tightly coupled to specific WASM runtimes and focus on running specific programming languages ​​in a sandbox, further impacting the user experience. Taking FaaS on cloud platforms as an example, FaaS frameworks are tightly coupled to a specific WASM runtime. For example, when developing programs, users need to adjust their application implementation based on the capabilities provided by different WASM runtimes and the associated runtime platforms, making it difficult to focus on implementing business logic, thus impacting the user experience. Furthermore, after selecting a WASM runtime and deploying the application to a platform that supports it, any subsequent adjustments or optimizations to the application require reconsidering the capabilities provided by different WASM runtimes and the associated runtime platforms. This significantly impacts development efficiency and, further, the user experience. For example, to adapt to different business scenarios or improve application performance, users may need to use multiple WASM runtimes and deploy applications on multiple platforms. This not only impacts development efficiency but also increases the difficulty of managing applications and resources, thus impacting the user experience. For another example, when a user needs to switch the deployment platform of an application, if the switched platform does not support the runtime of the current platform, intrusive modifications will be introduced to the code of the user's application.

[0070] In view of this, an embodiment of the present application provides a method for running WASM applications, providing multiple heterogeneous WASM runtimes on the same platform, shielding users from the differences in the underlying WASM runtimes, allowing users to focus on the development of their own business logic, which is conducive to improving user experience.

[0071] The solution of the embodiment of the present application can be applied to the cloud platform.

[0072] Exemplarily, the solution of the embodiments of the present application can be applied to the Serverless or FaaS logical multi-tenant business scenario of the central cloud platform or edge cloud platform, wherein the Serverless or FaaS logical multi-tenant business is implemented through the underlying isolation solution provided by WASM.

[0073] Exemplarily, the solution of the embodiment of the present application can be applied to the microservice scenario of the central cloud platform or the edge cloud platform, wherein the microservice scenario is built based on the underlying isolation solution provided by WASM.

[0074] Taking Serverless as an example, the solution of the embodiment of the present application can be applied to the Serverless scenario of the central cloud. The WASM solution has a fast cold start speed, which is conducive to the rapid cold start of the Serverless of the central cloud to cope with the peak of user business requests. At the same time, the WASM solution also has the advantages of being lightweight and having low additional overhead, which is conducive to the high-density deployment of function instances on the central cloud, carrying more function instances and processing more function requests with the same resources. The solution of the embodiment of the present application can also be applied to the Serverless scenario of the edge cloud. The WASM solution has low additional overhead, and the use of the new WASM ecosystem can get rid of the heavy resource solution of K8s+docker, thereby being able to integrate scattered edge nodes and computing resources, and provide users with EFaaS capabilities in edge scenarios where resources are extremely scarce.

[0075] The cloud platform can obtain user-provided application source code or the application's WASM module and schedule the WASM module to execute the application. The cloud platform can create a sandbox using a matching WASM runtime to execute the application. This shields users from differences in the underlying WASM runtime, eliminating the need to worry about underlying runtime types and computing resources during application development, thereby improving the user experience.

[0076] Figure 2 shows a schematic diagram of an application scenario of an embodiment of the present application. For example, as shown in Figure 2, the user can provide the compiled WASM module of the application to the cloud platform, and the cloud platform schedules the WASM module to execute the application. The application (such as the WA in Figure 2) can be deployed on the central cloud, and the central cloud will run the application. At the same time, the application can also be deployed on the edge cloud node, so that the user's request can be processed at a location close to the end user, which is conducive to reducing latency and improving user experience.

[0077] Figure 3 illustrates a method for running a WASM application in accordance with an embodiment of the present application. This method 300 can be applied to a cloud management platform, which manages infrastructure, including at least one cloud data center, each of which is equipped with multiple servers. The cloud management platform supports multiple WASM runtimes. In this embodiment of the present application, the cloud management platform may also be referred to simply as the platform.

[0078] As shown in FIG3 , method 300 may include the following steps.

[0079] 310, receiving a call request from an application.

[0080] 320, obtain the WASM module of the application.

[0081] 330 , determining a target WASM runtime for the WASM module from multiple WASM runtimes, where the target WASM runtime supports the WASM module.

[0082] 340, create a sandbox using the target WASM runtime.

[0083] 350, run the WASM module in the sandbox.

[0084] In the solution of the embodiment of the present application, the cloud management platform supports multiple WASM runtimes, that is, supports multiple heterogeneous WASM runtimes. After receiving the call request of the application, a sandbox can be created by the WASM runtime (i.e., the target WASM runtime) that supports the WASM module of the application to execute the application. This can shield the user from the differences in the underlying WASM runtime, so that the user does not need to pay attention to the type of the underlying WASM runtime during the application development process, and can focus on the business logic, thereby improving the user experience.

[0085] At the same time, in the solution of the embodiment of the present application, the cloud management platform supports multiple WASM runtimes, so that users can experience multiple WASM runtimes, for example, experience the differentiated features or latest features of different WASM runtimes, etc., which is conducive to meeting users' selection requirements for WASM runtimes in different business scenarios.

[0086] At the same time, the cloud management platform supports multiple WASM runtimes and can switch between multiple WASM runtimes. In this way, the matching WASM runtime can be switched according to the needs of the user, which is conducive to the management of the user's application and related resources, thereby improving the user experience. For example, when the user needs to implement different business scenarios, he may need to use different WASM runtimes. The solution of the embodiment of the present application can be used to deploy the application on a unified platform, avoiding the platform switching caused by the switching of the WASM runtime, which is conducive to the management of the user's application and related resources.

[0087] At the same time, the solution of the embodiment of the present application is conducive to the smooth migration of applications on other platforms to the cloud management platform provided by the embodiment of the present application, realizing multi-cloud deployment, and helping to avoid the introduction of intrusive modifications to the code of the user's application due to switching platforms. It can also reduce the risk of users being locked into a certain platform or a certain runtime. For example, if the A platform provided by the embodiment of the present application supports WASM runtime W1, WASM runtime W2 and WASM runtime W3, platform B supports WASM runtime W2, and platform C supports WASM runtime W3, then the applications of users of platform B and platform C can achieve smooth migration when migrating to platform A, and can achieve matching in terms of underlying capabilities, avoiding the introduction of modifications to the application code.

[0088] In step 310, a user's call request is received. This call request is used to indicate the application to be executed. This call request can also be called an execution request. For example, when the call request arrives, the cloud management platform can execute steps 320 to 350 to run the user's application, i.e., the WASM application.

[0089] In step 320, obtaining the WASM module of the application may include loading the WASM module.

[0090] The WASM module of an application can be obtained in a variety of ways.

[0091] For example, the WASM module of the application can be provided by the user. For example, the user can provide a compiled WASM module to the cloud management platform.

[0092] Alternatively, the WASM module of an application can be compiled from the application's source code. For example, the user can provide the application's source code to the cloud management platform, which then compiles the application's source code to generate the corresponding WASM module.

[0093] The WASM module of the application can also be obtained through other methods, which is not limited in this embodiment of the present application.

[0094] Furthermore, method 300 may further include: determining whether the WASM module of the application complies with the standard. If not, rejecting the call request, i.e., not executing steps 330 to 350. If compliant, executing steps 330 to 350.

[0095] For example, the standard may be a WASM de facto standard recognized by the community.

[0096] In step 330, a WASM runtime for creating a sandbox to execute the WASM module of the application, i.e., a target WASM runtime, may be determined. The target WASM runtime supports the WASM module, i.e., the target WASM runtime is a WASM runtime that matches the WASM module. A WASM runtime that matches the WASM module of the application means that the WASM runtime can be used to execute the WASM module, or in other words, the WASM runtime is used to create a sandbox so that the WASM module can be scheduled for execution in the sandbox.

[0097] An application can have one or more WASM modules.

[0098] For example, in some business scenarios, an application cannot be built using a single WASM runtime. In this case, the application may correspond to multiple WASM runtimes.

[0099] For example, application #A needs to access a database (DB) and key-value (KV) storage, that is, it needs to support WASI for accessing the DB and WASI for accessing the KV storage. If the WASI that supports accessing the DB and the WASI that supports accessing the KV storage are supported by two different WASM runtimes, then application #A needs to be built by at least these two different WASM runtimes. In this case, application #A can be compiled multiple times to obtain two WASM modules, and the two WASM modules correspond to the two WASM runtimes respectively.

[0100] For ease of description, the embodiments of the present application are described only with a WASM module of an application as an example, and do not limit the solutions of the embodiments of the present application. The WASM runtime that matches the WASM module of the application can be determined in a variety of ways. The following mainly uses two methods (method #1 and method #2) as examples to illustrate the method of determining the target WASM runtime. Optionally, the WASI supported by the target WASM runtime may include WASI in the WASM module.

[0101] Method #1:

[0102] In one possible implementation, the target WASM runtime can be determined by the user, or in other words, informed by the user to the platform.

[0103] Optionally, method 300 may further include: receiving input indication information #1, where indication information #1 is used to indicate a target WASM runtime. In this case, step 330 may include determining the target WASM runtime from multiple WASM runtimes based on indication information #1.

[0104] Exemplarily, method 300 may further include: displaying multiple candidate configuration items on a front-end user interface, the multiple candidate configuration items being used to indicate the multiple WASM runtimes; and receiving a user's selection result for the multiple candidate configuration items. The user's selection result for the multiple candidate configuration items, i.e., the candidate configuration item selected by the user, may serve as indication information #1.

[0105] Candidate configuration items can be provided in various forms. For example, a candidate configuration item can be a setting item of an application. The user can inform the platform of the WASM runtime required by the application by configuring the settings for the application. For another example, the candidate configuration item can include a tag item of the application. The user can inform the platform of the WASM runtime required by the application by tagging it. The above is only an example, and the embodiments of this application do not limit the specific form of the candidate configuration items.

[0106] There is a mapping relationship between the multiple candidate configuration items and the multiple WASM runtimes. The WASM runtime can be determined based on the candidate configuration item selected by the user and the mapping relationship. For example, the candidate configuration item selected by the user is configuration item #1. In this mapping relationship, configuration item #1 corresponds to the target WASM runtime. In this case, the cloud management platform can determine the target WASM runtime from the multiple WASM runtimes based on the candidate configuration item selected by the user and the mapping relationship.

[0107] It should be understood that the above is only an example, and the embodiments of this application do not limit the specific implementation of indication information #1. For example, indication information #1 can also be the name of the target WASM runtime entered by the user.

[0108] Instruction information #1 is only used to limit the WASM runtime indicated by the instruction information to the target WASM runtime and has no other limiting effect.

[0109] Optionally, method 300 may further include: receiving input indication information #2, where indication information #2 is used to indicate a target WASM runtime, and the target WASM runtime does not belong to the multiple WASM runtimes; and outputting prompt information #1, where prompt information #1 is used to prompt that the application cannot run.

[0110] In other words, if the user informs the platform that the WASM runtime is not one of the WASM runtimes supported by the platform, the platform can output a prompt error message to prompt the user.

[0111] For example, the content of prompt information #1 may include: the application cannot be run, the call request is rejected, or the target WASM runtime is not a WASM runtime supported by the platform, etc. The embodiment of the present application does not limit the specific content of the prompt information.

[0112] In this case, the platform may not perform steps 330 to 350 .

[0113] Instruction #2 is only used to limit the WASM runtime indicated by the instruction information to not belong to the multiple WASM runtimes supported by the platform, and has no other limiting effect.

[0114] Method #2:

[0115] In one possible implementation, the target WASM runtime may be determined by the platform.

[0116] Optionally, step 330 may include the following steps.

[0117] 331. Obtain a mapping relationship between multiple WASM runtimes and WASIs supported by the multiple WASM runtimes.

[0118] The mapping relationship can be expressed in various forms.

[0119] Exemplarily, the mapping relationship can be represented by a mapping list. For example, the mapping relationship between the multiple WASM runtimes and the WASI supported by the multiple WASM runtimes can be represented as a mapping list of the sets of the multiple WASM runtimes and the WASI supported by the multiple WASM runtimes. The mapping list can be called a WASI-specification support list. Exemplarily, the support list can be obtained by sorting out information from different WASM runtime communities and WASI / WASM standards.

[0120] The mapping relationship can be obtained in multiple ways.

[0121] Exemplarily, the mapping relationship may be pre-set. In this case, step 331 may include: reading the mapping relationship between multiple preset WASM runtimes and the WASIs supported by the multiple WASM runtimes. For example, reading a preset mapping list and storing the mapping list in a data structure.

[0122] 332, extract WASI used in the WASM module.

[0123] WASI used in a WASM module can also be called WASI in a WASM module, or WASI contained in a WASM module.

[0124] In step 332 , a set of WASI used in the WASM module is extracted.

[0125] 333. Determine one or more candidate WASM runtimes from the multiple WASM runtimes based on a mapping relationship between the multiple WASM runtimes and the WASIs supported by the multiple WASM runtimes, where the WASIs supported by the one or more candidate WASM runtimes include the WASI used in the WASM module. The one or more candidate WASM runtimes include the target WASM runtime.

[0126] Optionally, step 332 may include step 332a and step 332b.

[0127] 332a, decompile the WASM module into a WAT ​​file.

[0128] 332b, extract WASI used in WASM module from WAT file.

[0129] The WASI used in the WAT file is the WASI used in the WASM module. Step 332b can also be understood as extracting the WASI used in the WAT file.

[0130] In step 332b, the set of WASI used in the WAT file is extracted.

[0131] A WASM module is a binary bytecode module file executed by the WASM virtual machine and is difficult to parse. In step 332a, it can be decompiled into an easily extractable and parseable WASM text format file, which helps reduce the difficulty of WASI extraction.

[0132] In step 333, the WASIs supported by the one or more candidate WASM runtimes include the WASI used in the WASM module. It can be understood that the set of WASIs used in the WASM module can be a subset of the set of WASIs supported by the one or more candidate WASM runtimes.

[0133] The set of WASIs used by the WASM module may be a subset of the set of WASIs supported by each of the multiple candidate WASM runtimes.

[0134] The WASI supported by the one or more candidate WASM runtimes includes the WASI used in the WASM module, that is, the one or more candidate WASM runtimes can support the WASI used in the WASM module, that is, the one or more candidate WASM runtimes all support the WASM module of the application and can be used to execute the application.

[0135] In other words, in step 333, a WASM runtime that matches the WASM module (i.e., the one or more candidate WASM runtimes) can be determined from the multiple WASM runtimes. The one or more candidate WASM runtimes can be part or all of all runtimes in the multiple WASM runtimes that can execute the WASM module.

[0136] Exemplarily, determining one or more candidate WASM runtimes from the multiple WASM runtimes according to a mapping relationship between multiple WASM runtimes and WASIs supported by the multiple WASM runtimes may include determining the one or more candidate WASM runtimes according to whether the WASI used in the WASM module belongs to the set of WASIs supported by the multiple WASM runtimes.

[0137] The specific implementation of step 333 can be set as needed.

[0138] Exemplarily, the following operations are performed on each WASM runtime one by one to determine whether the WASI used in the WASM module belongs to the set of WASI supported by the WASM runtime. When the number of WASM runtimes that meet the conditions reaches a preset value, the above determination operation is terminated.

[0139] For example, the preset value can be 1. In this case, if a WASM runtime that meets the conditions appears (that is, the first WASM runtime that meets the conditions in the judgment process), that is, if it is determined that the set of WASIs supported by a certain WASM runtime includes all WASIs used in the WASM module, the above judgment operation is terminated. This WASM runtime is the one or more candidate runtimes mentioned above.

[0140] For another example, the preset value can be 2. In this case, if two WASM runtimes that meet the conditions appear (i.e., the first WASM runtime that meets the conditions and the second WASM runtime that meets the conditions in the judgment process), that is, if it is determined that the set of WASIs supported by the two WASM runtimes includes all WASIs used in the WASM module, then the above judgment operation is terminated. The two WASM runtimes are the one or more candidate runtimes mentioned above.

[0141] Alternatively, the following operations are performed on each WASM runtime one by one to determine whether the WASI used in the WASM module belongs to the set of WASI supported by the WASM runtime. When all WASM runtimes are traversed, the above determination operation is terminated to obtain all WASM runtimes that meet the conditions. In this case, the one or more candidate WASM runtimes are all WASM runtimes in the multiple WASM runtimes that match the WASM module.

[0142] The above is only an example. The one or more candidate WASM runtimes may also be determined by other methods, which is not limited in this embodiment of the present application.

[0143] In the case that the one or more candidate WASM runtimes are multiple candidate WASM runtimes, step 330 may further include: determining a target WASM runtime from the multiple candidate WASM runtimes.

[0144] The specific implementation method of determining the target WASM runtime from multiple candidate WASM runtimes can be set as needed.

[0145] Exemplarily, a WASM runtime is randomly selected from the multiple WASM candidate runtimes as the target WASM runtime. Alternatively, the target WASM runtime can be determined from the multiple WASM candidate runtimes according to preset rules. For example, the WASM runtime that supports the largest number of WASIs is selected from the multiple candidate WASM runtimes as the target WASM runtime. For another example, priorities are pre-set for the multiple WASM runtimes, and the WASM runtime with the highest priority is selected from the multiple candidate WASM runtimes as the target WASM runtime based on the priorities of the multiple candidate WASM runtimes.

[0146] The above is only an example. In actual scenarios, other methods can be used to determine the target WASM runtime from multiple candidate WASM runtimes. This embodiment of the present application does not limit this.

[0147] In addition, if the one or more candidate WASM runtimes do not exist in the multiple WASM runtimes, for example, if the set of WASI used in the WASM module is not a subset of the set of WASI supported by any WASM runtime in the multiple WASM runtimes, step 333 can be skipped and prompt information #2 can be output. Prompt information #2 is used to prompt that the application cannot run. For example, the content of prompt information #2 may include that the application does not comply with the specifications of the WASM runtime, or that there is no WASM runtime that can support the application. The embodiment of the present application does not limit the specific content of prompt information #2.

[0148] In the solution of the embodiment of this application, the WASM runtime that supports the WASM module is determined based on the WASM used in the WASM module. In this way, the user only needs to provide the application source code or WASM module, and the platform automatically matches and uses the underlying WASM runtime, which helps to further improve the user experience.

[0149] In addition, the WASM module can be decompiled to obtain a WAT ​​file and the WASI used in the WAT file can be extracted. The WAT file can be parsed, and it is relatively easy to extract information from the WAT file, which helps to reduce the difficulty of extracting WASI from the WASM module.

[0150] Furthermore, method #1 and method #2 can also be used in combination.

[0151] For example, if the input instruction information #2 is received and the instruction information #2 indicates WASM runtime #1, WASM runtime #1 does not belong to the multiple WASM runtimes. In this case, method #2 can be used to determine the target WASM runtime.

[0152] In other words, if the platform does not support the WASM runtime indicated by the user, the target WASM runtime can be determined by the platform.

[0153] For another example, if instruction #3 is received as input and indicates WASM runtime #2, the set of WASIs used in the WASM module is not a subset of the set of WASIs supported by WASM runtime #2. In this case, method #2 can be used to determine the target WASM runtime.

[0154] In other words, if the WASM runtime specified by the user cannot support WASI used by the WASM module, the platform can determine the target WASM runtime.

[0155] For another example, if method #2 is used to determine multiple candidate WASM runtimes, the multiple candidate WASM runtimes can be displayed to the user, and the user can determine the target WASM runtime.

[0156] It should be understood that method #1 and method #2 can also be combined in other ways, and the present application embodiment does not limit this. For the sake of ease of description, the following mainly uses method #2 as an example for explanation.

[0157] In step 340, a WASM sandbox is created using the target WASM runtime to provide a runtime environment for the user's code and run the user's application, i.e., the WASM application, or in other words, the WASM module.

[0158] After determining the target WASM runtime, method 300 may further include step 350 .

[0159] 350. Load the target WASI according to the target WASM runtime. The target WASI is used to communicate with the external environment of the sandbox during the execution of the WASM module. The target WASI is determined based on the WASI supported by the target WASM runtime.

[0160] For example, after determining the target WASM runtime, all WASIs supported by the target WASM runtime can be loaded. That is, the target WASI can include all WASIs supported by the target WASM runtime.

[0161] Alternatively, after the target WASM runtime is determined, a target WASI may be loaded, where the target WASI is obtained by performing at least one of adding, deleting, or modifying WASI supported by the target WASM runtime.

[0162] In other words, after determining the target WASM runtime, WASI can be loaded dynamically, that is, WASI extensions can be integrated as needed, rather than loading all WASIs of the target WASM runtime each time. For example, during the WASI loading process, operations such as adding, deleting, and / or modifying elements in the set of WASIs to be loaded (for example, the set of WASIs to be loaded may include the set of WASIs supported by the target WASM runtime) can be performed to obtain the set of target WASIs.

[0163] In the solution of the embodiment of the present application, WASI can be loaded dynamically, so that the loaded WASI can be adjusted as needed, which is conducive to meeting the personalized needs of users and thus helps to improve user experience.

[0164] For example, by dynamically loading WASI, WASI can be added to achieve WASI extensions. For example, when loading WASI, WASI extensions beyond the community WASI / WASM public standards can be added, such as deep learning, large model reasoning, or backend blockchain as a service (BaaS) resource access.

[0165] For example, by dynamically loading WASI, WASI can be deleted, which helps improve security. The WASM sandbox is a secure operating environment isolated from the outside world, and WASI provides the ability to communicate within and outside the sandbox and access external resources. While bringing more functional expansion, it also introduces security risks. In the embodiment of this application, some WASI involving internal and external communication with disks, networks, etc. can be deleted, thereby protecting the applications in the sandbox and achieving more secure isolation.

[0166] For example, WASI can be modified by dynamically loading it. Serverless and FaaS services need to provide more comprehensive observability capabilities, for example, collecting user logs. However, there are differences in the implementation of logs, which leads to obstacles in log collection. In an embodiment of the present application, the platform can provide standard WASI definitions and signatures. In this way, users can implement customized logging methods according to this standard when writing and testing applications, and complete the replacement of logging capabilities before running the application on the platform side, thereby smoothly connecting to the platform-side observability capabilities.

[0167] Figure 4 shows a schematic flowchart of another method for running a WASM application. Method 400 shown in Figure 4 can be considered a specific implementation of method 300 using method #2. For related descriptions, refer to method #2. To avoid repetition, some descriptions of 400 are omitted.

[0168] As shown in FIG4 , method 400 includes the following steps.

[0169] 410, initialize WASI supported by each WASM runtime.

[0170] For example, the WASI support list for each WASM run is initialized, that is, the preset WASI mapping list supported by each WASM runtime is read and stored in a data structure.

[0171] Step 410 corresponds to step 331 in method 300 , and for a detailed description, please refer to step 331 .

[0172] 420, load the WASM module of the application.

[0173] Step 420 corresponds to step 310 in method 300 , and for a detailed description, reference may be made to step 310 .

[0174] 430, decompile the WASM module into a WAT ​​file.

[0175] Step 430 corresponds to step 332a in method 300, and for a detailed description, please refer to step 332a.

[0176] 440, extract WASI used in WAT files.

[0177] Step 440 corresponds to step 332b in method 300. For a detailed description, please refer to step 332b.

[0178] The set of WASI used in WAT files can be represented as WASM 2 set .

[0179] 450, utilizes WASI used in WAT files to perform loop detection on each WASM runtime.

[0180] 460. Determine whether the WASI set used in the WAT file is a subset of the current WASM runtime.

[0181] That is, judgment Is it true? WASM 1 set[runtime] indicates the set of WASIs supported by the currently detected WASM runtime.

[0182] If yes, execute step 470 , if no, execute step 450 .

[0183] 470 , the WASM runtime is determined as the WASM runtime required to run the WASM module (i.e., the target WASM runtime).

[0184] Steps 450 to 470 correspond to step 333 in method 300 , and for detailed description, please refer to step 333 .

[0185] 480, load WASI according to the WASM runtime.

[0186] Step 480 corresponds to step 350 in method 300 , and for a detailed description, reference may be made to step 350 .

[0187] 490, execute the user's application using the WASM runtime.

[0188] It should be understood that the above is only an example and does not constitute any limitation to the embodiments of the present application.

[0189] FIG5 shows a schematic diagram of a system architecture for running WASM applications.

[0190] Taking method #2 in the previous article as an example, when a call request occurs, the platform can analyze the matching WASM runtime based on the application file provided by the user and load WASI based on the matching WASM runtime. The matching WASM runtime is used to create a WASM sandbox to provide an operating environment for the user's code.

[0191] As previously mentioned, the user-provided application file can be a WASM module for the application, which can be packaged with the application's engine and source code. Alternatively, it can be understood that the WASM module includes the application's engine and the user application, as shown in Figure 5.

[0192] As shown in Figure 5, the platform supports three WASM runtimes, namely WASM runtime #A, WASM runtime #B, and WASM runtime #C. The WASIs supported by the three WASM runtimes #A are represented as WASI WASM runtime#A WASI WASM runtime#B and WASI WASM runtime#C When a call request occurs, the plugin core in FIG5 can analyze a matching WASM runtime. For example, the plugin core can execute steps 410 to 470 in method 400.

[0193] The platform can load WASI based on the matching WASM runtime. For example, the plugin core analyzes that the matching WASM runtime is WASM runtime#A. The platform supports WASI based on the target WASM runtime, that is, WASI WASM runtime#A , load WASI. Then use the WASM runtime #A to create a sandbox and run the application.

[0194] Figure 6 shows a schematic diagram of another system architecture for running WASM applications. The architecture shown in Figure 6 can be considered a specific implementation of the architecture shown in Figure 5. System 600 shown in Figure 6 can be deployed on a cloud management platform. System 600 can be used to execute method 300 and / or method 400.

[0195] As shown in FIG6 , the system 600 may include an engine actor 610 , a plugin core 620 , a WASM engine plugin, and a WASM runtime.

[0196] The engine actor 610 is used to initialize and execute applications. Specifically, the WASM runtime needs to be driven to execute applications. The engine actor 610 can drive applications and schedule them to be executed in the sandbox of the WASM runtime.

[0197] As shown in Figure 6, the engine actor 610 communicates with the underlying WASM runtime through the plugin core 620 component. The engine actor 610 utilizes the WASM engine plugin API (such as the WASM runtime client API) through the plugin core 620 to schedule and dispatch applications for execution within the sandbox.

[0198] The engine actor 610 can be used to determine whether the application's WASM module complies with the standard. This standard refers to the de facto WASM standard recognized by the community. WASM modules that comply with the standard can be scheduled for execution.

[0199] The engine actor 610 may include a WASM parsing engine layer and / or a WASM module drop-in layer. For example, a user may provide application source code, which is compiled by the WASM parsing engine layer and then executed by the underlying plugin core 620. Alternatively, a user may provide an application WASM module, which is scheduled and delivered to the WASM module drop-in layer via the WASM module drop-in method, and then executed by the underlying plugin core 620.

[0200] The WASI-specification support list maintains a mapping of the WASI lists supported by different WASM runtimes. It can be used to identify the available runtimes for WASM modules (i.e., one or more candidate WASM runtimes mentioned above) and the scope of WASI that can be integrated.

[0201] The plugin core 620 is used to determine the target WASM runtime of the WASM module, that is, to determine the WASM runtime required by the WASM module.

[0202] The plugin core 620 may determine the target WASM runtime of the WASM module according to the WASI-specification support list.

[0203] The plugin core 620 may also integrate standard WASI and specific WASI when running an application using the WASM runtime according to the WASI-specification support list to access external resources (such as external devices or external systems).

[0204] Standard WASI can be understood as WASI based on community specifications and standards, and generally includes standard interfaces supported by mainstream runtimes.

[0205] The specific WASI may be understood as an extended WASI. For example, the specific WASI may be an extended WASI with additional support customized based on the standard.

[0206] The plugin core 620 can define lifecycle management standards to implement lifecycle management of sandbox instances and communication within and outside the sandbox. For example, the plugin core 620 can be used for instance initialization, request invocation, and instance destruction. Another example is loading WASI to enable the sandbox to access external resources.

[0207] The WASM engine plugin provides the system with the ability to connect to the underlying WASM runtime.

[0208] The platform includes multiple WASM engine plugins and multiple WASM runtimes.

[0209] There is a one-to-one correspondence between the multiple WASM engine plugins and the multiple WASM runtimes.

[0210] For example, as shown in FIG6 , the platform includes three WASM engine plugins, namely, WASM engine plugin 631 , WASM engine plugin 632 , and WASM engine plugin 633 . The three WASM engine plugins correspond to three WASM runtimes, namely, WASM runtime 641 , WASM runtime 642 , and WASM runtime 643 in FIG6 .

[0211] For example, the three WASM runtimes may be WASM Time, WASMEdge, and WASMer, respectively. Alternatively, the WASM runtime may be another runtime, which is not limited in the embodiments of the present application.

[0212] It should be understood that the number of WASM engine plugins and WASM runtimes in Figure 6 is only an example and does not limit the solution of the embodiments of the present application.

[0213] Each WASM engine plugin can be implemented according to the software development kit (SDK) of each WASM runtime.

[0214] The essence of a WASM engine plugin is that it integrates the corresponding WASM runtime SDK and implements the same standard interfaces for lifecycle management, function execution, and metering. By integrating the SDK's specific implementation, the platform knows how to communicate with the WASM runtime and execute instructions in the corresponding standard interfaces. This allows the platform to achieve the same capabilities through the WASM runtime SDK, regardless of the underlying WASM runtime, including instance initialization, request invocation, instance recycling, and instance execution time and memory usage metering.

[0215] WASI integration occurs during instance initialization. WASIs can be added, deleted, and / or modified during the WASI integration process. If a function instance does not contain a WASI after initialization, that WASI cannot be used in subsequent function calls.

[0216] The WASM engine plugin corresponding to each WASM runtime works together with the plugin core to process the WASM runtime and WASI implementation.

[0217] When a user's execution request arrives, the engine actor 610 determines whether the WASM module of the application indicated by the execution request meets the standards. If not, the execution request is rejected. If the WASM module meets the standards, the plugin core 620 decompiles the WASM module to obtain a WAT ​​file. The plugin core 620 analyzes the WAT file to determine the WASM runtime that matches the WASM module. The plugin core 620 can integrate WASI with the corresponding WASM engine plugin 630 according to the WASI-specification Support List and communicate with the WASM runtime to complete the creation of the sandbox and provide a running environment for the user's application. The user's execution request can then be executed in the sandbox.

[0218] It should be understood that the architectures shown in Figures 5 and 6 are merely examples and do not limit the solutions of the embodiments of this application. For example, in other implementations, other modules or devices may be used to analyze the matching WASM runtime. For another example, communication between the plugin core and the underlying WASM runtimes may also be achieved through the command line.

[0219] The apparatus of the embodiment of the present application is described below with reference to Figures 7 to 10. It should be understood that the apparatus described below can execute the method of the aforementioned embodiment of the present application. To avoid unnecessary repetition, repeated descriptions are appropriately omitted when introducing the apparatus of the embodiment of the present application.

[0220] Figure 7 is a schematic block diagram of a system for running a WASM application according to an embodiment of the present application. The system 2000 shown in Figure 7 can be used to execute the method shown in Figure 3 and / or Figure 4.

[0221] As shown in FIG7 , the system 2000 may include:

[0222] Receiving module 2010, for receiving an execution request of an application program;

[0223] Acquisition module 2020, used to obtain the WASM module of the application;

[0224] The processing module 2030 is used to determine a target WASM runtime from multiple WASM runtimes, where the target WASM runtime supports the WASM module.

[0225] Creation module 2040, for creating a sandbox using the target WASM runtime;

[0226] The running module 2050 is used to run the WASM module in the sandbox.

[0227] Optionally, the processing module 2030 is specifically configured to:

[0228] Get the mapping relationship between multiple WASM runtimes and the WASM system interface WASI supported by multiple WASM runtimes;

[0229] Extract WASI from WASM module;

[0230] One or more candidate WASM runtimes are determined from the multiple WASM runtimes according to the mapping relationship. WASI supported by the one or more candidate WASM runtimes includes WASI in the WASM module. The one or more candidate WASM runtimes include the target WASM runtime.

[0231] Optionally, the processing module 2030 is specifically configured to:

[0232] Decompile the WASM module into a WASM text format WAT file;

[0233] Extract WASI from WASM module from WAT file.

[0234] Optionally, the processing module 2030 is specifically configured to:

[0235] Controls the display of multiple candidate configuration items, which are used to indicate multiple WASM runtimes;

[0236] receiving a selection result of multiple candidate configuration items;

[0237] The target WASM runtime is determined based on the selection result.

[0238] Optionally, the system 2000 further includes a loading module (not shown in the figure) for loading a target WASI. The target WASI is used to communicate with the external environment of the sandbox during the operation of the WASM module. The target WASI is determined based on the WASI supported by the target WASM runtime.

[0239] Optionally, the target WASI is obtained by performing at least one operation of adding, deleting, or modifying WASI supported by the target WASM runtime.

[0240] For detailed description, please refer to method 300 and method 400 in the previous text, which will not be repeated here.

[0241] Each module in system 2000 can be implemented by software or hardware. For example, the implementation of processing module 2030 will be described below using processing module 2030 as an example. Similarly, the implementation of other modules can refer to the implementation of processing module 2030.

[0242] As an example of a software functional unit, the processing module 2030 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the processing module 2030 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0243] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0244] As an example of a hardware functional unit, processing module 2030 may include at least one computing device, such as a server. Alternatively, processing module 2030 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0245] The multiple computing devices included in processing module 2030 can be distributed in the same region or in different regions. The multiple computing devices included in processing module 2030 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in processing module 2030 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0246] It should be noted that, in other embodiments, the processing module 2030 can be used to execute any step in the method of running a WASM application, and other modules can be used to implement any step in the method of running a WASM application. The steps that each module is responsible for implementing can be specified as needed, and all functions of the system 2000 are realized by each module implementing different steps in the method of running a WASM application.

[0247] This application also provides a computing device 1000. As shown in FIG8 , computing device 1000 includes a bus 1002, a processor 1004, a memory 1006, and a communication interface 1008. Processor 1004, memory 1006, and communication interface 1008 communicate with each other via bus 1002. Computing device 1000 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 1000.

[0248] Bus 1002 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG8 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 1002 may include a path for transmitting information between various components of computing device 1000 (e.g., memory 1006, processor 1004, and communication interface 1008).

[0249] The processor 1004 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0250] The memory 1006 may include volatile memory, such as random access memory (RAM). The processor 1004 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0251] The memory 1006 stores executable program code, and the processor 1004 executes the executable program code to implement the functions of each of the aforementioned modules, thereby implementing the method for running a WASM application. In other words, the memory 1006 stores instructions for executing the method for running a WASM application.

[0252] The communication interface 1008 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1000 and other devices or a communication network.

[0253] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0254] As shown in Figure 9, the computing device cluster includes at least one computing device 1000. The memory 1006 in one or more computing devices 1000 in the computing device cluster may store the same instructions for executing the method for running a WASM application.

[0255] In some possible implementations, the memory 1006 of one or more computing devices 1000 in the computing device cluster may also store partial instructions for executing the method for running a WASM application. In other words, the combination of one or more computing devices 1000 can jointly execute the instructions for executing the method for running a WASM application.

[0256] It should be noted that the memory 1006 in different computing devices 1000 in the computing device cluster can store different instructions, each used to execute part of the functions of the system running the WASM application. In other words, the instructions stored in the memory 1006 in different computing devices 1000 can implement the functions of one or more modules in the system 2000.

[0257] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network, which may be a wide area network or a local area network.

[0258] Figure 10 illustrates a possible implementation. As shown in Figure 10 , two computing devices 1000A and 1000B are connected via a network. Specifically, the connection to the network is achieved via a communication interface within each computing device. In this possible implementation, the memory 1006 within computing device 1000A stores instructions for executing the functions of a receiving module 2010 and an acquiring module 2020. Simultaneously, the memory 1006 within computing device 1000B stores instructions for executing the functions of a processing module 2030, a creation module 2040, and an execution module 2050.

[0259] The connection method between the computing device clusters shown in Figure 10 can be that considering that the method for running WASM applications provided by this application may require data storage, it is considered to entrust the functions implemented by the processing module 2030, the creation module 2040 and the running module 2050 to the computing device 1000B for execution.

[0260] It should be understood that the functions of the computing device 1000A shown in FIG10 may also be completed by multiple computing devices 1000. Similarly, the functions of the computing device 1000B may also be completed by multiple computing devices 1000.

[0261] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute a method for running a WASM application.

[0262] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a method for running a WASM application.

[0263] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0264] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0265] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0266] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0267] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0268] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the processing method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0269] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for running a WASM application, characterized in that: The method is applied to a cloud management platform, the cloud management platform is used to manage infrastructure, the infrastructure includes at least one cloud data center, each of the at least one cloud data center is provided with multiple servers, the cloud management platform supports multiple WASM runtimes, and the method includes: receiving an execution request of an application; Get the WASM module of the application; Determine a target WASM runtime from the multiple WASM runtimes, the target WASM runtime supporting the WASM module; Create a sandbox using the target WASM runtime; Running the WASM module in the sandbox.

2. The method according to claim 1, characterized in that The determining a target WASM runtime from the multiple WASM runtimes includes: Obtain a mapping relationship between the multiple WASM runtimes and the WASM system interfaces WASI supported by the multiple WASM runtimes; Extract WASI from the WASM module; One or more candidate WASM runtimes are determined from the multiple WASM runtimes according to the mapping relationship, WASI supported by the one or more candidate WASM runtimes includes WASI in the WASM module, and the one or more candidate WASM runtimes include the target WASM runtime.

3. The method according to claim 2, characterized in that The extracting WASI in the WASM module includes: Decompile the WASM module into a WASM text format WAT file; Extract WASI in the WASM module from the WAT file.

4. The method according to claim 1, characterized in that The determining a target WASM runtime from the multiple WASM runtimes includes: Controlling display of multiple candidate configuration items, where the multiple candidate configuration items are used to indicate the multiple WASM runtimes; receiving a selection result of the plurality of candidate configuration items; The target WASM runtime is determined according to the selection result.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: A target WASI is loaded, where the target WASI is used to communicate with an external environment of the sandbox during the running of the WASM module, and the target WASI is determined according to the WASI supported by the target WASM runtime.

6. The method according to claim 5, characterized in that The target WASI is obtained by performing at least one operation of adding, deleting or modifying the WASI supported by the target WASM runtime.

7. A system for running WASM applications, characterized in that: The system is applied to a cloud management platform, which is used to manage infrastructure, wherein the infrastructure includes at least one cloud data center, each of the at least one cloud data center is provided with multiple servers, and the cloud management platform supports multiple WASM runtimes, including: A receiving module, used for receiving an execution request of an application program; An acquisition module is used to acquire a WASM module of the application; A processing module, configured to determine a target WASM runtime from the multiple WASM runtimes, wherein the target WASM runtime supports the WASM module; Create a module for creating a sandbox using the target WASM runtime; A running module is used to run the WASM module in the sandbox.

8. The system according to claim 7, characterized in that The processing module is specifically used for: Obtain a mapping relationship between the multiple WASM runtimes and the WASM system interfaces WASI supported by the multiple WASM runtimes; Extract WASI from the WASM module; One or more candidate WASM runtimes are determined from the multiple WASM runtimes according to the mapping relationship, wherein the WASI supported by the one or more candidate WASM runtimes includes the WASI in the WASM module, and the one or more candidate WASM runtimes When including the target WASM runtime.

9. The system according to claim 8, characterized in that The processing module is specifically used for: Decompile the WASM module into a WASM text format WAT file; Extract WASI in the WASM module from the WAT file.

10. The system according to claim 7, characterized in that The processing module is specifically used for: Controlling display of multiple candidate configuration items, where the multiple candidate configuration items are used to indicate the multiple WASM runtimes; receiving a selection result of the plurality of candidate configuration items; The target WASM runtime is determined according to the selection result.

11. The system according to any one of claims 7 to 10, characterized in that The system further comprises: A loading module is used to load a target WASI, where the target WASI is used to communicate with the external environment of the sandbox during the running of the WASM module, and the target WASI is determined according to the WASI supported by the target WASM runtime.

12. The system according to claim 11, characterized in that The target WASI is obtained by performing at least one operation of adding, deleting or modifying the WASI supported by the target WASM runtime.

13. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, and when the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 6.

15. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster is caused to perform the method according to any one of claims 1 to 6.

Images