Request processing method, device and equipment of internet gateway, and storage medium

Abstract

This application discloses a request processing method, apparatus, device, and storage medium for an Internet gateway, relating to the field of Internet communication technology. The request processing method for the Internet gateway includes: receiving an Internet access request initiated by a client and parsing it to obtain the request path; obtaining routing configuration rules and performing whitelist matching on the request path to obtain the corresponding target backend service; generating a conversion request corresponding to the Internet access request based on the protocol type of the Internet access request and the protocol type of the target backend service; forwarding the conversion request to the target backend service and receiving the returned response result. Because the protocol conversion is performed before forwarding the request, the protocol format of the conversion request issued by the processing device is consistent with the protocol format supported by the target backend service, eliminating the need for an additional independent TCP proxy layer and reducing the complexity of the system architecture and deployment costs.

Description

Technical Field

[0001] This application relates to the field of Internet communication technology, and in particular to a request processing method, apparatus, device and storage medium for Internet gateways. Background Technology

[0002] With the widespread adoption of microservice architecture, enterprise application systems are being broken down into numerous independent microservice modules, leading to increasingly complex communication and calls between systems. Application Programming Interface (API) gateways, as a core component of microservice architecture, serve as the gateway for external requests to enter the system. In high-concurrency production environments such as finance and the internet, the availability, security, and flexibility of API gateways directly determine the service quality and stability of the entire system.

[0003] Currently, most mainstream gateway solutions are built on open-source components such as Nginx reverse proxy or Spring Cloud Gateway. In complex gateway scenarios facing Internet traffic, solutions such as Nginx only support HTTP protocol forwarding. When a request needs to be forwarded to a TCP protocol backend, it lacks the ability to generate a corresponding format conversion request based on the request protocol and the target service protocol. Summary of the Invention

[0004] The main purpose of this application is to provide a request processing method, apparatus, device and storage medium for an Internet gateway, which aims to solve the technical problem that the single protocol support of existing solutions leads to increased system deployment complexity and operation and maintenance costs.

[0005] To achieve the above objectives, this application proposes a request processing method for an Internet gateway, the request processing method of which includes: Receive an internet access request initiated by the client and parse the request path of the internet access request; Obtain the routing configuration rules, and perform whitelist matching on the request path according to the routing configuration rules to obtain the target backend service corresponding to the Internet access request; A conversion request corresponding to the Internet access request is generated based on the protocol type of the Internet access request and the protocol type of the target backend service. The conversion request is forwarded to the target backend service, and the response result returned by the target backend service is received and then returned to the client.

[0006] In one embodiment, the step of performing whitelist matching on the request path according to routing configuration rules to obtain the target backend service corresponding to the Internet access request includes: Retrieve pre-stored routing configuration rules and a list of backend service paths; Determine the routing configuration rules corresponding to the Internet access request based on the request path; Based on the routing configuration rules, the request path is matched against the backend service path list to obtain the target backend service.

[0007] In one embodiment, the routing configuration rules include at least HTTP type routing rules and TCP type routing rules; The step of matching the request path against the backend service path list based on the routing configuration rules to obtain the target backend service includes: When the routing configuration rule is the HTTP type routing rule, the request path is matched with a path prefix in the backend service path list to obtain a target backend service that matches at least the path prefix of the request path. When the routing configuration rule is the TCP type routing rule, the request path is precisely matched in the backend service path list to obtain the target backend service that matches the request path.

[0008] In one embodiment, after the step of matching the request path against the backend service path list based on the routing configuration rules to obtain the target backend service, the method further includes: Determine whether the Internet access request carries a full-link grayscale identifier based on the request header of the Internet access request; When carrying the full-link grayscale identifier, query the list of available instances corresponding to the target backend service, and select the instance with grayscale label as the candidate instance from the list of available instances according to the full-link grayscale identifier; The target instance is selected from the candidate instances based on the load balancing strategy. Accordingly, the step of forwarding the conversion request to the target backend service, receiving the response result returned by the target backend service, and returning the response result to the client includes: The conversion request is forwarded to the network address and port corresponding to the target instance of the target backend service, and the response result returned by the target backend service is received and returned to the client.

[0009] In one embodiment, before the step of obtaining the routing configuration rules, the method further includes: Periodically read the database configuration table and load the full list of routing whitelist rules into the database configuration table; The routing configuration rules in the local memory cache will be updated according to the full routing whitelist rules; and... The full set of routing whitelist rules is serialized into a locally readable and writable file in a preset format.

[0010] In one embodiment, the step of obtaining routing configuration rules includes: If the query timeout of the database is greater than the preset time, the routing configuration rules are determined based on the local readable and writable file.

