Routing forwarding method and system for API (Application Program Interface) request

Abstract

The embodiment of the invention discloses a routing forwarding method and system for an API (Application Program Interface) request, and the method comprises the following steps: receiving the API request through a receiving end gateway instance, and obtaining a destination end gateway cluster corresponding to the API request through searching a global routing information table; under the condition that the destination gateway cluster is equal to the gateway cluster corresponding to the receiving end gateway instance, forwarding the API request to a micro service corresponding to the API request through the receiving end gateway instance; and under the condition that the destination gateway cluster is not equal to the gateway cluster corresponding to the receiving end gateway instance, forwarding the API request to the destination gateway cluster through the receiving end gateway instance, and forwarding the API request to a micro service corresponding to the API request through the destination gateway cluster. According to the embodiment of the invention, the purpose of same-layer peer-to-peer API Gateway cluster networking can be realized, and the stability of a gateway system is enhanced based on unitized deployment and cooperative forwarding capability.

Description

Technical Field

[0001] The present application belongs to the field of computer technology, and specifically relates to a method and system for routing and forwarding API requests. Background Art

[0002] The Internet is built on the HTTP protocol. After the microservice technology stack became the technical foundation, API Gateway (Application Programming Interface Gateway) middleware came into being. As an essential basic component in the field of microservice technology, API Gateway is located between the client and each microservice, mainly acting as a reverse proxy to route different API requests to the corresponding microservices. At the same time, it also has security, current limiting, caching, logging, monitoring, retry, circuit breaking and other functions.

[0003] Traditionally, the API gateway is a centralized basic microservice architecture component in the application architecture. It can route north-south API requests from the external network to internal upstream microservices, and can also perform the routing and distribution of east-west API requests on the internal network, routing API requests initiated by a microservice in one business domain to a microservice in another business domain. The east-west API request traffic is often greater than the north-south API request traffic.

[0004] In the prior art, API gateways are generally deployed in clustered horizontal multi-instances to form an API gateway cluster. A large number of east-west API requests are routed and forwarded through an API gateway cluster, which often poses a risk to system stability.

[0005] Application Contents

[0006] The purpose of the embodiments of the present application is to provide a method and system for routing and forwarding API requests to address the system stability risks existing in the prior art.

[0007] In order to solve the above technical problems, this application is implemented as follows:

[0008] In a first aspect, a method for routing and forwarding an API request is provided, comprising the following steps:

[0009] Receive the API request through the receiving gateway instance, and obtain the destination gateway cluster corresponding to the API request by searching the global routing information table;

[0010] When the destination gateway cluster is equal to the gateway cluster corresponding to the receiving gateway instance, forwarding the API request to the microservice corresponding to the API request through the receiving gateway instance;

[0011] When the destination gateway cluster is not equal to the gateway cluster corresponding to the receiving gateway instance, the API request is forwarded to the destination gateway cluster through the receiving gateway instance, and the API request is forwarded to the microservice corresponding to the API request through the destination gateway cluster.

[0012] In a second aspect, a routing and forwarding system for API requests is provided, including:

[0013] A search module is used to receive an API request through a receiving gateway instance, and obtain a destination gateway cluster corresponding to the API request by searching a global routing information table;

[0014] A first forwarding module, configured to forward the API request to a microservice corresponding to the API request through the receiving-end gateway instance when the destination-end gateway cluster is equal to the gateway cluster corresponding to the receiving-end gateway instance;

[0015] The second forwarding module is used to forward the API request to the destination gateway cluster through the receiving gateway instance when the destination gateway cluster is not equal to the gateway cluster corresponding to the receiving gateway instance, and forward the API request to the microservice corresponding to the API request through the destination gateway cluster.

[0016] The embodiment of the present application shares the API global routing table in the API Gateway cluster, which can accurately forward API requests directly to the target microservice or accurately forward them to the target microservice through other API Gateway clusters at the same level through one hop, thereby completing the API routing forwarding task and achieving the purpose of networking of peer-to-peer API Gateway clusters at the same level. Based on unit deployment and collaborative forwarding capabilities, the stability of the gateway system is enhanced, which can not only achieve isolation of business network topology, but also has good maintainability. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a schematic diagram of forwarding an API request provided in an embodiment of the present application;

[0018] Figure 2 This is a flow chart of a method for routing and forwarding an API request provided in an embodiment of the present application;

[0019] Figure 3 It is a schematic diagram of deploying an API Gateway cluster provided in an embodiment of the present application;

[0020] Figure 4 This is a schematic diagram of the mapping relationship in the API global routing table provided in the embodiment of the present application;

