Request processing method and apparatus, electronic device, storage medium, and product

Abstract

The present disclosure provides a request processing method and device, electronic equipment, storage medium and product. The method comprises: obtaining a WebAssembly file generated by compiling source code containing Web framework logic, and instantiating the WebAssembly file in a host runtime environment to generate a WebAssembly module; listening to a communication port by the host runtime environment to receive a network request of a client, and writing data of the network request into a shared storage area of the WebAssembly module; calling a request processing function exported by the WebAssembly module by the host runtime environment, triggering the Web framework logic in the WebAssembly module to read data in the shared storage area, and performing business processing according to the read data, and writing response data into the shared storage area after generating the response data; reading the response data from the shared storage area by the host runtime environment, and returning to the client through the communication port.

Description

Technical Field

[0001] This disclosure relates to the field of Web services technology, and in particular to a request processing method, apparatus, electronic device, storage medium, and product. Background Technology

[0002] In edge computing scenarios, existing solutions for deploying complex business applications based on Go language web frameworks (such as Gin) mainly suffer from the following problems: standard WebAssembly (WASM) environments (especially V8-based web environments) lack the ability to directly access system network sockets, while Go web frameworks rely on underlying network listening ports and cannot directly start HyperText Transfer Protocol (HTTP) servers in the WASM sandbox, resulting in strong coupling between network I / O and business logic. In addition, existing solutions can only support simple computational logic and cannot run a complete web framework, resulting in poor stability of network request processing. Summary of the Invention

[0003] This disclosure provides a request processing method, apparatus, electronic device, storage medium, and product to address problems in the related art.

[0004] A first aspect of this disclosure provides a request processing method, the method comprising:

[0005] Obtain the WebAssembly file generated by compiling the source code containing the Web framework logic, and instantiate the WebAssembly file in the host runtime environment to generate a WebAssembly module; The host runtime environment listens to the communication port to receive network requests from clients and writes the data of the network requests to the shared storage area of ​​the WebAssembly module; The host runtime environment calls the request processing function exported by the WebAssembly module, triggering the Web framework logic within the WebAssembly module to read data from the shared storage area, perform business processing based on the read data, generate response data, and write it to the shared storage area. The host runtime environment reads the response data from the shared storage area and returns it to the client through the communication port.

[0006] In one embodiment, obtaining a WebAssembly file generated by compiling source code containing Web framework logic includes: Obtain the source code containing the web framework logic; Modify the program entry logic in the source code; The modified source code is used to compile and generate a WebAssembly file.

[0007] In one embodiment, modifying the program entry logic in the source code includes: Delete the target code segment from the source code and define a request handling function and an initialization function. The target code segment is a program statement used to start network listening to receive external requests. The initialization function is used to build a Web framework instance and register a route mapping table.

[0008] In one embodiment, writing the data of the network request to the shared storage area of ​​the WebAssembly module includes: Extract the request metadata and request payload data of the network request; According to the preset memory layout rules, the request metadata and the request payload data are serialized to obtain the serialized data corresponding to the network request; The serialized data is written to the shared storage area of ​​the WebAssembly module.

[0009] In one embodiment, the host runtime environment calls a request handling function exported by the WebAssembly module to trigger the Web framework logic within the WebAssembly module to read data from the shared storage area, including: Get the starting position and offset length of the data in the shared storage area; The host runtime environment calls the request processing function exported by the WebAssembly module, triggering the Web framework logic within the WebAssembly module to read data from the shared storage area based on the starting position and offset length.

[0010] In one embodiment, the process of performing business processing based on the read data, generating response data, and then writing it to the shared storage area includes: The read data is reorganized into an internal request object, which is data that the Web framework can process; Perform business processing based on the internal request object to generate response data corresponding to the network request; The response data is written to the shared storage area.

[0011] A second aspect of this disclosure provides a request processing apparatus, the apparatus comprising: The acquisition unit is used to acquire the WebAssembly file generated by compiling the source code containing the Web framework logic, and instantiate the WebAssembly file in the host runtime environment to generate a WebAssembly module; The writing unit is used to listen to the communication port of the host runtime environment to receive network requests from the client, and write the data of the network request to the shared storage area of ​​the WebAssembly module; The processing unit is used to call the request processing function exported by the WebAssembly module by the host runtime environment, trigger the Web framework logic in the WebAssembly module to read the data in the shared storage area, perform business processing based on the read data, generate response data and write it to the shared storage area; The return unit is used to read the response data from the shared storage area by the host runtime environment and return it to the client through the communication port.

[0012] A third aspect of this disclosure provides an electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the methods described in the first aspect of this disclosure.