[0011] In one embodiment, after the step of determining routing configuration rules based on the local readable and writable file if the database query timeout is greater than a preset time, the method further includes: When the query timeout in the database exceeds a preset time, a probe query is sent to the database at an incrementing time interval; When the number of consecutive successful probe queries exceeds a preset number, the system reads the first full routing whitelist rule from the database, the second full routing whitelist rule from the local memory cache, and the third full routing whitelist rule from the local readable and writable file. The first full-list routing whitelist rule, the second full-list routing whitelist rule, and the third full-list routing whitelist rule are judged for difference type, and the database is backfilled according to the difference type.

[0012] Furthermore, to achieve the above objectives, this application also proposes a request processing apparatus for an Internet gateway, the request processing apparatus for the Internet gateway comprising: The request parsing module is used to receive internet access requests initiated by the client and parse the request path of the internet access request. The route matching module is used to obtain the route configuration rules and perform whitelist matching on the request path according to the route configuration rules to obtain the target backend service corresponding to the Internet access request. The request conversion module is used to generate a conversion request corresponding to the Internet access request based on the protocol type of the Internet access request and the protocol type of the target backend service. The request forwarding module is used to forward the conversion request to the target backend service, receive the response result returned by the target backend service, and return the response result to the client.

[0013] In addition, to achieve the above objectives, this application also proposes a request processing device for an Internet gateway, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the request processing method for the Internet gateway as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the request processing method of the Internet gateway as described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the request processing method for an Internet gateway as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application receives internet access requests initiated by clients and parses the request path to obtain the internet access request; acquires routing configuration rules and performs whitelist matching on the request path according to the routing configuration rules to obtain the target backend service corresponding to the internet access request; generates a conversion request corresponding to the internet access request based on the protocol type of the internet access request and the protocol type of the target backend service; forwards the conversion request to the target backend service, receives the response result returned by the target backend service, and returns the response result to the client. Because the protocol conversion is performed before forwarding the request, and the conversion request is generated based on the protocol type of the internet access request and the protocol type of the target backend service, the protocol format of the conversion request sent by the processing device is consistent with the protocol format supported by the target backend service. Compared with existing technologies that only support HTTP protocol forwarding and require the deployment of an independent TCP proxy layer when the backend service uses the TCP protocol, this solution can complete the conversion of HTTP protocol requests to TCP protocol requests within the same processing device, without the need for an additional independent TCP proxy layer, reducing the complexity of the system architecture and deployment costs. By identifying the target backend service through the correspondence between the request path and the routing configuration rules, and completing protocol conversion and forwarding within the same processing device, the gateway can simultaneously support the access of backend services of both Hypertext Transfer Protocol and Transmission Control Protocol, thus expanding the gateway's applicability and flexibility. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating an embodiment of the request processing method for an Internet gateway in this application. Figure 2 This is a schematic diagram of the gateway architecture in one implementation of the request processing method of the Internet gateway in this application; Figure 3 A flowchart illustrating the second embodiment of the request processing method for the Internet gateway in this application; Figure 4 A flowchart illustrating the request processing method for the Internet gateway in this application, as provided in Embodiment 3; Figure 5 This is a schematic diagram of the module structure of the request processing device of the Internet gateway in an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the request processing method of the Internet gateway in this embodiment of the application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of this application embodiment is as follows: receiving an Internet access request initiated by a client and parsing the request path of the Internet access request; obtaining routing configuration rules and performing whitelist matching on the request path according to the routing configuration rules to obtain the target backend service corresponding to the Internet access request; generating a conversion request corresponding to the Internet access request based on the protocol type of the Internet access request and the protocol type of the target backend service; forwarding the conversion request to the target backend service, receiving the response result returned by the target backend service, and returning the response result to the client.

[0024] This application provides a solution that, after obtaining routing configuration rules, performing whitelist matching on the request path, and determining the target backend service, does not directly forward the request according to the original protocol format. Instead, it first identifies the protocol type of the internet access request itself, and simultaneously identifies the protocol types supported by the matched target backend service. Then, based on the comparison result of the above two protocol types, a corresponding conversion request is generated. When the target backend service uses the TCP protocol, the processing device converts the HTTP request into a request conforming to the TCP protocol format; when the target backend service uses the HTTP protocol, it maintains the HTTP protocol format. This step ensures that the protocol format of the conversion request sent from the processing device is consistent with the protocol format supported by the target backend service. Through the above judgment and conversion actions, the processing device has already adapted the request format to a format that the target backend service can accept before forwarding the request. The target backend service can directly process the request after receiving it, without the need to deploy an additional conversion layer before or after the request arrives. Therefore, when the backend service uses the TCP protocol, there is no need to deploy an additional independent TCP proxy layer. Protocol conversion and forwarding can be completed within the same processing device, resulting in a simpler system architecture and lower deployment costs.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, server, etc., or an electronic device or virtual device capable of performing the above functions. The following description uses an Internet gateway request processing device (hereinafter referred to as the processing device) as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Based on this, embodiments of this application provide a request processing method for an Internet gateway, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the request processing method for an Internet gateway in this application.