[0021] Figure 5 is a target route selection determination flow chart provided in an embodiment of the present application;

[0022] Figure 6 It is a structural diagram of a routing and forwarding system for API requests provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments.

[0024] At present, large and medium-sized IT companies often release multiple online products for different business units in different tracks. The number of backend microservices and microservice copies of large SAAS platform products is often large. In terms of deployment, they are generally divided into multiple deployment zones according to the business field dimension. Each deployment zone has a zone identification name. Multiple microservice registration centers are deployed in a zone. A microservice has multiple copies registered with the registration center, and microservices are also deployed in multi-copy clusters. APIGateway can also be registered as a microservice to the microservice registration center, so that when the API Gateway addresses and discovers the specific instance forwarding address of the target microservice, it can use the discovery capability of the microservice of the registration center to forward the API request to one of the microservice instances.

[0025] Since it is common for enterprises to go to the cloud, computing resources are provided by cloud service providers. Enterprises deploy microservices on virtual machines in a certain availability zone of a cloud service provider. They cannot be too centralized, otherwise the entire line of microservices will be unreachable due to network failures in the availability zone. Deployment zone, microservice registration center, a controllable number of microservice instances cohesive in the business domain, and API gateway cluster form a deployment unit. It is necessary for enterprises to work together to support SAAS platform-type online products to provide stable and reliable services. At present, there are two technical routes for how to deploy API Gateway clusters:

[0026] One is the edge centralized gateway deployment technology. For companies with small scale and small business scale, each production line of the company can share a centralized edge gateway cluster, and deploy multiple instances horizontally in the APIGateway cluster. As the business scale grows, the number of instances is expanded. The other is the second-layer gateway deployment technology. As the company's business scale continues to increase, the shortcomings of all production lines sharing a centralized edge gateway cluster gradually emerge and affect each other. Therefore, a dedicated production line centralized gateway is deployed for each production line, and an edge centralized gateway cluster is deployed on it, forming a two-layer deployment method of edge centralized gateway + production line centralized gateway. The first-layer APIGateway cluster serves as a unified entrance and is only responsible for distributing APIs to the second-layer APIGateway. The second-layer APIGateway is responsible for forwarding API requests to the backend microservices.

[0027] However, in the edge centralized gateway deployment technology, all APIs are uniformly concentrated and forwarded from a centralized APIGateway cluster, which has the following three disadvantages: First, after sharing a centralized edge gateway cluster, the normal operation of business A has nothing to do with business B, but because the two share an APIGateway gateway entrance, when the traffic of business B surges, it puts pressure on APIGateway, causing APIGateway to be unable to perform API forwarding work normally or partially damaged, which indirectly affects the normal operation of business A. In addition, for the centralized APIGateway that carries all business lines of the company, its API Gateway's own function iteration, release, operation and maintenance, even if its original intention is only to respond to the needs of a certain business production line, if the API Gateway fails, it will affect all business production lines, which requires a means of isolating faults and unitizing deployment. Third, high requirements are placed on the concurrent throughput of the centralized APIGateway cluster, which must be able to cover all business peaks.

[0028] The two-layer gateway deployment technology has the following disadvantages: Although it can achieve partial isolation of business lines on the second-layer gateway, the first-layer API Gateway cluster still carries all API requests and is still a centralized bottleneck; Compared with the first-layer edge centralized gateway deployment technology, it actually bears more than twice the computing resources required for APIGateway deployment of all API requests; There are two different semantics in routing table management, which is not easy to maintain and manage in a unified manner. The first-layer API Gateway maintains the routing relationship table between the API and the second-layer API Gateway cluster, and the second-layer API Gateway maintains the routing relationship table between the API and the target upstream microservice. The first-layer API Gateway determines the target second-layer API Gateway address based on the path, and the second-layer API Gateway determines the target microservice ServiceId based on the path; The client side can generally only perceive the existence of the first-layer gateway, and client identity authentication is performed on the first-layer gateway. The second-layer gateway cannot directly accept API requests initiated by the client side.