[0013] A fourth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods described in the first aspect of this disclosure.

[0014] A fifth aspect of this disclosure provides a computer program product including a computer program that, when executed by a processor, implements the methods described in the first aspect of this disclosure.

[0015] In summary, this disclosure proposes a request processing method, which includes: obtaining a WebAssembly file generated by compiling source code containing Web framework logic, and instantiating the WebAssembly file in a host runtime environment to generate a WebAssembly module; the host runtime environment listening to a communication port to receive network requests from clients, and writing the data of the network requests into the shared storage area of ​​the WebAssembly module; the host runtime environment calling a request processing function exported by the WebAssembly module to trigger the Web framework logic within the WebAssembly module to read the data in the shared storage area, and performing business processing based on the read data to generate response data and write it into the shared storage area; and the host runtime environment reading the response data from the shared storage area and returning it to the client through the communication port.

[0016] According to the solution provided in this disclosure, by obtaining the WebAssembly file generated by compiling the source code containing Web framework logic, and instantiating the file in the host runtime environment to generate a WebAssembly module, cross-platform encapsulation and sandboxed operation of the Web framework logic are achieved, improving the deployment flexibility of business logic. By having the host runtime environment listen to the communication port to receive network requests from clients and write the network request data to the shared storage area of ​​the WebAssembly module, network I / O and business logic are decoupled, preventing the WebAssembly module from directly accessing network resources and improving operational security. By having the host runtime environment call the request processing function exported by the WebAssembly module, the Web framework logic within the module is triggered to read data in the shared storage area, perform business processing, generate response data, and write it back to the shared storage area, achieving standardized interaction between the host and the module, enabling the Web framework in the isolated environment to process business logic normally. By having the host runtime environment read response data from the shared storage area and return it to the client via the communication port, and having the host uniformly respond externally, the stability of network request processing can be improved.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0019] Figure 1 A flowchart illustrating a request processing method provided in an embodiment of this disclosure; Figure 2 A flowchart illustrating a method for obtaining a WebAssembly file provided in an embodiment of this disclosure; Figure 3 A flowchart illustrating a method for writing network request data to a shared storage area of ​​a WebAssembly module, provided as an embodiment of this disclosure; Figure 4 This is a schematic diagram of the structure of a request processing device provided in an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the hardware composition structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0020] Embodiments of this disclosure are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0021] To facilitate a better understanding of the technical solutions described in the embodiments of this disclosure by those skilled in the art, the technical terms in the embodiments of this disclosure are explained as follows before introducing the embodiments of this disclosure.

[0022] With the development of edge computing, developers need to run high-performance web services on edge nodes. Currently, there are two main deployment methods: The following is a brief introduction to two approaches to request processing in related technologies: Traditional virtual machine / container deployment: The solution proposes packaging Go programs as Docker containers or deploying them in virtual machines (VMs), relying on the complete network stack of the host operating system.

[0023] Simple WASM function deployment: The proposed solution is to compile Go code into WASM and call it via V8 / JS as a glue layer. Current implementations are mostly limited to simple computational logic (such as inputting a number and outputting a result), and use exported functions for simple data type exchange.

[0024] The above solution has the following drawbacks: In edge computing scenarios, directly applying the above technologies presents the following key challenges: (1) Poor security isolation, especially for Native / Foreign Function Interface (FFI): If Go-compiled shared libraries are called directly through FFI, the code runs in the host process space and lacks effective sandbox isolation. Once the Go code crashes or is attacked, it may endanger the entire runtime environment.

[0025] (2) Network model incompatibility (for WASM): Standard WASM environments (especially V8-based web environments) lack the ability to directly access system network sockets. Go web frameworks (such as Gin) rely on the underlying net / http listening port and cannot directly start an HTTP server in a standard WASM sandbox.

[0026] (3) Weak support for complex frameworks: Existing Go-WASM solutions are mostly used for simple algorithm migration and cannot support the complex features required by frameworks like Gin, such as asynchronous input / output (I / O), middleware lifecycle management, and route distribution.

[0027] High performance and resource overhead: Traditional container solutions have slow cold starts and high resource consumption, making them unsuitable for edge function scenarios with high concurrency and short runtime.