[0027] In this embodiment, the request processing method of the Internet gateway includes steps S10 to S40: Step S10: Receive the Internet access request initiated by the client and parse the request path of the Internet access request. Step S20: Obtain the routing configuration rules, and perform whitelist matching on the request path according to the routing configuration rules to obtain the target backend service corresponding to the Internet access request.

[0028] It should be noted that the aforementioned internet access request can refer to a request generated by the client based on a text transfer protocol. This internet access request can correspond to a request message, which can include at least three parts: a request line, a request header, and a request body. The request line can record request information such as the request method, request path, and protocol version.

[0029] It is understood that the aforementioned client can be a user request entry point from the channel layer, specifically a web client, a mobile app, etc., and this application embodiment does not limit this.

[0030] It should be explained that the aforementioned request path can be path information carried in the request message to identify the target of access. By parsing the request path of the Internet access request, the backend service information, such as the name or address of the backend service that the Internet access request needs to call, can be determined.

[0031] It should be understood that, in the embodiments of this application, the method for parsing Internet access requests can be based on field-by-field parsing according to protocol specifications or on parsing based on third-party parsing libraries, etc., and the embodiments of this application do not impose any limitations on this. By parsing Internet access requests, unstructured data transmitted in the form of raw byte streams can be converted into structured field data, thereby enabling the location and acquisition of the request path from the aforementioned structured data, providing input for subsequent whitelist matching steps.

[0032] It is understandable that the aforementioned routing configuration rules can be a whitelist rule set pre-stored locally on the processing device. Each rule in this whitelist rule set can contain a path matching pattern and the corresponding backend service information. By performing whitelist matching on the request path according to the routing configuration rules, it can be determined whether there is a backend service in the backend corresponding to the internet access request.

[0033] In practical applications, when a client needs to access a backend service, it can initiate an internet access request message. Upon receiving the client's internet access request, the processing device can parse it to determine the request path. It loads pre-stored routing configuration rules and compares the request path with each path string in these rules to determine if the request path matches any of them. If the request path matches a path string, the processing device determines the target backend service based on the backend service information corresponding to that path string. This method avoids requests that do not conform to the routing rules from entering the protocol conversion and forwarding stage, reducing unnecessary processing overhead for the processing device.

[0034] Step S30: Generate a conversion request corresponding to the Internet access request based on the protocol type of the Internet access request and the protocol type of the target backend service; Step S40: Forward the conversion request to the target backend service, receive the response result returned by the target backend service, and return the response result to the client.

[0035] It should be noted that the protocol type of the Internet access request in this embodiment refers to the communication protocol specification followed by the Internet access request, such as Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS), etc. This embodiment does not limit this.

[0036] In this embodiment, after parsing the Internet request message, the protocol version field can be extracted from the request line. By reading this field, the protocol type of the Internet access request can be determined. Specifically, both the Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Security Protocol (HTTP) request lines contain a protocol version field, such as "HTTP / 1.1" or "HTTP / 2.0".

[0037] In some embodiments of this application, since the request message can typically be encrypted using Transport Layer Security (TLS) before being sent, the original Hypertext Transfer Protocol (HTTP) message is encapsulated in an encrypted tunnel. Therefore, when the processing device receives an Internet access request, it can first perform TLS handshake and decryption operations. If the handshake and decryption operations are successfully completed, the processing device determines that the protocol type of the Internet access request is Hypertext Transfer Protocol (HTTP); if the handshake and decryption operations fail or the client does not initiate an encrypted handshake, the processing device determines that the protocol type of the Internet access request is HTTP.

[0038] It should be noted that the protocol type of the target backend service in this application embodiment, i.e. the communication protocol specification that the conversion request needs to follow, such as Hypertext Transfer Protocol, Transmission Control Protocol, etc., is not limited in this application embodiment.

[0039] In this embodiment, the protocol type corresponding to the target backend service can be stored in the local routing configuration rules. Each target backend service can have one or more corresponding protocol types. When the processing device successfully matches the whitelist, it can read the protocol type-related fields from the matched routing configuration rules and determine the protocol type of the target backend service based on this.

[0040] In some embodiments of this application, the gateway application architecture of this application can be as follows: Figure 2 As shown, Figure 2 This diagram illustrates the gateway architecture in one implementation of the request processing method for the internet gateway according to this application. In the gateway application architecture of this application, the gateway layer can be pre-configured with a mapping between port numbers and target backend service protocol types, thereby enabling protocol conversion and request access. For example, the processing logic configured on port 8080 corresponds to a backend service of the Transmission Control Protocol type, the processing logic configured on port 8081 corresponds to a backend service of the ZZ1 JSON format Hypertext Transfer Protocol type, and the processing logic configured on port 8080 corresponds to a backend service of the RESTful format Hypertext Transfer Protocol type.

[0041] It's worth noting that the Processing Layer can provide custom interceptors to implement functions such as interceptor chains, router resolvers, and protocol converters, thereby enabling functions like internet access request preprocessing, route distribution, and format standardization. The Config Layer can handle configuration caching, routing configuration, and business configuration, enabling hot updates and configuration management. The Data Layer can be configured with databases (such as MySQL) and local readable and writable files (such as CSV files), thus achieving persistent data storage.

