Gateway request processing method and device based on Vert.x and Dubbo, and medium

Abstract

The embodiment of the invention discloses a gateway request processing method and device based on Vert.x and Dubbo and a medium, belongs to the technical field of gateway construction, and solves the problems that in a high-concurrency scene, the number of concurrent connections of a single server of a gateway is difficult to effectively increase, and end-to-end delay is increased. Comprising the following steps: constructing an HTTP server as a communication entrance based on a Vert.x framework, receiving an HTTP request, and analyzing a message into a reference key value pair format based on a message format corresponding to the HTTP request; querying a local routing cache according to the request path, and determining a target Dubbo service and metadata corresponding to the path; based on the metadata of the target Dubbo service, asynchronously calling the message in the reference key value pair format to the target Dubbo service through a Dubbo generalization calling interface, and receiving an asynchronous return result; and converting the asynchronous return result into an HTTP response, and returning the HTTP response to the client through the HTTP server.

Description

Technical Field

[0001] This application relates to the field of gateway construction technology, and in particular to a gateway request processing method, device and medium based on Vert.x and Dubbo. Background Technology

[0002] With the widespread adoption of distributed and microservice architectures, systems are being broken down into multiple independently deployed service units. The gateway, as the service entry point, undertakes core responsibilities such as routing, access control, and traffic management, and is a critical infrastructure component of microservice architectures.

[0003] Existing gateway technologies are mainly divided into two categories: HTTP-based forwarding gateways and RPC (Remote Procedure Call)-based gateways. HTTP-based forwarding gateways forward requests via HTTP, which suffers from high serialization overhead, weak concurrency capabilities, and high response latency. While RPC-based gateways offer improved performance, they typically require strong coupling with specific RPC frameworks, lacking versatility and flexibility.

[0004] In high-concurrency scenarios, existing gateways typically use thread pools to handle requests. When the number of concurrent connections increases, the limited thread resources are quickly exhausted, causing requests to queue and making it difficult to effectively increase the number of concurrent connections per server. At the same time, during the protocol conversion process, the HTTP request body needs to be completely deserialized into an internal object and then serialized into the target protocol. This process not only consumes a lot of CPU resources but also generates huge memory overhead and garbage collection pressure, leading to increased response latency. Summary of the Invention

[0005] This application provides a gateway request processing method, device, and medium based on Vert.x and Dubbo to solve the following technical problems: In high-concurrency scenarios, existing gateways often experience request queuing, making it difficult to effectively increase the number of concurrent connections on a single server. Furthermore, during protocol conversion, multiple serialization / deserialization operations are required, leading to increased end-to-end latency.

[0006] The embodiments of this application adopt the following technical solutions: This application provides a gateway request processing method based on Vert.x and Dubbo. It includes: building an HTTP server based on the Vert.x framework as the communication entry point; receiving HTTP requests; determining the message format corresponding to the HTTP request; parsing the message into a reference key-value pair format based on the message format; querying the local routing cache according to the HTTP request path to determine the target Dubbo service and its metadata corresponding to the path; wherein the local routing cache is synchronized with the service routing information registered by the Dubbo service provider at startup by monitoring the configuration center; based on the metadata of the target Dubbo service, asynchronously calling the reference key-value pair format message to the target Dubbo service through the Dubbo generic call interface, and receiving the asynchronous return result; converting the asynchronous return result into an HTTP response and returning it to the client through the HTTP server.

[0007] In one implementation of this application, the message format corresponding to the HTTP request is determined, and the message is parsed into a reference key-value pair format based on the message format. Specifically, this includes: during the HTTP request reception process, extracting the header byte sequence features of the received request body data block, and extracting the Content-Type field value features that have been fully received in the HTTP request header; combining the header byte sequence features and field value features into a feature vector, and matching it with a predefined format rule library; wherein the format rule library sets a mapping relationship between the feature vector and the message format; determining the message format based on the matching result, and calling the corresponding target parser based on the message format; before the request body data block is fully received, preloading the target parser into memory so that when the remaining request body data is received, the data is input into the target parser for parsing to obtain the reference key-value pair format.

[0008] In one implementation of this application, before querying the local route cache based on the HTTP request path, the method further includes: determining the corresponding HTTP request information based on the preset annotations on the methods of the Dubbo service provider; wherein the request information includes at least one of the following: request path, method name, and interface name; when the Dubbo service starts, it registers metadata containing the request path and Dubbo service interface information with the Nacos configuration center; the gateway synchronizes the route information to the local route cache in real time by subscribing to the route information publishing channel of the Nacos configuration center.

[0009] In one implementation of this application, a Dubbo generic call interface is used to asynchronously call a key-value pair formatted message to the target Dubbo service and receive the asynchronous return result. Specifically, this includes: initiating a Dubbo generic call through the event loop thread of Vert.x and using the obtained CompletableFuture object as an asynchronous handle; encapsulating the task based on the CompletableFuture object and submitting the encapsulated task to an independent business thread pool for response processing; and after obtaining the result in the independent thread pool, submitting the result to the event loop thread through the asynchronous callback mechanism of Vert.x.