[0029] The problem to be solved by the embodiment of the present application is how to enable API routing forwarding between API gateway clusters, so that multiple independently deployed API gateway clusters can not only independently and directly forward API requests from the client side to the upstream target microservice, but also indirectly forward API requests from the previous hop API gateway cluster that are still from the client side to the upstream target microservice, forming a super API gateway cluster logically composed of multiple independent API gateway clusters. The independently deployed API gateway clusters are both independent and interconnected to realize the networking of peer API gateway clusters at the same level, thereby eliminating the generalized single-point bottleneck in which all API routing forwarding is concentrated on one API gateway cluster. Based on the API global routing table technology, API gateway transfer dedicated entry technology, API integrated forwarding target judgment technology and API Forward to Gateway technology described in this application, it is possible to accurately realize that the API request from the client side can reach the target microservice at most after being transferred between API gateway clusters once, that is, at most one hop between API gateways. The embodiment of the present application proposes the technology of each APIGateway cluster sharing the API global routing table, the API gateway transfer dedicated entry technology, the API integrated routing forwarding target judgment technology and the API Forward to Gateway technology. Based on the above technology, Figure 1As shown, the API Gateway accurately forwards an API request directly to the target microservice or accurately forwards it to the target microservice through another APIGateway cluster at the same level through one hop, completing the API routing and forwarding task. From the perspective of the API Gateway, the technical solution of the embodiment of the present application is that the same-layer API Gateway can accept both API requests initiated by the client side and API requests forwarded by other peer APIGateways at the same layer, ultimately achieving the purpose of networking the same-layer peer APIGateway cluster.

[0030] In the following, in conjunction with the accompanying drawings, a routing and forwarding method for an API request provided in an embodiment of the present application is described in detail through specific embodiments and their application scenarios.

[0031] like Figure 2 As shown, it is a flow chart of a method for routing and forwarding an API request provided in an embodiment of the present application, and the method comprises the following steps:

[0032] Step 201: Receive an API request through a receiving-end gateway instance, and obtain a destination-end gateway cluster corresponding to the API request by searching a global routing information table.

[0033] In this embodiment, before obtaining the destination gateway cluster corresponding to the API request by searching the global routing information table, it can also be determined whether the API request is an API request received through the dedicated forwarding entry of the receiving gateway instance;

[0034] Accordingly, the step of obtaining the destination gateway cluster corresponding to the API request by searching the global routing information table specifically includes: obtaining the destination gateway cluster corresponding to the API request by searching the global routing information table when the API request is not an API request received through the dedicated forwarding entry of the receiving gateway instance;

[0035] After determining whether the API request is an API request received through the dedicated forwarding entry of the receiving-end gateway instance, it also includes: if the API request is an API request received through the dedicated forwarding entry of the receiving-end gateway instance, forwarding the API request to a microservice corresponding to the API request through the receiving-end gateway instance.

[0036] The global routing information table includes the mapping relationship between API and microservice, the mapping relationship between microservice and registration center, and the mapping relationship between registration center and API gateway cluster;

[0037] Correspondingly, the method of obtaining the destination gateway cluster corresponding to the API request by searching the global routing information table specifically includes: obtaining the microservice corresponding to the API request by searching the global routing information table; searching the registration center where the microservice has been registered in the global routing information table; and searching the destination gateway cluster corresponding to the registration center in the global routing information table.

[0038] Specifically, the destination gateway cluster list bound to the registration center can be searched in the global routing information table; when the destination gateway cluster list contains the gateway cluster corresponding to the receiving gateway instance, it is determined that the destination gateway cluster is equal to the gateway cluster corresponding to the receiving gateway instance; when the destination gateway cluster list does not contain the gateway cluster corresponding to the receiving gateway instance, the destination gateway cluster list is traversed to determine whether there is a gateway cluster in the destination gateway cluster list that is the same as the deployment area of ​​the receiving gateway instance; if so, the gateway cluster with the same deployment area is used as the destination gateway cluster corresponding to the registration center; otherwise, the first gateway cluster in the destination gateway cluster list is used as the destination gateway cluster corresponding to the registration center.

[0039] Step 202: When the destination gateway cluster is equal to the gateway cluster corresponding to the receiving gateway instance, forward the API request to the microservice corresponding to the API request through the receiving gateway instance.

[0040] Step 203, when the destination gateway cluster is not equal to the gateway cluster corresponding to the receiving gateway instance, the API request is forwarded to the destination gateway cluster through the receiving gateway instance, and the API request is forwarded to the microservice corresponding to the API request through the destination gateway cluster.

[0041] In this embodiment, multiple registration centers are deployed in each deployment area, and each microservice has multiple copies registered with multiple registration centers. Different registration centers correspond to different API gateway clusters, and each API gateway cluster has the same deployment area attribute information as the corresponding registration center;

[0042] The method further comprises:

[0043] The global routing information table is registered and managed through the gateway management console, and the global routing information table is distributed to all gateway instances of all API gateway clusters in the system; when the global routing information table changes, the changed global routing information table is distributed to all gateway instances of all API gateway clusters in the system.