[0042] In some embodiments of this application, the custom interceptor of this application may be injected with traffic verification logic. The custom interceptor may be configured on the request processing chain to achieve interception of requests.

[0043] In some embodiments of this application, a circuit breaker platform can be set up to save and update circuit breaker and rate limiting rules. These rules can perform rate limiting and circuit breaking judgments, thereby preventing system crashes caused by a high number and / or low-quality requests. In this application embodiment, traffic verification logic can be embedded in a custom interceptor: when the custom interceptor receives a request, it can access the circuit breaker platform and manage the circuit breaking and rate limiting of the access request through the platform's circuit breaker verification rules. This configuration linkage between the custom interceptor and the circuit breaker platform enables dynamic binding between access resources and circuit breaker and rate limiting rules. By verifying internet access requests through a custom interceptor before parsing them, system crashes caused by low-quality internet access requests or sudden traffic surges are avoided.

[0044] This application embodiment receives an internet access request initiated by a client and parses the request path of the internet access request; obtains routing configuration rules and performs whitelist matching on the request path according to the routing configuration rules to obtain the target backend service corresponding to the internet access request; generates a conversion request corresponding to the internet access request based on the protocol type of the internet access request and the protocol type of the target backend service; forwards the conversion request to the target backend service, receives the response result returned by the target backend service, and returns the response result to the client. Because the protocol conversion is performed before forwarding the request, and the conversion request is generated based on the protocol type of the internet access request and the protocol type of the target backend service, the protocol format of the conversion request issued by the processing device is consistent with the protocol format supported by the target backend service. Compared with the existing technology that only supports HTTP protocol forwarding and requires the deployment of an independent TCP proxy layer when the backend service uses the TCP protocol, this solution can complete the conversion of HTTP protocol requests to TCP protocol requests within the same processing device, without the need to deploy an independent TCP proxy layer, reducing the complexity of the system architecture and deployment costs. By identifying the target backend service through the correspondence between the request path and the routing configuration rules, and completing protocol conversion and forwarding within the same processing device, the gateway can simultaneously support the access of backend services of both Hypertext Transfer Protocol and Transmission Control Protocol, thus expanding the gateway's applicability and flexibility.

[0045] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the request processing method for the Internet gateway in this application.

[0046] like Figure 3 As shown in this embodiment, the step of performing whitelist matching on the request path according to routing configuration rules to obtain the target backend service corresponding to the Internet access request includes: Step S41: Obtain the pre-stored routing configuration rules and backend service path list; Step S42: Determine the routing configuration rules corresponding to the Internet access request based on the request path; Step S43: Match the request path in the backend service path list based on the routing configuration rules to obtain the target backend service.

[0047] It is understandable that the processing device may pre-store routing configuration rules and a list of backend service paths corresponding to those rules. This list of backend service paths may include paths corresponding to each backend service.

[0048] In some embodiments of this application, the backend service path list of this application can store the paths of each backend service in the form of strings, wherein each string can correspond to a backend service.

[0049] In practical applications, when the processing device extracts the request path, it can load the pre-stored routing configuration rules in local memory and load the list of backend service paths corresponding to the routing configuration rules.

[0050] In some embodiments of this application, the routing configuration rules include at least HTTP type routing rules and TCP type routing rules; the step of matching the request path in the backend service path list based on the routing configuration rules to obtain the target backend service includes: when the routing configuration rule is the HTTP type routing rule, performing path prefix matching on the request path in the backend service path list to obtain a target backend service that at least matches the path prefix of the request path; when the routing configuration rule is the TCP type routing rule, performing exact path matching on the request path in the backend service path list to obtain a target backend service consistent with the request path.

[0051] It is understandable that the HTTP type routing rules mentioned above refer to rule records in the routing configuration rules where the target backend service's protocol type is Hypertext Transfer Protocol. The path matching method in these rule records can include both prefix matching and exact path matching, with exact path matching having higher priority than path prefix matching. The TCP type routing rules mentioned above refer to rule records in the routing configuration rules where the target backend service's protocol type is Transmission Control Protocol, and the path matching method in these rule records is exact path matching.

[0052] It should be noted that the HTTP routing rules in this embodiment support multi-dimensional matching modes, namely path prefix matching and exact path matching. When performing prefix path matching, at least two path prefixes can be configured, such as a path with the prefix / onbd / portal / . Virtual path interception can also be performed when executing HTTP routing rules, such as intercepting URL paths that are repeated more than a preset number of times.

[0053] Understandably, when performing precise path matching, it is possible to strictly verify whether the front-end request and the configured address are consistent.