[0028] To address the shortcomings of related technologies, this disclosure achieves cross-platform encapsulation and sandboxed operation of the Web framework logic by obtaining a WebAssembly file compiled from the source code containing Web framework logic and instantiating the file in the host runtime environment to generate a WebAssembly module, thereby improving the deployment flexibility of business logic. By having the host runtime environment listen to the communication port to receive network requests from clients and write the network request data to the shared storage area of ​​the WebAssembly module, network I / O and business logic are decoupled, preventing the WebAssembly module from directly accessing network resources and improving operational security. Furthermore, by having the host runtime environment call the request processing function exported by the WebAssembly module, the Web framework logic within the module reads data from the shared storage area, performs business processing, generates response data, and writes it back to the shared storage area, achieving standardized interaction between the host and the module, enabling the Web framework in the isolated environment to process business logic normally. Finally, by having the host runtime environment read response data from the shared storage area and return it to the client via the communication port, with the host providing unified external responses, the stability of network request processing can be improved.

[0029] The present disclosure will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0030] The request processing method provided in this disclosure can be applied to scenarios that require efficient processing of network requests and cross-platform deployment, such as enterprise-level web services, lightweight embedded device network request processing, and cloud-native service deployment. It is particularly suitable for scenarios with strict requirements on resource consumption and sandbox isolation protection, such as multi-tenant services and edge computing devices. The execution subject of the method can be a server with a host runtime environment, or an embedded device or cloud node equipped with the corresponding runtime environment.

[0031] like Figure 1 As shown, Figure 1 This is a flowchart illustrating a request processing method provided in an embodiment of this disclosure. The request processing method provided in this embodiment includes the following steps: Step 101: Obtain the WebAssembly file generated by compiling the source code containing the Web framework logic, and instantiate the WebAssembly file in the host runtime environment to generate a WebAssembly module; In one embodiment, the Web framework logic is a collection of code used to receive, parse, route network requests and perform business processing. The Web framework logic may include request routing, middleware, interface processing logic, etc.

[0032] In one embodiment, the WebAssembly file is a binary format file compiled from source code of a high-level programming language, which can be loaded and run in a variety of host environments.

[0033] In one embodiment, the host runtime environment refers to a runtime environment capable of loading, instantiating, and running WebAssembly modules, which can be used for network monitoring, memory management, module scheduling, and external interaction. A WebAssembly module refers to the runtime environment formed after a WebAssembly file is loaded and instantiated in the host runtime environment; the WebAssembly module includes memory space, exported functions, and internal business logic. Furthermore, the WebAssembly module runs in an isolated environment provided by the V8 engine.

[0034] In one embodiment, the host runtime environment can be Deno, Node.js, etc. In this application, Deno is used as an example of the host runtime environment.

[0035] In one embodiment, a WebAssembly file, generated by compiling source code containing Web framework logic, can be read from a local file path.

[0036] In one embodiment, a WebAssembly file compiled from source code containing Web framework logic and located on a remote server can also be downloaded over a network; alternatively, a WebAssembly file compiled from source code containing Web framework logic and cached in memory can also be loaded.

[0037] By obtaining the WebAssembly file generated by compiling the source code containing the Web framework logic, and instantiating the file in the host runtime environment to generate the WebAssembly module, cross-platform encapsulation and sandboxed operation of the Web framework logic are achieved, improving the deployment flexibility of business logic.

[0038] Step 102: The host runtime environment listens to the communication port to receive network requests from the client and writes the data of the network request into the shared storage area of ​​the WebAssembly module; In one embodiment, a network request includes at least a request header, a request body, and other information.

[0039] In one embodiment, the shared storage area is a memory space accessible to both the host runtime environment and the WebAssembly module.

[0040] In one embodiment, the host runtime environment can synchronously block listening to the communication port and directly write the complete data to the shared storage area of ​​the WebAssembly module after receiving a network request.

[0041] In one embodiment, the host runtime environment may first verify and compress the data of the network request, and then write the processed data into the shared storage area of ​​the WebAssembly module.

[0042] By having the host runtime environment listen to the communication port to receive network requests from clients and write the network request data to the shared storage area of ​​the WebAssembly module, network I / O and business logic are decoupled. This avoids the WebAssembly module from directly accessing network resources and improves operational security.

[0043] Step 103: The host runtime environment calls the request processing function exported by the WebAssembly module, triggering the Web framework logic within the WebAssembly module to read the data in the shared storage area, perform business processing based on the read data, generate response data, and write it to the shared storage area; In one embodiment, the exported request processing function is a callable interface exposed by the WebAssembly module, which is triggered by the host runtime environment to start the request processing flow of the internal Web framework.

[0044] In one embodiment, the host runtime environment can directly call the exported function without passing additional parameters, and the Web framework can traverse and read all the requested data in the shared storage area; In one embodiment, the host runtime environment can also pass in the starting address and length of the data in the shared storage when calling the exported function, and the Web framework reads the data in the shared storage area according to the specified location (starting address and length).