[0044] The embodiment of the present application shares the API global routing table in the API Gateway cluster, which can accurately forward API requests directly to the target microservice or accurately forward them to the target microservice through other API Gateway clusters at the same level through one hop, thereby completing the API routing forwarding task and achieving the purpose of networking of peer-to-peer API Gateway clusters at the same level. Based on unit deployment and collaborative forwarding capabilities, the stability of the gateway system is enhanced, which can not only achieve isolation of business network topology, but also has good maintainability.

[0045] In the embodiment of the present application, multiple independent API Gateway clusters can be deployed, such as Figure 3 As shown, the APIGateway instance provides two API entrances, one entrance accepts API requests initiated by the client side, and the other entrance specifically accepts API requests forwarded by other APIGateways of the same layer. In the configuration state, the registration management maintains an API global routing table. Whenever there is a change in the API global routing table, the API global routing table is accurately and real-timely distributed to all Gateway instances of all APIGateway clusters. Any API Gateway instance can accurately know which API Gateway instance or instances an API request can reach the target microservice from. In the running state, the API request arrives at the API forwarding dedicated entrance or the client-side API request entrance; refer to the global routing table, execute the integrated routing forwarding target judgment logic, and select the forwarding destination of this API request. Regardless of which entrance the API request comes from, it is judged according to the unified API integrated routing forwarding target judgment technology; forward this API request to the target microservice or other API Gateway clusters of the same layer.

[0046] Specifically, when deploying the API Gateway, the AP transit dedicated entrance technology is used. The Gateway makes special reservations for the first-level root path. The / forward keyword represents the dedicated entrance for forwarding API requests, and / inner represents the client-side API request entrance. When API requests such as / forward / xxx / yyy / zzz arrive, the Gateway will identify them as API requests forwarded from other peer API Gateways at the same level. This Gateway will be responsible for routing the forwarded API requests to the target microservice. API requests sent to the API transit dedicated entrance can only come from other API Gateways. It is impossible to construct API requests to the API dedicated entrance from the client side. This can be ensured by using the internal authentication mechanism between Gateways.

[0047] Furthermore, the client side accesses the API Gateway cluster through an external shared domain name or an intranet shared domain name. An independently deployed API Gateway cluster is equipped with an independent load balancer, which has an external IP address and an internal IP address. The gateway instance of the independently deployed API Gateway cluster is registered with a microservice registration center in the zone where it is located. For all independently deployed API Gateway clusters, apply for a shared external domain name, and the external network returns different external IP addresses of the load balancer of the API Gateway cluster based on conventional DNS load balancing technology or intelligent DNS technology. For all independently deployed API Gateway clusters, apply for a shared intranet domain name, and the intranet returns different internal IP addresses of the load balancer of the API Gateway cluster based on the client request source IP segment based on intelligent DNS technology. Business microservices on different zones can also discover the request address of the API Gateway service based on the registration center in the zone where they are located and directly initiate API requests to the Gateway in a microservice manner. When it is clearly determined that a certain API Gateway cluster is in a fault, in order not to affect the forwarding work of other APIs, it is necessary to manually or add an automatic mechanism to exclude the external load IP address and the internal load IP address of the faulty API Gateway cluster from the domain name resolution. Furthermore, the APIGateway clusters on the server side access each independent API Gateway cluster with independent intranet domain names. For each independently deployed API Gateway cluster, apply for an independent intranet domain name, pointing to the load balancer intranet IP address of different API Gateway clusters. To forward API requests between peer APIGateway clusters at the same layer, it is necessary to distinguish different API Gateway clusters and use independent intranet domain names.

[0048] In addition, the registration management and maintenance of the API global routing table include: registering and filing the microservice registration center. That is, registering the microservice registration center, and obtaining a unique identification name for each microservice registration center. Such as registration center 1-1, registration center 1-2, and registration center 2; registering the Gateway cluster identifier, such as lb-gw-zone1, lb-gw-zone2, specifying which registration center the Gateway cluster is registered to, and specifying the zone information of the deployment area for the Gateway cluster; deploying the Gateway server service, and registering the independent intranet domain name of the Gateway cluster to the registration center. Further, registering and filing the API Gateway cluster. That is, registering the API Gateway cluster, obtaining a unique identification name for each API Gateway cluster, such as lb-gw-zone1, lb-gw-zone2; specifying an independent intranet domain name for each deployed API Gateway cluster registration; specifying which registration center the APIGateway cluster is associated with; specifying the zone information of the deployment area for the API Gateway cluster. Further, registering and filing the microservice. That is, register a microservice, select a registration center, find a list of microservices from the registration center, and select a microservice; further, register an API. When registering an API, select the registered microservice name, the entry path open to the client, and the upstream service path. The registered API is visible to all API Gateway clusters.

