Cross-protocol compatible invoking method, device, equipment and storage medium
By configuring a web container and servlet interface for the gRPC service, direct invocation of the gRPC service from the web server is enabled, solving the high overhead problem of inter-system invocation and communication, reducing development costs, and improving system compatibility and flexibility.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA CONSTRUCTION BANK
- Filing Date
- 2023-07-04
- Publication Date
- 2026-06-05
AI Technical Summary
Calls and communications between heterogeneous systems require additional gateway components due to the use of different service frameworks and communication protocols, which increases network overhead and development costs.
By configuring a web container for the gRPC service and configuring a servlet interface and servlet facade class for the web container, direct invocation of the gRPC service within the web server can be achieved, avoiding the need for additional gateway components.
It reduces the overhead and development cost of inter-system calls, improves system compatibility and flexibility, and supports cross-language and cross-platform communication.
Smart Images
Figure CN116708526B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a cross-protocol compatible invocation method, apparatus, device and storage medium. Background Technology
[0002] Google Remote Procedure Call (gRPC) and Hypertext Transfer Protocol (HTTP) are two different protocols. HTTP is a simple request-response protocol, while gRPC provides a lightweight and seamless way to communicate across processes. gRPC uses HTTP as its transport protocol to transfer data.
[0003] In recent years, due to the development of cloud computing technology, there are many scenarios where gRPC and HTTP are used in combination, especially between services with high performance and latency requirements or large data transmission volumes. Typically, the technology selection tends to use gRPC as the internal communication protocol for Internet Data Centers (IECs), while HTTP is used for external interfaces or interfaces with lower performance requirements. However, due to the booming development of open-source software, many organizations modify open-source software to reduce development costs while adhering to protocols. They usually only support one protocol, either gRPC or HTTP. Heterogeneous systems using different service frameworks and communication protocols make inter-service calls and communication a challenge.
[0004] Currently, the solution to the above-mentioned calls and communication between heterogeneous systems is to implement it through an additional gateway component. However, this requires additional network overhead, has high development costs, and also indirectly increases operation and maintenance costs. Summary of the Invention
[0005] This application provides a cross-protocol compatible calling method, apparatus, device, and storage medium, which reduces the overhead and development cost of calling between heterogeneous systems.
[0006] In a first aspect, this application provides a cross-protocol compatible invocation method, comprising: configuring a web container for a gRPC service and configuring a servlet interface for the web container, wherein the servlet interface is used to perform message conversion between the gRPC service and the web server; configuring a servlet facade class for the web container, wherein the servlet facade class includes a startup binding facade class; and starting the gRPC service through the servlet facade class.
[0007] Secondly, this application provides a cross-protocol compatible invocation device, comprising: an interface configuration module for configuring a web container for a gRPC service and configuring a servlet interface for the web container, wherein the servlet interface is used for message conversion between the gRPC service and the web server; a class configuration module for configuring a servlet facade class for the web container, wherein the servlet facade class includes a startup binding facade class; and a service startup module for starting the gRPC service through the servlet facade class.
[0008] This application provides a method, apparatus, device, and storage medium for cross-protocol compatible invocation. By configuring a web container for the gRPC service, configuring a servlet interface for the web container, and configuring a servlet facade class for the web container, including a startup binding facade class, the gRPC service can be started through the servlet facade class. This allows the web server to directly call the gRPC service through the web container without the need for additional gateway components, thereby reducing overhead and development difficulty. Attached Figure Description
[0009] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0010] Figure 1 The flow of the cross-protocol compatible invocation method provided in the embodiments of this application Figure 1 ;
[0011] Figure 2 The flow of the cross-protocol compatible invocation method provided in the embodiments of this application Figure 2 ;
[0012] Figure 3 This is a schematic diagram of the structure of a cross-protocol compatible invocation device provided in an embodiment of this application;
[0013] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0014] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0015] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. The acquisition, storage, use, and processing of data in the technical solutions of this application all comply with the relevant provisions of national laws and regulations.
[0016] gRPC and HTTP are two different protocols, and they have some important differences.
[0017] From a transport protocol perspective, gRPC uses the HTTP / 2 protocol to transmit data, while HTTP typically uses HTTP / 1.1 or HTTP / 2. HTTP / 2 is the next-generation protocol of HTTP, supporting features such as multiplexing and flow control, making data transmission more efficient.
[0018] From a serialization protocol perspective, gRPC uses Protocol Buffers as its default serialization protocol, which is an efficient binary serialization protocol. HTTP, on the other hand, typically uses text-based serialization protocols such as JSON or XML, which handle larger amounts of data and have lower transmission efficiency.
[0019] From a service definition perspective, gRPC uses an Interface Definition Language (IDL) to define services. IDL can be used to generate client and server code in different programming languages, providing a more standardized and regulated interface definition. HTTP, on the other hand, typically uses RESTful APIs to define services. While RESTful APIs offer more flexibility in interface definition, they lack standardization.
[0020] From an error handling perspective, gRPC uses status codes and status messages to identify error types. These error codes and messages are predefined, helping developers locate problems more quickly. HTTP, on the other hand, typically uses HTTP status codes and error messages to identify error types. These error codes and messages lack a unified standard, requiring developers to parse them themselves.
[0021] From a performance perspective, gRPC typically offers higher performance and lower network overhead than HTTP because it uses the HTTP / 2 protocol and Protocol Buffers serialization protocol.
[0022] In recent years, due to the development of cloud computing technology, there are many scenarios where gRPC and HTTP are used in combination, especially between services with high performance and latency requirements or large data transmission volumes. Typically, the technology selection tends to use gRPC as the internal communication protocol for data centers, while external interfaces or interfaces with lower performance requirements use HTTP. However, due to the booming development of open-source software, many organizations modify open-source software to reduce development costs while adhering to protocols. They usually only support one protocol, either gRPC or HTTP. Heterogeneous systems using different service frameworks and communication protocols make inter-service calls and communication a challenge.
[0023] Currently, the problem of inter-system calls and communication composed of gRPC and HTTP is usually solved by additional gateway components, but this requires additional network overhead, has high development costs, increases deployment processes and technology, and indirectly increases operation and maintenance costs.
[0024] For example, a gateway-based heterogeneous system call method is as follows:
[0025] 1. The HTTP client initiates a REST API call. This call is usually a traditional HTTP 1.1 request. This request does not directly call the service, but instead calls the gateway.
[0026] 2. The gateway parses the protocol, queries the service address corresponding to the protocol, and converts the protocol to generate a new request body.
[0027] 3. The gateway calls the gRPC service, parses the returned gRPC response, converts it into a RESTful / JSON response, and returns it to the client.
[0028] While the above method enables calls between gPRC and HTTP by deploying an additional gateway component, it also incurs additional overhead.
[0029] Figure 1 The flow of the cross-protocol compatible invocation method provided in the embodiments of this application Figure 1 .like Figure 1 As shown, this cross-protocol compatible invocation method includes:
[0030] Step S110: Configure a web container for the gRPC service and configure a servlet interface for the web container. The servlet interface is used to perform message translation between the gRPC service and the web server.
[0031] The cross-protocol compatible invocation method of this embodiment can be applied to a web server where various services are developed based on a hybrid of gRPC and HTTP, i.e., a web server that combines gRPC and HTTP services. This web server can be deployed in the cloud or on a server within a network.
[0032] Since services developed based on gRPC use HTTP / 2 as their transport protocol, while some existing services are developed based on HTTP / 1.1, and some services with low latency or data transmission requirements are also developed based on HTTP / 1.1 to reduce development costs, it is necessary to solve the problem of deploying two services developed based on different protocols on the same web server. To avoid the additional overhead of deploying extra gateway components, this application proposes a cross-protocol compatible invocation method that enables mutual invocation of services developed based on different protocols without deploying any additional components.
[0033] The cross-protocol compatible invocation method proposed in this embodiment adopts a web container approach. By modifying the gRPC kernel, gRPC service messages can conform to the servlet specification and run within a web container. Since the gRPC protocol is based on HTTP / 2, the above method can be used to put gRPC services into a web container for execution. This allows the web server to support services developed based on HTTP / 1.1 as well as services developed based on gRPC through the web container.
[0034] To run a gRPC service within a web container, the first step is to configure the web container for the gRPC service and then configure the servlet interface for the web container. A web container, also known as a servlet container, is a component of a web server. It provides a runtime environment, implementing various interfaces and classes defined by the servlet specification to provide underlying support for servlet execution. It also manages user-written servlet classes, such as instantiation classes, method invocation classes, and destruction classes. A servlet is a small program running on a server. Its main function is to interactively browse and modify data and generate dynamic web content. The main functions of a servlet can be summarized as follows: 1. The client sends a request to the server; 2. The server sends the request information to the servlet; 3. The servlet generates the response content and sends it to the server. The response content is dynamically generated, usually depending on the client's request; 4. The server returns the response to the client. Therefore, the function of a servlet is very similar to that of a gateway component. Thus, after configuring the web container for the gRPC service, configuring the servlet interface for the web container is sufficient. As long as the servlet interface is configured to match the gRPC service, calls to the gRPC service can be made through the web container. The servlet interface configured for the web container is used to perform message translation between the gRPC service and the web server, that is, to convert the web server's HTTP requests and responses into gRPC requests and responses. The servlet interface acts as a gateway between the web server and the gRPC service. However, the servlet interface only needs to be configured with the appropriate interface translation methods within the web container configured for the gRPC service. After instantiating the configured web container, the instantiated web container will then have message translation capabilities.
[0035] In this way, the web server can directly call services developed using HTTP, and the web server can also call gRPC services through the web container without adding any additional components.
[0036] Furthermore, configuring the servlet interface for the web container includes configuring the `doPost` interface within the servlet. Configuring the web container and servlet interface for the gRPC service is equivalent to enabling gRPC to conform to the servlet specification and run within the web container; it's like wrapping the gRPC service in a servlet shell. One implementation is through the `doPost` interface in the servlet, configuring the `doPost` interface in the servlet for the web container. `doPost` is a method used by clients to send requests to the server. The `doPost` interface passes parameters through the request body, and `doPost` requests have no size limit. The parameters of a `doPost` request are included in the request body, offering relatively high security. Parameters in a `doPost` request are not cached, further enhancing security. Therefore, by configuring the `doPost` interface for the web container, it's possible to call the gRPC service within the web container with relatively high security. Specifically, the `doPost` interface is used to convert HTTP client servlet requests and responses into gRPC requests and responses. When the instantiated web container receives an HTTP POST request, it checks whether the request is a gRPC request. This can be done by checking if the Content-Type field in the request contains a gRPC service (application / grpc). If the received request is determined to be a gRPC request, the web container will convert the HTTP request into a gRPC request through the configured servlet interface and invoke the gRPC service within the web container. The gRPC service's response is also converted into an HTTP response through the servlet interface and returned to the requesting client on the web server.
[0037] Configuring a servlet interface for a web container allows you to delegate the doPost interface to a registered gRPC service implementation. This enables routing to the specific service name and the appropriate method call based on the request path.
[0038] Step S120: Configure a servlet facade class for the web container. The servlet facade class includes the startup binding facade class.
[0039] Furthermore, to enable calls to gRPC services through the web container, a servlet facade class needs to be configured for the web container used for the gRPC service. This servlet facade class includes a startup binding facade class. The servlet facade class is used to uniformly handle all services conforming to the servlet specification and proxies gRPC protocol requests to specific implementations. In other words, by configuring a servlet facade class including a startup binding facade class for the web container, it becomes clear that the web container is specifically designed for calls to gRPC services, thus facilitating calls to gRPC services through the web container.
[0040] Configure a servlet facade class for the web container. This involves first configuring the servlet facade class for the web container, which includes a startup binding facade class. Then, bind the gRPC service implementation started by the web container to the startup binding facade class. This binding allows these gRPC services located in the web container to be registered. The startup binding facade class can be a bootstrap class.
[0041] Step S130: Start the gRPC service through the servlet facade class.
[0042] After configuring a servlet facade class for the web container, the gRPC service can be started through this servlet facade class. Since the servlet facade class configured for the web container for the gRPC service includes a startup binding facade class, the startup binding facade class can directly locate the web container with the gRPC service, thus allowing the gRPC service in the web container to be run directly.
[0043] The method provided in this embodiment uses a web container and only configures the servlet interface and facade class. It does not require intrusive modification of the original gRPC service implementation, so the development cost is low and there is no need to redevelop the gRPC service.
[0044] Specifically, starting a gRPC service via a servlet facade class can be achieved by adding an instance of the servlet facade class to the web container context; then, the gRPC service can be started without going through the web container itself. In other words, by adding an instance of the servlet facade class configured for the web container to the web container context, it's possible to start the gRPC service directly within the web container after obtaining the web container context, or if the web container contains the gRPC service. For example, in Tomcat, the `Tomcat.addServlet` method can be used to add an instance of the servlet facade class to the container context.
[0045] The cross-protocol compatible invocation method provided in this embodiment configures a web container for the gRPC service, a servlet interface for the web container, and a servlet facade class for the web container. The servlet facade class includes a startup binding facade class, which allows the gRPC service to be started through the servlet facade class. This enables the web server to directly call the gRPC service through the web container without the need for additional gateway components, thereby reducing overhead and development difficulty.
[0046] Furthermore, by using the method described in the above embodiments to implement gRPC service calls through a web container, HTTP services can directly respond to calls from the web server. This means that without any additional components, the web server can implement mixed HTTP and gRPC service calls. In this case, for gRPC client service calls, the configured servlet interface calls the gRPC service in the web container; the web server responds to the gRPC service in the web container. In other words, both HTTP and gRPC calls can be supported simultaneously on the same service port. Additionally, both gRPC and HTTP protocols can be supported within a unified service.
[0047] In this embodiment, when the web container configured with the servlet interface is destroyed, the servlet interface and servlet facade class also need to be destroyed simultaneously.
[0048] Figure 2 The flow of the cross-protocol compatible invocation method provided in the embodiments of this application Figure 2 .like Figure 2 As shown, this cross-protocol compatible invocation method includes:
[0049] Step S210: Establish a listening stream, which listens to each frame received by the web server.
[0050] Step S220: Parse each received frame and put the parsed frame into the processing queue of the web server.
[0051] Step S230: Use the web server's service thread to process the frames in the queue in turn.
[0052] To enable calls to the gPRC service, for streaming transmission, a listening stream can be established. This listening stream listens for every frame received by the web server, parses each received frame, and puts the parsed frame into the web server's processing queue. Then, the web server's service thread processes the frames in the processing queue in turn.
[0053] The cross-protocol compatible calling method provided in this application enables gRPC to support traditional HTTP calls, which offers the following advantages:
[0054] Cross-language support: gRPC is a cross-language RPC framework, but some programming languages may not support the native gRPC protocol. By supporting HTTP / 1.1, gRPC can communicate with clients written in any programming language.
[0055] Compatibility: gRPC uses features of the HTTP / 2 protocol, such as multiplexing and binary data streaming. However, in some situations (e.g., low-bandwidth network environments), using HTTP / 2 may lead to performance degradation. Using HTTP / 1.1 ensures that gRPC can function correctly in any network environment and has broader compatibility.
[0056] Simplicity: HTTP / 1.1 is a widely used protocol that is simpler and easier to understand than HTTP / 2. By supporting HTTP / 1.1, gRPC can be more readily adopted and used by developers.
[0057] Transparency: Because HTTP / 1.1 is a standard protocol, gRPC can be deployed on most web servers and accessed using any HTTP client by supporting HTTP / 1.1. This makes gRPC deployment more flexible and transparent.
[0058] Cross-platform support: HTTP / 1.1 is a cross-platform protocol that can run on various operating systems and hardware platforms. By supporting HTTP / 1.1, gRPC can run across platforms without additional programming work.
[0059] Scalability: Running gRPC in a web container provides a foundation for scalability, which can be achieved using web interceptors and filters, including: access control, logging, encryption and decryption of requests and responses, encoding and decoding, performance monitoring, etc.
[0060] In summary, the cross-protocol compatible invocation method provided in this embodiment achieves superior performance with relatively low development costs.
[0061] Figure 3 This is a schematic diagram of the structure of a cross-protocol compatible invocation device provided in an embodiment of this application. Figure 3 As shown, the cross-protocol compatible calling device includes: an interface configuration module 310, a class configuration module 320, and a service startup module 330.
[0062] The interface configuration module 310 is used to configure the web container for the gPRC service and to configure the servlet interface for the web container.
[0063] Class configuration module 320 is used to configure servlet facade classes for the web container. The servlet facade classes include the startup binding facade class.
[0064] Service startup module 330 is used to start gRPC services through a servlet facade class.
[0065] In some embodiments, the interface configuration module 310 is specifically used to configure the doPost interface in the servlet for the web container.
[0066] In some embodiments, the interface configuration module 310 is specifically used to delegate the doPost interface to a registered gRPC service implementation.
[0067] In some embodiments, the class configuration module 320 is specifically used to configure a servlet facade class for a web container, the servlet facade class including a startup binding facade class; and to bind the gRPC service implementation started by the web container to the startup binding facade class.
[0068] In some embodiments, the startup binding facade class is the bootstrap class.
[0069] In some embodiments, the service startup interface configuration module 330 is specifically used to add a servlet facade class instance to the web container context; and to start the gRPC service without using the web container.
[0070] In some embodiments, for service calls made by HTTP clients, the web server directly responds to the call.
[0071] In some embodiments, for service calls made by gRPC clients, the gRPC service in the web container is invoked through the configured servlet interface; and the web server responds to the gRPC service in the web container.
[0072] In some embodiments, the cross-protocol compatible invocation apparatus further includes: a stream service module, configured to establish a listening stream, the listening stream listening to each frame received in the web server; parse each received frame and put the parsed frame into the processing queue of the web server; and process the frames in the processing queue sequentially using the service thread of the web server.
[0073] In some embodiments, the gRPC service transmits data based on the HTTP / 2 protocol.
[0074] In some embodiments, the web container supports the HTTP / 1.1 protocol.
[0075] The cross-protocol compatible invocation device provided in this application embodiment can be used to execute the technical solution of the cross-protocol compatible invocation method in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.
[0076] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, the interface configuration module 310, class configuration module 320, and service startup module 330 can all be separate processing elements, or they can be integrated into a chip in the above device. Alternatively, they can be stored as program code in the memory of the above device, and their functions can be called and executed by a processing element of the above device. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through the integrated logic circuits in the hardware of the processor element or through software instructions.
[0077] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device may include: transceiver 41, processor 42, and memory 43.
[0078] Processor 42 executes computer execution instructions stored in memory, causing processor 42 to perform the scheme in the above embodiments. Processor 42 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0079] The memory 43 is connected to the processor 42 via the system bus and completes communication between them. The memory 43 is used to store computer program instructions.
[0080] Transceiver 41 can be used to obtain the task to be run and its configuration information.
[0081] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.
[0082] The electronic device provided in this application embodiment can be a computer or server in the financial institution system described above.
[0083] This application also provides a chip for executing instructions, which is used to execute the technical solution of the cross-protocol compatible calling method in the above embodiments.
[0084] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the cross-protocol compatible invocation method described above.
[0085] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the cross-protocol compatible invocation method described in the above embodiments.
[0086] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.
[0087] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. A cross-protocol compatible invocation method, applied to a web server, characterized in that, include: Configure a web container for the gRPC service and configure a servlet interface for the web container. The servlet interface is used to perform message conversion between the gRPC service and the web server. Configure a servlet facade class for the web container, the servlet facade class including a startup binding facade class; The gRPC service is started using the servlet facade class. Starting the gRPC service through the servlet facade class includes: Add the instance of the servlet facade class to the web container context; The gRPC service is started without using the web container context.
2. The method according to claim 1, characterized in that, Configuring the servlet interface for the web container includes: Configure the doPost interface in the servlet for the web container. The doPost interface is used to convert HTTP client servlet requests and servlet responses into gRPC requests and gRPC responses.
3. The method according to claim 2, characterized in that, After configuring the doPost interface in the servlet for the web container, the process also includes: The doPost interface is delegated to a registered gRPC service implementation.
4. The method according to claim 1, characterized in that, Configuring the servlet facade class for the web container includes: Configure a servlet facade class for the web container, the servlet facade class including a startup binding facade class; The gRPC service started through the web container is bound to the startup binding facade class.
5. The method according to claim 4, characterized in that, The startup binding facade class is the bootstrap class.
6. The method according to any one of claims 1 to 5, characterized in that, For service calls made by HTTP clients, the web server responds directly to the call.
7. The method according to any one of claims 1 to 5, characterized in that, For service calls made by the gRPC client, the gRPC service in the web container is invoked through the configured servlet interface; Use a web server to respond to gRPC services in a web container.
8. The method according to any one of claims 1 to 5, characterized in that, Also includes: Establish a listening stream that listens for each frame received by the web server; Each received frame is parsed, and the parsed frame is placed into the processing queue of the web server; The service thread of the web server processes the frames in the queue to be processed in sequence.
9. The method according to any one of claims 1 to 5, characterized in that, The gRPC service transmits data based on the HTTP / 2 protocol.
10. The method according to any one of claims 1 to 5, characterized in that, The web container supports the HTTP / 1.1 protocol.
11. A cross-protocol compatible invocation device, applied to a web server, characterized in that, include: The interface configuration module is used to configure a web container for the gRPC service and a servlet interface for the web container. The servlet interface is used to perform message conversion between the gRPC service and the web server. The class configuration module is used to configure servlet facade classes for the web container, wherein the servlet facade classes include startup binding facade classes; The service startup module is used to start the gRPC service through the servlet facade class; The service startup module is specifically used to add the servlet facade class instance to the web container context; and to start the gRPC service through the web container context without going through the web container.
12. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-10.
13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-10.
14. 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-10.