A service request processing method and system based on a GRPC framework

Abstract

The embodiment of the application discloses a service request processing method and system based on a GRPC framework. The technical scheme provided by the embodiment of the application injects a predefined codec, and the codec is used for transparent transmission of a service request through communication of protocol data based on the GRPC framework and upper nodes and lower nodes. The service request of the upper node is received based on the codec, a URL address contained in the service request is determined, a target lower node is determined according to the URL address, and the service request is forwarded to the target lower node based on the codec. By injecting the predefined codec into the GRPC framework to replace the codec of the GRPC framework itself, it is ensured that the GRPC framework can normally receive and process the service request and forward the service request to the target lower node. In this way, the difficulty of the service request processing of the service gateway in the GRPC framework can be reduced, the service request processing efficiency can be optimized, and the network traffic management can be optimized.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a service request processing method and system based on the gRPC framework. Background Technology

[0002] Currently, in distributed backend service network architectures, a unified service gateway is set up to handle network service requests, serving functions such as permission verification, service rate limiting, and traffic distribution. The service gateway typically uses Nginx (an open-source, high-performance web server) as its entry point. To automate message routing, code is embedded in Nginx to implement the relevant business logic of the service gateway.

[0003] However, within the gRPC processing framework (Google's open-source, high-performance, cross-platform, multi-language remote procedure call service processing framework), the service gateway does not provide corresponding code to embed and implement its business logic because the embedded code is not developed based on the gRPC processing framework. Under the gRPC processing framework, the service gateway needs to maintain two sets of code. Processing network service requests based on this framework is complex, hinders maintenance and upgrades, and increases service costs. Summary of the Invention

[0004] This application provides a service request processing method and system based on the GRPC framework, which can reduce the difficulty of service request processing in the service gateway of the GRPC framework and solve the technical problem of high difficulty in service request processing of existing service gateways based on the GRPC framework.

[0005] In a first aspect, embodiments of this application provide a service request processing method based on the gRPC framework, comprising:

[0006] Inject predefined codecs, which are used to communicate protocol data based on the gRPC framework with upper and lower level nodes, and to transparently transmit service requests.

[0007] The codec receives service requests from the upper-level node, determines the URL address contained in the service request, and identifies the target lower-level node based on the URL address.

[0008] The service request is forwarded to the target lower-level node based on the codec.

[0009] In a second aspect, embodiments of this application provide a service request processing system based on the gRPC framework, comprising:

[0010] The injection module is used to inject predefined codecs. These codecs are used to communicate protocol data based on the gRPC framework with upper and lower level nodes, enabling transparent transmission of service requests.

[0011] The decoding module is used to receive service requests from the upper-level node based on the codec, determine the URL address contained in the service request, and determine the target lower-level node based on the URL address;

[0012] The forwarding module is used to forward service requests to the target lower-level node based on the codec.

[0013] In a third aspect, embodiments of this application provide an electronic device, including:

[0014] Memory and one or more processors;

[0015] The memory is used to store one or more programs;

[0016] When the one or more programs are executed by the one or more processors, the one or more processors implement the service request processing method based on the gRPC framework as described in the first aspect.

[0017] In a fourth aspect, embodiments of this application provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the service request processing method based on the gRPC framework as described in the first aspect.

[0018] This application embodiment injects a predefined codec. This codec is used to communicate protocol data with upper-level and lower-level nodes based on the gRPC framework, enabling transparent transmission of service requests. It receives service requests from upper-level nodes, determines the URL address contained in the service request, identifies the target lower-level node based on the URL address, and forwards the service request to the target lower-level node. By injecting a predefined codec into the gRPC framework to replace the framework's own codec, this ensures that the gRPC framework can correctly receive and process service requests and forward them to the target lower-level node. This reduces the difficulty of service request processing at the service gateway within the gRPC framework, optimizes service request processing efficiency, and improves network traffic management. Attached Figure Description

[0019] Figure 1 This is a flowchart of a service request processing method based on the gRPC framework provided in an embodiment of this application;

[0020] Figure 2 This is a flowchart of the service request processing of the service gateway in this application embodiment;

[0021] Figure 3 This is a schematic diagram of data forwarding of the service gateway in an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of the structure of a service request processing device based on the gRPC framework provided in an embodiment of this application;

[0023] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0025] This application provides a service request processing method based on the gRPC framework. It aims to replace the gRPC framework's own protocol data exchange format library by injecting predefined codecs into the gRPC framework, ensuring that the gRPC framework can correctly receive and process service requests and forward them to target downstream nodes. This achieves seamless service request processing by the service gateway based on the gRPC framework, eliminating the need for complex code configuration, improving service request processing efficiency, and reducing the difficulty of service request processing. Compared to traditional distributed backend network service architectures, which require a unified service gateway for functions such as permission verification, service rate limiting, and traffic distribution, the current approach uses nginx (an open-source high-performance web server) as the gateway entry point. However, nginx only allows manual configuration of downstream service routing and cannot automate data forwarding. Furthermore, it cannot monitor the liveness status of downstream services in real time, increasing operational complexity and the difficulty of network service provision. Another approach is to embed code within nginx to implement the relevant business logic of the service gateway. However, this couples the service gateway with nginx, hindering maintenance and upgrades. Therefore, in network service architectures, service gateways with strong business relevance are generally independent modules, separate from Nginx, to achieve decoupling. However, in the GRPC architecture (Google's open-source high-performance, cross-platform, multi-language remote procedure call service processing framework), since the embedded code is not developed based on the GRPC processing framework, the service gateway does not provide corresponding code to embed and implement the relevant business logic. Even if relevant code exists, if the technical team using the GRPC framework as their technology stack does not develop based on this code, the service gateway still needs to maintain two sets of code. Processing network service requests based on this service gateway is difficult, hindering its maintenance and upgrades, and increasing its service costs. Therefore, this application provides a service request processing method based on the GRPC framework to solve the technical problem of the high difficulty in processing service requests in existing GRPC-based service gateways.