[0010] In one implementation of this application, before asynchronously invoking the target Dubbo service with a reference key-value pair format message, the method further includes: obtaining a preset traffic identifier parameter in the HTTP request header; setting the traffic identifier parameter in the Dubbo RPC context during the asynchronous call; and routing the request to the target Dubbo service provider whose service node label matches the traffic identifier parameter based on the traffic identifier parameter in the RPC context through Dubbo's tag routing mechanism; wherein the traffic identifier parameter is the X-User-Tag field in the HTTP header, and the value includes greyUser for identifying grayscale users and newUser for identifying newly registered users.

[0011] In one implementation of this application, before querying the local route cache based on the HTTP request path, the method further includes building and updating the local route cache. Specifically, this includes: obtaining a Dubbo service instance from the service registry and calling the metadata endpoint corresponding to the Dubbo service instance to obtain service metadata; dynamically generating a call adapter for calling the corresponding Dubbo service based on the obtained service metadata; wherein the call adapter corresponds to the Dubbo interface method signature, and the call adapter maps HTTP parameters to the method parameters required for Dubbo generic calls; mapping the HTTP request path to the call adapter and the target service address, and storing it in a pre-set in-memory routing table; when the metadata of the Dubbo service changes, re-obtaining the metadata and updating the corresponding call adapter and in-memory routing table to achieve hot updating of routing information.

[0012] In one implementation of this application, before asynchronously invoking the target Dubbo service with a reference key-value pair format message, the method further includes: using the received HTTP request body as the raw byte stream and determining the structured data boundary corresponding to the HTTP request body; determining the offset information of the parameter value positions in the raw byte stream based on the structured data boundary, and dynamically generating a call adapter; when initiating a Dubbo call, extracting byte fragments from the raw byte buffer of the HTTP request body according to the offset information, and assembling them into a serialization format that conforms to the Dubbo protocol requirements; and pre-calculating and caching the offset information of interfaces with call frequencies greater than a preset frequency threshold according to the interface call frequency.

[0013] In one implementation of this application, byte fragments are extracted from the original byte buffer of the HTTP request body based on offset information and assembled into a serialization format conforming to the Dubbo protocol requirements. Specifically, this includes: generating a byte map based on offset information; wherein the byte map describes the starting position, length, and data type of the values ​​corresponding to each call parameter of the target Dubbo service in the original byte buffer; based on the byte map, logically reorganizing the discrete parameter value byte fragments in the original byte buffer into a virtual data packet conforming to the Dubbo call parameter order; the serializer generates a complete protocol frame header according to the format specification of the target Dubbo protocol, and simultaneously establishes a logical positional mapping relationship from the HTTP request parameters to the parameter part of the Dubbo protocol frame based on the logical order of the parameter values ​​in the virtual data packet; based on the logical positional mapping relationship, the corresponding parameter value byte fragments in the original byte buffer of the HTTP request body are filled into the parameter part of the Dubbo protocol frame to obtain a serialization format conforming to the Dubbo protocol requirements.

[0014] This application provides a gateway request processing device based on Vert.x and Dubbo, including: 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, which, when executed by the at least one processor, enable the at least one processor to: build an HTTP server based on the Vert.x framework as a communication entry point, receive HTTP requests, determine the message format corresponding to the HTTP request, and parse the message into a reference key-value pair format based on the message format; query the local routing cache according to the path of the HTTP request to determine the target Dubbo service and metadata corresponding to the path; wherein the local routing cache is synchronized with the service routing information registered by the Dubbo service provider at startup through a monitoring configuration center; based on the metadata of the target Dubbo service, asynchronously call the reference key-value pair format message to the target Dubbo service through the Dubbo generic call interface, and receive the asynchronous return result; convert the asynchronous return result into an HTTP response and return it to the client through the HTTP server.

[0015] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: construct an HTTP server based on the Vert.x framework as a communication entry point; receive HTTP requests; determine the message format corresponding to the HTTP request; parse the message into a reference key-value pair format based on the message format; query the local routing cache according to the HTTP request path to determine the target Dubbo service and its metadata corresponding to the path; wherein the local routing cache is synchronized with the service routing information registered by the Dubbo service provider during startup by monitoring the configuration center; based on the metadata of the target Dubbo service, asynchronously call the reference key-value pair format message to the target Dubbo service through the Dubbo generic call interface and receive the asynchronous return result; convert the asynchronous return result into an HTTP response and return it to the client through the HTTP server.

[0016] The above-mentioned technical solutions adopted in this application embodiment can achieve the following beneficial effects: The HTTP server built on Vert.x in this application embodiment lays the foundation for high-concurrency processing, and the intelligent message recognition mechanism ensures accurate and efficient parsing of multi-format requests, improving the compatibility and processing efficiency of the gateway. Secondly, by listening to the configuration center to achieve dynamic synchronization of routing information, the local routing cache can be updated in real time, ensuring the accuracy and agility of service discovery. In addition, this application embodiment utilizes the Dubbo generic calling interface, combined with the asynchronous non-blocking characteristics of Vert.x, to transform the traditional synchronous service call into an asynchronous process. This not only completely releases the I / O thread and avoids resource blocking, but also minimizes response latency through deep collaboration between the event loop and the independent thread pool. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A gateway architecture diagram based on Vert.x and Dubbo is provided for embodiments of this application; Figure 2 A protocol conversion flowchart provided for an embodiment of this application; Figure 3 A flowchart of a gateway request processing method based on Vert.x and Dubbo provided for embodiments of this application; Figure 4 This is a schematic diagram of a gateway request processing flow provided in an embodiment of this application; Figure 5 This application provides a service call diagram as an embodiment of the present application. Figure 6 This is a schematic diagram of the structure of a gateway request processing device based on Vert.x and Dubbo, provided in an embodiment of this application.

