Method and system for running WASM application

Abstract

The invention provides a method and system for running a WASM application, the method is applied to a cloud management platform, the cloud management platform is used for managing infrastructures, the infrastructures comprise at least one cloud data center, each cloud data center of the at least one cloud data center is provided with a plurality of servers, and when the cloud management platform supports running of a plurality of WASMs, the servers are connected with the servers. The method comprises the steps of receiving an execution request of an application program; obtaining a WASM module of the application program; determining a target WASM operation time from the plurality of WASM operation time, wherein the target WASM operation time supports a WASM module; creating a sandbox when the target WASM runs; and running the WASM module in the sandbox. The scheme provided by the embodiment of the invention is beneficial to improving the development experience of the user.

Description

[0001] This application claims the priority of a Chinese patent application with the application number 202311675427.7, titled "Method and System for Executing WASM Applications", which was filed with the China National Intellectual Property Administration on December 7, 2023. The entire content of this Chinese patent application is incorporated herein by reference. Technical Field

[0002] This 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. With the characteristics of lightweight, high security, and fast cold start, WASM has gradually expanded from the browser domain to the cloud computing domain and the edge computing domain. The source code of an application can be compiled into a WASM module, and then executed through a WASM runtime in an embedded environment. Among them, in other environments outside the browser, the WASM module needs to be executed by a WASM runtime that supports the WebAssembly system interface (WASI).

[0004] As an emerging technology, WASM is in a rapid development stage, and the standards of WASM and WASI are still evolving. There are multiple runtimes in the community. The support for WASI and the implementation methods of different WASM runtimes are different. For example, WASMEdge currently supports WASI related to databases and sockets, and can provide the network capabilities to access database backend resources and send hypertext transfer protocol (HTTP) requests, while other WASM runtimes do not provide such capabilities yet. This difference will affect the user experience. For example, when developing a program, users need to adjust the implementation method of the application according to the capabilities provided by different WASM runtimes and the relevant operating platforms, and it is difficult to focus on the implementation of the business logic, thus affecting the user's development experience. Moreover, after selecting a certain WASM runtime and deploying the application to a platform that supports this WASM, if the application needs to be adjusted or optimized later, it is necessary to reconsider the capabilities provided by different WASM runtimes and the relevant operating platforms, which seriously affects the user's development efficiency and further affects the user's development experience. Summary of the Invention

[0005] This application provides a method and system for running WASM applications, which is beneficial to improving the user's development experience.

[0006] First aspect, a method for running a WASM application is provided. The method is applied to a cloud management platform for managing infrastructure, where 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 the 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.

[0007] 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 of an application, a sandbox can be created through the WASM runtime (i.e., the target WASM runtime) that supports the WASM module of the application, so as to execute the application. This can shield the differences of the underlying WASM runtimes from the user, enabling the user not to pay attention to the type of the underlying WASM runtime during the development of the application and focus on the business logic, thus being beneficial to improving the user experience.

[0008] Exemplarily, 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.

[0009] Alternatively, the WASM module of the application can be obtained by compiling the source code of the application. For example, the user can provide the source code of the application to the cloud management platform, and the cloud management platform compiles the source code of the application to obtain the corresponding WASM module.

[0010] The target WASM runtime supports the WASM module, that is, the running of the WASM module can be achieved through the target WASM runtime.

[0011] Combined with the first aspect, in some implementation manners of the first aspect, the WASI supported by the target WASM runtime includes the WASI in the WASM module.

[0012] This can achieve the support of the target WASM runtime for the WASM module.

[0013] In combination with the first aspect, in some implementations of the first aspect, determining a target WASM runtime from multiple WASM runtimes includes: obtaining the mapping relationship between multiple WASM runtimes and the WebAssembly System Interface (WASI) supported by the multiple WASM runtimes; extracting the WASI in the WASM module; and determining one or more candidate WASM runtimes from the multiple WASM runtimes according to the mapping relationship. 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.

[0014] In the solution of the embodiment of the present application, the WASI used in the WASM module is extracted, and based on this, the WASM runtime that supports the WASM module is determined. In this way, the user only needs to provide the source code of the application or the WASM module, and the platform automatically completes the matching and use of the underlying WASM runtime, which is beneficial to further improving the user experience.

[0015] In combination with the first aspect, in some implementations of the first aspect, extracting the WASI in the WASM module includes: decompiling the WASM module into a WebAssembly Text Format (WAT) file; and extracting the WASI in the WASM module from the WAT file.

[0016] In the solution of the embodiment of the present application, the WAT file can be obtained by decompiling the WASM module, and the WASI used by the WAT file is extracted. The WAT file is parsable, and it is relatively easy to extract information from the WAT file, which is beneficial to reducing the difficulty of extracting the WASI in the WASM module.

[0017] In combination with the first aspect, in some implementations of the first aspect, determining a target WASM runtime from multiple WASM runtimes includes: controlling the display of multiple candidate configuration items for indicating the multiple WASM runtimes; receiving the selection result of the multiple candidate configuration items; and determining the target WASM runtime according to the selection result.

[0018] In combination with the first aspect, in some implementations of the first aspect, the method further includes: loading the target WASI for communicating with the external environment of the sandbox during the running of the WASM module. The target WASI is determined according to the WASI supported by the target WASM runtime.

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

[0020] In combination with the first aspect, in some 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.

[0021] In the solution of the embodiment of the present application, WASI can be dynamically loaded, so that the loaded WASI can be adjusted according to needs, which is beneficial to meeting the personalized needs of users and thus beneficial to improving the user experience.

[0022] In a second aspect, a system for running a WASM application is provided. The system 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, including: a receiving module for receiving an execution request of an application; an obtaining module for obtaining the WASM module of the application; a processing module for determining a target WASM runtime from the multiple WASM runtimes, where the target WASM runtime supports the WASM module; a creating module for creating a sandbox using the target WASM runtime; and a running module for running the WASM module in the sandbox.

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