[0026] Example:

[0027] Figure 1A flowchart of a service request processing method based on a gRPC framework according to an embodiment of this application is provided. This method can be executed by a service request processing device based on a gRPC framework. This device can be implemented in software and / or hardware, and can consist of two or more physical entities, or a single physical entity. Generally, this device can be executed by a service gateway within the gRPC framework.

[0028] The following description uses a service gateway device based on the gRPC framework as an example to illustrate the execution of the service request processing method based on the gRPC framework. (Refer to...) Figure 1 The service request processing method based on the gRPC framework specifically includes:

[0029] S110. Inject a predefined codec. The codec is used to communicate protocol data with upper and lower level nodes based on the gRPC framework and to transparently transmit service requests.

[0030] This application embodiment injects predefined codecs into the service gateway within the gRPC framework, enabling the service gateway to become a general-purpose service gateway. As a general-purpose service gateway, it must possess functions such as service discovery, authorization verification, service rate limiting, and traffic distribution. To achieve generality, the data in the service request must be transparent to the service gateway; that is, the service gateway does not need to be aware of the specific content of the protocol. The service gateway can correctly discover the service request and perform normal decoding and forwarding.

[0031] In a network service architecture based on gRPC, network service requests mainly consist of three parts: the URL address, which identifies the specific backend service node that the request needs to reach; metadata, which stores the header information of the current service request, such as session and token, and is used for permission verification, service processing, etc.; and the specific request body (defined based on the protobuf protocol data exchange format tool library, which needs to be predefined during the compilation stage).

[0032] Since the default protocol of the gRPC framework is protobuf (a protocol data exchange format utility library), and the interface used is a URL, both must be defined in advance for the received service requests to be processed normally. Otherwise, a 404 error (URL not defined in advance) or a protobuf format error (protobuf not defined in advance) will be reported.

[0033] However, in a general gateway, the interface data structures of the upper-level and lower-level nodes cannot be known in advance, and the corresponding protobuf protocol code is not pre-injected during the compilation phase. Using the original service gateway directly, lacking the communication protocol of the upper-level nodes (such as the corresponding protobuf protocol code), makes it impossible to determine the service requests sent by the upper-level nodes, thus failing to achieve service discovery. It also cannot decode the service requests to obtain the URL address and determine the lower-level service node to which they should be forwarded.

[0034] Therefore, a protocol-agnostic mechanism is needed to make the request body of service requests in the gRPC framework transparent, while being able to decode information such as URL address and metadata normally, so that the service gateway can perform functions such as service discovery, permission verification, service rate limiting, and traffic distribution.

[0035] Based on this, embodiments of this application predefine a codec capable of implementing a protocol-agnostic mechanism. This codec can recognize service requests compiled using the corresponding protocol code from protobuf, enabling the service gateway to transparently transmit service requests. Transparent transmission of service requests means that the server gateway does not need to parse the specific content of the service request; it only needs to correctly receive the service request based on the protocol data and determine the URL address within it to transmit the service request according to the URL address.