[0045] In one embodiment, after reading the data, the Web framework first performs format validation, and then routes the read data to the corresponding business interface to perform business processing. After the business processing is completed, the Web framework can directly write the response data to the shared storage area, or it can cache it first and then write it to the shared storage area in batches.

[0046] Step 104: The host runtime environment reads the response data from the shared storage area and returns it to the client through the communication port.

[0047] In one embodiment, the communication port is used as a communication interface for establishing network connections with clients and sending and receiving network request and response data.

[0048] In one embodiment, the host runtime environment can read all response data and send it to the client all at once through the communication port.

[0049] In one embodiment, the response data can also be read in blocks of fixed size and sent to the client in multiple batches.

[0050] By calling the request processing function exported by the WebAssembly module through the host runtime environment, the Web framework logic within the module is triggered to read data in the shared storage area, perform business processing, generate response data, and write it back to the shared storage area. This achieves standardized interaction between the host and the module, enabling the Web framework in the isolated environment to process business logic normally. By reading response data from the shared storage area through the host runtime environment and returning it to the client via the communication port, the host can provide unified external responses, which can improve the stability of network request processing.

[0051] In one embodiment, such as Figure 2 As shown, the WebAssembly file generated by compiling the source code containing the Web framework logic is obtained, including: Step 201: Obtain the source code containing the Web framework logic; In one embodiment, the source code is the original program code written in a high-level programming language, containing complete Web framework business logic and routing configuration.

[0052] In one embodiment, the source code containing the Web framework logic can be read directly from the local code project directory, or the source code containing the Web framework logic can be pulled from a remote code repository through version management tools such as Git or SVN; alternatively, a predefined framework source code package can be downloaded from a configuration center or cloud storage service to obtain the source code containing the Web framework logic.

[0053] Step 202: Modify the program entry logic in the source code; In one embodiment, the program entry logic of the source code refers to the initialization code segment that is executed first after the program starts, which is used to configure the runtime environment, start services, load components, etc. In this application, the program entry logic of the source code refers to the entry file, such as main.go.

[0054] In one embodiment, the target code segment is a program statement used to enable network listening to receive external requests.

[0055] In one embodiment, modifying the program entry logic in the source code includes: Delete the target code segment from the source code and define a request handling function and an initialization function. The target code segment is a program statement used to start network listening to receive external requests. The initialization function is used to build a Web framework instance and register a route mapping table.

[0056] In one embodiment, the function call statement that starts port listening can be directly deleted from the entry file; alternatively, the port listening logic can be disabled when compiling to the WebAssembly version using conditional compilation directives.

[0057] In one embodiment, the program entry logic of the source code is modified to remove the code that binds to and listens to the network port of the Web framework itself, so that the Web framework no longer has independent network receiving capabilities.

[0058] In one embodiment, the request handling function receives calls from the host runtime environment, reads shared storage data, and initiates request processing. The initialization function executes during the loading phase and is used to construct a Web framework instance, register routes and middleware. The Web framework instance refers to the core object created by the Web framework runtime, which carries routing rules, middleware, request context, etc., such as a Gin engine instance. The route mapping table is a configuration structure used to record the correspondence between request paths, request methods, and corresponding business processing logic, enabling accurate request distribution.

[0059] In one embodiment, a global request handling function is added to the entry file, and the initialization function is automatically executed when the module is instantiated; the route mapping table is loaded in the form of a configuration file, the initialization function reads the configuration and registers routes in batches, and at the same time completes middleware registration, exception handling configuration, database connection initialization and other operations; the request handling function receives parameters such as memory address and length to locate the request data in the shared storage area.

[0060] In one embodiment, request handling functions and initialization functions are defined in the source code, which can complete the creation of framework objects and loading of route configurations when the program starts.

[0061] Step 203: Compile and generate a WebAssembly file based on the modified source code.

[0062] In one embodiment, compiling a WebAssembly file based on the modified source code refers to converting the modified source code into a WebAssembly file that can run in the host runtime environment using a compiler.

[0063] In one embodiment, a native language compiler is used, specifying the target architecture as WebAssembly, to compile a WebAssembly file. For example, for the Go language, the native Go compiler is used to compile the modified source code into a WebAssembly file using the command GOOS=js GOARCH=wasm go build-o gin.wasm main.go.

[0064] For example, obtain the source code of the Gin Web framework written in Go, including user interface, routing configuration and other logic; modify the main function entry point, delete the code lines such as gin.Run() that start port listening, so that the Web framework no longer listens to the network port; define handleRequest() as the request handling function, write the initGin() initialization function, in which create a Gin engine instance and register routes; use the Go compiler to execute the compilation command, specify the target architecture as WebAssembly, and generate WebAssembly files.