[0054] In some embodiments of this application, after the step of matching the request path in the backend service path list based on the routing configuration rules to obtain the target backend service, the method further includes: determining whether the Internet access request carries a full-link grayscale identifier based on the request header of the Internet access request; when carrying the full-link grayscale identifier, querying the available instance list corresponding to the target backend service, and selecting an instance with a grayscale label as a candidate instance in the available instance list based on the full-link grayscale identifier; selecting the target instance from the candidate instances based on a load balancing strategy; correspondingly, the step of forwarding the conversion request to the target backend service, receiving the response result returned by the target backend service, and returning the response result to the client includes: forwarding the conversion request to the network address and port corresponding to the target instance of the target backend service, receiving the response result returned by the target backend service, and returning the response result to the client.

[0055] It should be noted that the aforementioned end-to-end grayscale identifier refers to the tag field carried in the request header of the Internet access request. This tag field can be used to identify the grayscale environment version to which the Internet access request belongs. For example, "gray-v2" indicates that the request needs to be routed to the grayscale environment of version 2.0.

[0056] It should be explained that the above list of available instances is a collection of all running service instances corresponding to the target backend service that are capable of receiving requests. Each service instance in this collection can have a corresponding network address and port number. For example, the network address of service instance 1 is "192.168.1.10" and the port number is "8080".

[0057] It should be noted that the grayscale label mentioned above is the tag information that is pre-attached to the service instance. This tag information can be used to distinguish between grayscale instances and non-grayscale instances. For example, instances tagged as "gray" belong to the grayscale environment, while untagged instances belong to the stable environment.

[0058] It is understood that the candidate instances mentioned above are instances with grayscale labels selected from the list of available instances, and can be used as input for load balancing. The target instance is the service instance that the processing device ultimately determines from the candidate instances using the load balancing strategy, and can be used to receive conversion requests.

[0059] For example, the processing device may select different instances from the candidate instance set sequentially according to a polling strategy, or randomly select an instance according to a random strategy, or select an instance according to a weighted strategy based on a preset weight value. This application embodiment does not limit this.

[0060] In some embodiments of this application, the embodiments of this application can also inject grayscale context into the request call chain through link coloring technology, so that the backend service can achieve accurate routing and scheduling of traffic based on the colored link identifier.

[0061] It should be noted that link coloring technology refers to the operation of the processing device injecting a full-link grayscale identifier into the request call chain of an Internet access request. This request call chain is the path chain of all service nodes traversed by the Internet access request from the processing device, through the target backend service, and the downstream services called by the target backend service, until the final response is returned. The grayscale context can refer to request context information carrying the full-link grayscale identifier, used for progressively passing between each service node in the request call chain.

[0062] In some embodiments of this application, to refine traffic isolation capabilities, this application embodiment can provide a source IP whitelist authentication and verification mechanism. Only when the request source IP completely matches the configuration rules is a custom static routing policy triggered to forward traffic to a preset destination IP address; for requests that do not match, the default service discovery routing logic of the microservice cluster is used to ensure that the baseline business traffic of the test environment is not interfered with by joint debugging requests.

[0063] In its implementation, after identifying the target backend service, the processing device can further parse the request header fields of the aforementioned internet access request and detect whether it contains a full-link grayscale identifier. The processing device can read the names of each field in the request header; if a field named "Full-link Grayscale Identifier" exists, it can determine that the internet access request carries a full-link grayscale identifier, and read the value of this identifier field. When the internet access request carries a full-link grayscale identifier, the processing device can send a query request to the service registry (e.g., Nacos, Eureka). This query request can be used to obtain a list of available instances corresponding to the target backend service. By checking each instance in the list for a grayscale label, instances carrying grayscale labels are filtered out to form a candidate instance set. When the internet access request does not carry a full-link grayscale identifier, all instances in the list of available instances can be used as the candidate instance set. After obtaining the candidate instance set, the processing device can select an instance as the target instance based on a load balancing strategy and determine the network address and port number corresponding to the target instance. This method isolates gray-scale traffic from regular traffic at the instance level. Gray-scale traffic only reaches gray-scale instances and does not affect the running status of regular instances, while regular traffic can access all instances normally.

[0064] This application embodiment obtains pre-stored routing configuration rules and a list of backend service paths; determines the routing configuration rule corresponding to the Internet access request based on the request path; and matches the request path against the backend service path list based on the routing configuration rules to obtain the target backend service. By matching the request path with path strings in the backend service path list to determine the target backend service, rather than rigidly binding the request path to a backend service, the same backend service path list can serve multiple different request paths. Different request paths can be assigned to the same or different backend services based on the matching results, achieving the reuse and flexible expansion of routing configuration rules.

[0065] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the first and / or second embodiments described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart illustrating the request processing method for the Internet gateway in this application, as provided in Embodiment 3.

[0066] like Figure 4 As shown in this embodiment, to improve availability, the step of obtaining routing configuration rules is further included before: Step S01: Periodically read the database configuration table and load the full routing whitelist rules into the database configuration table; Step S02 involves updating the routing configuration rules in the local memory cache according to the full routing whitelist rules; and... Step S03: Serialize the full set of routing whitelist rules into a local readable and writable file in a preset format.

