CN114143261B

CN114143261B - Method and system for dynamically routing back-end address by API gateway

Info

Publication number: CN114143261B
Application number: CN202111455384.2A
Authority: CN
Inventors: 张积磊; 栗凯; 朱璐; 玄德
Original assignee: Inspur Cloud Information Technology Co Ltd
Current assignee: Inspur Cloud Information Technology Co Ltd
Priority date: 2021-12-01
Filing date: 2021-12-01
Publication date: 2023-06-27
Anticipated expiration: 2041-12-01
Also published as: CN114143261A

Abstract

The invention discloses a method and a system for dynamically routing a back-end address of an API gateway, which belong to the technical field of cloud computing, and the method and the system are used for realizing the dynamic routing of the API by assembling an actual back-end address by using a defined splicing rule through a query custom parameter value carried in url of a native API; the implementation flow of the method comprises the following steps: the user creates a defined back-end address splicing rule, and the rule is cached in a Redis database of the Kong gateway; creating an API, and selecting to start a dynamic routing function when creating; and issuing an API and writing relevant configuration into a Kong gateway, carrying a parameter value which accords with the rule definition when the API is called, reading the parameter value by an expansion plug-in of Kong, and splicing a back-end address after verifying the parameter according to the rule in a Redis cache. The realization user only needs to create and call an API in the API gateway, so that the back-end interfaces with similar characteristics and different addresses can be called.

Description

Method and system for dynamically routing back-end address by API gateway

Technical Field

The invention relates to the technical field of cloud computing, in particular to a method and a system for dynamically routing a back-end address by an API gateway.

Background

The API gateway encapsulates the system internal architecture, providing a custom API for each client. The API gateway also has other functions such as identity verification, monitoring, load balancing, caching, request fragmentation and management, static response processing and the like.

In an actual application environment, the back-end addresses of APIs of different departments are similar but different, and some APIs with the same path and similar functions can be called only by creating different APIs in the gateway because the back-end addresses are different.

Disclosure of Invention

The technical task of the invention is to provide a method and a system for dynamically routing the back-end address of an API gateway aiming at the defects, which can realize the function that a client can route to different back-end addresses by calling the same API and carrying different parameters, and is convenient for a user to call a back-end interface with similar characteristics but different addresses by only creating and calling one API in the API gateway.

The technical scheme adopted for solving the technical problems is as follows:

a method for dynamically routing back-end address of API gateway, which uses defined splicing rule to assemble actual back-end address to realize API dynamic routing by carrying query custom parameter value in url of original API;

the implementation flow of the method comprises the following steps:

the user creates a defined back-end address splicing rule, and the rule is cached in a Redis database of the Kong gateway;

creating an API, and selecting to start a dynamic routing function when creating;

and issuing an API and writing relevant configuration into a Kong gateway, carrying parameter values of a number conforming to rule definition when the API is called, reading the parameter values by an expansion plug-in of Kong, verifying parameters according to rules in a Redis cache, splicing a back-end address, and routing after verifying validity, so that the function that a client can carry different parameters and route to different back-end addresses when calling the same API is realized.

The method is realized based on a custom Kong plug-in and Redis cache. In the method, the API gateway provides a dynamic routing function, and the opening function firstly needs to define and assign a routing rule and enables the function when creating the API. When the API is called after being released, the corresponding back-end address is disassembled according to the carried parameter information and the affiliated user, so that the effect that one API can access a plurality of back-end addresses is achieved.

Further, the implementation of the method comprises routing rule formulation, API management and API dynamic routing, wherein the routing rule formulation comprises the steps of creating, selecting, deleting and modifying by the routing rule; the API management comprises creation, modification, switch dynamic routing function, release, offline and deletion of API metadata;

the method is characterized in that an API management console creates, selects rules, creates an API, opens a dynamic route when creating the API, issues the API, and performs parameter identification, rule inquiry and route address assembly by an API dynamic route part when calling the API.

Preferably, the method is specifically implemented as follows:

the user creates a defined back-end address splicing rule, which comprises parameter transmission number definition, splicing rule definition and definition of a default back-end address when the parameter transmission number is zero; after definition, storing the defined rule into a database capable of being stored in a lasting mode, and selecting a certain rule as an API for starting a static routing function; if the API does not start the function, the corresponding routing plug-in is not started, the rule is not effective, and the API adopts an original back-end routing strategy;

the user creates an API, selects to open an API dynamic route, and issues after creating;