[0018] Figure label: 200: Gateway request processing device based on Vert.x and Dubbo; 201: Processor; 202: Memory. Detailed Implementation

[0019] This application provides a gateway request processing method, device, and medium based on Vert.x and Dubbo.

[0020] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0021] Figure 1 A gateway architecture diagram based on Vert.x and Dubbo is provided for embodiments of this application, as follows: Figure 1 As shown, the gateway based on Vert.x and Dubbo includes a client, a Vert.x and Dubbo gateway cluster, a management backend, a Vert.x distributed event bus, a configuration management module, and a Dubbo registry center.

[0022] In this architecture, the client, acting as the request initiator, sends HTTP requests to the Vert.x and Dubbo gateway cluster. Within the gateway cluster, communication and state synchronization between nodes are achieved through the Vert.x distributed event bus, and routing information is dynamically obtained by interacting with the Dubbo registry center through the configuration management module. The management backend is used for centralized control of gateway configurations, routing rules, and plugin policies. This overall architecture achieves efficient processing and traffic scheduling for high-concurrency requests through event-driven and asynchronous collaboration mechanisms.

[0023] The gateway architecture based on Vert.x and Dubbo in this embodiment consists of a Vert.x HTTP server, a Dubbo generic invocation module, a gateway route synchronization module, a chain of responsibility plugin module, and a route registration module. The Vert.x HTTP server serves as the core communication entry point, handling HTTP / WebSocket requests based on a multi-Reactor pattern. Each CPU core maintains an independent event loop, supporting 5000 concurrent connections. The Dubbo generic invocation module implements HTTP-to-RPC protocol conversion based on the Dubbo SDK, dynamically invoking any Dubbo service without relying on service interface JAR packages. Generic functions invoke the corresponding Dubbo service using the full interface path, interface name, method name, and parameters; parameters of type map are automatically mapped to Dubbo service Bean parameters. The gateway route synchronization module is implemented based on Nacos data push, with the gateway listening to specified Nacos data. The `dataId` corresponds to the routing data of the Dubbo service. It dynamically matches routing rules based on the request path and parameters, and distributes the request to different Dubbo services. The chain of responsibility plugin module adopts the Vert.x asynchronous chain of responsibility pattern, integrating authentication, circuit breaking, rate limiting, and other plugins to handle requests without blocking. The route registration module is implemented based on Spring annotations. The business implementation methods of the Dubbo service register the request path, request parameters, method name, and interface name corresponding to the method by adding the `DubboPost` annotation to the method interface. These parameters are uniformly encapsulated as system metadata and written to Nacos.

[0024] Figure 2 A protocol conversion flowchart is provided for an embodiment of this application, such as Figure 2 As shown, the client's HTTP request is first received by the Vert.x event loop, and then the request parameters are parsed asynchronously. After parsing, a Dubbo generic call is initiated, which calls the backend service via RPC. After the service completes its processing, the result is returned asynchronously, and finally, the gateway responds to the client. The entire process adopts an asynchronous non-blocking architecture to achieve efficient request processing.

[0025] Figure 3 This document provides a flowchart of a gateway request processing method based on Vert.x and Dubbo, as illustrated in an embodiment of this application. Figure 3 As shown, the gateway request processing method based on Vert.x and Dubbo includes the following steps: Step 101: Build an HTTP server based on the Vert.x framework as the communication entry point, receive HTTP requests, determine the message format corresponding to the HTTP request, and parse the message into a reference key-value pair format based on the message format.

[0026] In one implementation of this application, during the HTTP request reception process, the header byte sequence features of the received request body data block are extracted, as are the features of the Content-Type field value features that have been fully received in the HTTP request header. The header byte sequence features and field value features are combined into a feature vector, which is then matched against a predefined format rule library; wherein the format rule library sets a mapping relationship between feature vectors and message formats. The message format is determined based on the matching result, and the corresponding target parser is called based on the message format. Before the request body data block is fully received, the target parser is preloaded into memory so that when the remaining request body data is received, the data is input to the target parser for parsing to obtain a reference key-value pair format.

[0027] Specifically, upon receiving the HTTP request body, the system does not wait for the entire request body to be transmitted completely, but instead initiates a parallel analysis process. That is, it reads the header byte sequence of the received data block and quickly scans it for structural characters that indicate type, such as square brackets or angle brackets. Simultaneously, it parses the fully received HTTP header to accurately extract the value of the Content-Type field. For example, it scans the header byte sequence of the received request body data block to identify whether it contains a left curly brace or left square bracket used to identify JSON format, and a left angle bracket or XML declaration header used to identify XML format. Next, it accurately extracts the complete value of the Content-Type field from the fully received HTTP request header, such as application / json or text / xml.

[0028] The extracted header byte sequence features are combined with the Content-Type field value features to form a multi-dimensional feature vector, which is then input into a predefined format rule base for matching queries. This format rule base is essentially a mapping table, in which the correspondence between different feature vector combinations and target message formats is predefined. By querying this rule base, the most matching message format type, such as JSON, XML, or form format, is determined based on the current feature vector, and the target parser to be invoked is decided accordingly.