[0067] It should be noted that, in order to ensure the high throughput, low latency, and operational stability of the API gateway, this embodiment of the application can adopt a local cache preheating and three-layer synchronization architecture to achieve efficient management of routing rules and personalized application configurations.

[0068] In this embodiment, a pre-loading caching mechanism can be used to preload all routing rules and application-specific configurations stored in the configuration center into the local heap cache during the API gateway startup phase. When making routing decisions, the complete rules in the local cache can be read directly for matching, thereby completely avoiding the overhead of database queries at runtime and ensuring that the single-request routing latency is controlled at the microsecond level.

[0069] In the three-layer storage synchronization architecture of this application embodiment, there may be a three-layer mechanism including persistent storage of routing and configuration, real-time synchronization of gateway local cache, and local readable and writable file storage of processing device.

[0070] Specifically, the database can be used as a trusted data source, periodically reading and persistently storing the database configuration table, and updating all routes and configuration rules. Different tables can be used to manage route whitelist information and the default configurations of various applications on the API gateway.

[0071] It is understood that the time intervals mentioned above can be set according to the needs of actual applications, and this application embodiment does not impose any restrictions on this.

[0072] For example, in this application embodiment, the database cache can be asynchronously refreshed to the local heap cache (local memory cache) and local readable and writable files every minute by a scheduled task, thereby realizing automatic refresh of the local cache and ensuring that configuration updates, deletions, additions, etc. can be quickly synchronized to the local memory cache and local readable and writable files.

[0073] It should be noted that the specific format of the aforementioned locally readable and writable file can be selected according to the needs of the actual application. For example, a CSV file can be selected as the locally readable and writable file. This application embodiment does not limit this.

[0074] In this embodiment, based on the above architecture, a three-tiered protection mechanism can be implemented to provide a safety net for the availability of the API gateway. Specifically, dynamic updates and real-time queries of the database configuration ensure the latest and most accurate configuration source; local read-write files enable rapid recovery when the database is unavailable, providing a backup of the most recent configuration; and local memory caching maintains service availability even if both the database and local read-write files fail, using the oldest configuration data as a fallback. This design ensures high availability of the gateway system, allowing it to continue providing services even when the database is completely unavailable, through CSV backup files or memory caching, thus avoiding system paralysis caused by a single point of failure.

[0075] In some embodiments of this application, when querying database configuration, a preset query time can be set to determine if the query has timed out. If the query times out, routing configuration rules can be determined from a local readable and writable file. That is, the step of obtaining routing configuration rules includes: if the database query timeout time is greater than the preset time, then determining routing configuration rules based on the local readable and writable file.

[0076] In some embodiments of this application, after the step of determining routing configuration rules based on the local readable and writable file if the query timeout of the database is greater than a preset time, the method further includes: when the query timeout of the database is greater than the preset time, sending a probe query to the database with an incrementing time interval; when the number of consecutive successful probe queries is greater than a preset number, reading a first full routing whitelist rule from the database, reading a second full routing whitelist rule from the local memory cache, and reading a third full routing whitelist rule from the local readable and writable file; performing a difference type determination on the first full routing whitelist rule, the second full routing whitelist rule, and the third full routing whitelist rule, and performing database backfilling based on the difference type.

[0077] In some embodiments of this application, an exponential backoff algorithm can be used to incrementally increase the time interval of the probing query to achieve database health checks, ensuring effective retries in case of database failure. When using the exponential backoff algorithm, the aforementioned time interval can be exponentially increased. For example, the initial preset time is 1 second. If the first query times out, a 2-second retry can be waited; if the second query times out, a 4-second retry can be waited; if the third query times out, an 8-second retry can be waited until the maximum value is reached (e.g., the maximum value is 60 seconds). By incrementally increasing the probing time interval in this way, database health checks are performed, ensuring effective retries in case of database failure.

[0078] In some embodiments of this application, a cache alarm can also be set to automatically expand the cache and alert relevant contacts when the amount of cache in memory exceeds a preset value (such as 2 / 3, 80%, etc.).

[0079] In this embodiment, when the database query time exceeds a preset time, the database probing query time interval can be incremented sequentially. Upon successfully probing a routing configuration rule from the database, further probing queries can continue. When the number of consecutive successful probing queries exceeds a preset number, the database is considered recovered, and the query time interval can be restored to the preset time interval. The latest full routing whitelist rule, i.e., the first full routing whitelist rule, is then read from the database. Simultaneously, the second newest third full routing whitelist rule can be obtained from a local readable and writable file, and the oldest third full routing whitelist rule can be obtained from the local memory cache. The difference type of these three rules is determined, and database backfilling is performed based on the difference type.