[0024] In combination with the second aspect, in some implementations of the second aspect, the processing module is specifically configured to: obtain the mapping relationship between the multiple WASM runtimes and the WASM system interface WASI supported by the multiple WASM runtimes; extract the WASI in the WASM module; and determine one or more candidate WASM runtimes from the multiple WASM runtimes according to the mapping relationship. 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.

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

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

[0027] In combination with the second aspect, in certain implementations of the second aspect, the system further includes: a loading module, configured to load the 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.

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

[0029] It should be understood that the extensions, limitations, explanations, and descriptions of the relevant content in the above first aspect also apply to the same content in the second aspect.

[0030] In a third aspect, a computing device cluster is provided, including at least one computing device, and each computing device includes 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 in the first aspect or any implementation manner of the first aspect.

[0031] In a fourth aspect, a computer-readable medium is provided, including computer program instructions, and when the computer program instructions are executed by the computing device cluster, the computing device cluster executes the method in the first aspect or any implementation manner of the first aspect.

[0032] In a fifth aspect, a computer program product including instructions is provided, and when the instructions are run by the computing device cluster, the computing device cluster is caused to execute the method in the above first aspect or any implementation manner of the first aspect. Description of the Drawings

[0033] Figure 1 are schematic diagrams of two solutions for running WASM applications;

[0034] Figure 2 is a schematic diagram of an application scenario of an embodiment of the present application;

[0035] Figure 3 is a schematic flowchart of a method for running a WASM application according to an embodiment of the present application;

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

[0037] Figure 5 It is a schematic diagram of a system architecture for running a WASM application according to an embodiment of the present application;

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

[0039] Figure 7 It is a schematic block diagram of a system for running a WASM application according to an embodiment of the present application;

[0040] Figure 8 It is a schematic block diagram of a computing device according to an embodiment of the present application;

[0041] Figure 9 It is a schematic block diagram of a computing device cluster according to an embodiment of the present application;

[0042] Figure 10 It is a schematic block diagram of another computing device cluster according to an embodiment of the present application. Detailed implementation manners

[0043] The terms used in the following embodiments are only for the purpose of describing specific embodiments and are not intended to limit the present application. As used in the specification and appended claims of the present application, the singular forms "a", "an" and "the" are intended to include the forms such as "one or more", unless there is a clear contrary indication in the context. It should also be understood that in the following embodiments of the present application, "at least one", "at least one item", and "one or more" mean one, two or more. The "first", "second" and various numerical numbers are only for the convenience of description and do not limit the scope of the embodiments of the present application. " / ", used to describe the corresponding relationship of the corresponding objects, indicates that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist at the same time. Among them, A and B can be singular or plural. The character " / " generally means that the front and back associated objects are in an "or" relationship. The magnitudes of the sequence numbers of the following processes do not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application. For example, in the embodiments of the present application, the words such as "301", "401", "501" are only identifiers for the convenience of description and do not limit the order of execution steps.

[0044] References to "one embodiment" or "some embodiments" etc. described in this specification mean that specific features, structures, or characteristics described in connection with that embodiment are included in one or more embodiments of the present application. In this application, words such as "exemplary" or "for example" are used to represent examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary" or "for example" in this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner. The terms "include", "comprise", "have" and their variants all mean "including but not limited to", unless otherwise specifically emphasized in other ways. In the embodiments of this application, descriptions such as "when...", "in the case of...", "if", and "when" all refer to the device making corresponding processing under certain objective circumstances, which does not limit the time, and does not require the device to have a judgment action when implemented, nor does it mean that there are other limitations.

[0045] In this application, "for indicating" may include for direct indication and for indirect indication. When it is described that a certain indication information is used to indicate A, it may include that the indication information directly indicates A or indirectly indicates A, and it does not mean that A must be carried in the indication information.

[0046] To facilitate those skilled in the art to better understand the technical solutions of this application, some terms that may be involved in the embodiments of this application will be described below.

[0047] (1) WASM:

[0048] WASM is a new bytecode format with the following advantages: strong portability, supporting cross-platform deployment and operation; lightweight, small module size, fast loading and cold start speed, etc. WASM is a compilation target of a high-level language. Currently, toolchains of various languages such as C, C++, GO, RUST, and JAVA can be used to compile code in different languages into WASM module (module), that is,.wasm file.

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

[0050] WAT files follow the standard format defined by WASM. Compared with the bytecode files of WASM module, for developers, the readability and comprehensibility of the file content in WAT files are greatly improved. The mutual conversion between WAT files and WASM modules can be achieved through toolchains.

[0051] (3) WASI:

[0052] WASI is a standardized system interface based on the WASM standard, providing a standardized environment to support the execution of WASM programs outside the web browser, while ensuring code portability and security. Through WASI, WASM can access resources such as the network, storage, and heterogeneous computing hardware on the host machine within a sandbox, greatly enhancing the extensibility of WASM and providing more diverse application scenarios for WASM.

[0053] (4) Runtime:

[0054] The runtime usually includes a runtime system and a runtime environment, providing an execution environment for programs. The runtime includes memory management, variable access, parameter passing mechanisms, and interfaces with the operating system, etc.

[0055] (5) Serverless computing:

[0056] Serverless computing is a model of cloud computing. Based on platform as a service (PaaS), serverless computing provides a micro-architecture where end customers do not need to deploy, configure, or manage servers. All server services required for code execution are provided by the cloud platform, including elastic scaling of backend resources, etc. Users "pay per usage". Serverless technology is considered the next-generation new paradigm of cloud computing.

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