[0029] Before the HTTP request body is fully received, the corresponding target parser instance is preloaded into memory. For example, if the request is determined to be in JSON format, the Jackson parser is preloaded; if it is determined to be in XML format, the Dom4j parser is preloaded. This preloading operation ensures that parsing resources are ready in advance, preparing for subsequent streaming parsing. As the remaining data blocks of the request body arrive, the data is directly input into the preloaded target parser. The parser parses the input data in a streaming manner, gradually converting it into a structured key-value pair model. Finally, reference key-value pair format data is obtained, which is consistent with the parameter structure of the Dubbo service interface, providing directly usable parameter input for subsequent generalized calls.

[0030] It should be noted that the Vert.x in this embodiment is an event-driven asynchronous non-blocking framework that adopts a multi-Reactor pattern to support the development of distributed applications with high concurrency and low resource consumption. The multi-Reactor pattern means that each CPU core independently maintains an event loop, fully utilizing multi-core resources and improving concurrent processing capabilities. This embodiment addresses the poor compatibility issues caused by traditional gateways' single message format support by designing a unified parsing scheme for multi-format messages based on Vert.x.

[0031] Step 102: Based on the path of the HTTP request, query the local route cache to determine the target Dubbo service and metadata corresponding to the path.

[0032] In one implementation of this application, the local route cache is first constructed and updated. Specifically, this includes: obtaining a Dubbo service instance from the service registry and calling the metadata endpoint corresponding to the Dubbo service instance to obtain service metadata. Based on the obtained service metadata, a call adapter for invoking the corresponding Dubbo service is dynamically generated; wherein the call adapter corresponds to the Dubbo interface method signature, and the call adapter maps HTTP parameters to the method parameters required for Dubbo generic invocation. The path of the HTTP request is mapped to the call adapter and the target service address, and stored in a pre-set in-memory routing table. When the metadata of the Dubbo service changes, the metadata is re-obtained and the corresponding call adapter and in-memory routing table are updated to achieve hot updating of routing information.

[0033] Specifically, the gateway first queries the service registry to obtain a list of all registered Dubbo service instances. For each discovered service instance, the gateway retrieves detailed service metadata by calling its corresponding metadata endpoint (such as HTTP interface / metadata). This metadata includes all Dubbo interfaces provided by the service, method signatures, and corresponding HTTP path mapping information. After obtaining the Dubbo service metadata, the gateway dynamically generates a corresponding invocation adapter at runtime based on this information. This adapter is a lightweight invocation stub that encapsulates the logic for mapping HTTP request parameters to the method parameters required for Dubbo generic invocation. It precisely corresponds to the method signature of the target Dubbo interface, realizing the conversion between protocol and parameters.

[0034] Furthermore, the gateway uses the HTTP request path as the key and the dynamically generated invocation adapter and the service's target address in the registry as the value to construct a mapping relationship, which is then stored in a pre-built in-memory routing table. This in-memory routing table acts as a high-speed route cache for the gateway, enabling fast route lookups during request processing. When the metadata of a Dubbo service provider changes, the service provider re-registers with the registry or updates its metadata. The gateway can detect such metadata changes by listening for service change events in the registry or by periodically polling. When the gateway detects a metadata change, it re-fetches the latest metadata, dynamically generates or updates the corresponding invocation adapter, and immediately updates the relevant mapping entries in the in-memory routing table. This is accomplished without downtime of the gateway, achieving hot updates of routing information and ensuring real-time consistency between the gateway's routing state and the actual state of the backend services.

[0035] In one implementation of this application, the local route cache synchronizes with the service route information registered by the Dubbo service provider at startup by monitoring the configuration center. Specifically, based on the preset annotations on the methods of the Dubbo service provider, the corresponding HTTP request information is determined; wherein the request information includes at least one of the following: request path, method name, and interface name. When the Dubbo service starts, it registers metadata containing the request path and Dubbo service interface information with the Nacos configuration center. The gateway synchronizes the route information to the local route cache in real time by subscribing to the route information publishing channel of the Nacos configuration center.

[0036] Specifically, in the business methods of the Dubbo service provider, developers declare their corresponding HTTP access paths by adding preset annotations. When the Dubbo service provider starts, its built-in annotation scanning component automatically collects information such as the HTTP request paths, corresponding Dubbo service interface names, and method names defined in these annotations, thereby forming structured service metadata.

[0037] When a Dubbo service provider starts up, its built-in registration module automatically encapsulates the collected service metadata into a specific data model and proactively calls the Nacos configuration center's client interface to register it under the namespace and data identifier specified by the Nacos configuration center, thereby completing the publication of service metadata in the registration center. The Nacos configuration center is responsible for maintaining the registered routing information and, when its content changes, proactively pushes the latest full routing data to all gateway instances that have subscribed to that data identifier through a publish-subscribe mechanism.

[0038] After receiving the pushed data, the gateway's internal routing synchronization component immediately parses the data and updates it to the local memory routing cache, thereby ensuring that the routing information of all gateway nodes remains consistent with the real state of the backend service in real time.