[0065] By removing the Web framework and network listening functionality, the Web framework can run in a sandboxed, lightweight environment without network permissions, improving security and applicability.

[0066] In one embodiment, such as Figure 3 As shown, writing the data of the network request to the shared storage area of ​​the WebAssembly module includes: Step 301: Extract the request metadata and request load data of the network request; In one embodiment, request metadata refers to data describing the basic attributes of a network request, including request method, request path, request headers, protocol version, etc., but does not include business transmission content; request payload data refers to the data in the network request that carries business content, i.e., request data.

[0067] In one embodiment, the request method, URL, and request headers are extracted from the request header of the network request as request metadata, and the request payload data is extracted from the request body of the network request.

[0068] Step 302: Serialize the request metadata and the request payload data according to a preset memory layout rule to obtain the serialized data corresponding to the network request; In one embodiment, the preset memory layout rule refers to the predefined memory data arrangement rule that is jointly followed by the host runtime environment and the WebAssembly module, which may include data storage order, offset position, length identifier, etc.

[0069] In one embodiment, serialization refers to the process of converting structured data into byte data that can be stored contiguously in memory and read across environments.

[0070] In one embodiment, the request metadata and the request payload data can be serialized in a format where metadata comes first and payload data comes last, to obtain the serialized data corresponding to the network request.

[0071] Step 303: Write the serialized data into the shared storage area of ​​the WebAssembly module.

[0072] In one embodiment, the complete serialized data can be written directly to the shared storage area of ​​the WebAssembly module in one go.

[0073] In one embodiment, the serialized data can also be divided into blocks according to a preset data size and written to the shared storage area of ​​the WebAssembly module.

[0074] In one embodiment, the host runtime environment calls a request handling function exported by the WebAssembly module to trigger the Web framework logic within the WebAssembly module to read data from the shared storage area, including: Get the starting position and offset length of the data in the shared storage area; The host runtime environment calls the request processing function exported by the WebAssembly module, triggering the Web framework logic within the WebAssembly module to read data from the shared storage area based on the starting position and offset length.

[0075] In one embodiment, the exported request handling function refers to the interface function exposed by the WebAssembly module at compile time, which can be called by the host runtime environment to trigger internal business logic.

[0076] In one embodiment, the starting position refers to the starting memory address of the network request data in the shared storage area, which is used to locate the beginning position of the data; the offset length refers to the length of bytes occupied by the effective data starting from the starting position, which is used to define the data range and avoid out-of-bounds reading.

[0077] In one embodiment, the host runtime environment determines the starting position and offset length of the data in the shared storage area based on records previously written to the shared storage area.

[0078] In one embodiment, the host passes the starting position and offset length of the data in the shared storage area as parameters to the request processing function, triggering the Web framework logic within the WebAssembly module, and then reads the data in the shared storage area according to the starting position and offset length.

[0079] In one embodiment, the Web framework verifies the validity of the address based on the input parameters. If the verification is successful, the framework reads the data in the shared storage area based on the starting position and offset length.

[0080] In one embodiment, the process of performing business processing based on the read data, generating response data, and then writing it to the shared storage area includes: The read data is reorganized into an internal request object, which is data that the Web framework can process; Perform business processing based on the internal request object to generate response data corresponding to the network request; The response data is written to the shared storage area.

[0081] In one embodiment, the data read refers to serialized data that the Web framework logic reads from the shared storage area.

[0082] In one embodiment, the internal request object refers to a structured request entity natively defined by the Web framework, which includes request methods, paths, header information, parameters, etc., and is an object that the Web framework can directly identify and process.

[0083] In one embodiment, reorganizing the read data into an internal request object means parsing and encapsulating the request data in binary byte stream form into a structured internal request object that can be recognized by the Web framework; according to preset memory layout rules, request metadata and request payload data can be parsed from the read data in sequence and encapsulated into an internal request object.

[0084] In one embodiment, business processing refers to performing business-related processes such as route matching, logical calculation, data verification, and database operations based on an internal request object.

[0085] In one embodiment, response data refers to the return result data generated after the business processing is completed, which may include status codes, response headers, response bodies, etc.

[0086] In one embodiment, the Web framework performs route distribution based on information such as the path and method in the internal request object, executes business logic, and generates a response. It can match the request path and request method against a registered route mapping table and call the corresponding business request processing function; alternatively, it can perform pre-processing on the request object, such as parameter validation, authentication, and middleware execution, before executing the business logic.

[0087] In one embodiment, response data is generated based on the result of the business execution. Specifically, if the business execution is successful, the corresponding data is used as the response data; if the business execution fails, the exception message and error code are used as the response data.