[0036] When injecting predefined codecs into the service gateway, the predefined codecs are also injected through the protocol injection interface pre-built by the gRPC framework. It's understandable that in order for the service gateway to obtain the codec and replace its existing business processing logic with it to perform functions such as service discovery, permission verification, service rate limiting, and traffic distribution, a corresponding protocol injection interface needs to be set up to inject the codec protocol into the service gateway. The protocol injection interface is essentially the UnknownServiceHandler interface (unknown service handler interface). After the service gateway injects the codec based on this interface, it can use the codec to communicate with upper-level and lower-level nodes, forwarding service requests from upper-level nodes to lower-level nodes, thus implementing service request processing functionality.

[0037] By injecting a codec, a common library is implemented within the service gateway. This library integrates all the business functions of a traditional service gateway, such as service discovery, authorization verification, rate limiting, and traffic distribution. Furthermore, it is compatible with the gRPC framework, recognizing and processing service requests compiled using the gRPC-based protocol data exchange format library (protobuf). This reduces the complexity of network service request processing within the gRPC framework and optimizes network traffic service processing.

[0038] S120. Receive service requests from the upper-level node based on the codec, determine the URL address contained in the service request, and determine the target lower-level node based on the URL address.

[0039] Furthermore, referring to Figure 2 Based on the pre-injected codec of the service gateway, the codec runs synchronously when the service gateway is running, and uses the codec to receive service requests from the upper-level node.

[0040] It is understandable that the service gateway in this application will not be aware of the protobuf definitions between upstream and downstream nodes, nor does it need to concern itself with the specific request body content of service requests compiled based on the protobuf protocol. The service gateway only needs to forward the raw data correctly.

[0041] In order to correctly forward service requests, determine which backend service node (i.e., the next-level node) the current service request should be forwarded to, and how to process business-related data, the service gateway needs to decode the service request before processing it. Therefore, by running this codec, after service discovery of the service request, the service request is decoded based on the codec to obtain the URL address contained in the service request, and the URL address is processed based on the stream processor pre-built in the gRPC framework.

[0042] Specifically, prior to this, a stream processor is injected into the service gateway via the UnknownServiceHandler interface (unknown service handler interface). This stream processor enables the service gateway to extract and process any URL address. For an undefined URL address, a "not implemented" error message will be output.

[0043] URL processing typically involves segmenting the URL. Service requests are generally binary streams compiled based on the protobuf protocol. A URL typically consists of a basic URL containment pattern (or protocol), server name (or IP address), path, and filename, such as "protocol: / / authorization / path?query". The complete syntax of a standard Uniform Resource Identifier (URI) with the authorization component is "protocol: / / username:password@subdomain.domain.top-level-domain:port / directory / filename.filesuffix?parameter=value#flag". To facilitate identification of the different parts of a URL, it needs to be segmented.

[0044] Furthermore, based on the determined URL address, the lower-level node pointed to by the current URL address can be defined as the target lower-level node, thereby forwarding the service request to the target lower-level node.

[0045] Among them, a pre-built mapping relationship is queried based on the URL address, and the corresponding target sub-node is determined according to the queried mapping relationship. The mapping relationship is pre-built based on the URL address and the corresponding sub-node.

[0046] Understandably, after receiving a network request from the requester (i.e., the upstream node), the service gateway needs to find the correct address of the responder (i.e., the target downstream node) based on the URL address information in the service request. Only after the two establish a connection can the entire service request data packet be forwarded to the responder without loss.

[0047] After decoding the service request, the URL address in the service request is obtained through the MethodFromServerStream interface provided by the gRPC framework. Then, a pre-defined mapping relationship is queried, and based on the mapping relationship between the URL address and the IP address of the downstream node, the IP address corresponding to the target downstream node is found. In this way, the service request can be processed transparently, without needing to obtain its specific content, and the complete service request can be directly transmitted to the target downstream node.

[0048] The mapping relationship between URL address and lower-level node IP address can be achieved using any service registration and discovery mechanism. In this embodiment, etcd is used as the registration center for the mapping relationship between URL address and lower-level node IP address to construct the mapping relationship.