[0049] Then, build the API global routing table. The global routing table consists of three associations, including which microservice provides the API, which registration center the microservice is registered on, and which API Gateway cluster name the registration center corresponds to. The mapping relationship is as follows: Figure 4 In addition, as one of the important properties of the Gateway cluster, it can be inferred from the relationship between the deployment zone and the microservice registry and the 1:1 correspondence between the registry and the API Gateway cluster that the API Gateway cluster can pass on the zone attribute information.

[0050] After the API registration is completed, the API global routing table consisting of the core elements of API, microservices, registration center, and API Gateway is established, as shown in Table 1.

[0051] Table 1 API global routing table

[0052]

[0053] Furthermore, distribute the API global routing table and propagate the routing information of the API global routing table to each API Gateway cluster. The API global routing table is configuration information. Changes in configuration information need to be perceived by each Gateway instance of each API Gateway cluster in real time, so that the same-layer peer API Gateway clusters can use a global routing table for routing judgment, accurately and indiscriminately identifying which route any API request from the client side is forwarded from. In practice, you can learn from the configuration center hot update mechanism, the Redis Master-slave update mechanism, and the active push mechanism.

[0054] The API global routing table is shared by the Gateway instances of each API Gateway cluster, and ensures eventual consistency in near real time under normal circumstances. In special circumstances, eventual consistency is achieved through version reconciliation, compensation, etc. In the configuration state, after the API global routing table information changes, it is generally issued at night when business is not busy, unless in an emergency.

[0055] Based on the above API global routing table, API integrated routing forwarding target judgment can be realized, such as Figure 5 As shown. When the API request arrives at the general entrance of the API Gateway instance, after the original request authentication is passed, the destination routing judgment logic is executed. The embodiment of the present application designs and implements an API integrated routing forwarding target judgment technology from which the API can directly reach the backend microservice from which Gateway cluster. Find the microservice ServiceID from the API, find out which registration center it is registered on from the microservice ServiceID, and find out from the registration center which Gateway cluster the microservice ServiceId on the registration center can be directly reached from. When the API request arrives at the dedicated forwarding entrance of the API Gateway instance, request authentication is not performed, and the destination routing judgment logic is not executed. The API request is directly routed and forwarded to the target microservice. Under normal circumstances, there is no situation where the API route cannot be found for API requests coming in from the dedicated forwarding entrance. If there is a situation where the API route cannot be found, a special log is recorded for use in troubleshooting the problem, and 404 is returned.

[0056] The execution result of the route forwarding target judgment is shown in Table 2.

[0057] Table 2 Routing table

[0058]

[0059]

[0060]

[0061] Since the global API routing table contains all routing information, after receiving the API request, the API Gateway instance can accurately determine from which API Gateway cluster to directly reach the microservice. When you need to forward the API to the dedicated forwarding entrance of other API Gateway clusters at the same level, you need to complete the following steps:

[0062] First, replace the prefix of the received API path with the prefix of the dedicated forwarding entry to get the new path. Second, query the global routing table, use the name of the destination API Gateway cluster as the input parameter, and get the intranet domain name of the destination API Gateway cluster. Finally, send the new path to the intranet domain name of the destination API Gateway cluster, and the body remains unchanged, thus implementing the API Forward to Gateway action.

[0063] The embodiment of the present application designs and implements a peer-to-peer API Gateway cluster networking technology with API Forward to Gateway capability, as well as a dedicated entry technology and device for API Gateway transfer. The first-layer path is managed, and based on the first-layer path, it can be determined whether the API request comes directly from the client or from other API Gateway clusters at the same layer, so that API requests from different sources can be processed differently.

[0064] In addition, the embodiment of the present application also designs and implements a set of API global routing table technology and devices consisting of a set of 3-layer mapping relationships. The first-layer mapping relationship establishes the mapping relationship between API and microservice ServiceID, the second-layer mapping relationship establishes the mapping relationship between microservice ServiceID and microservice registration center, and the third-layer mapping relationship establishes the mapping relationship between microservice registration center and APIGateway cluster address.

[0065] The embodiment of the present application also designs and implements a set of API integrated routing forwarding target judgment technology and apparatus. The API Gateway address returned by the API integrated routing forwarding target judgment technology is either the API Gateway itself that receives the API request, which can be directly forwarded to the backend microservice, or a sibling API Gateway address of the same layer, but the API request can be forwarded to the backend microservice through the sibling API Gateway address.