calling an API, and sequentially designating a specific value of each parameter in the query according to the number of parameters required by the rule;

kong judges whether dynamic routing is started according to configuration, if the function is started, identifying url and parameter transmission, verifying the number and legality of parameters, searching an assembly rule corresponding to a user in a cache in Redis according to user information in the configuration, and performing back-end address assembly; if the correspondence between the parameter transmission number and the rule definition is not up or the assembled address is illegal, reporting errors, not carrying out routing, if the rule is legal, carrying out routing, and if the parameter transmission number is zero, routing a set default back-end address.

Preferably, whether a required back-end address assembly rule exists or not is searched from the Redis, the user id is used as the Key of the query, if the corresponding rule is searched, the Key is returned to Kong, otherwise, the next search is performed;

calling an interface of the back end to inquire whether an assembly rule corresponding to a user exists in the back end persistent storage database, if so, returning the rule, and updating Redis; if not yet found, updating a null value on the user id prevents initiating an invalidation request to the backend.

Preferably, for the assembly rule, a mode of combining a custom character string with a { } symbol is adopted to define the assembly rule;

the string is a known partial backend address;

the { } symbol is used to replace the parameter value to be transferred when calling the API, and the fact that there are several { } symbols in the character string indicates that several parameter values are needed when calling the API.

Preferably, the parameter definition and parameter value transfer settings at the time of calling the API are as follows:

a routing_parameter, which is used as the name of the query parameter, and the content of which is a plurality of parameter values added when calling the API, and is used for assembling the back-end address;

when a user calls an API, a parameter named routing_parameter needs to be added on the basis of url of the original API, the content is a parameter value required in an assembly rule, and each value is separated by using a_separation.

Further, the process of creating the dynamic routing API by the user is as follows:

a user opens a dynamic route definition creating interface, creates a dynamic route assembly rule and stores the dynamic route assembly rule;

selecting a rule as an execution rule when dynamic routing is started, and storing selection information;

the user creates an API, opens the function when creating the API, and stores the API;

releasing an API, updating corresponding dynamic route configuration during release, and writing the configuration into Kong;

the flow of client calling the API is as follows:

the client sends an API call request to the gateway;

the gateway identifies a parameter route_parameter, and marks a segmentation parameter according to "__";

inquiring a routing rule from a user_id to a Redis in API configuration information corresponding to the gateway;

after a series of execution logic, judging whether the final query result is empty, and if so, returning error information;

if the result is not null, analyzing the queried routing rule, identifying the number of parameters, comparing and verifying the number of the parameters segmented by the route_parameter, and if the number is inconsistent, returning an error;

and after the verification is passed, the routing address is assembled, the validity of the assembled address is checked, the routing is carried out if the address is legal, and an error is returned if the address is illegal.

Preferably, the database capable of being stored in a persistent manner, the database at the back end stores the automatic route assembly rule of the user in a persistent manner, the data is stored in a dynamic route table, when the Redis inquires the route assembly rule corresponding to the user Id, the query is carried out again in the table in the database at the back end, and the field requirements of the table are as follows:

id is a unique identification sequence of a routing rule, and one row of data corresponds to one Id and is used as a main key of a table;

user Id, the unique identification sequence of the gateway user;

route assembly rules: using a character string type storage, wherein the field can only store one route assembly rule, if a user has a plurality of rules, storing a plurality of data in the table, and inquiring all route assembly rules under the user through a user Id;

whether the dynamic routing rule tag is set by the current user or not: using boolean values to store, marking whether the rules stored in the line of data are routing assembly rules being used by the user;

deletion of the tag: using Boolean value to store, marking whether the rule is deleted; when the demand of the routing rule setting of the user is not large, the logic deletion mark can be adopted to carry out rule deletion, thereby facilitating data recovery and error checking;

optional fields: the number of parameters contained in the rule is stored in an integer manner, the number of parameters in the routing assembly rule is recorded, and the value can be directly used for comparison with the number of parameters in the parameter values added when the API is called during parameter verification, so that the verification efficiency is accelerated to a certain extent; if the parameter is set, the field is correspondingly added in Redis to keep the query logic consistent.

The invention also claims a system for dynamically routing back-end addresses by an API gateway, comprising an API management console, at least one memory and at least one processor;

the at least one memory for storing a machine readable program;

the at least one processor is configured to invoke the machine-readable program to perform the method for dynamically routing backend addresses by the API gateway described above.

The present invention also claims a computer readable medium having stored thereon computer instructions which, when executed by a processor, cause the processor to perform the above-described method of dynamically routing backend addresses by an API gateway.