[0049] Optionally, embodiments of this application further involve decoding the service request using a codec to obtain the header information contained in the service request, and then performing permission verification on the service request based on the header information. It is understood that the service gateway pre-defines which nodes' service requests it will handle, and for service requests from upstream nodes, it needs to verify whether they have the necessary permissions. Therefore, embodiments of this application determine the header information by decoding the service request, thereby enabling permission verification of the service request based on the header information. There are many ways to perform permission verification based on header information; embodiments of this application do not impose fixed limitations on specific permission verification methods, and will not elaborate further here.

[0050] S130: Forward the service request to the target lower-level node based on the codec.

[0051] Finally, based on the identified target lower-level node's IP address, the service request can be sent to that target lower-level node's IP address using the codec, thus completing the forwarding of the service request.

[0052] Specifically, refer to Figure 3The service gateway pre-builds a first coroutine and a second coroutine. The first coroutine processes the forwarded data from the service gateway to the target lower-level node, while the second coroutine processes the data returned by the target lower-level node. During data forwarding, the pre-built first coroutine runs, forwarding service requests to the target lower-level node. The first coroutine is used to forward data to the corresponding lower-level node. The pre-built second coroutine is then used to receive data returned by the target lower-level node.

[0053] For example, such as Figure 3 As shown, if the target lower-level node of the current service request is determined to be lower-level node 1, then the service request is forwarded to lower-level node 1 through the first coroutine, and the second coroutine runs synchronously to receive the data returned by lower-level node 1. For example, the second coroutine listens for the response packet information returned by lower-level node 1 based on the service request reception status at a set listening period, so as to determine the current reception status of lower-level node 1 for the service request based on the response packet information.

[0054] Optionally, the service gateway in this embodiment also performs service rate limiting and traffic distribution functions of the current gRPC framework. The service gateway can determine the service request reception status and running status of the target lower-level nodes based on the response messages from the target lower-level nodes, and perform traffic scheduling for the target lower-level nodes. For example, lower-level nodes 1, 2, and 3 are respectively responsible for processing service requests within the routing field range of user ID tails 00-33, 34-66, and 67-99. Under normal circumstances, the service gateway forwards service requests corresponding to the tails of the IDs to the corresponding lower-level nodes for processing based on the aforementioned routing field ranges. When traffic scheduling is required, the stability and reliability of message forwarding processing are achieved by adjusting the field ranges handled by the lower-level nodes.

[0055] Specifically, if the service gateway determines that the target lower-level node is overloaded based on the response message, it narrows the field range corresponding to the target lower-level node and allocates the routing fields of the specified segments within the field range to other lower-level nodes. For example, if the response message determines that lower-level node 3 is overloaded, it is necessary to narrow the field range that lower-level node 3 is responsible for. The original ID tail number range "67-99" is adjusted to "67-88", and the ID tail number "89-99" is allocated to lower-level node 2, which has idle computing resources. Then, lower-level node 2 is responsible for processing messages with ID tail numbers "34-66" and "89-99".

[0056] If the service gateway determines that the target lower-level node is faulty based on the response message, it will reassign service requests for the field range corresponding to the target lower-level node to other lower-level nodes, instructing them to handle the service requests within that field range. For example, if the response message determines that lower-level node 3 is faulty, the field range for lower-level node 3, i.e., the D tail number range "67-99", needs to be reassigned to lower-level node 1 and / or lower-level node 2, so that lower-level node 1 and / or lower-level node 2 can process messages with ID tail numbers "67-99".

[0057] Optionally, by extracting the backup routing information contained in the service request, the backup routing node for the service request is determined from the remaining lower-level nodes based on the backup routing information, and the service request is sent to the backup routing node. Prior to this, backup routing nodes for messages with each field value are pre-specified. When the lower-level node for the corresponding routing field fails, the message can be processed through the backup routing node. For example, if lower-level node 3 fails, and the backup routing node for messages with the ID tail "67-88" is determined to be lower-level node 1, then this part of the message is forwarded to lower-level node 1 for processing. If the backup routing node for messages with the ID tail "89-99" is determined to be lower-level node 2, then this part of the message is forwarded to lower-level node 2 for processing.

[0058] Furthermore, the service gateway determines the computing resource status of the target lower-level node based on the response message and expands the field range corresponding to the target lower-level node according to the computing resource status. Understandably, for lower-level nodes with relatively idle computing resources, the field ranges handled by other heavily loaded nodes can be scheduled to the current target lower-level node to expand the field range corresponding to the target lower-level node. This ensures full utilization of the target lower-level node's computing resources, reduces the load pressure on other nodes, and optimizes the stability and efficiency of message processing.