[0088] By reorganizing the read data into an internal request object, which is data that the Web framework can process, the framework can directly use native interfaces, simplifying business logic development.

[0089] For example, for business logic code written in Go that includes the Gin Web framework, the framework's own port listening logic is removed, and the code is compiled into a WebAssembly file. The WebAssembly file is loaded in a host runtime environment such as Deno or Node.js, instantiated, and allocated in linear shared memory. The host environment listens on the TCP communication port, receives HTTP requests, serializes the request headers and body, and writes them into the linear shared memory. The host calls the handleRequest function exported by the WebAssembly module, triggering the internal Gin framework to read the request data. The Web framework reconstructs the data in the linear shared memory into a standard request object, completes route matching and business processing, and writes the response back to the linear shared memory. The host reads the response data from the linear shared memory and returns it to the client through the original communication port, completing one request processing cycle.

[0090] In one embodiment, GIN deployment can be achieved by using Deno's FFI to call a Go-compiled C shared library. This involves directly loading the shared library (such as libgin.so) in Deno and using FFI to call Go functions to handle HTTP requests. However, this approach lacks V8 isolation and is only suitable for low-security scenarios.

[0091] In one embodiment, the TinyGo compilation tool can be used instead of native Go compilation to optimize the WASM file size, but the GIN code needs to be adjusted to be compatible with a subset of the TinyGo standard library.

[0092] Taking Go as the programming language and Deno as the host runtime environment as an example, it includes: Step 1: Build a Go web service adapted for WASM, including: code adjustments and initialization logic. Code adjustments refer to modifying the entry file (main.go) of the Go program. Instead of directly listening on the TCP port using gin.Run(), a global request handling function (such as handleRequest) is defined. The handleRequest function receives request data passed in via WASM memory. Initialization logic refers to writing the initialization function initGIN(), which is used to build the Gin engine instance, register routes, and middleware.

[0093] Compilation instructions: Use the native Go compiler and set the target architecture to WASM.

[0094] Example command: GOOS=js GOARCH=wasm go build -o gin.wasm main.go .

[0095] Step 1 generates a binary instruction file containing the Go Runtime and Gin framework logic, but does not include the operating system's system call capabilities.

[0096] Step 2: Edge environment runtime loading, including: host environment preparation, module instantiation, and API injection. Host environment preparation involves using a runtime that supports WASM and system APIs (i.e., Deno). Module instantiation involves writing TypeScript / JavaScript scripts (such as main.ts) and reading the gin.wasm file. API injection involves injecting the system interfaces required by Deno (such as console output, time acquisition, etc.) into the WASM import object when calling WebAssembly.instantiate, thus establishing the basic runtime environment.

[0097] Step 3: Establishing a network I / O bridge includes request proxying, memory data exchange, Go internal processing, and response postback. Request proxying: The Deno script uses `Deno.listen` or `Deno.serve` to listen on the actual edge node port (e.g., 8080). Memory data exchange: When Deno receives an external HTTP request, it serializes the request headers, body, and other information. The serialized data is written to the shared linear memory of the WASM instance. The `handleRequest` function exported by WASM is called, passing in a pointer to the data in memory and its length. Go internal processing: The Go code inside WASM reads the memory data via syscall / js or a custom adapter, reassembles it into an `http.Request` object, and directly calls Gin's `ServeHTTP` method for processing. Response postback: After Gin completes processing, it generates response data, which the Go code writes to memory and notifies the Deno side (via return value or callback). Deno reads the response data from memory and returns it to the client via a network socket.

[0098] The pseudocode for the Go side (WASM) is as follows: engine := gin.Default() func main() { engine.GET(" / hello", func(c gin.Context) { c.JSON(http.StatusOK, gin.H{ "message": c.PostForm("name"), }) }) / / Export functions for JS calls js.Global().Set("handleRequest", js.FuncOf(handleRequest)) / / Instead of executing r.Run(), keep it running and wait to be called. select {} } func handleRequest(this js.Value, args []js.Value) { / / 1. Read the Request from memory sent by JS if len(args)<1 { return js.ValueOf("Incorrect parameter") } denoReq := args[0].String() / / 2. Construct the http Request resp := WASMResponseWriter{} getURL := url.URL{ Scheme: "XX", Host:"XX", Path:" / hello", } req := http.Request{ Method: "GET" URL:&getURL, Header: http.Header{}, PostForm: url.Values{ "name": []string{denoReq}, }, } / / 3. Call ServeHTTP(w, req) egine.Handler().ServeHTTP(resp,&req) / / 4. Write w(Response) to memory and return. return js.ValueOf(string(resp.body)) } The pseudocode for the Deno side (TypeScript) is as follows: import "wasm_exec.js"; / / This comes from the Go installation directory (go env GOROOT) / misc / wasm / wasm_exec.js const go = new Go(); / / Global Go class defined in wasm_exec.js const wasmCode = await Deno.readFile("gin.wasm"); const wasmModule = await WebAssembly.instantiate(wasmCode,go.importObject); / / Monitoring the real network Deno.serve(async (req) =>{ const url = req.url; const headers = req.headers; const body = await req.text(); / / or req.json(), choose according to actual needs. / / 1. Serialize req const requestData = JSON.stringify({ url, headers, body}); / / 2. Write to memory by calling wasmModule.instance.exports.handleRequest(); const resp = (globalThis as any).handleRequest(requestData); / / 3. Read the result and return a new Response(...) return new Response(`Go WASM executed: ${resp}\n`,{ headers: { "content-type": "text / plain"}, }); }).