Compared with the prior art, the method and the system for dynamically routing the back-end address by the API gateway have the following beneficial effects:

by using the dynamic routing function of the API gateway, the back end address rule to be routed can be flexibly formulated, the dynamic routing can be started or closed according to the requirement, after the function is started, when the client calls the API which is created and released in the gateway by the user, the client only needs to call the same API, and the actual back end API which the client wants to call can be dynamically designated by additionally adding parameters in the query.

For some APIs with the same path and similar functions, because the back-end addresses are different, different APIs need to be created in the gateway to call, and the back-end address dynamic routing function can well solve the problems.

Drawings

FIG. 1 is a design flow diagram of a user created dynamic routing API method provided by an embodiment of the present invention;

fig. 2 is a design flow diagram of a client call API provided by an embodiment of the present invention.

Detailed Description

The invention will be further described with reference to the drawings and the specific examples.

A method for dynamically routing back-end address of API gateway, which is realized based on custom Kong plug-in and Redis cache, uses defined splicing rule to assemble actual back-end address by the query custom parameter value carried in url of original API, realizes API dynamic routing;

the implementation flow of the method comprises the following steps:

In the method, the API gateway provides a dynamic routing function, and the opening function firstly needs to define and assign a routing rule and enables the function when creating the API. When the API is called after being released, the corresponding back-end address is disassembled according to the carried parameter information and the affiliated user, so that the effect that one API can access a plurality of back-end addresses is achieved.

The implementation of the method comprises routing rule establishment, API management and API dynamic routing, wherein the routing rule establishment comprises the steps of creating, selecting, deleting and modifying by the routing rule; the API management comprises creation, modification, switch dynamic routing function, release, offline and deletion of API metadata;

Kong is a high availability based on the nmginx_lua module write, which easily extends the API Gateway project that was sourced by the mashe company. Since Kong is ng nx-based, multiple Kong servers can be horizontally expanded to handle large volumes of network requests by distributing requests evenly to individual servers through a pre-load balancing configuration.

Kong uses a plug-in mechanism for functional customization, and a plug-in set (which may be 0 or n) is executed during the life cycle of the API request response loop. Plug-ins are written using Lua, and there are several basic functions: HTTP basic authentication, key authentication, CORS (Cross-origin Resource Sharing, cross-domain resource sharing), TCP, UDP, file log, API request throttling, request forwarding, and Nginx monitoring.

Redis is one of the most popular NoSQL databases today, redis is an open source written using ANSI C, contains various data structures, supports networking, memory-based, optionally persistent key-value pair storage databases, and has the following properties:

based on memory operation, the performance is high;

support the distributed type, can be expanded infinitely theoretically;

a key-value storage system;

the open source is written by ANSI C language, complies with BSD protocol, supports network, can be based on memory and can be durable log type, key-Value database, and provides API of multiple languages.

Compared with other database types, redis has the characteristics that:

C/S communication model;

a single process single thread model;

rich data types;

the operation is atomic;

persistence;

high concurrency read-write;

the lua script is supported.

Upon joining Kong, each client's request for an API will first arrive at Kong and then be proxied to the final API, between which Kong will execute any installed plug-ins, expanding the API function set, and Kong effectively becomes the entry point for each API.

The method comprises the following specific implementation processes:

For caching:

1) Searching whether a required back-end address assembly rule exists from the Redis, using the user id as a Key of the query, returning to Kong if the corresponding rule is queried, otherwise, performing the next search;

2) Calling an interface of the back end to inquire whether an assembly rule of a corresponding user exists in the back end persistent storage database, if so, returning the rule, and updating Redis; if not yet found, updating a null value on the user id prevents initiating an invalidation request to the backend.

Dynamic routing principle: the API gateway can dynamically assemble and route the back-end addresses according to the parameter transmission, and has the function of accessing a plurality of back-end addresses by one API.

For the assembly rule, a self-defined character string plus { } symbol combination mode is adopted to define the assembly rule;

the string is a known partial backend address;

The parameter definition and parameter value transfer settings at the time of calling the API are as follows:

routing_parameter: as the name of the query parameter, the content is a plurality of parameter values added when calling the API, for assembling the back-end address;

Back-end address rule definition example:

routing_rules：aaa.{}.{}.cn

request example:

http://xxxx.comrouting_parameter＝bbb_ccccc

the backend address of the actual request:

aaa.bbb.ccccc.cn