[0039] Upon receiving an HTTP request, the gateway's routing component first extracts the complete access path from the request. Then, using this path as a key index, the component initiates a query request to its local in-memory routing cache to find the backend service information bound to that path. Upon receiving the query request, the local routing cache performs a matching search in its internally stored routing mapping table. This cache stores routing rules synchronized from the registry center, each rule associating an HTTP path pattern with the metadata of a target Dubbo service. If a completely matching path is found, the corresponding target Dubbo service identifier and its complete metadata information, including the interface name, method name, and parameter types, are returned. The gateway's routing component obtains the query results returned by the local routing cache. If a target Dubbo service and its metadata are successfully matched, this metadata information is passed to the subsequent protocol conversion and invocation module, preparing for initiating a Dubbo generic call. If no routing rule is matched, the process is immediately terminated, and an error response indicating that the path does not exist is returned to the client.

[0040] Step 103: Based on the metadata of the target Dubbo service, asynchronously call the target Dubbo service with a reference key-value pair format message through the Dubbo generic call interface, and receive the asynchronous return result.

[0041] In one implementation of this application, a Dubbo generic call is initiated through the event loop thread of Vert.x, and the obtained CompletableFuture object is used as an asynchronous handle. The task is encapsulated based on the CompletableFuture object, and the encapsulated task is submitted to an independent business thread pool for response processing. After obtaining the result in the independent thread pool, the result is submitted to the event loop thread through the asynchronous callback mechanism of Vert.x.

[0042] To address the issues of request blocking and resource waste, this application optimizes the asynchronous communication link. Specifically, after an HTTP request enters the gateway, the Vert.x event loop thread is used only for request reception and result return. The Dubbo interface call returns an asynchronous result, a CompletableFuture, which is then handled by an independent thread pool, thus preventing the Vert.x event loop thread from blocking.

[0043] Specifically, Vert.x's event loop thread initiates a remote service call through the Dubbo generic invocation interface based on the determined target Dubbo service metadata. This call immediately returns a CompletableFuture object as an asynchronous handle representing the expected future result. During this process, the event loop thread itself is not blocked and can continue processing other I / O events. After obtaining the CompletableFuture object, the event loop thread encapsulates it along with necessary context information into an asynchronous task unit. After encapsulation, the event loop thread submits this task to a dedicated business thread pool for handling blocking or time-consuming operations, thereby delegating the work of waiting for RPC responses and ensuring that it can continuously and efficiently respond to new network requests.

[0044] Furthermore, after a worker thread in the independent business thread pool takes over the asynchronous task, it calls methods such as `get` of `CompletableFuture` to wait for the Dubbo service provider to return the actual result. Once the result or exception is obtained, the worker thread does not directly process the response. Instead, it uses the asynchronous callback mechanism provided by Vert.x to return the result or exception signal to the event loop thread that initially received the request. The initial event loop thread, after receiving the result from the business thread pool in the callback function, executes subsequent response assembly logic, such as converting the result into an HTTP response format and returning the final response to the client via a network connection. This ensures that all I / O operations are always handled by a specific event loop thread, guaranteeing the consistency and efficiency of the thread model.

[0045] In one implementation of this application, before asynchronously invoking the target Dubbo service with a reference key-value pair format message, a preset traffic identifier parameter is obtained from the HTTP request header. During the asynchronous call, the traffic identifier parameter is set in the Dubbo RPC context. Based on the traffic identifier parameter in the RPC context, the request is routed to the target Dubbo service provider whose service node label matches the traffic identifier parameter through Dubbo's tag routing mechanism. The traffic identifier parameter is the X-User-Tag field in the HTTP header, and its value includes greyUser for identifying grey-scale users and newUser for identifying newly registered users.

[0046] Specifically, after receiving an HTTP request, the gateway's traffic identification component first extracts a pre-defined traffic identifier parameter from the HTTP request header. Specifically, this component searches for and retrieves the value of the header field named X-User-Tag, such as greyUser or newUser. This parameter will serve as the basis for subsequent precise traffic routing. When the gateway prepares to initiate a Dubbo generic call, its routing processing component sets the traffic identifier parameter extracted in the first step into the DubboRPC context of the current thread. This operation binds the traffic identifier information to this RPC call, providing the necessary input conditions for subsequent tag routing.

[0047] When a gateway initiates a remote call via the Dubbo generic API, the Dubbo framework proactively retrieves a pre-defined traffic identifier parameter from the RPC context. Subsequently, Dubbo's built-in tag routing mechanism matches this parameter value with the tags of service provider instances in the registry, thus precisely routing the call to the target Dubbo service provider instance with the matching tag. The target Dubbo service provider instance has already defined its service tag (e.g., greyUser) at startup by setting the `-DDubbo.provider.tag` parameter. Therefore, only RPC requests carrying the matching tag can invoke this instance, achieving logical isolation between canary and official traffic, and enabling tag-based canary releases or new user redirection scenarios. New users are defined as users who registered within the past month; to optimize the new user experience, new user traffic is routed to a separate Dubbo service deployment machine. For example, when the gateway initiates a Dubbo call, it carries a tag to match the service node tag in the registry. When the Dubbo canary service starts, the startup parameter -DDubbo.provider.tag=greyUser is added, and when the Dubbo new user service starts, the startup parameter -DDubbo.provider.tag=newUser is added. In this way, only requests with tags can call the service with the corresponding tag.