[0059] This application embodiment configures the routing field range of each subordinate node based on the range of the routing field. The routing field range is divided according to the last digit of the user ID, where user IDs ending in 00-33 are assigned to subordinate node 1, 34-66 to subordinate node 2, and 67-99 to subordinate node 3. This allows for precise control of the traffic to subordinate nodes. When the capacity of a subordinate node changes, the traffic to that subordinate node can be adjusted by configuring the range of the last digit of the user ID, thus preventing the subordinate node from being overloaded or underloaded.

[0060] Optionally, the service gateway can also block traffic from specified downstream nodes with a single click. When encountering downstream node failures or other situations requiring downstream node traffic scheduling, it can quickly isolate the faulty downstream node and transfer its traffic to a backup downstream node, thus achieving disaster recovery. By transforming unreliable asynchronous messages into reliable synchronous messages without changing the ingress message format, the link service gateway can promptly perceive the message processing status and anomalies of downstream nodes, thereby isolating faulty nodes. This achieves service rate limiting and traffic distribution functions, improving the stability of business processing. Simultaneously, the service gateway possesses traffic routing and scheduling capabilities, enabling precise control of traffic allocation and further enhancing the stability and reliability of business processing. It should be noted that there are many scenarios for service rate limiting and traffic distribution in practical applications; the above are only some of the service rate limiting and traffic distribution scenarios provided in this application's embodiments, and will not be elaborated upon here.

[0061] As described above, by injecting predefined codecs, which are used to communicate protocol data with upper-level and lower-level nodes based on the gRPC framework, transparent transmission of service requests is achieved. The codecs receive service requests from upper-level nodes, determine the URL addresses contained in the service requests, identify the target lower-level nodes based on the URL addresses, and then forward the service requests to the target lower-level nodes. By employing these techniques, and replacing the gRPC framework's own protocol data exchange format toolkit with predefined codecs, the gRPC framework can be ensured to correctly receive and process service requests and forward them to the target lower-level nodes. This reduces the difficulty of service request processing at the service gateway within the gRPC framework, optimizes service request processing efficiency, and improves network traffic management.

[0062] Based on the above embodiments, Figure 4 This application provides a schematic diagram of the structure of a service request processing system based on the gRPC framework. (Reference) Figure 4 The service request processing system based on the GRPC framework provided in this embodiment specifically includes: an injection module 21, a decoding module 22, and a forwarding module 23.

[0063] Among them, the injection module 21 is used to inject a predefined codec, which is used to communicate with the upper and lower nodes based on the GPPC framework protocol data and to transparently transmit service requests.

[0064] Decoding module 22 is used to receive service requests from the upper-level node based on the codec, determine the URL address contained in the service request, and determine the target lower-level node based on the URL address;

[0065] Forwarding module 23 is used to forward service requests to the target lower-level node based on the codec.

[0066] Specifically, injection module 21 is used to inject predefined codecs through a protocol injection interface pre-built by the GRPC framework.

[0067] Specifically, the decoding module 22 is used to decode the service request based on the codec, obtain the URL address contained in the service request, and process the URL address based on the stream processor pre-built in the GRPC framework; query the pre-built mapping relationship based on the URL address, and determine the corresponding target lower-level node according to the queried mapping relationship. The mapping relationship is pre-built based on the URL address and the corresponding lower-level node.

[0068] The decoding module 22 is also used to decode the service request based on the codec, obtain the header information contained in the service request, and perform permission verification of the service request based on the header information.

[0069] The forwarding module 23 is specifically used to run a pre-built first coroutine, which forwards service requests to the target lower-level node. The first coroutine is used to forward data to the corresponding lower-level node.

[0070] Forwarding module 23 is also used to run a pre-built second coroutine, based on which data is received from the target lower-level node.

[0071] As described above, by injecting predefined codecs, which are used to communicate protocol data with upper-level and lower-level nodes based on the gRPC framework, transparent transmission of service requests is achieved. The codecs receive service requests from upper-level nodes, determine the URL addresses contained in the service requests, identify the target lower-level nodes based on the URL addresses, and then forward the service requests to the target lower-level nodes. By employing these techniques, and replacing the gRPC framework's own protocol data exchange format toolkit with predefined codecs, the gRPC framework can be ensured to correctly receive and process service requests and forward them to the target lower-level nodes. This reduces the difficulty of service request processing at the service gateway within the gRPC framework, optimizes service request processing efficiency, and improves network traffic management.