[0058] FaaS, also known as "function as a service", is a representative service form of Serverless. FaaS allows developers to build, compute, run, and manage their application packages in the form of functions without maintaining the backend infrastructure. FaaS is an event-driven execution model running in stateless containers, and functions utilize the services of FaaS providers to manage server-side logic and state.

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

[0060] Edge Function as a Service refers to the service form of Function as a Service in the edge cloud. EFaaS allows users to write scripts and run custom code on edge nodes close to the end users to implement complex business logics. Similar to Function as a Service, developers only need to write function code snippets without concerning about maintaining the infrastructure.

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

[0062] In the business scenario of Serverless logic multi-tenancy, the use of docker and K8s is very extensive. For example, docker provides relatively isolated and independent running environments and resources for different function instances; K8s orchestrates and manages a large number of user instances. However, in extreme business scenarios, this solution has the following drawbacks: the cold start time for creating function instances for users through K8s is relatively long, resulting in an increase in the scaling time of user function instances, making it unable to cope with the business peak of users and difficult to respond to user demands in a timely manner; in scenarios with an extremely large instance scale, the K8s cluster cannot efficiently manage a large number of instances, posing huge challenges to the scheduling efficiency and system stability. At the same time, in resource-constrained extreme environments such as edge computing and wearable devices, the additional overhead brought by K8s and docker makes it difficult to implement this technical solution.

[0063] With the characteristics of lightweight, secure and fast cold start, WASM has gradually moved from the browser field to the cloud computing and edge computing fields and is regarded as 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 has stronger security in the multi-tenancy scenario. Another example is that the cold start performance of WASM enables the platform to quickly scale user instances when the user business peak arrives and respond to user requests in a timely manner.

[0064] Figure 1 Two solutions for running WASM applications are shown.