[0080] Specifically, if a configuration record in the database exists in both the local memory cache and the local readable / writable file, and their version numbers are identical, then the difference type is that all three are the same, and no operation is required. If the database version number is higher than the version numbers in the local memory cache and the local readable / writable file, then the difference type is that the database version is the latest, and the processing device synchronizes the configuration record in the database to the local memory cache and the local readable / writable file, overwriting the local version. If the version number in the local memory cache or the local readable / writable file is higher than the database version number, then the difference type is that the local version is the latest, and the processing device refills the database with the configuration record that has the higher version number from the local memory cache or the local readable / writable file, and then executes the corresponding operation. Insert or update operations; if the version numbers of the local memory cache and the local readable and writable file are inconsistent and both are higher than the database version number, the difference type is a local three-way inconsistency. The processing device can compare the configuration record in the local memory cache with the configuration record in the local readable and writable file, and use the higher version number to populate the configuration record with the higher version number back into the database and synchronize it to another local storage; if the version numbers of the database, local memory cache, and local readable and writable file are inconsistent, the difference type is a three-way conflict. The processing device skips the synchronization of this configuration record, marks the record as a conflict pending arbitration, sends an alarm notification to the operation and maintenance monitoring platform, and waits for manual intervention by operation and maintenance personnel.

[0081] This application embodiment reads the database configuration table periodically and loads the full routing whitelist rules into it. It then updates the routing configuration rules in the local memory cache based on these whitelist rules and serializes them into a locally readable and writable file in a preset format. By periodically reading the database configuration table and loading the full routing whitelist rules, the full routing whitelist rules in the database are synchronized to the local memory cache, eliminating the need to query the database for each request. Compared to querying the database for every request, this avoids database query overhead, shortens the time required for route matching, and improves request processing efficiency. By periodically performing the above synchronization operations, configuration updates in the database can be automatically synchronized to the local memory cache at certain time intervals, without manual intervention or restarting the processing device. By serializing the full routing whitelist rules into a locally readable and writable file in a preset format, a copy of the routing configuration rules identical to those in the local memory cache is stored in this file. When the local memory cache becomes empty due to a restart or fault recovery, the processing device can directly load the routing configuration rules from the locally readable and writable file without relying on database availability.

[0082] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the request processing method of the Internet gateway of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0083] This application also provides a request processing device for an Internet gateway, please refer to... Figure 5 , Figure 5 This is a schematic diagram of the module structure of the request processing device of the Internet gateway according to an embodiment of this application. The request processing device of the Internet gateway includes: The request parsing module 10 is used to receive an Internet access request initiated by the client and parse the request path of the Internet access request. The route matching module 20 is used to obtain the route configuration rules and perform whitelist matching on the request path according to the route configuration rules to obtain the target backend service corresponding to the Internet access request. The request conversion module 30 is used to generate a conversion request corresponding to the Internet access request based on the protocol type of the Internet access request and the protocol type of the target backend service. The request forwarding module 40 is used to forward the conversion request to the target backend service, receive the response result returned by the target backend service, and return the response result to the client.

[0084] The request processing apparatus for an internet gateway provided in this application, employing the request processing method for an internet gateway in the above embodiments, can solve the technical problem of increased system deployment complexity and operation and maintenance costs caused by the single protocol support in existing solutions. Compared with the prior art, the beneficial effects of the request processing apparatus for an internet gateway provided in this application are the same as those of the request processing method for an internet gateway provided in the above embodiments, and other technical features in the request processing apparatus for an internet gateway are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0085] This application provides a request processing device for an Internet gateway, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the request processing method of the Internet gateway in the first embodiment described above.

[0086] The following is for reference. Figure 6This document illustrates a schematic diagram of a request processing device suitable for implementing an Internet gateway according to embodiments of this application. The request processing device for the Internet gateway in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), tablet computers, PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The request processing device of the Internet gateway shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0087] like Figure 6 As shown, the request processing device of the Internet gateway may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the request processing device of the Internet gateway. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the request processing device of an Internet gateway to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show request processing devices for Internet gateways with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0088] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0089] The request processing device for an internet gateway provided in this application, employing the request processing method for an internet gateway in the above embodiments, can solve the technical problem of increased system deployment complexity and operation and maintenance costs caused by the single protocol support in existing solutions. Compared with the prior art, the beneficial effects of the request processing device for an internet gateway provided in this application are the same as those of the request processing method for an internet gateway provided in the above embodiments, and other technical features in this request processing device for an internet gateway are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0090] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0092] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the request processing method of the Internet gateway in the above embodiments.

[0093] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0094] The aforementioned computer-readable storage medium may be included in the request processing device of the Internet gateway; or it may exist independently and not assembled into the request processing device of the Internet gateway.

[0095] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the request processing device of the Internet gateway, cause the request processing device of the Internet gateway to: Receive an internet access request initiated by the client and parse the request path of the internet access request; Obtain the routing configuration rules, and perform whitelist matching on the request path according to the routing configuration rules to obtain the target backend service corresponding to the Internet access request; A conversion request corresponding to the Internet access request is generated based on the protocol type of the Internet access request and the protocol type of the target backend service. The conversion request is forwarded to the target backend service, and the response result returned by the target backend service is received and then returned to the client.