[0072] The service request processing system based on the GRPC framework provided in this application can be used to execute the service request processing method based on the GRPC framework provided in the above embodiments, and has corresponding functions and beneficial effects.

[0073] Based on the above practical examples, this application also provides an electronic device, referring to... Figure 5The electronic device includes a processor 31, a memory 32, a communication module 33, an input device 34, and an output device 35. The memory, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the service request processing method based on the GPRC framework described in any embodiment of this application (e.g., injection module, decoding module, and forwarding module in a GPRC framework-based service request processing system). The communication module 33 is used for data transmission. The processor 31 executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory, thereby implementing the aforementioned GPRC framework-based service request processing method. The input device 34 can be used to receive input digital or character information and generate key signal inputs related to user settings and function control of the device. The output device 35 may include a display device such as a screen. The electronic device provided above can be used to execute the GPRC framework-based service request processing method provided in the above embodiments, possessing corresponding functions and beneficial effects.

[0074] Based on the above embodiments, this application also provides a storage medium containing computer-executable instructions. When executed by a computer processor, these computer-executable instructions are used to perform a service request processing method based on a gRPC framework. The storage medium can be any type of memory device or storage device. Of course, the computer-executable instructions provided in this application are not limited to the gRPC-based service request processing method described above; they can also execute related operations within the gRPC-based service request processing method provided in any embodiment of this application.

[0075] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A service request processing method based on the gRPC framework, characterized in that, include: Inject a predefined codec, which is used to communicate protocol data with upper and lower level nodes based on the gRPC framework and to transparently transmit service requests; The codec receives the service request from the upper-level node, decodes the service request, obtains the URL address contained in the service request, processes the URL address based on the stream processor pre-built in the GRPC framework, segments the URL address, identifies the components of the URL address, and determines the target lower-level node based on the components of the URL address. Based on the codec, the service request is forwarded to the target lower-level node; The service request reception status and running status of the target lower-level node are determined based on the response message from the target lower-level node. Traffic scheduling of the target lower-level node is performed based on the service request reception status and the running status, including adjusting the routing field range configured by the target lower-level node, wherein the routing field range represents the range of ID tail numbers of the service requests handled by the target lower-level node.

2. The service request processing method based on the gRPC framework according to claim 1, characterized in that, The injected predefined codec includes: Predefined codecs are injected through the protocol injection interface pre-built in the GRPC framework.

3. The service request processing method based on the gRPC framework according to claim 1, characterized in that, The step of determining the target subordinate node based on the URL address includes: Based on the URL address, a pre-built mapping relationship is queried, and the corresponding target subordinate node is determined according to the queried mapping relationship. The mapping relationship is pre-built based on the URL address and the corresponding subordinate node.

4. The service request processing method based on the gRPC framework according to claim 1, characterized in that, The step of forwarding the service request to the target lower-level node based on the codec further includes: Run a pre-built first coroutine to forward the service request to the target lower-level node. The first coroutine is used to forward data to the corresponding lower-level node.

5. The service request processing method based on the gRPC framework according to claim 4, characterized in that, After forwarding the service request to the target lower-level node via the first coroutine, the process further includes: Run a pre-built second coroutine to receive data returned by the target lower-level node.

6. The service request processing method based on the gRPC framework according to claim 1, characterized in that, After receiving the service request from the upper-level node based on the codec, the process further includes: The service request is decoded using the codec to obtain the header information contained in the service request, and the permission verification of the service request is performed based on the header information.

7. A service request processing system based on the gRPC framework, characterized in that, include: The injection module is used to inject predefined codecs, which are used to communicate protocol data with upper and lower level nodes based on the gRPC framework and to transparently transmit service requests. The decoding module is used to receive service requests from upper-level nodes based on the codec, decode the service requests based on the codec, obtain the URL address contained in the service request, process the URL address based on the stream processor pre-built in the GRPC framework, segment the URL address, identify the components of the URL address, and determine the target lower-level node based on the components of the URL address. The forwarding module is used to forward the service request to the target lower-level node based on the codec; The service request reception status and running status of the target lower-level node are determined based on the response message from the target lower-level node. Traffic scheduling of the target lower-level node is performed based on the service request reception status and the running status, including adjusting the routing field range configured by the target lower-level node, wherein the routing field range represents the range of ID tail numbers of the service requests handled by the target lower-level node.

8. An electronic device, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the service request processing method based on the gRPC framework as described in any one of claims 1-6.

9. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the service request processing method based on the gRPC framework as described in any one of claims 1-6.

Images