[0066] The embodiment of the present application also designs and implements a set of API Forward to Gateway technology and devices. APIGateway uses this technology to forward a request initiated by a client to a dedicated forwarding entrance of other API Gateway clusters at the same level by changing the path prefix.

[0067] The embodiment of the present application also designs and implements a method for preferentially selecting a target API Gateway with zone affinity when forwarding an API. When the target microservice is registered with multiple registration centers and multiple independently deployed API Gateway clusters are found, an API Gateway cluster with the same regional zone as the API Gateway that first receives the API request is found based on zone affinity for forwarding.

[0068] The embodiment of the present application is based on the networking technology of the same-layer peer API Gateway cluster. When a Gateway instance node of an APIGateway cluster fails, only the routing forwarding of a part of the APIs may be affected, that is, the scope of damage is controllable. In an API Gateway cluster that adopts centralized edge gateway deployment technology, each API Gateway instance is responsible for the routing forwarding of all APIs. If a Gateway instance fails, the API forwarding may be affected, which may happen to any API; similarly, in a first-layer API Gateway cluster that adopts the second-layer gateway deployment technology, the routing forwarding may be affected, which may happen to any API; and for the same-layer peer API Gateway cluster with API forward capability in the embodiment of the present application, a Gateway instance failure will only affect the API that the gateway cluster can directly forward, and other APIs will not be affected.

[0069] Compared with the two-layer gateway deployment technology, the embodiment of the present application can significantly reduce the number of transit hops through the API Gateway during the API routing forwarding process brought about by a single API request. When the two-layer gateway deployment technology is adopted, the first-layer API gateway cluster will forward the API request to the second-layer gateway cluster, and then the second-layer gateway will directly forward it to the backend upstream server. That is, every API request has a 100% probability of passing through 2 gateway instances to reach the backend microservice, and the ratio of 2 hops is 100%. For the same-layer peer API Gateway gateway cluster with API forward capability described in this application, each cluster has its own direct routing forwarding work to be responsible for. It only needs to forward the API that other API Gateway clusters are responsible for forwarding to another Gateway in a forward manner before the second hop request needs to pass through the second gateway instance.

[0070] The embodiment of the present application is based on the same-layer peer-to-peer API Gateway cluster networking technology, and can also support unitized deployment of API Gateway clusters according to the business production line dimension. Each unit API Gateway cluster is responsible for a part of the direct routing and forwarding work to achieve fault isolation. Each unit API Gateway cluster can also perceive each other and collaborate with each other to complete the API routing distribution work, ultimately realizing the same-layer peer-to-peer networking.

[0071] Among them, same-layer equality, on the one hand, means that the location relationship of API Gateway clusters is the same, and there is no distinction between the first layer and the second layer. Both can face both clients and brother API Gateway clusters. On the other hand, it means that the capabilities of API Gateway clusters are also the same, and both can directly forward APIs to directly reachable microservices and indirectly forward APIs to non-directly reachable microservices through API Forward to Gateway.

[0072] The embodiment of the present application is based on the same-layer peer API Gateway cluster networking technology, which can also reduce the backend microservice operation and maintenance workload of the production environment and reduce the complexity of operation and maintenance. In terms of network interoperability, it is not necessary for the API Gateway node to be interconnected with all internal service servers of all business production lines. It can be divided according to business domains, and the API Gateway and business servers of each business domain can be interconnected. This can achieve interoperability of API requests sent to all business domains based on the API Gateway, which can achieve isolation of business network topology and better maintainability.

[0073] The embodiment of the present application is based on the same-layer peer API Gateway cluster networking technology, which can also save the computing resources required to deploy the API Gateway cluster. There is no need to deploy two layers of API Gateway according to twice the actual API request volume like the two-layer gateway deployment technology.

[0074] like Figure 6 As shown, it is a structural diagram of a routing and forwarding system for API requests provided in an embodiment of the present application, including:

[0075] The search module 610 is used to receive an API request through a receiving-end gateway instance, and obtain a destination-end gateway cluster corresponding to the API request by searching a global routing information table.

[0076] Among them, the global routing information table includes the mapping relationship between API and microservices, the mapping relationship between microservices and registration centers, and the mapping relationship between registration centers and API gateway clusters.

[0077] Specifically, the search module 610 is specifically used to obtain the microservice corresponding to the API request by searching the global routing information table; searching the registration center where the microservice is registered in the global routing information table; and searching the destination gateway cluster corresponding to the registration center in the global routing information table.