[0099] In summary, the solution provided in this public disclosure is as follows: First, by obtaining the WebAssembly file generated from the source code containing the Web framework logic and compiling it, and instantiating the file in the host runtime environment to generate a WebAssembly module, cross-platform encapsulation and sandboxed operation of the Web framework logic are achieved, improving the deployment flexibility of business logic. Second, by having the host runtime environment listen to the communication port to receive network requests from clients and write the network request data to the shared storage area of ​​the WebAssembly module, network I / O and business logic are decoupled, preventing the WebAssembly module from directly accessing network resources and improving operational security. Third, by having the host runtime environment call the request handling function exported by the WebAssembly module, the Web framework logic within the module reads data from the shared storage area, performs business processing, generates response data, and writes it back to the shared storage area, achieving standardized interaction between the host and the module, enabling the Web framework in the isolated environment to process business logic normally. Finally, by having the host runtime environment read response data from the shared storage area and return it to the client via the communication port, with the host providing unified external responses, the stability of network request processing can be improved.

[0100] To implement the request processing method provided in this disclosure, this disclosure also provides a request processing apparatus, such as... Figure 4 As shown. Figure 4 This is a schematic diagram of a request processing apparatus provided in an embodiment of the present disclosure. The request processing apparatus 400 includes: The acquisition unit 401 is used to acquire the WebAssembly file generated by compiling the source code containing Web framework logic, and instantiate the WebAssembly file in the host runtime environment to generate a WebAssembly module; The writing unit 402 is used to listen to the communication port of the host runtime environment to receive network requests from the client, and write the data of the network request to the shared storage area of ​​the WebAssembly module; The processing unit 403 is used to call the request processing function exported by the WebAssembly module by the host runtime environment, trigger the Web framework logic in the WebAssembly module to read the data in the shared storage area, perform business processing based on the read data, generate response data and write it to the shared storage area; The return unit 404 is used to read the response data from the shared storage area by the host runtime environment and return it to the client through the communication port.

[0101] In one embodiment, the acquisition unit 401 is specifically used for: Obtain the source code containing the web framework logic; Modify the program entry logic in the source code; The modified source code is used to compile and generate a WebAssembly file.

[0102] In one embodiment, the acquisition unit 401 is specifically used for: Delete the target code segment from the source code and define a request handling function and an initialization function. The target code segment is a program statement used to start network listening to receive external requests. The initialization function is used to build a Web framework instance and register a route mapping table.

[0103] In one embodiment, the writing unit 402 is specifically used for: Extract the request metadata and request payload data of the network request; According to the preset memory layout rules, the request metadata and the request payload data are serialized to obtain the serialized data corresponding to the network request; The serialized data is written to the shared storage area of ​​the WebAssembly module.

[0104] In one embodiment, the processing unit 403 is specifically used for: Get the starting position and offset length of the data in the shared storage area; The host runtime environment calls the request processing function exported by the WebAssembly module, triggering the Web framework logic within the WebAssembly module to read data from the shared storage area based on the starting position and offset length.

[0105] In one embodiment, the return unit 404 is specifically used for: The read data is reorganized into an internal request object, which is data that the Web framework can process; Perform business processing based on the internal request object to generate response data corresponding to the network request; The response data is written to the shared storage area.

[0106] It should be noted that the request processing apparatus provided in the above embodiments is only illustrated by the division of the above program modules. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the request processing apparatus can be divided into different program modules to complete all or part of the processing described above. In addition, the request processing apparatus provided in the above embodiments and the request processing method embodiments provided in this disclosure belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0107] Figure 5 This is a schematic diagram of the hardware composition structure of the electronic device provided in the embodiments of this disclosure, such as... Figure 5 As shown, the electronic device 500 includes at least one processor 502; and a memory 501 communicatively connected to the at least one processor 502; wherein the memory 501 stores instructions executable by the at least one processor 502, the instructions being executed by the at least one processor 502 to implement the steps of the request processing method of the present disclosure embodiments.