[0048] In one implementation of this application, to eliminate unnecessary memory copying and object creation overhead during protocol conversion by the gateway, thereby improving performance and reducing latency, this embodiment also uses the received HTTP request body as the raw byte stream and determines the structured data boundary corresponding to the HTTP request body. Based on the structured data boundary, the offset information of the parameter value positions in the raw byte stream is determined, and a call adapter is dynamically generated. When initiating a Dubbo call, byte fragments are extracted from the raw byte buffer of the HTTP request body according to the offset information and assembled into a serialization format that conforms to the Dubbo protocol requirements. Based on the interface call frequency, the offset information of interfaces with a frequency greater than a preset threshold is pre-calculated and cached.

[0049] Specifically, the gateway processes the received HTTP request body as a raw byte stream. The gateway's parsing component scans this byte stream, identifying specific syntax boundary symbols, such as curly braces and quotation marks in JSON format, or angle brackets in XML format, to determine the start and end positions of each parameter name and value, thereby accurately obtaining the offset information of the parameter values ​​within the byte stream. Based on the parameter value offset information obtained in the first step, the gateway dynamically generates a dedicated call adapter at runtime. This call adapter does not contain the actual parameter value data, but rather encapsulates the logical rules for quickly locating and extracting the corresponding parameter values ​​from the raw byte stream based on the offsets; its structure corresponds to the method signature of the target Dubbo service interface.

[0050] Furthermore, when a Dubbo call is initiated, the operation is performed according to the offset rules defined in the call adapter. By accessing the raw byte buffer of the HTTP request body, the byte fragments corresponding to each parameter value are extracted based on the offset information. These byte fragments are then assembled with the protocol header information into a serialized data frame according to the format specifications of the target Dubbo protocol, ready for network transmission. The gateway continuously monitors the call frequency of each interface. For interfaces with a call frequency exceeding a preset threshold, the gateway pre-calculates their parameter offset information and related protocol assembly rules, and caches the calculation results. When subsequent requests for the same high-frequency interface arrive again, the gateway can directly use the cached optimized path for processing, thereby saving the overhead of real-time calculation and accelerating request processing.

[0051] In one implementation of this application, byte fragments are extracted from the original byte buffer of the HTTP request body based on offset information and assembled into a serialization format conforming to the Dubbo protocol requirements. Specifically, this includes: generating a byte map based on the offset information; wherein the byte map describes the starting position, length, and data type of the values ​​corresponding to each call parameter of the target Dubbo service in the original byte buffer; based on the byte map, the discrete parameter value byte fragments in the original byte buffer are logically reorganized into a virtual data packet conforming to the Dubbo call parameter order. The serializer generates a complete protocol frame header according to the format specification of the target Dubbo protocol. Simultaneously, based on the logical order of the parameter values ​​in the virtual data packet, a logical positional mapping relationship is established from the HTTP request parameters to the parameter part of the Dubbo protocol frame. Based on this logical positional mapping relationship, the corresponding parameter value byte fragments from the original byte buffer of the HTTP request body are filled into the parameter part of the Dubbo protocol frame to obtain a serialization format conforming to the Dubbo protocol requirements.

[0052] Specifically, the gateway generates a byte map based on parameter boundary information identified from the raw byte stream of the HTTP request body. This byte map, as metadata, describes the starting position, length, and data type of the value corresponding to each call parameter of the target Dubbo service in the raw byte buffer. For example, a string parameter starts at byte 102 and has a length of 36 bytes. The gateway then uses this byte map to logically reorganize the originally discretely distributed parameter value byte fragments in the raw byte buffer. That is, according to the parameter order of the Dubbo service interface method, a virtual data packet conforming to its call specification is constructed, thereby completing the logical mapping from the HTTP message structure to the Dubbo call parameter list. This application embodiment also includes a serializer, which is a software component for implementing zero-copy protocol conversion. Its function is to convert data in memory into a byte sequence that can be transmitted over the network according to a specific binary protocol specification, or to perform the reverse operation. The serializer extracts data fragments from the raw byte buffer by offset and directly assembles them into a target protocol data frame. This serializer is dynamically instantiated by the gateway according to the protocol type required by the target Dubbo service interface. Specifically, the gateway maintains a serializer factory that supports multiple protocols. When it is determined to call a Dubbo service, the gateway obtains a corresponding serializer instance from the factory, which is dedicated to this call, based on the protocol information registered in its metadata.

[0053] The serializer first generates the header of the protocol frame according to the format specification of the target Dubbo protocol. This header contains fixed information such as the protocol version and request ID. After generating the protocol header frame, the serializer works based on the formed virtual data packet. Following the guidance in the byte map, it directly extracts byte fragments corresponding to the parameter values ​​from the raw byte buffer of the HTTP request body and fills these fragments into the parameter part of the Dubbo protocol frame in sequence, finally assembling a complete serialized data frame that conforms to the Dubbo protocol requirements for network transmission.

[0054] Step 104: Convert the asynchronous return result into an HTTP response and return it to the client via an HTTP server.

[0055] In one implementation of this application, the Vert.x event loop thread receives the asynchronous return result from the Dubbo service, processed by an independent business thread pool, via an asynchronous callback mechanism. Upon receiving the result, the event loop thread first restores the original HTTP context information corresponding to the request, preparing for the generation of an HTTP response. The gateway's response processing component converts the raw result data returned by the Dubbo service into a standard HTTP response format. This component serializes the result data into a JSON string or other client-supported message format according to predefined rules and sets the corresponding HTTP response header fields such as Content-Type. The Vert.x HTTP server receives the formatted response data, encapsulates it into a complete HTTP response message, including a status code, response headers, and a response body. Subsequently, the server returns the final generated HTTP response data to the requesting client through the established original network connection, completing the entire service call process.