[0078] In this embodiment, the search module 610 is specifically used to search the destination gateway cluster list bound to the registration center in the global routing information table; when the destination gateway cluster list includes the gateway cluster corresponding to the receiving gateway instance, determine that the destination gateway cluster is equal to the gateway cluster corresponding to the receiving gateway instance; when the destination gateway cluster list does not include the gateway cluster corresponding to the receiving gateway instance, traverse the destination gateway cluster list to determine whether there is a gateway cluster with the same deployment area as the receiving gateway instance in the destination gateway cluster list, if so, use the gateway cluster with the same deployment area as the destination gateway cluster corresponding to the registration center; otherwise, use the first gateway cluster in the destination gateway cluster list as the destination gateway cluster corresponding to the registration center.

[0079] The first forwarding module 620 is configured to forward the API request to a microservice corresponding to the API request through the receiving-end gateway instance when the destination-end gateway cluster is equal to the gateway cluster corresponding to the receiving-end gateway instance.

[0080] The second forwarding module 630 is used to forward the API request to the destination gateway cluster through the receiving gateway instance when the destination gateway cluster is not equal to the gateway cluster corresponding to the receiving gateway instance, and forward the API request to the microservice corresponding to the API request through the destination gateway cluster.

[0081] In this embodiment, the above system further includes:

[0082] The judgment module is used to judge whether the API request is an API request received through the dedicated forwarding entry of the receiving-end gateway instance.

[0083] Accordingly, the search module 610 is specifically used to: when the API request is not an API request received through the dedicated forwarding entry of the receiving gateway instance, obtain the destination gateway cluster corresponding to the API request by searching the global routing information table;

[0084] The first forwarding module 620 is further used to: when the API request is an API request received through the dedicated forwarding entry of the receiving-end gateway instance, forward the API request to the microservice corresponding to the API request through the receiving-end gateway instance.

[0085] In this embodiment, multiple registration centers are deployed in each deployment area, and each microservice has multiple copies registered with multiple registration centers. Different registration centers correspond to different API gateway clusters, and each API gateway cluster has the same deployment area attribute information as the corresponding registration center;

[0086] Furthermore, the above system further includes:

[0087] A configuration module is used to register and manage the global routing information table through the gateway management console, and distribute the global routing information table to all gateway instances of all API gateway clusters in the system; when the global routing information table changes, the changed global routing information table is distributed to all gateway instances of all API gateway clusters in the system.

[0088] The embodiment of the present application shares the API global routing table in the API Gateway cluster, which can accurately forward API requests directly to the target microservice or accurately forward them to the target microservice through other API Gateway clusters at the same level through one hop, thereby completing the API routing forwarding task and achieving the purpose of networking of peer-to-peer API Gateway clusters at the same level. Based on unit deployment and collaborative forwarding capabilities, the stability of the gateway system is enhanced, which can not only achieve isolation of business network topology, but also has good maintainability.

[0089] The embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each process of the routing forwarding method embodiment of the above-mentioned API request is implemented, and the same technical effect can be achieved. To avoid repetition, it is not repeated here. Among them, the computer-readable storage medium, such as read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk, etc.

[0090] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0091] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0092] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims

1. A routing forwarding method for API requests, characterized in that: The following steps are involved: Receive the API request through the receiving gateway instance, and obtain the destination gateway cluster corresponding to the API request by searching the global routing information table; When the destination gateway cluster is equal to the gateway cluster corresponding to the receiving gateway instance, forwarding the API request to the microservice corresponding to the API request through the receiving gateway instance; When the destination gateway cluster is not equal to the gateway cluster corresponding to the receiving gateway instance, the API request is forwarded to the destination gateway cluster through the receiving gateway instance, and the API request is forwarded to the microservice corresponding to the API request through the destination gateway cluster.

2. The method according to claim 1, characterized in that Before obtaining the destination gateway cluster corresponding to the API request by searching the global routing information table, the method further includes: Determining whether the API request is an API request received through a dedicated forwarding entry of the receiving-end gateway instance; The step of obtaining the destination gateway cluster corresponding to the API request by searching the global routing information table specifically includes: In the case where the API request is not an API request received through the dedicated forwarding entry of the receiving-end gateway instance, obtaining a destination-end gateway cluster corresponding to the API request by searching a global routing information table; After determining whether the API request is an API request received through the dedicated forwarding entry of the receiving end gateway instance, the method further includes: In the case where the API request is an API request received through a dedicated forwarding entry of the receiving-end gateway instance, the API request is forwarded to a microservice corresponding to the API request through the receiving-end gateway instance.