request failure return:

return format: { "code": "1000", "msg": "Routing address not found" }

The method aims at realizing the call of the same API in the API gateway, and can route to different back-end addresses only by attaching different parameter values, and in certain scenes, a user can conveniently call back-end interfaces with similar characteristics and different addresses only by creating and calling an API in the API gateway.

As shown in fig. 1, the flow design of the user creation dynamic routing API is as follows:

(1) A user opens a dynamic route definition interface, creates a dynamic route assembly rule and stores the dynamic route assembly rule;

(2) Selecting a rule as an execution rule when dynamic routing is started, and storing selection information;

(3) The user creates an API, and opens the function when creating the API, and saves the API;

(4) And the release API updates the corresponding dynamic routing configuration during release and writes the configuration into Kong.

As shown in fig. 2, the flow design of the client calling the API is as follows:

(1) The client sends an API call request to the gateway;

(2) Gateway identification parameter route_parameter, according to "_sign segmentation parameter;

(3) Inquiring a routing rule from a user_id to a Redis in API configuration information corresponding to the gateway;

(4) After a series of execution logic, judging whether the final query result is empty, and if so, returning error information;

(5) If the result is not null, analyzing the queried routing rule, identifying the number of parameters, comparing and verifying the number of the parameters segmented by the route_parameter, and if the number is inconsistent, returning an error;

(6) And verifying the passing of the post-assembly routing address, checking the validity of the assembled address, routing if the address is legal, and returning an error if the address is illegal.

According to the method, the dynamic routing plug-in function of Kong is realized through Lua codes, and Redis is used as a cache database. When carrying parameters and carrying out API call through url, kong plugin can read user id from configuration information of the API when issuing, find corresponding back end address assembly scheme in Redis by taking user id as key, analyze parameter number in scheme, then plugin identifies the transmitted url and routing_parameter in query, judge whether parameter number is matched, if so, address splicing is carried out, address validity detection is carried out, and if so, routing is carried out in accordance with rule.

When the dynamic routing plug-in of Kong does not find the routing scheme corresponding to the user id when inquiring the Redis, the plug-in indicates that the information of the Redis may be invalid at the moment, the plug-in calls a back-end interface to go to a back-end database for further searching, if the rule defined and opened by the user is found, the plug-in is updated to the Redis, and carries out the next verification assembly operation, if the data is still not found, an empty value of the user id is updated in the Redis, so that an invalid request is prevented from being initiated to the back end, an error is returned, and the error information is that the user does not have the custom routing scheme.

When the plug-in unit goes to the Redis again to inquire the routing scheme of the user next time, judging whether the scheme is empty, if so, the plug-in unit does not need to go to the back end for further inquiry, and the information that the routing scheme does not exist is directly returned. If the user updates the routing scheme after the blanking operation, after inquiring the user Id in Redis, the user Id becomes the two conditions of existence of the routing scheme or record invalidation, and the user Id is inquired according to a normal inquiring method.

The user needs to define the assembly rules before calling the API, each user can create a plurality of rules, but only one rule can be validated under one user, each created rule is stored in a back-end database which can be stored in a lasting mode, and the rule which is selected to be validated is written in Redis for Kong to search in addition to the back-end database.

In addition to defining the assembly rules, the user additionally needs to set a default routing address for each rule. After the dynamic routing function is started and released when the API is created, the plug-in will automatically route to the address when the API is called but the routing_parameter parameter is not carried. And when the user does not start the automatic routing function and does not carry the routing_parameter, the routing plug-in is not effective, and Kong will execute the original routing strategy.

Original routing policy description: the gateway does not use the routing policy of the automatic routing function, and typically routes directly to the backend address filled in when the api is created.

Redis cache format:

storing application and API authorization relationships using a hash format

Plug-in configuration:

the back-end queries the interface of the route assembly rule:

the authentication data in Redis is not persisted, and Kong will carry token calling API to manage the back-end interface to query the route assembly rule in the back-end database after failure.

The request mode is as follows: GET (GET)

Request address: xxxxx

header:

H-Token:xxxxxxxxxxxxxxx

query：user_id:xxxxxxxxx

Request response:

success: { "code": "0", data { "user_id": "xxxxxxxxxxxx", "route_rule": "xxxxxxxxxxxxx", "default_route": "xxxxxxxxxxxxx" } "

Failure: { "code": "XXXX", message: "XXXXXXXXXXXXXXXXXXX" }

And (3) designing a field of a back-end database table:

the database of the back end permanently stores the automatic route assembly rule of the user, the data is stored in a dynamic route table, when the Redis inquires the route assembly rule corresponding to the user Id, the user is inquired again in the table in the back end database, and the field requirements of the table are as follows:

user Id, the unique identification sequence of the gateway user;

storing the dynamic routing rule tag set by the current user by using a Boolean value, and marking whether the rule stored in the row of data is a routing assembly rule used by the user or not;

deletion of the tag: the Boolean value is used for storage, whether the rule is deleted or not is marked, the demand of the user for setting the routing rule is not large, and the logic deletion mark can be used for rule deletion, so that data recovery and error checking are facilitated.

Optional fields: the number of parameters contained in the rule is stored in an integer manner, the number of parameters in the routing assembly rule is recorded, and the value can be directly used for comparison with the number of parameters in the routing_parameter when the parameter is checked, so that the checking efficiency is accelerated to a certain extent. If the parameter is set, the field is correspondingly added in Redis to keep the query logic consistent.

Dynamic routing address transfer:

transmission route parameters

When the client calls the API, the following parameters are required to be put in an HTTP request and transmitted to an API gateway for signature verification, and currently tentatively put in a query:

routing_parameter: parameter values required for dynamic route assembly, and using "_" to distinguish each parameter value

Request examples of query transfer:

http://demo.comrouting_parameter＝xxxxx_xxx_xxxxxx

return code description:

the embodiment of the invention also provides a system for dynamically routing the back-end address of the API gateway, which comprises an API management console, at least one memory and at least one processor;

the at least one memory for storing a machine readable program;

the at least one processor is configured to invoke the machine-readable program to perform the method for dynamically routing backend addresses by the API gateway according to the above-described embodiments of the present invention.

The embodiment of the invention also provides a computer readable medium, wherein the computer readable medium stores computer instructions, and the computer instructions, when executed by a processor, cause the processor to execute the method for dynamically routing the backend address by the API gateway according to the embodiment of the invention. Specifically, a system or apparatus provided with a storage medium on which a software program code realizing the functions of any of the above embodiments is stored, and a computer (or CPU or MPU) of the system or apparatus may be caused to read out and execute the program code stored in the storage medium.

In this case, the program code itself read from the storage medium may realize the functions of any of the above-described embodiments, and thus the program code and the storage medium storing the program code form part of the present invention.

Examples of the storage medium for providing the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (e.g., CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), a magnetic tape, a nonvolatile memory card, and a ROM. Alternatively, the program code may be downloaded from a server computer by a communication network.

Further, it should be apparent that the functions of any of the above-described embodiments may be implemented not only by executing the program code read out by the computer, but also by causing an operating system or the like operating on the computer to perform part or all of the actual operations based on the instructions of the program code.

Further, it is understood that the program code read out by the storage medium is written into a memory provided in an expansion board inserted into a computer or into a memory provided in an expansion unit connected to the computer, and then a CPU or the like mounted on the expansion board or the expansion unit is caused to perform part and all of actual operations based on instructions of the program code, thereby realizing the functions of any of the above embodiments.

While the invention has been illustrated and described in detail in the drawings and in the preferred embodiments, the invention is not limited to the disclosed embodiments, and it will be appreciated by those skilled in the art that the code audits of the various embodiments described above may be combined to produce further embodiments of the invention, which are also within the scope of the invention.

Claims

1. A method for dynamically routing back-end addresses of an API gateway is characterized in that the back-end addresses are assembled into actual back-end addresses by using defined splicing rules through query custom parameter values carried in url of a native API, so that the dynamic routing of the API is realized;

the implementation flow of the method comprises the following steps:

the user creates a defined back-end address splicing rule, which comprises parameter transmission number definition, splicing rule definition and definition of a default back-end address when the parameter transmission number is zero; for the splicing rule, a mode of combining a custom character string with { } symbols is adopted to define the splicing rule: the character string is a known part of back end address, the { } symbol is used for replacing parameter values to be transferred when the API is called, and a plurality of { } symbols in the character string indicate that a plurality of parameter values are needed when the API is called; caching the back-end address splicing rule in a Redis cache of a Kong gateway;

releasing an API and writing plug-in configuration into a Kong gateway, carrying parameter values which are consistent with the definition of a back-end address splicing rule when the API is called, reading the parameter values by an expanding plug-in of Kong, splicing the back-end address after verifying the parameters according to the back-end address splicing rule in a Redis cache, carrying out routing after verifying validity, and calling the same API by a client to carry different parameters to route to different back-end addresses;

when a user calls an API, a parameter named routing_parameter needs to be added on the basis of url of the original API, the content is a parameter value required in a back-end address splicing rule, and each value is separated by using a_separation.

2. The method for dynamically routing back-end addresses of an API gateway as recited in claim 1, wherein the method comprises routing rule creation, API management and API dynamic routing, the routing rule creation comprising creating, selecting, deleting and modifying routing rules; the API management comprises creation, modification, switch dynamic routing function, release, offline and deletion of API metadata;

the method is characterized in that an API management console creates, selects a routing rule, creates an API, opens a dynamic route when creating the API, issues the API, and performs parameter identification by an API dynamic route part when calling the API, routing rule inquiry and routing address assembly after routing operation.

3. A method for dynamically routing backend addresses by an API gateway according to claim 1 or 2, characterized in that the method is implemented as follows:

the user creates a defined back-end address splicing rule, which comprises parameter transmission number definition, splicing rule definition and definition of a default back-end address when the parameter transmission number is zero; after definition, storing the defined rule into a rear-end persistent storage database, and selecting a certain rule as an API for starting a static routing function; if the API does not start the function, the corresponding routing plug-in is not started, the back-end address splicing rule is not effective, and the API adopts an original back-end routing strategy;

calling an API, and sequentially designating a specific value of each parameter in the query according to the number of parameters required by a back-end address splicing rule;

kong judges whether dynamic routing is started according to configuration, if the function is started, identifying url and parameter transmission, verifying the number and legality of parameters, searching a back end address splicing rule corresponding to a user in a Redis cache according to user information in the configuration, and performing back end address assembly; if the correspondence between the parameter transmission number and the rule definition is not up or the assembled address is illegal, reporting errors, not carrying out routing, if the rule is legal, carrying out routing, and if the parameter transmission number is zero, routing a set default back-end address.

4. The method for dynamically routing back-end addresses of an API gateway according to claim 3, wherein whether a back-end address splicing rule is needed is searched from a Redis cache, a user id is used as a Key of the query, if the corresponding rule is queried, the Key is returned to Kong, otherwise, the next search is performed;

calling a back-end interface to inquire whether a back-end address splicing rule corresponding to a user exists in a back-end persistence storage database, if so, returning the rule, and updating a Redis cache; if not yet found, updating a null value on the user id prevents initiating an invalidation request to the backend.

5. The method for dynamically routing back-end addresses of an API gateway as recited in claim 4, wherein the process of creating the dynamic routing API by the user is as follows:

the user creates an API, opens the dynamic routing function when creating the API, and stores the API;

the flow of client calling the API is as follows:

the client sends an API call request to the gateway;

inquiring a routing rule from a user_id to a Redis cache in API configuration information corresponding to the gateway;

after the execution logic for creating the dynamic routing API flow and the execution logic for calling the API flow by the client, judging whether a final query routing rule result is empty or not, and returning error information if the final query routing rule result is empty;

and after the verification is passed, the routing address is spliced, the validity of the spliced routing address is checked, the routing is carried out if the spliced routing address is legal, and an error is returned if the spliced routing address is illegal.

6. A method for dynamically routing a back-end address of an API gateway as claimed in claim 3, wherein said back-end persistence stores a database for persisting a user's back-end address splice rule, the back-end address splice rule data is stored in a dynamic routing table, and when the Redis cache query fails to find the back-end address splice rule corresponding to the user Id, the query is performed again in the dynamic routing table in the back-end database, and the fields of the dynamic routing table include:

user Id, the unique identification sequence of the gateway user;

deletion of the tag: using Boolean value to store, marking whether the rule is deleted; the logical deletion mark is adopted for regular deletion, so that data recovery and error checking are facilitated;

optional fields: the number of parameters contained in the rule is stored in integer form, the number of parameters in the route assembly rule is recorded, and the value can be directly used for comparison with the number of parameters in the parameter values added when the API is called during parameter verification; if the parameter is set, the optional field is correspondingly added in the Redis cache to keep the query logic consistent.

7. A system for dynamically routing backend addresses by an API gateway comprising an API management console and at least one memory and at least one processor;

the at least one memory for storing a machine readable program;

the at least one processor being configured to invoke the machine readable program to perform the method of any of claims 1 to 6.

8. A computer readable medium having stored thereon computer instructions which, when executed by a processor, cause the processor to perform the method of any of claims 1 to 6.