[0065] As Figure 1 shown in (a) of Figure 1 it, users can provide the JavaScript source code of the application (app) (such as the app.js file shown in Figure 1 ) and the compilation and build toolchain provided by the platform can package the source code and the JavaScript engine (such as the QuickJS engine shown in Figure 1 into the WASM binary file of the application, that is, the WASM module (such as(the app.wasm file shown). The Linker is part of this toolchain. The QuickJS engine can compile source code into bytecode. As Figure 1 shown in (a) of

[0066] As Figure 1 shown in (b) of

[0067] As Figure 1 shown, the WASM module runs in a WASM sandbox. The WASM runtime can provide the capabilities of the QuickJS engine in the form of a WASM module (such as Figure 1 QuickJS.wasm in

[0068] Currently, there are differences in the support for WASI and implementation methods among different WASM runtimes, which greatly affects the user experience. In addition, the platforms that support WASM are tightly coupled with specific WASM runtimes and focus on running specific programming languages in sandboxes, which further affects the user experience. Taking the FaaS of cloud platforms as an example, FaaS frameworks are all tightly coupled with a specific WASM runtime. For example, when users develop programs, they need to adjust the implementation methods of application programs according to the capabilities provided by different WASM runtimes and the relevant running platforms, making it difficult to focus on the implementation of business logic, thus affecting the user experience. Moreover, after selecting a certain WASM runtime and deploying the application program to a platform that supports the WASM, if the application program needs to be adjusted or optimized later, it is necessary to reconsider the capabilities provided by different WASM runtimes and the relevant running platforms, which seriously affects the development efficiency of users and further affects the user experience. For another example, in order to apply to different business scenarios or to improve the performance of application programs, users may need to use multiple WASM runtimes and deploy application programs on multiple platforms respectively. On the one hand, it affects the development efficiency of users, and on the other hand, it also increases the management difficulty of users' application programs and resources, thus affecting the user experience. For another example, when users need to switch the deployment platform of application programs, if the switched platform does not support the runtime of the current platform, it will also introduce intrusive modifications to the code of users' application programs.

[0069] In view of this, the embodiments of the present application provide a method for running WASM applications, which provides multiple heterogeneous WASM runtimes on the same platform, shields the differences in the underlying WASM runtimes for users, and enables users to focus on the development of their own business logic, which is beneficial to improving the user experience.

[0070] The solution of the embodiments of the present application can be applied to cloud platforms.

[0071] Exemplarily, the solution of the embodiments of the present application can be applied to the scenarios of Serverless or FaaS logical multi-tenant services in central cloud platforms or edge cloud platforms, where the Serverless or FaaS logical multi-tenant services are implemented through the underlying isolation solution provided by WASM.

[0072] Exemplarily, the solution of the embodiments of the present application can be applied to the microservice scenarios of central cloud platforms or edge cloud platforms, where the microservice scenarios are constructed based on the underlying isolation solution provided by WASM.

[0073] 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 beneficial to achieving a fast cold start of Serverless in the central cloud to cope with the request peak of user services. At the same time, the WASM solution also has advantages such as lightweight and low additional overhead, which is beneficial to achieving high-density deployment of function instances on the central cloud, carrying more function instance numbers with the same resources and processing more function requests. 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. Adopting a new WASM ecosystem can get rid of the heavy-resource solution of K8s+docker, so as to be able to integrate scattered edge nodes and computing resources and provide EFaaS capabilities for users in extremely resource-scarce edge scenarios.

[0074] The cloud platform can obtain the source code of the application program provided by the user or the WASM module of the application program, and schedule the WASM module to execute the application program. The cloud platform can create a sandbox through a matching WASM runtime to execute the application program. 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 underlying runtime type and computing resources during the development process of the application program, which is beneficial to improving the user experience.

[0075] Figure 2 The schematic diagram of an application scenario of the embodiment of the present application is shown. For example, as Figure 2 shown, the user can provide the WASM module of the compiled application program to the cloud platform, and the cloud platform schedules the WASM module to execute the application program. The application program (such as Figure 2 WA in) can be deployed on the central cloud, and the central cloud runs the application program. At the same time, the application program can also be deployed on the edge cloud node. In this way, the user's request can be processed at a position close to the end user, which is beneficial to reducing the latency and improving the user experience.

[0076] Figure 3 The schematic diagram of a method for running a WASM application according to an embodiment of the present application is shown. The method 300 can be applied to a cloud management platform, which is used to manage the infrastructure. The infrastructure includes at least one cloud data center, and each cloud data center is provided with multiple servers. The cloud management platform supports multiple WASM runtimes. In the embodiment of the present application, the cloud management platform can also be simply referred to as the platform.

[0077] As Figure 3 shown, the method 300 may include the following steps.

[0078] 310, receive a call request for an application program.

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

[0080] 330, determine the target WASM runtime for the WASM module from multiple WASM runtimes, where the target WASM runtime supports the WASM module.

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

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

[0083] In the solution of the embodiment of this application, the cloud management platform supports multiple WASM runtimes, that is, it supports multiple heterogeneous WASM runtimes. After receiving a call request for an application, a sandbox can be created through 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 runtimes, so that the user does not need to pay attention to the type of the underlying WASM runtime during the development of the application and can focus on the business logic, which is conducive to improving the user experience.

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

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

[0086] Meanwhile, the solution of the embodiment of the present application is conducive to realizing the smooth migration of application programs on other platforms to the cloud management platform provided by the embodiment of the present application, realizing multi-cloud deployment, and is conducive to avoiding intrusive modifications to the code of the user's application programs due to platform switching. At the same time, it can also reduce the risk of users being locked by a certain platform or a certain runtime. For example, if the A platform provided by the embodiment of the present application supports the WASM runtimes W1, W2, and W3, the B platform supports the WASM runtime W2, and the C platform supports the WASM runtime W3, then the application programs of users on the B platform and the C platform can be smoothly migrated to the A platform, and the underlying capabilities can be matched to avoid introducing modifications to the code of the application programs.

[0087] In step 310, a call request from the user is received. The call request is used to indicate the application program to be executed. The call request can also be referred to as 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 program, that is, the WASM application.

[0088] In step 320, the WASM module of the application program is obtained, which may include loading the WASM module.

[0089] The WASM module of the application program can be obtained in various ways.

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

[0091] Alternatively, the WASM module of the application program can be obtained by compiling the source code of the application program. For example, the user can provide the source code of the application program to the cloud management platform, and the cloud management platform compiles the source code of the application program to obtain the corresponding WASM module.

[0092] The WASM module of the application program can also be obtained by other means, and the embodiment of the present application does not limit this.

[0093] Further, method 300 may further include: determining whether the WASM module of the application program meets the standard. If it does not meet the standard, the call request is rejected, that is, steps 330 to 350 are no longer executed. If it meets the standard, steps 330 to 350 are executed.

[0094] Exemplarily, the standard can be the WASM de facto standard recognized by the community.

[0095] In step 330, the WASM runtime for creating a sandbox to execute the WASM module of the application, i.e., the target WASM runtime, can be determined. The target WASM runtime supports the WASM module, i.e., the target WASM runtime is the WASM runtime that matches the WASM module. The WASM runtime that matches the WASM module of the application is the WASM runtime that can be used for the execution of the WASM module, or rather, the WASM runtime that is used to create a sandbox so that the WASM module can be scheduled and executed in the sandbox.

[0096] The WASM module of the application can be one or multiple.

[0097] Exemplarily, in some business scenarios, the application cannot be built with a single WASM runtime. In this case, the number of WASM runtimes corresponding to the application may be multiple.

[0098] For example, application #A needs to access a database (DB) and a key-value (KV) store, i.e., it needs to support WASI for accessing the DB and WASI for accessing the KV store. If the WASI for accessing the DB and the WASI for accessing the KV store are supported by two different WASM runtimes respectively, then application #A needs to be built with 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 respectively correspond to the two WASM runtimes.

[0099] For ease of description, the embodiments of the present application are only described by taking one WASM module of the application as an example, which does 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 various ways. The determination methods of the target WASM runtime are mainly exemplarily described below by taking two methods (method #1 and method #2) as examples. Optionally, the WASI supported by the target WASM runtime may include the WASI in the WASM module.

[0100] Method #1:

[0101] In a possible implementation, the target WASM runtime can be determined by the user, or rather, informed to the platform by the user.

[0102] Optionally, method 300 may further include: receiving input indication information #1, where the 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 according to the indication information #1.

[0103] Exemplarily, method 300 may further include: displaying multiple candidate configuration items on a front-end user interface, where the multiple candidate configuration items are used to indicate the multiple WASM runtimes; receiving a selection result of the user for the multiple candidate configuration items. The selection result of the user for the multiple candidate configuration items, that is, the candidate configuration item selected by the user, may be used as the indication information #1.

[0104] The candidate configuration items may be provided in various forms. For example, the candidate configuration item may be a setting item of an application. The user may inform the platform of the WASM runtime required by the application by configuring the settings of the application. Again, for example, the candidate configuration item may include a tag item of the application. The user may inform the platform of the WASM runtime required by the application by tagging. The above are only examples, and the embodiments of the present application do not limit the specific manifestation forms of the candidate configuration items.

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

[0106] It should be understood that the above are only examples, and the embodiments of the present application do not limit the specific implementation manners of the indication information #1. For example, the indication information #1 may also be the name of the target WASM runtime input by the user.

[0107] The indication information #1 is only used to define that the WASM runtime indicated by the indication information is the target WASM runtime, and has no other limiting effects.

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

[0109] In other words, if the WASM runtime informed by the user does not belong to the WASM runtimes supported by the platform, the platform may output a prompt message to report an error to prompt the user.

[0110] For example, the content of prompt message #1 may include: the application cannot run, the call request is rejected, or the target WASM runtime does not belong to the WASM runtimes supported by the platform, etc. The embodiments of the present application do not limit the specific content of the prompt message.

[0111] In this case, the platform may not execute steps 330 to 350.

[0112] The indication message #2 is only used to limit that the WASM runtime indicated by the indication message does not belong to the multiple WASM runtimes supported by the platform, and has no other limiting effect.

[0113] Method #2:

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

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

[0116] 331. Obtain the mapping relationship between multiple WASM runtimes and the WASI supported by the multiple WASM runtimes.

[0117] The mapping relationship can be represented in various forms.

[0118] 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 multiple WASM runtimes and the set of WASI supported by the multiple WASM runtimes. This mapping list can be called a WASI - specification support list. Exemplarily, this support list can be sorted out through information of different WASM runtime communities and the WASI / WASM standards.

[0119] The mapping relationship can be obtained in various ways.

[0120] Exemplarily, the mapping relationship may be preset. In this case, step 331 may include: reading the preset mapping relationship between multiple WASM runtimes and the WASI supported by the multiple WASM runtimes. For example, reading the preset mapping list and storing the mapping list through a data structure.

[0121] 332. Extract the WASI used in the WASM module.

[0122] The WASI used in the WASM module can also be referred to as the WASI in the WASM module, or the WASI included in the WASM module.

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

[0124] 333. Determine one or more candidate WASM runtimes from the multiple WASM runtimes according to the 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 WASIs used in the WASM module. The one or more candidate WASM runtimes include the target WASM runtime.

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

[0126] 332a. Decompile the WASM module into a WAT file.

[0127] 332b. Extract the WASIs used in the WASM module from the WAT file.

[0128] The WASIs used in the WAT file are the same as the WASIs used in the WASM module. Step 332b can also be understood as extracting the WASIs used in the WAT file.

[0129] In step 332b, a set of WASIs used in the WAT file is extracted.

[0130] The WASM module is a binary bytecode module file for execution by the WASM virtual machine, and it is difficult to parse. In step 332a, it can be decompiled into a WASM text format file that is easy to extract and parse, which helps to reduce the difficulty of extracting WASIs.

[0131] In step 333, the WASIs supported by the one or more candidate WASM runtimes include the WASIs used in the WASM module, which can be understood as 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.

[0132] Among them, the set of WASIs used in the WASM module can be a subset of the set of WASIs supported by each candidate WASM runtime among the multiple candidate WASM runtimes.

[0133] 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, each of the one or more candidate WASM runtimes supports the WASM module of the application and can be used to execute the application.

[0134] 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 the runtimes among the multiple WASM runtimes that can execute the WASM module.

[0135] Exemplarily, determining one or more candidate WASM runtimes from the multiple WASM runtimes according to the mapping relationship between the multiple WASM runtimes and the WASI 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 WASI supported by the multiple WASM runtimes.

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

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

[0138] For example, the preset value can be 1. In this case, if a WASM runtime that meets the conditions appears (i.e., the first WASM runtime that meets the conditions during the determination process), that is, if it is determined that the set of WASI supported by a certain WASM runtime includes all the WASI used in the WASM module, then abort the above determination operation. This WASM runtime is the one or more candidate runtimes in the previous text.

[0139] 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 during the determination process), that is, if it is determined that the sets of WASI supported by the two WASM runtimes include all the WASI used in the WASM module, then abort the above determination operation. These two WASM runtimes are the one or more candidate runtimes in the previous text.

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

[0141] The above is only an example. The one or more candidate WASM runtimes can also be determined by other means, and the embodiments of the present application do not limit this.

[0142] When 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.

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

[0144] Exemplarily, randomly select a WASM runtime from the multiple WASM candidate runtimes as the target WASM runtime. Or, the target WASM runtime can also be determined from the multiple WASM candidate runtimes according to a preset rule. For example, select the WASM runtime with the largest number of supported WASIs from the multiple candidate WASM runtimes as the target WASM runtime. Another example is to preset priorities for the multiple WASM runtimes, and select the WASM runtime with the highest priority from the multiple candidate WASM runtimes as the target WASM runtime.

[0145] The above is only an example. In an actual scenario, the target WASM runtime can also be determined from the multiple candidate WASM runtimes by other means, and the embodiments of the present application do not limit this.

[0146] In addition, if the one or more candidate WASM runtimes do not exist in the multiple WASM runtimes, for example, if the set of WASIs used in the WASM module is not a subset of the set of WASIs supported by any of the multiple WASM runtimes, step 333 can be skipped and a prompt message #2 can be output. The prompt message #2 is used to prompt that the application cannot run. For example, the content of the prompt message #2 can include that the application does not conform to the specification of the WASM runtime, or there is no WASM runtime that can support the application, etc. The embodiments of the present application do not limit the specific content of the prompt message #2.

[0147] In the solution of the embodiment of the present application, the WASI used in the WASM module is extracted, and based on this, the WASM runtime that supports the WASM module is determined. In this way, the user only needs to provide the source code of the application or the WASM module, and the platform automatically completes the matching and use of the underlying WASM runtime, which is beneficial to further improving the user experience.

[0148] In addition, the WAT file can be obtained by decompiling the WASM module, and the WASI used by the WAT file can be extracted. The WAT file is parsable, and it is relatively easy to extract information from the WAT file, which is beneficial to reducing the difficulty of extracting the WASI in the WASM module.

[0149] Furthermore, Method #1 and Method #2 can also be used in combination.

[0150] For example, receive the input indication information #2, where the indication information #2 indicates the WASM runtime #1, and the 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.

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

[0152] Another example is to receive the input indication information #3, where the indication information #3 indicates the WASM runtime #2, and the set of WASIs used in the WASM module is not a subset of the set of WASIs supported by the WASM runtime #2. In this case, Method #2 can be used to determine the target WASM runtime.

[0153] In other words, if the WASM runtime indicated by the user cannot support the WASIs used by the WASM module, the platform can determine the target WASM runtime.

[0154] Another example is that if multiple candidate WASM runtimes are determined by using Method #2, the multiple candidate WASM runtimes can be displayed to the user, and the user determines the target WASM runtime.

[0155] It should be understood that Method #1 and Method #2 can also be combined in other ways, and the embodiments of the present application do not limit this. For the convenience of description, Method #2 is mainly used as an example for illustration in the following text.

[0156] In step 340, a WASM sandbox is created by using the target WASM runtime to provide a running environment for the user's code and run the user's application, that is, the WASM application. Or rather, run the WASM module.

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

[0158] 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 running of the WASM module. The target WASI is determined according to the WASI supported by the target WASM runtime.

[0159] Exemplarily, after determining the target WASM runtime, all WASIs supported by the target WASM runtime can be loaded. That is, the target WASI may include all WASIs supported by the target WASM runtime.

[0160] Alternatively, after determining the target WASM runtime, the target WASI can be loaded, and the target WASI is obtained by performing at least one of adding, deleting, or modifying the WASIs supported by the target WASM runtime.

[0161] In other words, after determining the target WASM runtime, the WASI can be dynamically loaded, that is, the WASI extension can be integrated according to needs, rather than loading all WASIs of the target WASM runtime every time. For example, during the process of loading the WASI, operations such as adding, deleting, and / or modifying can be performed on the 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) to obtain the set of target WASIs.

[0162] In the solution of the embodiments of the present application, the WASI can be dynamically loaded, so that the loaded WASI can be adjusted according to needs, which is beneficial to meeting the personalized needs of users and thus beneficial to improving the user experience.

[0163] Exemplarily, by dynamically loading the WASI, the WASI can be added, thereby realizing the WASI extension. For example, when loading the WASI, WASI extensions exceeding the community WASI / WASM common standard can be added, such as deep learning, large model inference, or access to backend blockchain as a service (BaaS) resources.

[0164] Exemplarily, by dynamically loading WASI, WASI can be removed, which is beneficial to improving security. The WASM sandbox is a secure operating environment isolated from the outside world, while WASI provides the ability to communicate inside and outside the sandbox and access external resources, which will introduce security risks while bringing more functional extensions. In the embodiments of the present application, some WASI related to internal and external communication such as disks and networks can be removed, thereby protecting the application programs in the sandbox and achieving more secure isolation.

[0165] Exemplarily, by dynamically loading WASI, WASI can be modified. Serverless and FaaS services need to provide relatively comprehensive observability capabilities. For example, collecting user logs. However, there are differences in the implementation methods of logs, resulting in obstacles in log collection. In the embodiments of the present application, the platform can provide standard WASI definitions and signatures. In this way, when users write and test application programs, they can implement custom log recording methods according to this standard and complete the replacement of log capabilities before running the application programs on the platform side, so as to smoothly dock with the observability capabilities on the platform side.

[0166] Figure 4 A schematic flowchart showing another method for running a WASM application is shown. Figure 4 The method 400 shown can be regarded as a specific implementation method of implementing the method 300 using the method #2. The relevant descriptions can refer to the method #2. To avoid repetition, some descriptions are appropriately omitted when describing 400.

[0167] As Figure 4 shown, the method 400 includes the following steps.

[0168] 410, Initialize the WASI supported by each WASM runtime.

[0169] For example, initialize the WASI support list (supportlist) for each WASM runtime, that is, read the pre-set mapping list of WASI supported by each WASM runtime and store it through a data structure.

[0170] Step 410 corresponds to step 331 in method 300. The specific description can refer to step 331.

[0171] 420, Load the WASM module of the application program.

[0172] Step 420 corresponds to step 310 in method 300. The specific description can refer to step 310.

[0173] 430, Decompile the WASM module into a WAT file.

[0174] Step 430 corresponds to step 332a in method 300, and for the specific description, reference can be made to step 332a.

[0175] 440. Extract the WASI used in the WAT file.

[0176] Step 440 corresponds to step 332b in method 300, and for the specific description, reference can be made to step 332b.

[0177] The set of WASI used in the WAT file can be represented as WASM. 2 set .

[0178] 450. Use the WASI used in the WAT file to perform loop detection on each WASM runtime.

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

[0180] That is, determine whether holds. WASM 1 set[runtime] represents the set of WASI supported by the currently detected WASM runtime.

[0181] If so, execute step 470; if not, execute step 450.

[0182] 470. Determine this WASM runtime as the WASM runtime required to run the WASM module (i.e., the target WASM runtime).

[0183] Steps 450 to 470 correspond to step 333 in method 300, and for the specific description, reference can be made to step 333.

[0184] 480. Load the WASI according to this WASM runtime.

[0185] Step 480 corresponds to step 350 in method 300, and for the specific description, reference can be made to step 350.

[0186] 490. Use this WASM runtime to execute the user's application.

[0187] It should be understood that the above is only an example and does not impose any limitation on the solutions of the embodiments of this application.

[0188] Figure 5 shows a schematic diagram of a system architecture for running WASM applications.

[0189] Taking the method #2 in the previous text 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 according to the matching WASM runtime. Create a WASM sandbox using the matching WASM runtime to provide a running environment for the user's code.

[0190] As mentioned above, the application file provided by the user can be the WASM module of the application, and this WASM module can be obtained by packaging the engine of the application and the source code of the application. Or, it can also be understood that the WASM module includes the engine of the application and the user's application (user application). For example, as Figure 5 shown.

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

[0192] The platform can load WASI according to the matching WASM runtime. For example, the plugin core analyzes that the matching WASM runtime is WASM runtime #A. The platform loads WASI according to the WASI supported by the target WASM runtime, that is, WASI WASMruntime#A . Then create a sandbox using WASM runtime #A to run the application.

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

[0194] As Figure 6 shown, the system 600 can include an engine actor 610, a plugin core 620, a WASM engine plugin, and a WASM runtime.

[0195] Among them, the engineactor 610 is used to initialize and execute applications. Specifically, the WASM runtime needs to be driven to execute applications. The application can be driven by the engineactor 610 and scheduled to be sent to the sandbox on the WASM runtime for execution.

[0196] As Figure 6 shown, the engineactor 610 communicates with the underlying WASM runtime through the plugincore 620 component. The engineactor 610 uses the API of the WASM engineplugin (such as the client API of the WASM runtime) through the plugincore 620 to implement scheduling and sending the application to be executed in the sandbox.

[0197] The engineactor 610 can be used to determine whether the WASM module of the application meets the standard. This standard refers to the community-recognized WASM de facto standard. The WASM module that meets the standard can be scheduled for execution.

[0198] The engineactor 610 can include a WASM parsing engine layer and / or a WASM module drop-in layer. Exemplarily, the user can provide the source code of the application, which is compiled through the WASM parsing engine layer, and then the application is executed through the underlying plugincore 620. Alternatively, the user can provide the WASM module of the application, and the WASM module is scheduled and sent to the WASM module drop-in layer in the WASM module drop-in manner, and then the application is executed through the underlying plugincore 620.

[0199] The WASI-specification support list is used to maintain the mapping of the WASI lists supported by different WASM runtimes, and can be used to identify the available runtimes of the WASM module (i.e., one or more candidate WASM runtimes mentioned above) and the scope of WASI that can be integrated.

[0200] The plugincore 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.

[0201] The plugincore 620 can determine the target WASM runtime of the WASM module according to the WASI - specification support list.

[0202] The plugincore 620 can also integrate the standard WASI and specific WASI when running an application using the WASM runtime according to the WASI - specification support list for accessing external resources (such as external devices or external systems, etc.).

[0203] The standard WASI can be understood as the WASI based on community norms and standards, which usually includes standard interfaces supported by mainstream runtimes.

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

[0205] The plugincore 620 can define lifecycle management standards for implementing the lifecycle management of sandbox instances and realizing communication inside and outside the sandbox. For example, the plugincore 620 can be used for instance initialization, request invocation, and instance destruction. Another example is that the plugincore 620 can be used to load WASI to enable the sandbox to access external resources.

[0206] The WASM engineplugin provides the system with the ability to dock with the underlying WASM runtime.

[0207] The platform includes multiple WASM engineplugins and multiple WASM runtimes.

[0208] The multiple WASM engineplugins and multiple WASM runtimes are in one - to - one correspondence.

[0209] For example, as Figure 6 shown, the platform includes three WASM engineplugins, namely WASM engineplugin 631, WASM engineplugin 632, and WASM engineplugin 633. These three WASM engineplugins respectively correspond to three WASM runtimes, namely Figure 6 the WASM runtime 641, the WASM runtime 642, and the WASM runtime 643 in

[0210] For example, these three WASM runtimes can be WASM Time, WASMEdge, and WASMer respectively. Alternatively, the WASM runtime can also be other runtimes, which are not limited in the embodiments of this application.

[0211] It should be understood that Figure 6 the number of WASM engineplugins and WASM runtimes in [[ ]] is only an example and does not limit the solutions of the embodiments of this application.

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

[0213] The essence of the WASM engineplugin is to integrate the SDK of the corresponding WASM runtime and implement the same standard interfaces for lifecycle management, function execution, metering, etc. Through the specific implementation of integrating the SDK, the platform knows how to communicate with the WASM runtime and execute the instructions of the corresponding standard interfaces. In this way, for the platform, regardless of what the underlying WASM runtime is, the same capabilities are achieved through the SDK of the WASM runtime, including instance initialization, request invocation, instance recycling, and metering of execution time and memory occupancy in the instance.

[0214] WASI integration occurs during the instance initialization process. Additions, deletions, and / or modifications to WASI can be made during the WASI integration process. If a function instance does not include a certain WASI after initialization, that WASI cannot be used during subsequent function calls.

[0215] The WASM engineplugin corresponding to each WASM runtime, together with the plugincore, processes the WASM runtime and WASI implementation.

[0216] When the user's execution request arrives, the engine actor 610 determines whether the WASM module of the application indicated by the execution request meets the standard. If it does not meet the standard, the execution request is rejected. If the WASM module meets the standard, the plug-in core 620 decompiles the WASM module to obtain a WAT file. The plug-in core 620 analyzes the WAT file to determine the WASM runtime that matches the WASM module. The plug-in 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. Subsequently, the user's execution request can be executed in the sandbox.

[0217] It should be understood that Figure 5 and Figure 6 the architectures in are only examples and do not limit the solutions of the embodiments of the present application. For example, in other implementation manners, other modules or devices may also analyze the matching WASM runtime. For another example, the communication between the plug-in core and each underlying WASM runtime can also be implemented through the command line.

[0218] The following describes the device of the embodiment of the present application in conjunction with Figures 7 to 10 It should be understood that the device described below can execute the method of the foregoing embodiments of the present application. To avoid unnecessary repetition, the following description of the device of the embodiment of the present application appropriately omits the repeated description.

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

[0220] As Figure 7 shown, the system 2000 may include:

[0221] A receiving module 2010, configured to receive an execution request of an application;

[0222] An obtaining module 2020, configured to obtain the WASM module of the application;

[0223] A processing module 2030, configured to determine a target WASM runtime from multiple WASM runtimes, where the target WASM runtime supports the WASM module;

[0224] A creation module 2040, configured to create a sandbox by using a target WASM runtime;

[0225] An execution module 2050, configured to execute a WASM module in the sandbox.

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

[0227] Obtain a mapping relationship between multiple WASM runtimes and WASI, a WASM system interface supported by the multiple WASM runtimes;

[0228] Extract WASI from the WASM module;

[0229] Determine one or more candidate WASM runtimes from the multiple WASM runtimes according to 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.

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

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

[0232] Extract the WASI in the WASM module from the WAT file.

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

[0234] Control the display of multiple candidate configuration items for indicating the multiple WASM runtimes;

[0235] Receive a selection result of the multiple candidate configuration items;

[0236] Determine the target WASM runtime according to the selection result.

[0237] Optionally, the system 2000 further includes a loading module (not shown in the figure) configured to load a target WASI for communicating with an external environment of the sandbox during the execution of the WASM module, where the target WASI is determined according to the WASI supported by the target WASM runtime.

[0238] Optionally, the target WASI is obtained by performing at least one of addition, deletion, or modification on the WASI supported by the target WASM runtime.

[0239] For specific descriptions, reference may be made to Method 300 and Method 400 in the foregoing text, which will not be elaborated herein.

[0240] Among them, each module in the system 2000 can be implemented by software or by hardware. Exemplarily, next, taking the processing module 2030 as an example, the implementation manner of the processing module 2030 will be introduced. Similarly, the implementation manners of other modules can refer to the implementation manner of the processing module 2030.

[0241] As an example of a software functional unit, the processing module 2030 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above 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 for running this code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers for running this code may be distributed in the same availability zone (AZ), or in different AZs, and each AZ includes one data center or multiple geographically proximate data centers. Among them, generally one region may include multiple AZs.

[0242] Similarly, the multiple hosts / virtual machines / containers for running this code may be distributed in the same virtual private cloud (VPC), or in multiple VPCs. Among them, generally one VPC is set within one region. For cross-region communication between two VPCs within the same region and between VPCs in different regions, a communication gateway needs to be set in each VPC, and the interconnection between VPCs is realized through the communication gateway.

[0243] As an example of a hardware functional unit, the processing module 2030 may include at least one computing device, such as a server, etc. Or, the processing module 2030 may also be a device implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). Among them, the above PLD may be implemented by a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

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

[0245] 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 responsible for implementation by each module can be specified as needed. The entire function of the system 2000 is realized by each module respectively implementing different steps in the method of running a WASM application.

[0246] This application also provides a computing device 1000. As Figure 8 shown, the computing device 1000 includes: a bus 1002, a processor 1004, a memory 1006, and a communication interface 1008. The processor 1004, the memory 1006, and the communication interface 1008 communicate with each other through the bus 1002. The 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 the computing device 1000.

[0247] The bus 1002 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity of representation, Figure 8 only one line is shown in the figure, but it does not mean that there is only one bus or one type of bus. The bus 1002 can include a path for transmitting information between various components of the computing device 1000 (for example, the memory 1006, the processor 1004, the communication interface 1008).

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

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

[0250] The executable program code is stored in the memory 1006, and the processor 1004 executes the executable program code to implement the functions of the foregoing respective modules, thereby implementing the method for running the WASM application. That is, the memory 1006 stores instructions for executing the method for running the WASM application.

[0251] 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.

[0252] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device may 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 may also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

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

[0254] In some possible implementation manners, partial instructions for executing the method for running the WASM application may also be stored separately in the memory 1006 of one or more of the computing devices 1000 in the computing device cluster. In other words, a combination of one or more computing devices 1000 may jointly execute the instructions for executing the method for running the WASM application.

[0255] It should be noted that the memories 1006 in different computing devices 1000 in the computing device cluster may store different instructions, which are respectively used to execute partial functions of the system for running the WASM application. That is, the instructions stored in the memories 1006 of different computing devices 1000 may implement the functions of one or more modules in the system 2000.

[0256] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. Among them, the network can be a wide area network or a local area network, etc.

[0257] Figure 10 A possible implementation is shown. As Figure 10 shown, two computing devices 1000A and 1000B are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device. In this type of possible implementation, the memory 1006 in the computing device 1000A stores instructions for executing the functions of the receiving module 2010 and the obtaining module 2020. At the same time, the memory 1006 in the computing device 1000B stores instructions for executing the functions of the processing module 2030, the creating module 2040, and the running module 2050.

[0258] Figure 10 The connection method between the computing device clusters shown can be considered that since the method for running a WASM application provided in this application may need to store data, it is considered to hand over the functions implemented by the processing module 2030, the creating module 2040, and the running module 2050 to the computing device 1000B for execution.

[0259] It should be understood that Figure 10 the functions of the computing device 1000A shown can also be completed by multiple computing devices 1000. Similarly, the functions of the computing device 1000B can also be completed by multiple computing devices 1000.

[0260] The embodiments of this application also provide a computer program product containing instructions. The computer program product can be software or a program product containing instructions that can run on a computing device or be stored in any available medium. When the computer program product runs on at least one computing device, it causes at least one computing device to execute the method for running a WASM application.

[0261] The embodiments of this application also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive), etc. The computer-readable storage medium includes instructions that instruct the computing device to execute the method for running a WASM application.

[0262] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0263] Those skilled in the art can 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 foregoing method embodiments and will not be elaborated herein.

[0264] In 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 illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, 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 displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of the devices or units can be in electrical, mechanical, or other forms.

[0265] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place, or they can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0266] In addition, the functional units in each embodiment of this application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit.

[0267] When the above-mentioned 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 this application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the processing methods described in various embodiments of this application. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes.

[0268] As described above, the above are only specific implementation manners of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art within the technical scope disclosed by this application can easily think of changes or substitutions, which should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope 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, 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.

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