[0056] This application provides a gateway request processing device based on Vert.x and Dubbo, including: 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, which, when executed by the at least one processor, enable the at least one processor to: build an HTTP server based on the Vert.x framework as a communication entry point, receive HTTP requests, determine the message format corresponding to the HTTP request, and parse the message into a reference key-value pair format based on the message format; query the local routing cache according to the path of the HTTP request to determine the target Dubbo service and metadata corresponding to the path; wherein the local routing cache is synchronized with the service routing information registered by the Dubbo service provider at startup through a monitoring configuration center; based on the metadata of the target Dubbo service, asynchronously call the reference key-value pair format message to the target Dubbo service through the Dubbo generic call interface, and receive the asynchronous return result; convert the asynchronous return result into an HTTP response and return it to the client through the HTTP server.

[0057] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: construct an HTTP server based on the Vert.x framework as a communication entry point; receive HTTP requests; determine the message format corresponding to the HTTP request; parse the message into a reference key-value pair format based on the message format; query the local routing cache according to the HTTP request path to determine the target Dubbo service and its metadata corresponding to the path; wherein the local routing cache is synchronized with the service routing information registered by the Dubbo service provider during startup by monitoring the configuration center; based on the metadata of the target Dubbo service, asynchronously call the reference key-value pair format message to the target Dubbo service through the Dubbo generic call interface and receive the asynchronous return result; convert the asynchronous return result into an HTTP response and return it to the client through the HTTP server.

[0058] Figure 4 This is a schematic diagram of a gateway request processing flow provided in an embodiment of this application, such as... Figure 4 As shown, after the Dubbo service module starts, its two internal Dubbo business services first register by calling the gateway service registration interface. Subsequently, the gateway service calls the metadata management Dubbo service, which stores the metadata in the DB database and simultaneously publishes it to the Nacos registry. Finally, the gateway service retrieves information from the management service through its service discovery interface and pushes it to the service listeners, thus completing the entire service metadata registration and publication process.

[0059] Figure 5 This application provides a service call illustration, such as... Figure 5 As shown, when a service call begins, it enters the gateway module, sequentially going through Sentinel rate limiting, parameter parsing, path matching, RPC call, and response processing. During the RPC call phase, it interacts with the service implementation module via Dubbo generic calls. This module contains the Service implementation, business logic, and MyBatis Plus components. Simultaneously, the service implementation module registers the service with the Nacos registry center via Dubbo registration, completing the service registration and discovery process.

[0060] Figure 6 This is a schematic diagram illustrating the structure of a gateway request processing device based on Vert.x and Dubbo, provided as an embodiment of this application. Figure 6As shown, a gateway request processing device 200 based on Vert.x and Dubbo includes: at least one processor 201; and a memory 202 communicatively connected to the at least one processor 201. The memory 202 stores instructions executable by the at least one processor 201, which, when executed, enable the at least one processor 201 to: build an HTTP server based on the Vert.x framework as a communication entry point, receive HTTP requests, determine the message format corresponding to the HTTP request, and parse the message into a reference key-value pair format; query the local routing cache according to the path of the HTTP request to determine the target Dubbo service and its metadata corresponding to the path; wherein the local routing cache is synchronized with the service routing information registered by the Dubbo service provider at startup through a monitoring configuration center; based on the metadata of the target Dubbo service, asynchronously call the reference key-value pair format message to the target Dubbo service through the Dubbo generic call interface, and receive the asynchronous return result; convert the asynchronous return result into an HTTP response and return it to the client through the HTTP server.

[0061] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: construct an HTTP server based on the Vert.x framework as a communication entry point; receive HTTP requests; determine the message format corresponding to the HTTP request; parse the message into a reference key-value pair format based on the message format; query the local routing cache according to the HTTP request path to determine the target Dubbo service and its metadata corresponding to the path; wherein the local routing cache is synchronized with the service routing information registered by the Dubbo service provider during startup by monitoring the configuration center; based on the metadata of the target Dubbo service, asynchronously call the reference key-value pair format message to the target Dubbo service through the Dubbo generic call interface and receive the asynchronous return result; convert the asynchronous return result into an HTTP response and return it to the client through the HTTP server.

[0062] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0063] The above descriptions are merely embodiments of this application and are not intended to limit the scope of this application. For those skilled in the art, various modifications and variations can be made to the embodiments of this application. These modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions in the embodiments of this application.

Claims