[0096] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0097] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0098] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0099] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the request processing method of the aforementioned Internet gateway. This addresses the technical problem of increased system deployment complexity and maintenance costs caused by the single protocol support in existing solutions. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the request processing method of the Internet gateway provided in the above embodiments, and will not be elaborated upon here.

[0100] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the request processing method for an Internet gateway as described above.

[0101] The computer program product provided in this application can solve the technical problem that the single protocol support of existing solutions leads to increased system deployment complexity and operation and maintenance costs. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the request processing method of the Internet gateway provided in the above embodiments, and will not be repeated here.

[0102] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A request processing method for an Internet gateway, characterized in that, The method includes: Receive an internet access request initiated by the client and parse the request path of the internet access request; Obtain the routing configuration rules, and perform whitelist matching on the request path according to the routing configuration rules to obtain the target backend service corresponding to the Internet access request; A conversion request corresponding to the Internet access request is generated based on the protocol type of the Internet access request and the protocol type of the target backend service. The conversion request is forwarded to the target backend service, and the response result returned by the target backend service is received and returned to the client.

2. The request processing method for an Internet gateway as described in claim 1, characterized in that, The step of performing whitelist matching on the request path according to the routing configuration rules to obtain the target backend service corresponding to the Internet access request includes: Retrieve pre-stored routing configuration rules and a list of backend service paths; Determine the routing configuration rules corresponding to the Internet access request based on the request path; Based on the routing configuration rules, the request path is matched against the backend service path list to obtain the target backend service.

3. The request processing method for an Internet gateway as described in claim 2, characterized in that, The routing configuration rules include at least HTTP type routing rules and TCP type routing rules; The step of matching the request path against the backend service path list based on the routing configuration rules to obtain the target backend service includes: When the routing configuration rule is the HTTP type routing rule, the request path is matched with a path prefix in the backend service path list to obtain a target backend service that matches at least the path prefix of the request path. When the routing configuration rule is the TCP type routing rule, the request path is precisely matched in the backend service path list to obtain the target backend service that matches the request path.

4. The request processing method for an Internet gateway as described in claim 2, characterized in that, After the step of matching the request path against the backend service path list based on the routing configuration rules to obtain the target backend service, the method further includes: Determine whether the Internet access request carries a full-link grayscale identifier based on the request header of the Internet access request; When carrying the full-link grayscale identifier, query the list of available instances corresponding to the target backend service, and select the instance with grayscale label as the candidate instance from the list of available instances according to the full-link grayscale identifier; The target instance is selected from the candidate instances based on the load balancing strategy. Accordingly, the step of forwarding the conversion request to the target backend service, receiving the response result returned by the target backend service, and returning the response result to the client includes: The conversion request is forwarded to the network address and port corresponding to the target instance of the target backend service, and the response result returned by the target backend service is received and returned to the client.

5. The request processing method for an Internet gateway as described in claim 1, characterized in that, Before the step of obtaining the routing configuration rules, the following steps are also included: Periodically read the database configuration table and load the full list of routing whitelist rules into the database configuration table; The routing configuration rules in the local memory cache will be updated according to the full routing whitelist rules; and... The full set of routing whitelist rules is serialized into a locally readable and writable file in a preset format.

6. The request processing method for an Internet gateway as described in claim 5, characterized in that, The steps for obtaining routing configuration rules include: If the query timeout of the database is greater than the preset time, the routing configuration rules are determined based on the local readable and writable file.

7. The request processing method for an Internet gateway as described in claim 6, characterized in that, Following the step of determining routing configuration rules based on the local readable and writable file if the query timeout of the database is greater than a preset time, the method further includes: When the query timeout in the database exceeds a preset time, a probe query is sent to the database at an incrementing time interval; When the number of consecutive successful probe queries exceeds a preset number, the system reads the first full routing whitelist rule from the database, the second full routing whitelist rule from the local memory cache, and the third full routing whitelist rule from the local readable and writable file. The first full-list routing whitelist rule, the second full-list routing whitelist rule, and the third full-list routing whitelist rule are judged for difference type, and the database is backfilled according to the difference type.

8. A request processing device for an Internet gateway, characterized in that, The request processing device of the Internet gateway includes: The request parsing module is used to receive internet access requests initiated by the client and parse the request path of the internet access request. The route matching module is used to obtain the route configuration rules and perform whitelist matching on the request path according to the route configuration rules to obtain the target backend service corresponding to the Internet access request. The request conversion module is used to generate a conversion request corresponding to the Internet access request based on the protocol type of the Internet access request and the protocol type of the target backend service. The request forwarding module is used to forward the conversion request to the target backend service, receive the response result returned by the target backend service, and return the response result to the client.

9. A request processing device for an Internet gateway, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the request processing method of the Internet gateway as claimed in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the request processing method of the Internet gateway as described in any one of claims 1 to 7.

Images