[0108] Optionally, the electronic device may specifically be a request processing device in the embodiments of this application, and the electronic device may implement the corresponding processes implemented by the request processing device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0109] It is understood that the electronic device also includes a communication interface 503. Various components in the electronic device are coupled together via a bus system 504. It is understood that the bus system 504 is used to implement communication between these components. In addition to a data bus, the bus system 504 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 5 The general designated all buses as Bus System 504.

[0110] It is understood that memory 501 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 501 described in this embodiment of the invention is intended to include, but is not limited to, these and any other suitable types of memory.

[0111] The methods disclosed in the above embodiments can be applied to or implemented by processor 502. Processor 502 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 502 or by instructions in software form. Processor 502 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 502 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, specifically memory 501. Processor 502 reads information from memory 501 and, in conjunction with its hardware, completes the steps of the aforementioned methods.

[0112] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), FPGAs, general-purpose processors, controllers, MCUs, microprocessors, or other electronic components to perform the aforementioned method.

[0113] This disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the steps of the request processing method of the embodiments of the present invention.

[0114] Optionally, the computer-readable storage medium can be applied to the request processing apparatus in the embodiments of this application, and the computer instructions cause the computer to execute the corresponding processes implemented by the request processing apparatus in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0115] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the request processing method provided in this embodiment of the invention.

[0116] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and 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. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0117] The units described above as separate components may or may not be physically separate. 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 the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0118] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0119] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0120] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0121] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A request processing method characterized by comprising: include: Obtain the WebAssembly file generated by compiling the source code containing the Web framework logic, and instantiate the WebAssembly file in the host runtime environment to generate a WebAssembly module; The host runtime environment listens to the communication port to receive network requests from clients and writes the data of the network requests to the shared storage area of ​​the WebAssembly module; The host runtime environment calls the request processing function exported by the WebAssembly module, triggering the Web framework logic within the WebAssembly module to read data from the shared storage area, perform business processing based on the read data, generate response data, and write it to the shared storage area. The host runtime environment reads the response data from the shared storage area and returns it to the client through the communication port.

2. The method of claim 1, wherein, The process of obtaining the WebAssembly file generated by compiling the source code containing the Web framework logic includes: Obtain the source code containing the web framework logic; Modify the program entry logic in the source code; The modified source code is used to compile and generate a WebAssembly file.

3. The method of claim 2, wherein, The modification of the program entry logic in the source code includes: Delete the target code segment from the source code and define a request handling function and an initialization function. The target code segment is a program statement used to start network listening to receive external requests. The initialization function is used to build a Web framework instance and register a route mapping table.

4. The method of claim 1, wherein, The step of writing the data of the network request to the shared storage area of ​​the WebAssembly module includes: Extract the request metadata and request payload data of the network request; According to the preset memory layout rules, the request metadata and the request payload data are serialized to obtain the serialized data corresponding to the network request; The serialized data is written to the shared storage area of ​​the WebAssembly module.

5. The method of claim 1, wherein, The process of the host runtime environment calling the request handling function exported by the WebAssembly module to trigger the Web framework logic within the WebAssembly module to read data from the shared storage area includes: Get the starting position and offset length of the data in the shared storage area; The host runtime environment calls the request processing function exported by the WebAssembly module, triggering the Web framework logic within the WebAssembly module to read data from the shared storage area based on the starting position and offset length.

6. The method of claim 1, wherein, The step of processing the read data, generating response data, and writing it to the shared storage area includes: The read data is reorganized into an internal request object, which is data that the Web framework can process; Perform business processing based on the internal request object to generate response data corresponding to the network request; The response data is written to the shared storage area.

7. A request processing apparatus characterized by comprising: include: The acquisition unit is used to acquire the WebAssembly file generated by compiling the source code containing the Web framework logic, and instantiate the WebAssembly file in the host runtime environment to generate a WebAssembly module; The writing unit is used to listen to the communication port of the host runtime environment to receive network requests from the client, and write the data of the network request to the shared storage area of ​​the WebAssembly module; The processing unit is used to call the request processing function exported by the WebAssembly module by the host runtime environment, trigger the Web framework logic in the WebAssembly module to read the data in the shared storage area, perform business processing based on the read data, generate response data and write it to the shared storage area; The return unit is used to read the response data from the shared storage area by the host runtime environment and return it to the client through the communication port.

8. An electronic device, comprising: include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.

Images