1. A Vert.x and Dubbo-based gateway request processing method, characterized in that, The method comprises: The method comprises: Based on the Vert.x framework, an HTTP server is built as a communication portal to receive an HTTP request, determine a message format corresponding to the HTTP request, and parse a message into a reference key-value pair format based on the message format; According to the path of the HTTP request, a local routing cache is queried to determine the target Dubbo service and metadata corresponding to the path; wherein the local routing cache is synchronized with service routing information registered by the Dubbo service provider when starting by listening to the configuration center; Based on the metadata of the target Dubbo service, the message in the reference key-value pair format is asynchronously called to the target Dubbo service through a Dubbo generalized calling interface, and an asynchronous return result is received; 2. The Vert.x and Dubbo-based gateway request processing method according to claim 1, characterized in that, The asynchronous return result is converted into an HTTP response and returned to the client through the HTTP server. The method comprises: During the HTTP request receiving process, the first byte sequence feature of the received request body data block is extracted, and the Content-Type field value feature in the HTTP request header that has been completely received is extracted; The first byte sequence feature and the field value feature are combined into a feature vector, which is matched with a predefined format rule library; wherein the format rule library is provided with a mapping relationship between the feature vector and the message format; Based on the matching result, the message format is determined, and the corresponding target parser is called based on the message format; 3. The Vert.x and Dubbo-based gateway request processing method according to claim 1, characterized in that, Before the request body data block receiving is completed, the target parser is preloaded into the memory, so that when the remaining data of the request body is received, the data is input into the target parser for parsing to obtain the reference key-value pair format. Before the local routing cache is queried according to the path of the HTTP request, the method further comprises: Based on the preset annotation corresponding to the method of the Dubbo service provider, the corresponding HTTP request information is determined; wherein the request information at least includes one of the request path, the method name and the interface name; When the Dubbo service starts, the metadata containing the request path and the Dubbo service interface information is registered to the Nacos configuration center; 4. The Vert.x and Dubbo-based gateway request processing method according to claim 1, characterized in that, The gateway synchronizes the routing information to the local routing cache in real time by subscribing to the routing information publishing channel of the Nacos configuration center. The method comprises: Through the event loop thread of Vert.x, Dubbo generalized calling is initiated, and the obtained CompletableFuture object is used as an asynchronous handle; Based on the CompletableFuture object, the task is encapsulated, and the encapsulated task is submitted to an independent business thread pool for response processing; After the result is obtained in the independent thread pool, the result is submitted to the event loop thread through the asynchronous callback mechanism of Vert.x.

5. The Vert.x and Dubbo-based gateway request processing method according to claim 1, characterized in that, Before the message in the reference key-value pair format is asynchronously called to the target Dubbo service, the method further comprises: In the HTTP request header, a preset traffic identification parameter is obtained; When performing asynchronous calling, the traffic identification parameter is set to the RPC context of Dubbo; Based on the traffic identification parameter in the RPC context, the request is routed to the target Dubbo service provider whose service node label matches the traffic identification parameter through the label routing mechanism of Dubbo. The traffic identification parameter is an X-User-Tag field in the HTTP header, and the value includes greyUser for identifying gray users and newUser for identifying new registered users.

6. The Vert.x and Dubbo-based gateway request processing method according to claim 1, characterized in that, Before the local routing cache is queried according to the path of the HTTP request, the method further comprises updating and constructing the local routing cache, specifically including: Obtaining a Dubbo service instance in a service registry center and calling a metadata endpoint corresponding to the Dubbo service instance to obtain service metadata; Based on the obtained service metadata, an invocation adapter for calling the corresponding Dubbo service is dynamically generated; wherein the invocation adapter corresponds to the Dubbo interface method signature, and the invocation adapter maps the HTTP parameters to the method parameters required by the Dubbo generalized call; Map the path of the HTTP request with the invocation adapter and the target service address, and store it in the preset memory routing table. When the metadata of the Dubbo service changes, the metadata is reacquired and the corresponding invocation adapter and memory routing table are updated to realize hot updating of routing information.

7. The Vert.x and Dubbo-based gateway request processing method according to claim 1, characterized in that, Before the message in the reference key-value pair format is asynchronously called to the target Dubbo service, the method further comprises: The received HTTP request body is taken as an original byte stream, and the structured data boundary corresponding to the HTTP request body is determined; Based on the structured data boundary, the offset information of the parameter value position in the original byte stream is determined, A calling adapter is dynamically generated; When initiating Dubbo calling, according to the offset information, a byte segment is extracted from the original byte buffer of the HTTP request body and assembled into a serialized format conforming to the requirements of Dubbo protocol; According to the interface calling frequency, the offset information of the interface greater than the preset frequency threshold is precalculated and cached.

8. The Vert.x and Dubbo-based gateway request processing method of claim 7, wherein, According to the offset information, a byte segment is extracted from the original byte buffer of the HTTP request body and assembled into a serialized format conforming to the requirements of Dubbo protocol, specifically including: Based on the offset information, a byte map is generated; wherein the byte map is used to describe the starting position, length and data type of the value corresponding to each calling parameter of the target Dubbo service in the original byte buffer. Based on the byte map, the discrete parameter value byte segments in the original byte buffer are logically reorganized into a virtual data packet conforming to the Dubbo call parameter order; The serializer generates a complete protocol frame header according to the format specification of the target Dubbo protocol, and establishes a logical position mapping relationship from the HTTP request parameters to the parameter part of the Dubbo protocol frame based on the logical order of the parameter values in the virtual data packet; Based on the logical position mapping relationship, the corresponding parameter value byte segments in the HTTP request body original byte buffer are filled into the parameter part of the Dubbo protocol frame to obtain a serialized format conforming to the Dubbo protocol requirements.

9. A Vert.x and Dubbo based gateway request processing device, characterized in that, The device comprises a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to execute the method of any one of claims 1-8.

10. A non-transitory computer storage medium storing computer-executable instructions, the computer-executable instructions comprising instructions for: receiving a request to access a file; determining whether the file is stored in a cache; and in response to determining that the file is stored in the cache, providing access to the file from the cache. The computer executable instructions can execute the method of any one of claims 1-8.

Images