3. The method according to claim 1, characterized in that The global routing information table includes the mapping relationship between API and microservice, the mapping relationship between microservice and registration center, and the mapping relationship between registration center and API gateway cluster; The step of obtaining the destination gateway cluster corresponding to the API request by searching the global routing information table specifically includes: Obtain the microservice corresponding to the API request by searching the global routing information table; Search the global routing information table for the registration center where the microservice is registered; The destination gateway cluster corresponding to the registration center is searched in the global routing information table.

4. The method according to claim 3, characterized in that The searching the global routing information table for the destination gateway cluster corresponding to the registration center specifically includes: Searching the global routing information table for a destination gateway cluster list bound to the registration center; In a case where the destination gateway cluster list includes the gateway cluster corresponding to the receiving gateway instance, determining that the destination gateway cluster is equal to the gateway cluster corresponding to the receiving gateway instance; In the case that the destination gateway cluster list does not include the gateway cluster corresponding to the receiving gateway instance, the destination gateway cluster list is traversed to determine whether there is a gateway cluster in the destination gateway cluster list that has the same deployment area as the receiving gateway instance; if so, the gateway cluster with the same deployment area is used as the destination gateway cluster corresponding to the registration center; otherwise, the first gateway cluster in the destination gateway cluster list is used as the destination gateway cluster corresponding to the registration center.

5. The method according to claim 4, characterized in that Multiple registries are deployed in each deployment area. Each microservice has multiple copies registered with multiple registries. Different registries correspond to different API gateway clusters, and each API gateway cluster has the same deployment area attribute information as the corresponding registry. The method further comprises: Register and manage the global routing information table through the gateway management console, and distribute the global routing information table to all gateway instances of all API gateway clusters in the system; When the global routing information table changes, the changed global routing information table is distributed to all gateway instances of all API gateway clusters in the system.

6. A routing and forwarding system for API requests, characterized in that: include: A search module is used to receive an API request through a receiving gateway instance, and obtain a destination gateway cluster corresponding to the API request by searching a global routing information table; A first forwarding module, configured to forward the API request to a microservice corresponding to the API request through the receiving-end gateway instance when the destination-end gateway cluster is equal to the gateway cluster corresponding to the receiving-end gateway instance; The second forwarding module is used to forward the API request to the destination gateway cluster through the receiving gateway instance when the destination gateway cluster is not equal to the gateway cluster corresponding to the receiving gateway instance, and forward the API request to the microservice corresponding to the API request through the destination gateway cluster.

7. The system according to claim 6, characterized in that Also includes: A determination module, used to determine whether the API request is an API request received through a dedicated forwarding entry of the receiving-end gateway instance; The search module is specifically used to: when the API request is not an API request received through the dedicated forwarding entry of the receiving-end gateway instance, obtain the destination-end gateway cluster corresponding to the API request by searching the global routing information table; The first forwarding module is further used to: when the API request is an API request received through the dedicated forwarding entry of the receiving-end gateway instance, forward the API request to the microservice corresponding to the API request through the receiving-end gateway instance.

8. The system according to claim 6, characterized in that The global routing information table includes the mapping relationship between API and microservice, the mapping relationship between microservice and registration center, and the mapping relationship between registration center and API gateway cluster; The search module is specifically used to obtain the microservice corresponding to the API request by searching the global routing information table; Search the registration center where the microservice is registered in the global routing information table; and search the destination gateway cluster corresponding to the registration center in the global routing information table.

9. The system according to claim 8, characterized in that The search module is specifically used to search the destination gateway cluster list bound to the registration center in the global routing information table; when the destination gateway cluster list contains the gateway cluster corresponding to the receiving gateway instance, determine that the destination gateway cluster is equal to the gateway cluster corresponding to the receiving gateway instance; In the case that the destination gateway cluster list does not include the gateway cluster corresponding to the receiving gateway instance, traverse the destination gateway cluster list to determine whether there is a gateway cluster in the destination gateway cluster list that has the same deployment area as the receiving gateway instance; if so, use the gateway cluster in the same deployment area as the destination gateway cluster corresponding to the registration center; Otherwise, the first gateway cluster in the destination gateway cluster list is used as the destination gateway cluster corresponding to the registration center.

10. The system according to claim 9, characterized in that Multiple registries are deployed in each deployment area. Each microservice has multiple copies registered with multiple registries. Different registries correspond to different API gateway clusters, and each API gateway cluster has the same deployment area attribute information as the corresponding registry. The system further comprises: A configuration module is used to register and manage the global routing information table through the gateway management console, and distribute the global routing information table to all gateway instances of all API gateway clusters in the system; when the global routing information table changes, the changed global routing information table is distributed to all gateway instances of all API gateway clusters in the system.

Images