CN113938527B

CN113938527B - Extension processing method of API gateway, computing device and storage medium

Info

Publication number: CN113938527B
Application number: CN202111013431.8A
Authority: CN
Inventors: 韩勇; 林佳梁
Original assignee: Alibaba China Co Ltd; Alibaba Cloud Computing Ltd
Current assignee: Alibaba China Co Ltd; Alibaba Cloud Computing Ltd
Priority date: 2021-08-31
Filing date: 2021-08-31
Publication date: 2024-04-26
Anticipated expiration: 2041-08-31
Also published as: CN113938527A

Abstract

The embodiment of the application provides an expansion processing method, computing equipment and storage medium of an API gateway, wherein in the embodiment of the application, an access request is received through an original service corresponding to the API gateway; forwarding request information corresponding to the access request to an expansion service in the API gateway through the corresponding original service, processing the request information through the expansion service and returning a processing result to the corresponding original service, wherein the expansion service and the original service are mutually independent; and receiving the processing result through the corresponding original service, and processing the access request according to the processing result. And forwarding the request information corresponding to the access request to the expansion service through the original service, processing the request information corresponding to the expansion service through the expansion service, and returning a processing result to the corresponding original service, so that the API gateway can realize the expansion service. Meanwhile, the expansion service and the original service are independent, so that the expansion service and the original service are not limited by the influence of the original service.

Description

Extension processing method of API gateway, computing device and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to an API gateway extension processing method, a computing device, and a storage medium.

Background

Since the gateway is one of the most important components of the application production environment, the performance and stability of the gateway need to be guaranteed to the greatest extent. In order to help the gateway user to quickly and conveniently implement various extension functions such as unified flow control, it is important how to implement the extension functions conveniently and reliably.

Disclosure of Invention

Aspects of the present application provide an extension processing method, a computing device, and a storage medium for an API gateway, so as to implement an extension function of the API gateway conveniently and reliably.

The embodiment of the application provides an extension processing method of an API gateway, which comprises the following steps: receiving an access request through an original service corresponding to an API gateway, wherein the access request is used for accessing a target service through the API gateway; forwarding the request information corresponding to the access request to an expansion service in an API gateway through an original service corresponding to the API gateway, processing the request information through the expansion service and returning a processing result to the original service corresponding to the API gateway, wherein the expansion service and the original service are mutually independent; and receiving a processing result through the original service corresponding to the API gateway, and processing the access request according to the processing result.

The embodiment of the application also provides an Nginx gateway, which comprises: a first sub-process for running a first service and a second sub-process for running an extended service; the first subprocess receives an access request, wherein the access request is used for accessing a target service through an Nginx gateway; the first subprocess forwards the request information corresponding to the access request to a second subprocess running the extension service; the second subprocess carries out corresponding expansion service processing on the request information and returns a processing result to the corresponding first subprocess; and the first subprocess receives the processing result and processes the access request according to the processing result.

The embodiment of the application also provides a computing device, which comprises: a memory, a processor; the memory is used for storing a computer program; the processor executes the computer program for: receiving an access request through an original service corresponding to an API gateway, wherein the access request is used for accessing a target service through the API gateway; forwarding the request information corresponding to the access request to an expansion service in an API gateway through an original service corresponding to the API gateway, processing the request information through the expansion service and returning a processing result to the original service corresponding to the API gateway, wherein the expansion service and the original service are mutually independent; and receiving a processing result through the original service corresponding to the API gateway, and processing the access request according to the processing result.

Embodiments of the present application also provide a computer-readable storage medium storing a computer program which, when executed by one or more processors, causes the one or more processors to implement the steps in the above-described method.

In the embodiment of the application, an access request is received through an original service corresponding to an API gateway, and the access request is used for accessing a target service through the API gateway; forwarding request information corresponding to the access request to an expansion service in the API gateway through an original service corresponding to the API gateway, processing the request information through the expansion service and returning a processing result to the original service corresponding to the API gateway, wherein the expansion service and the original service are mutually independent; and receiving a processing result through the original service corresponding to the API gateway, and processing the access request according to the processing result.

The method comprises the steps of forwarding request information corresponding to an access request to an expansion service in an API gateway through an original service corresponding to the API gateway, processing the request information through the expansion service to correspond to the expansion service, and returning a processing result to the original service corresponding to the API gateway, so that the API gateway can realize the expansion service. Meanwhile, as the extension service and the original service are mutually independent, the extension service and the original service of the API gateway are in a decoupled state, and the extension service and the original service are not limited by the influence of the original service. And even if the expansion service is abnormal, the original service of the API gateway can maintain the stability and the performance of the original service well due to the fact that the expansion service and the expansion service are independent of each other.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:

FIG. 1 is a flow chart of an extension processing method of an API gateway according to an exemplary embodiment of the present application;

FIG. 2 is a schematic diagram of the process of the expansion process according to an exemplary embodiment of the present application;

FIG. 3 is a schematic diagram of the architecture of an API gateway according to an exemplary embodiment of the present application;

FIG. 4 is a schematic diagram of an extended processing system of an API gateway according to an exemplary embodiment of the present application;

fig. 5 is a schematic structural diagram of an nginnx gateway according to an exemplary embodiment of the present application;

Fig. 6 is a schematic structural diagram of an extension processing apparatus of an API gateway according to an exemplary embodiment of the present application;

FIG. 7 is a schematic diagram of a computing device according to an exemplary embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

From the foregoing, it is clear that since the gateway is one of the most important components of the application production environment, the performance and stability thereof need to be guaranteed to the greatest extent. In order to help the gateway user to quickly and conveniently implement various extension functions such as unified flow control, it is important how to implement the extension functions conveniently and reliably.

Based on this, the embodiment of the application provides an extension processing method, a computing device and a storage medium of an API gateway, which can conveniently and reliably realize the extension function of the API gateway.

The following describes the extension process of the API gateway in detail in connection with the method embodiment.

Fig. 1 is a flowchart of an extension processing method of an API gateway according to an exemplary embodiment of the present application. The method 100 provided by the embodiment of the present application is performed by a computing device, which may be a server device in particular. The method 100 comprises the steps of:

101: and receiving an access request through the original service corresponding to the API gateway.

Wherein the access request is for accessing the target service through the API gateway.

102: And forwarding the request information corresponding to the access request to the expansion service in the API gateway through the original service corresponding to the API gateway, processing the request information through the expansion service and returning a processing result to the original service corresponding to the API gateway.

Wherein the extended service is independent of the original service.

103: And receiving a processing result through the original service corresponding to the API gateway, and processing the access request according to the processing result.

The following is a detailed description of the above steps:

The API (Application Programming Interface, application program interface) gateway refers to a unified access portal for an application (e.g., a target service) to provide services to the outside, and is one of important components of a user and cloud native application production deployment, and may also be referred to as an application access portal. For example, an nmginx gateway (a widely used open source high performance HTTP (Hyper Text Transfer Protocol, hypertext transfer protocol) gateway is widely used as an API gateway for the HTTP protocol).

The original service corresponding to the API gateway may refer to an original service of the API gateway, for example, receiving an access request, filtering the access request, forwarding the access request, and the like. The original service may be a native service of the API gateway, i.e. a service provided by the API gateway itself, or a service developed again based on the native service, such as OpenResty (which is a core Web application service based on nglnx), kong (which is an API gateway and a micro service management layer with high performance and reliability).

The target service refers to a service that the access request is ultimately to access, and may be deployed on other devices, such as other servers. The target service may be a data query service, a video play service, a game service, etc.

For example, a user may access a data query service on a cloud server through a web browser client of a computer, such as a database, and the user may send an HTTP access request to a target cloud server through the web browser client to perform a data query, where the request may first pass through an API gateway, such as an nginnx gateway. I.e. the nginix gateway receives the access request through its own receiving service. It will be appreciated that the access request will carry some necessary parameters and data, i.e. access information such as query keywords etc., domain names, physical addresses of computers etc.

In order to better implement gateway services, request processing may be performed in a multi-process manner.

Specifically, receiving an access request through an original service corresponding to an API gateway includes: and receiving a plurality of access requests, and distributing the access requests to a first service in the original services, wherein the first service runs in each corresponding sub-process.

The first service may be a function for implementing forwarding the request, which may be a piece of instruction or code, or may perform other functions, which implement a function of sending the request to either the target service or to the extended service. Which runs within a sub-process of the API gateway. The starting mode can be as follows:

specifically, the original service has a second service running in a corresponding main process, and the method 100 further includes: and starting a plurality of subprocesses through a second service in the main process, and running corresponding first services through the subprocesses so as to forward the request information to the expansion service through the first services.

The second service may be a function for implementing a management API gateway, and may be a piece of instruction or code, such as starting the first service and expanding the service. The corresponding service may also be turned off. Which runs in the main process of the API gateway.

For example, according to the foregoing, when an API gateway, such as an nginix gateway, starts to operate, its main process is started for operating the second service. Then, a plurality of sub-processes of the gateway are started through a second service in the main process, each of the sub-processes being used to run the first service, implement a function of forwarding a request to a target service, and send the request to an extended service.

And the second service in the main process firstly closes a plurality of sub-processes when the operation needs to be finished, the corresponding service is finished, and then the second service is closed.

After starting the sub-process for running the first service, the physical device where the nginnx gateway is located receives the access request. The access request may then be distributed to the sub-process by the operating system of the physical device, such that the first service in the sub-process processes the access request, such as to an extension service.

Besides, the first service in the sub-process may forward the access request to other application services on the physical device where the gateway is located, where the other application services are running in its own process, and the services are used to implement the functions of the extended service.

Wherein the extended service is an added service outside the original service, which may be added according to the user's needs or demands, with respect to the original service. Such as flow management, illegal access, etc. The extended service may be a piece of instructions or code. And in order that the extended service does not interfere with or be subject to the original service, the extended service and the original service need to be independent from each other.

The independent mode can be independent through the mode between the sub-processes, or independent through the mode between the sub-processes and other processes. Wherein the extended services may be implemented by Sidecar independent program components, which may be run as independent programs.

For example, according to the foregoing, an API gateway, such as an nginix gateway, after receiving an access request, the original service may directly send the access request or the access information carried in the request to an extension service in Sidecar isolated from the access request, for performing flow control and illegal access, where the Sidecar is also deployed on a physical device where the gateway is located. The extended service in Sidecar is enabled to process the access request and return a corresponding processing result.

Specifically, forwarding request information corresponding to an access request to an extension service in an API gateway through an original service corresponding to the API gateway includes: and forwarding the request information to an extension service running in the subprocess in the API gateway through a first service running in the subprocess in the API gateway.

When the extension service also runs in the sub-process in the main process, the starting mode is as follows:

specifically, a sub-process of the extension service is started through a second service in the main process corresponding to the API gateway, and the corresponding extension service is operated through the sub-process, so that the request information is processed through the extension service.

For example, according to the foregoing, after the main process is started, a sub-process of the extended service, such as Sidecar process (also referred to as a sub-process, i.e., a process of Sidecar independent program component is regarded as a sub-process of the extended service) may be started through the second service running thereon, so that the sub-process runs the corresponding extended service, and the starting process of the sub-process is similar to that of the foregoing.

It should be noted that, in order to avoid the constraint and influence of the function codes of the API gateway, such as the nginix gateway, that is, the original service and the extended service, the main implementation part of the function of the extended service is implemented by a separate program component, such as Sidecar, on the whole framework. The implementation code corresponding to Sidecar thus independently maintains and builds packages, and is completely decoupled from the API gateway's own code. However, as can be seen from the foregoing, the Sidecar process may accompany the process running on the API gateway, but it will run in a separate sub-process, so as to avoid that the exception in the Sidecar process running affects the process on the API gateway. The API gateway itself adopts a multi-process architecture, and the process of Sidecar is controlled by the main process of the API gateway as the self-process of the API gateway.

In order to enable a convenient operation and maintenance user or a research and development user to conveniently start an extended service, the start and the shut-down of a process of the extended service can be managed through an intermediate management component. Therefore, the corresponding user does not need to pay attention to how to start the process (or the subprocess) of the extended service, but only needs to reasonably arrange the intermediate management component and reasonably trigger the intermediate management component, so that the starting and the closing of the process (or the subprocess) of the extended service can be realized, and the development, operation and maintenance time and the cost are reduced.

More specifically, starting a sub-process of the extended service through a second service in the main process corresponding to the API gateway, including: and reading the configuration file of the API gateway through the second service in the main process, loading the dynamic module, and starting the subprocess of the expansion service through the loaded dynamic module so as to enable the subprocess to run the corresponding expansion service.

Wherein the dynamic module is the above-mentioned intermediate management component. It may have the function of managing the processes (or sub-processes) of the extended service. For example, operations such as starting and stopping of Sidecar processes are encapsulated and controlled by the dynamic module, and Sidecar belongs to an internal implementation framework of the dynamic module and is not perceived by a user.

For example, after the main process is started, the configuration file of the nginnx gateway may be read, so as to load the dynamic module, and after the dynamic module is loaded, a sub-process of the extended service, such as Sidecar processes, is started, so that the sub-process runs the corresponding extended service. The starting of this sub-process is the same as the starting of the sub-process described above.

In contrast, the dynamic module may also shut down sub-processes of the extended service. And will not be described in detail.

Thus, information transmission between sub-processes can be performed. For example, as shown in fig. 2, a process 200 of an expansion process is shown. According to the foregoing, the user sends, to the nglnx gateway, through the web browser client of the computer, i.e. the client 201, the Http access request a, which is distributed to a sub-process 202 running the first service, i.e. the client 201 performs step 211 to the sub-process 202 of the first service of the gateway: and sending an Http access request A. After the sub-process 202 running the first service receives the request, step 212 is executed: the request information corresponding to access request a is sent to a sub-process running an extended service, such as Sidecar process, sidecar independent program component 203.Sidecar upon receipt of this information, the independent program component 203 performs step 214: request information corresponding to the access request a is processed, for example, a flow management process is performed, so as to return a processing result to the sub-process 202 running the first service. Wherein Sidecar the independent program component 203 and the sub-process 202 of the first service belong to an API gateway 204, such as an nginnx gateway.

It should be noted that, for an application deployed on a physical device where an API gateway is located and used for implementing an extended service, the application may also be started by the physical device, where the application has a process mode belonging to itself, and then interact with a process where the application is located through a sub-process where the first service is located, so that an access request is sent to the application, so that the application performs processing of a corresponding extended service.

The first service in the sub-process can also be implemented by the intermediate management component when interacting with the extended service in the sub-process. That is, the component may interact with the extended services in the sub-process in addition to managing the sub-process of the extended services. Thus, the corresponding user does not need to be concerned about how the first service interacts with the extension service.

Specifically, forwarding, by a first service running in a sub-process in the API gateway, request information to an extension service running in the sub-process in the API gateway includes: and calling a dynamic module in the first service through the first service in the subprocess, and forwarding the request information to an extension service running in the subprocess in the API gateway.

The dynamic module may be loaded in the configuration file as described above, and may be invoked by the first service in the first service. I.e. the dynamic module is part of the first service.

For example, according to the foregoing, the sub-process running with the first service may call its own dynamic module, through which the request information is sent to the extended service running in the sub-process (e.g., sidecar process).

In addition, since the interaction between the extended service and the first service belongs to the interaction between the processes, the interaction can also be performed in an inter-process manner.

Specifically, forwarding, by a first service running in a sub-process in the API gateway, request information to an extension service running in the sub-process in the API gateway includes: and sending the request information to the expansion service running in the subprocess through the first service running in the subprocess in an inter-process communication mode.

The Inter-process communication mode (IPC, inter-Process Communication, inter-process communication) may be determined according to an operating environment deployed by the API gateway, for example, the nginnx gateway may be deployed in an environment of the Linux operating system, where a Unix Domain Socket communication mode may be used for communication.

More specifically, the dynamic module is invoked by the first service running in the sub-process, and the corresponding request information is sent to the extended service running in the sub-process (such as Sidecar process) according to the communication mode between the processes, such as Unix Domain Socket communication mode.

For example, according to the foregoing, the first service running in the sub-process may send the request information to the extended service running in the sub-process through Unix Domain Socket communication means. Or alternatively, the first and second heat exchangers may be,

The first service running in the sub-process may send the request information to the extended service running in the sub-process (e.g., sidecar process) by invoking its own dynamic module and communicating via Unix Domain Socket. Thus, the dynamic module can actively access Sidecar the extended functionality provided by the process as needed through inter-process communication. And will not be described in detail.

The communication mode among the processes can be realized by a memory copying mode:

specifically, through a communication manner between processes, the request information is sent to an extension service running in a sub-process through a first service running in the sub-process, including: storing the request information into a first memory corresponding to a first service through the first service running in the subprocess; copying the request information in the first memory to a second memory of the operating system through an operating system deployed by the API gateway; and copying the request information in the second memory into a third memory corresponding to the expansion service running in the subprocess through the operating system so that the expansion service acquires the request information.

More specifically, it may also be: the dynamic module is invoked by the first service running in the sub-process, and sends corresponding request information to the extension service running in the sub-process according to the communication mode between processes, such as Unix Domain Socket communication mode, including: calling a dynamic module through a first service running in a subprocess, and storing request information into a first memory corresponding to the first service; copying the request information in the first memory to a second memory of the operating system through an operating system deployed by the API gateway; and copying the request information in the second memory into a third memory corresponding to the expansion service running in the subprocess through the operating system so that the expansion service acquires the request information.

For example, according to the foregoing, through the first service running in the sub-process, the request information may be saved directly or by calling the dynamic module to the memory corresponding to the first service (the memory is the memory allocated to the sub-process where the first service is located); an operating system deployed through an API gateway, such as a Linux operating system of an Nginx gateway, copies request information in a memory corresponding to a first service to a memory of the operating system (the memory is a memory of the operating system); the method comprises the steps of copying request information in a memory of an operating system to a memory corresponding to an expansion service running in a subprocess (such as Sidecar process) through the operating system, wherein the memory is a memory allocated to the subprocess where the expansion service is located, so that the expansion service obtains the request information from the memory through the subprocess (such as Sidecar process) and performs information processing.

It should be noted that, since the dynamic module can encapsulate the management Sidecar process, the operation and maintenance user or the development user may not perceive Sidecar, sidecar to be transparent. The corresponding user can use the dynamic module adopting Sidecar framework like the common module, and better stability and performance guarantee are obtained.

As can be seen from the foregoing, since the main implementation part of the function of the extended service is implemented by an independent program component, such as Sidecar, the decoupled Sidecar is not limited by the API gateway, and is easier to implement and maintain, and is more convenient to independently perform testing and optimizing. Meanwhile, the corresponding single subprocess is used for communication with the working processes of the API gateways, global information processing can be greatly facilitated, for example, a dynamic module can conveniently uniformly manage and control all access requests under the working processes of the plurality of API gateways (namely, a plurality of subprocesses running with first services) through independent program components, such as Sidecar, and information of the access requests is known.

Meanwhile, the dynamic module belongs to a module developed on the basis of original service, and is matched with a main process of an API gateway to complete the management of a life cycle of an independent program component, such as Sidecar. The dynamic module based on the independent program component, such as Sidecar, delegates the main body realization logic of the function of the extended service to the independent program component, such as Sidecar process, thereby greatly simplifying the realization logic of the dynamic module and greatly reducing the probability of introducing program defects. Meanwhile, the main logic code of the dynamic module can be a shallow package of an IPC client, and can be used as a development framework for rapidly developing other dynamic modules based on independent program components, such as Sidecar.

Thus, it is known that an API gateway, such as an nginnx gateway, may employ a multi-process architecture of a main process and a plurality of working sub-processes, as shown in fig. 3, which illustrates the architecture 300, where the API gateway 204 includes a main process 301, and a plurality of sub-processes a302, which belong to sub-processes of the API gateway 204 itself, i.e. running with a first service, and a sub-process B303, which belongs to sub-processes of an extended service, i.e. running with an extended service.

Through the multi-process framework, the sub-process running with the extended service, such as Sidecar processes, is controlled by the main process as the sub-process running with the first service. And the configuration file can be modified, and the modified content refers to loading and unloading the dynamic module, and supports dynamic loading or unloading of the dynamic module when reload reloads are executed. Wherein, the dynamic module is automatically started Sidecar when being loaded for the first time, and the dynamic module is automatically stopped Sidecar after being unloaded.

In addition, the sub-process running with the extended service, such as Sidecar process and the sub-process running with the first service, run under the same user rights, which may be "nginx" user rights or "www-data" user rights.

If a sub-process running with an extension service is abnormally exited, such as Sidecar processes, a message is sent to the main process through the operation of the API gateway to inform the main process that the sub-process is closed, the main process can determine whether the process is automatically closed due to the abnormality according to the message (namely, if the main process does not indicate to close the sub-process, the sub-process is abnormally closed), and if the sub-process is abnormally closed, the process is automatically restarted through the dynamic module. Other sub-processes may also restart as such.

In addition, when the dynamic module is not unloaded, the API gateway will restart other working sub-processes only when it is reloaded reload, and will not restart the sub-process running with the extended service, such as Sidecar process, by restarting the dynamic module, so that the process can continuously and stably provide the service.

In addition, in the process of storing information into the memory, or in other words, when information is interacted between processes or between services, a data structure of a message receiving and sending body, such as a binary data structure, that is, a preset stored data structure, can be preset according to the requirement of an extension service, and the information or the message is stored according to the data structure, so that the high performance of the API gateway is further ensured.

In order to enable the API gateway to rapidly handle a large number of requests, interactions between services, or processes, are implemented through asynchronous messaging.

Specifically, forwarding request information corresponding to an access request to an extension service in an API gateway through an original service corresponding to the API gateway includes: and forwarding the request information corresponding to the access request to the extension service in the API gateway according to the asynchronous message communication mode through the original service.

More specifically, forwarding, by a first service running in a sub-process in an API gateway, request information to an extension service running in the sub-process in the API gateway, includes: and forwarding the request information corresponding to the access request to the expansion service running in the subprocess according to the asynchronous message communication mode through the first service running in the subprocess.

More specifically, the method for forwarding the request information to the extension service running in the subprocess in the API gateway by calling the dynamic module in the first service through the first service in the subprocess comprises the following steps: and calling a dynamic module in the first service through the first service in the subprocess, and forwarding the request information to an expansion service running in the subprocess in the API gateway according to the asynchronous message communication mode.

For example, according to the foregoing, asynchronous messaging is used between a sub-process running a first service, such as in an nmginx gateway, and a sub-process running an extended service, such as Sidecar processes, in an API gateway. As shown in FIG. 2, after the sub-process 202 running the first service in the Nginx gateway sends the request information to the Sidecar process (i.e., sidecar independent program component 203), it will immediately continue to process other requests without waiting for Sidecar to return the result. The client 201 performs step 213: sending Http access request B to the sub-process 202 running the first service in the nmginx gateway, where the sub-process 202 running the first service in the nmginx gateway immediately processes the request, performing step 215: request information corresponding to access request B is sent to Sidecar independent program component 203 without waiting Sidecar for independent program component 203 to return a return result for access request a.

In addition, after the Sidecar independent program component 203 executes the result of completing the information processing, a message is sent to notify the sub-process 202 running the first service in the corresponding nmginx gateway, if the flow control checks that the access request a should be intercepted, the sub-process 202 running the first service in the corresponding nmginx gateway is notified, and then the sub-process 202 running the first service in the corresponding nmginx gateway intercepts the request.

It should be noted that the stability and high performance of Sidecar are achieved by the high-performance IPC and asynchronous messaging modes described above. Meanwhile, the performance requirement of the API gateway at the flow peak value can be met, so that the API gateway can process a large number of requests faster at the time of the flow peak value.

To avoid affecting the original services of the API gateway due to anomalies in the extended services, this can also be achieved by downgrading the extended services.

Specifically, the method 100 further includes: and in the preset time, if the original service corresponding to the API gateway does not receive the processing result, directly processing the original service on the access request.

For example, according to the foregoing, the API gateway, such as the sub-process running with the first service of the nginnx gateway, may set a preset time, which is aimed at the return time of the processing result of the sub-process running with the extended service, such as Sidecar processes, and the time may be very short (such as in milliseconds), when the preset time is exceeded, the sub-process running with the first service still does not receive the feedback message of the sub-process running with the extended service, such as Sidecar processes, and the sub-process running with the first service ignores the Sidecar process feedback result and continues to complete the normal processing of the corresponding access request, such as directly forwarding the access request to the target service.

It should be noted that, the preset time may be set within a controllable range, for example, the controllable range is 5 ms, and then the preset time is less than or equal to 5 ms. The condition of timeout does not occur under the condition that Sidecar processes normally run, because after timeout, the API gateway can not process the result returned by Sidecar processes any more, even if the subsequent Sidecar processes return the processing result, the API gateway can not process the processing result any more, because it can process the corresponding access request according to the normal program of itself, such as directly forwarding the access request. Whereby Sidecar processes do not affect the stability and performance of API gateways, such as the nginnx gateway, in any case, if Sidecar processes are not available, the API gateway will automatically downgrade the extended functionality provided by Sidecar processes and then continue to run its own programs normally. The API gateway can automatically downgrade the dependence on Sidecar process expansion functions, and Sidecar processes can be prevented from affecting the performance and stability of the API gateway in any scene.

In addition to the above manner, the API gateway may be a self-contained dynamic module (not the dynamic module described above, where the dynamic module belongs to a native service of the gateway, and may be referred to as a native dynamic module hereinafter for distinguishing from the foregoing) of the nginnx gateway. The function module of the extension service is customized and developed for the API gateway, such as the Nginx gateway, can be compiled into a ". So" file under the environment of the GNU/Linux operating system, and supports dynamic loading and unloading when the API gateway runs. The native dynamic module is a component provided to an operation and maintenance user of the API gateway, a research and development user or a deployment script for direct operation and use. The code of the native dynamic module is directly called by the code of the API gateway, for example, the code of the Nginx gateway and the code of the native dynamic module are alternately executed in the same process.

Although it can be implemented by a native dynamic module, it has the following problems with respect to the dynamic modules described above: native dynamic module development is much more limited. The code of the native dynamic module is alternately invoked and executed with the code of the native dynamic module, such as the Nginx gateway, and a conflict may exist between the code of the native dynamic module and the code of the native dynamic module, such as the Nginx gateway, needs to be adapted and coordinated, so that the conflict is avoided. The code of the native dynamic module cannot affect the code of the native dynamic module, such as the nmginx gateway, which may bring a lot of restrictions to the development of the native dynamic module, such as the native dynamic module may use the native dependent libraries of the nmginx gateway, but cannot randomly introduce the program libraries to avoid conflicts with the native dependent libraries of the nmginx gateway. Meanwhile, there are a large number of customized compiled versions for different environments, such as the nmginx gateway, and the native dynamic module needs to be considered compatible with various versions, such as the nmginx gateway, and only one minimum available function set can be used, which brings more restrictions to the development of the native dynamic module.

Furthermore, native dynamic module defects will affect the availability of, for example, an nmginx gateway. Since the code of the native dynamic module is executed in the same process as the process of the nmginx gateway, when the code of the native dynamic module crashes abnormally, the process of the whole nmginx gateway crashes abnormally. Although the multi-process architecture such as the nmginx gateway can be adopted to alleviate the influence generated when a single sub-process crashes, the abnormal request on the working sub-process still can be caused, if the frequent crashes are caused by the program defects of the native dynamic module, the whole usability of the nmginx gateway is still greatly influenced, and the stability of the nmginx gateway is influenced.

In addition, performance issues of the native dynamic module will directly impact the performance of, for example, the nmginx gateway. In addition to the exception crash, when the code of the native dynamic module has a performance problem, the execution path of the code of the Nginx gateway is directly blocked, and the overall performance of the Nginx gateway is slowed down. The dynamic modules developed as described above will not.

In addition, the processing of the corresponding extension service is carried out on the request information through the extension service, and the processing result is returned to the original service corresponding to the API gateway, which comprises the following steps: determining whether an access request corresponding to the request information needs to be intercepted or not according to a threshold value of the access flow through the extension service; and when the access request is determined to be intercepted, returning information representing intercepting the access request to a first service running in a corresponding subprocess in the API gateway so as to intercept the access request through the first service, and returning information representing intercepting the access request to equipment for sending the access request.

For example, according to the foregoing, as shown in fig. 2, the sub-process running with the extended service, such as Sidecar process, that is, sidecar independent program component 203, after receiving the request information of the access request a, performs step 214, such as performing the flow control process, and Sidecar independent program component 203 may determine whether the corresponding access request can normally access the corresponding target service according to the preset access flow of the target service within the preset time, such as the preset access flow threshold within 1 second, for example, the access request number threshold. If the current 1 second contains that the access request has exceeded a threshold, it is determined that the access needs to be intercepted. Then Sidecar independent program component 203 performs step 216: for access request a, information representing the intercept process, such as an HTTP 429 error code, is sent back to the sub-process 202 of the nginix gateway running with the first service. The sub-process 202 with the first service then runs, step 218: information representing the intercept process, such as an HTTP 429 error code, is sent back to the client 201 of the computer for presentation to the user, who may then resend the access request.

Thus, as shown in fig. 2, sidecar the independent program component 203 processes the access request a, and then continues to process the access request B, i.e., step 217 is performed: processing the request information corresponding to the access request B, and if the processing result is that interception is not required, executing step 219: for access request B, information is sent indicating that the request can be forwarded to the sub-process 202 running the first service. After the sub-process 202 running the first service receives the feedback result, step 220 is executed: forwarding the access request B to the target service device.

It should be noted that, when the target service device returns the request result, the request result may also be forwarded to the client of the user computer through the API gateway, which will not be described again.

In addition, the above sub-process running with the extended service, such as Sidecar independent program component, may also perform filtering of illegal access, and may determine whether the current access belongs to a preset list of illegal access according to the request information, if so, intercept the access, and if not, may continue the flow control process, which will not be repeated.

If the access request is not intercepted, the access request is forwarded, and specifically, the method 100 further includes: and when the access request is determined not to be intercepted, returning information representing that the access request can be forwarded to a first service running in a corresponding subprocess in the API gateway so as to forward the access request to target equipment where the corresponding target service is located through the first service.

As already described above, the description is omitted here.

As already described above, the description is omitted here. Only, the processing result may be interception or non-interception, and will not be described in detail.

Fig. 4 is a schematic structural diagram of an extension processing system of an API gateway according to an exemplary embodiment of the present application. As shown in fig. 4, the system 400 may include: a first device 401 and a second device 402. In addition to this, a third device 403 may be included.

The first device 401 may be a device with a certain computing capability, which may implement a function of sending data to the second device 402, or may receive data sent by the second device 402. The basic structure of the first device 401 may include: at least one processor. The number of processors may depend on the configuration and type of device with some computing power. Devices with some computing power may also include Memory, which may be volatile, such as RAM, or nonvolatile, such as Read-Only Memory (ROM), flash Memory, etc., or both. The memory typically stores an Operating System (OS), one or more application programs, program data, and the like. In addition to the processing unit and the memory, the device with certain computing power also includes some basic configurations, such as a network card chip, an IO bus, a display component, and some peripheral devices. Alternatively, some peripheral devices may include, for example, a keyboard, a stylus, and the like. Other peripheral devices are well known in the art and are not described in detail herein. Alternatively, the first device 401 may be a smart terminal, for example, a mobile phone, a desktop computer, a notebook computer, a tablet computer, or the like.

The second device 402 may refer to a device that may provide a computing processing service in a network virtual environment, and may refer to a device that performs an API gateway service using a network. In a physical implementation, the second device 402 may be any device capable of providing a computing service, may be based on an access request, and perform an API gateway service, and may be, for example, a cloud server, a cloud host, a virtual center, a regular server, a physical machine, and the like. The second device 402 is comprised primarily of a processor, hard disk, memory, system bus, etc., similar to a general purpose computer architecture.

The third device 403 may be a device that may provide a computing service in a network virtual environment, and may be a device that provides a target service using a network. In a physical implementation, the third device 403 may be any device capable of providing a computing service, may respond to an access request, and provides a target service, for example, may be a cloud server, a cloud host, a virtual center, a regular server, and the like. The third device 403 mainly comprises a processor, a hard disk, a memory, a system bus, etc., similar to the general computer architecture.

Specifically, the second device 402 receives, through an original service corresponding to the second device 402, an access request, where the access request is used to access, through the second device 402, a target service of the third device 403; forwarding request information corresponding to the access request to an expansion service in the second device 402 through a corresponding original service, so as to process the request information through the expansion service and return a processing result to the corresponding original service, wherein the expansion service and the original service are mutually independent; and receiving the processing result through the corresponding original service, and processing the access request according to the processing result.

Specifically, the first device 401 sends an access request to the second device 402.

Specifically, the second device 402 receives a plurality of access requests, and distributes the access requests to a first service in the original services, where the first service runs in a respective corresponding sub-process.

Specifically, the second device 402 starts a plurality of sub-processes through a second service in the main process, and runs a corresponding first service through the sub-processes, so that the request information is forwarded to the extension service through the first service.

Specifically, the second device 402 forwards the request information to the extension service running in the sub-process in the API gateway through the first service running in the sub-process.

In addition, the second device 402 starts a sub-process of the extended service through a second service in the corresponding main process, and runs the corresponding extended service through the sub-process, so that the request information is processed through the extended service.

Specifically, the second device 402 reads the configuration file of the second device 402 through the second service in the main process, loads the dynamic module, and starts the sub-process of the extended service through the loaded dynamic module, so that the sub-process runs the corresponding extended service.

Specifically, the second device 402 invokes the dynamic module in the first service through the first service in the sub-process, and forwards the request information to the extended service running in the sub-process in the second device 402.

Specifically, the second device 402 sends, through an inter-process communication manner, the request information to the extended service running in the sub-process through the first service running in the sub-process.

Specifically, the second device 402 forwards, through the original service, the request information corresponding to the access request to the extension service in the API gateway according to the asynchronous message communication manner.

In addition, the second device 402 directly processes the original service on the access request if the processing result is not received by the corresponding original service within the preset time.

Specifically, the second device 402 determines, through the extension service, whether the access request corresponding to the request information needs to be intercepted according to the threshold value of the access flow; when it is determined that the access request needs to be intercepted, information indicating that the access request is intercepted is returned to the first service running in the corresponding sub-process in the second device 402, so that the access request is intercepted by the first service, and information indicating that the access request is intercepted is returned to the device that sent the access request.

When no interception is used, the second device 402 forwards the access request to the third device 403.

It should be noted that, the content that cannot be fully described in the system 400 is referred to in the foregoing method 100, and the specific embodiments thereof are also referred to in the foregoing method 100, which is not repeated herein.

In the extension processing scenario of the API gateway according to the embodiment of the present application, as shown in fig. 4, a user may access, through a web browser client of a first device 401, such as a computer, a data query service on a cloud server, such as a database, and the user may send, through the web browser client, an HTTP access request to a third device 403, such as a target cloud server, to perform a data query, where the request needs to first pass through a second device 402, such as a server of a nginnx gateway. I.e. the server of the nginix gateway receives the access request through its own receiving service. That is, the computer performs step 411: and sending an access request to a server of the Nginx gateway.

After the nmginx gateway starts to operate, its main process is started for operating the second service. Then, a plurality of sub-processes of the gateway are started through a second service in the main process, each of the sub-processes being used to run the first service to implement the function of forwarding the request to the target service. After the main process is started, the configuration file of the Nginx gateway can be read, so that a dynamic module is loaded, and after the dynamic module is loaded, a sub-process of the expansion service, such as Sidecar process, is started, so that the sub-process runs the corresponding expansion service. After starting the sub-process for running the first service, the physical device where the nginnx gateway is located receives the access request. The access request may then be distributed to the sub-process by the operating system of the physical device, such that the first service in the sub-process processes the access request, such as to the Sidecar process.

The first service running in the sub-process may send the request information to the extension service in the Sidecar process by calling its own dynamic module and communicating via Unix Domain Socket. After receiving the request information of the access request, the Sidecar process performs flow control processing, and can determine whether the corresponding access request can normally access the corresponding target cloud server according to the threshold value of the number of access requests within 1 second. If the current 1 second contains that the access request has exceeded a threshold, it is determined that the access needs to be intercepted. Then Sidecar process sends information representing the intercept process, such as an HTTP 429 error code, to the child process of the nginix gateway running with the first service, for the access request. The sub-process running the first service then sends information indicative of the interception process, such as returning an HTTP 429 error code, i.e. performs step 412: and sending the information representing interception to a web browser client of the computer for display to a user, wherein the user can resend the access request later.

If interception is not required, the Sidecar process sends information indicating that the request can be forwarded to the sub-process running the first service according to the access request, and after receiving the feedback result, the sub-process running the first service forwards the access request to the target cloud server, namely, step 413 is executed: and forwarding the access request to the target cloud server. After receiving the request, the target cloud server performs data query according to the request, and returns the data query result to the nginnx gateway, that is, step 414 is executed: and sending the result of the request to the Nginx gateway. The nmginx gateway receives the result and performs step 415: and sending the result of the request to a web browser client of the computer for display to the user.

When the preset time is exceeded, the sub-process running with the first service still does not receive the feedback message of the sub-process running with the extended service, such as Sidecar processes, and the sub-process running with the first service ignores Sidecar process feedback results and continues to complete normal processing of the corresponding access request, such as directly forwarding the access request to the target service.

Details not described herein may be referred to the foregoing and will not be repeated.

In the present embodiment described above, the first device 401, the second device 402, and the third device 403 are network-connected. If the network connection is a communication connection, the network system of the mobile network may be any of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 4g+ (lte+), wiMax, 5G, and the like.

Based on a similar inventive configuration, fig. 5 is a schematic structural diagram of an nginnx gateway according to an exemplary embodiment of the present application. As shown in fig. 5, the nginnx gateway 500 may include: a first sub-process 501 for running a first service and a second sub-process 502 for running an extended service.

The first sub-process 501 receives an access request for accessing a target service through an nmginx gateway.

The first sub-process 501 forwards the request information corresponding to the access request to the second sub-process 502 running the extended service.

The second sub-process 502 performs processing of the corresponding extension service on the request information, and returns the processing result to the corresponding first sub-process 501.

The first sub-process 501 receives the processing result and processes the access request according to the processing result.

The nginnx gateway 500 further includes: a main process that starts a plurality of first sub-processes 501 and runs corresponding first services through the first sub-processes 501 such that an access request is received through the first services and is transmitted to the second sub-processes 502.

The main process starts the second sub-process 502 and runs the corresponding extended service through the second sub-process 502, so that the request information is processed through the extended service.

Since the specific embodiment of the nginix gateway 500 has been described above, a detailed description thereof is omitted. If there are unexplained places, please refer to the foregoing.

Fig. 6 is a schematic structural diagram of an extension processing device of an API gateway according to an exemplary embodiment of the present application. The apparatus 600 may be applied to a server of a gateway. The apparatus 600 includes: a receiving module 601, a forwarding module 602, and a processing module 603; the functions of the respective modules are explained in detail below:

The receiving module 601 is configured to receive an access request through an original service corresponding to an API gateway, where the access request is used to access a target service through the gateway.

And the forwarding module 602 is configured to forward, through an original service corresponding to the API gateway, request information corresponding to the access request to an extension service in the API gateway, so that the extension service processes the request information corresponding to the extension service, and return a processing result to the original service corresponding to the API gateway.

Wherein the extended service is independent of the original service.

And the processing module 603 is configured to receive a processing result through the original service corresponding to the API gateway, and process the access request according to the processing result.

The receiving module 601 is configured to receive a plurality of access requests, and distribute the access requests to a first service in the original services, where the first service runs in a corresponding sub-process.

In addition, the original service has a second service running in a corresponding main process, and the apparatus 600 further includes: and the starting module is used for starting a plurality of subprocesses through the second service in the main process and running the corresponding first service through the subprocesses so as to forward the request information to the expansion service through the first service.

And the forwarding module 602 is configured to forward the request information to an extension service running in the sub-process in the API gateway through a first service running in the sub-process in the API gateway.

In addition, the starting module starts a sub-process of the expansion service through a second service in the main process corresponding to the API gateway, and runs the corresponding expansion service through the sub-process, so that the request information is processed through the expansion service.

Specifically, the starting module is used for: and reading the configuration file of the API gateway through the second service in the main process, loading the dynamic module, and starting the subprocess of the expansion service through the loaded dynamic module so as to enable the subprocess to run the corresponding expansion service.

Specifically, the forwarding module 602 is configured to call, through a first service in the sub-process, a dynamic module in the first service, and forward the request information to an extension service running in the sub-process in the API gateway.

Specifically, the forwarding module 602 is configured to send, by using an inter-process communication manner, the request information to the extension service running in the sub-process through the first service running in the sub-process.

Specifically, the forwarding module 602 is configured to forward, through an original service, request information corresponding to an access request to an extension service in an API gateway according to an asynchronous message communication manner.

In addition, the processing module 603 is configured to directly process the access request for the original service if the processing result is not received by the original service corresponding to the API gateway within a preset time.

Specifically, the forwarding module 602 includes: the determining unit is used for determining whether the access request corresponding to the request information needs to be intercepted or not according to the threshold value of the access flow through the extension service; and the return unit is used for returning information representing intercepting the access request to the first service running in the corresponding subprocess in the API gateway when determining that the access request needs to be intercepted, so that the access request is intercepted by the first service, and returning the information representing intercepting the access request to the equipment for sending the access request.

Please refer to the foregoing for details of the device 600, and the detailed description is omitted.

The internal functions and structures of the apparatus 600 shown in fig. 6 are described above, and in one possible design, the structure of the apparatus 600 shown in fig. 6 may be implemented as a computing device, and more particularly may be a server of a gateway. As shown in fig. 7, the apparatus 700 may include: memory 701, processor 702;

memory 701 for storing a computer program.

A processor 702 for executing a computer program for: receiving an access request through an original service corresponding to an API gateway, wherein the access request is used for accessing a target service through the API gateway; forwarding request information corresponding to the access request to an expansion service in the API gateway through an original service corresponding to the API gateway, processing the request information through the expansion service and returning a processing result to the original service corresponding to the API gateway, wherein the expansion service and the original service are mutually independent; and receiving a processing result through the original service corresponding to the API gateway, and processing the access request according to the processing result.

Specifically, the apparatus 700 further includes: a communication component for receiving a plurality of access requests. Further, the processor 702 is specifically configured to: and distributing the access request to a first service in the original services, wherein the first service runs in each corresponding sub-process.

Specifically, the processor 702 is specifically configured to: and starting a plurality of subprocesses through a second service in the main process, and running a corresponding first service through the subprocesses so as to forward the request information to the expansion service through the first service.

Specifically, the processor 702 is specifically configured to: and forwarding the request information to an extension service running in the subprocess in the API gateway through a first service running in the subprocess in the API gateway.

Further, the processor 702 is further configured to: and starting a sub-process of the expansion service through a second service in the main process corresponding to the API gateway, and running the corresponding expansion service through the sub-process so as to process the request information through the expansion service.

Specifically, the processor 702 is specifically configured to: and reading the configuration file of the API gateway through the second service in the main process, loading the dynamic module, and starting the subprocess of the expansion service through the loaded dynamic module so as to enable the subprocess to run the corresponding expansion service.

Specifically, the processor 702 is specifically configured to: and calling a dynamic module in the first service through the first service in the subprocess, and forwarding the request information to an extension service running in the subprocess in the API gateway.

Specifically, the processor 702 is specifically configured to: and sending the request information to the expansion service running in the subprocess through the first service running in the subprocess in an inter-process communication mode.

Specifically, the processor 702 is specifically configured to: and forwarding the request information corresponding to the access request to the extension service in the API gateway according to the asynchronous message communication mode through the original service.

Further, the processor 702 is further configured to: and in the preset time, if the original service corresponding to the API gateway does not receive the processing result, directly processing the original service on the access request.

Specifically, the processor 702 is specifically configured to: determining whether an access request corresponding to the request information needs to be intercepted or not according to a threshold value of the access flow through the extension service; and when the access request is determined to be intercepted, returning information representing intercepting the access request to a first service running in a corresponding subprocess in the API gateway so as to intercept the access request through the first service, and returning information representing intercepting the access request to equipment for sending the access request.

In addition, embodiments of the present invention provide a computer storage medium, where a computer program is executed by one or more processors, to cause the one or more processors to implement the steps of an extension processing method of an API gateway in the method embodiments of fig. 1-3.

In addition, in some of the flows described in the above embodiments and the drawings, a plurality of operations appearing in a specific order are included, but it should be clearly understood that the operations may be performed out of the order in which they appear herein or performed in parallel, the sequence numbers of the operations such as 101, 102, 103, etc. are merely used to distinguish between the various operations, and the sequence numbers themselves do not represent any order of execution. In addition, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel. It should be noted that, the descriptions of "first" and "second" herein are used to distinguish different messages, devices, modules, etc., and do not represent a sequence, and are not limited to the "first" and the "second" being different types.

The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

From the above description of the embodiments, it will be apparent to those skilled in the art that the embodiments may be implemented by adding necessary general purpose hardware platforms, or may be implemented by a combination of hardware and software. Based on such understanding, the foregoing aspects, in essence and portions contributing to the art, may be embodied in the form of a computer program product, which may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable multimedia data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable multimedia data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable multimedia data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable multimedia data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An extension processing method of an API gateway is characterized by comprising the following steps:

Receiving an access request through a process which is operated on an API gateway and used for providing an original service, wherein the access request is used for accessing a target service through the API gateway, the process which is operated on the API gateway and used for providing the original service and the process which is operated on the API gateway and used for providing an extended service are respectively operated, and the process which is operated on the API gateway and used for providing the original service comprises a main process;

forwarding request information corresponding to the access request to the process for providing the extended service through the process for providing the original service, so as to process the corresponding extended service on the request information through the process for providing the extended service, and returning a processing result to the process for providing the original service;

And receiving a processing result through the process for providing the original service, and processing the access request according to the processing result.

2. The method of claim 1, wherein the process for providing the original service further comprises a work process, and wherein the process for providing the original service, running on the API gateway, receives the access request, comprises:

receiving an access request through the work process;

Forwarding, by the process for providing an original service, request information corresponding to the access request to the process for expanding the service, including:

And forwarding the request information of the access request to the process of the extended service through the working process.

3. The method according to claim 2, wherein the method further comprises: and starting the working process and the process for providing the extension service through the main process.

4. A method according to claim 3, wherein starting the process for providing extended services by the main process comprises:

and reading the configuration file of the API gateway through the main process, loading the dynamic module, and starting the process for providing the extension service through the loaded dynamic module so as to provide the extension service.

5. The method of claim 4, wherein forwarding, by the worker process, the request information of the access request to the process for providing extended services comprises:

and calling the dynamic module through the working process, and forwarding the request information to the process of the extension service.

6. The method of claim 4, wherein forwarding, by the worker process, the request information of the access request to the process for providing extended services comprises:

And forwarding the request information to the process for providing the expansion service by adopting an inter-process communication mode through the working process.

7. The method according to claim 1, wherein the forwarding, by the process for providing an original service, the request information corresponding to the access request to the process for providing an extended service includes:

and forwarding the request information corresponding to the access request to the process for providing the extension service by adopting an asynchronous message communication mode through the process for providing the original service.

8. The method according to claim 1, wherein the method further comprises:

And in the preset time, if the process for providing the original service does not receive the processing result, directly processing the original service for the access request.

9. The method according to claim 1, wherein the processing of the request information corresponding to the extended service by the process for providing the extended service and returning the processing result to the process for providing the original service includes:

determining whether an access request corresponding to the request information needs to be intercepted or not according to a threshold value of the access flow through the process for providing the extension service;

And when the access request is determined to be intercepted, returning information for intercepting the access request to the process for providing the original service so as to intercept the access request through the process for providing the original service, and returning information for intercepting the access request to equipment for sending the access request.

10. The method according to claim 4 or 5, characterized in that a Sidecar process of independent program components is used as the process for providing extended services.

11. An nginix gateway, comprising: the system comprises an original service process module and an extended service process module, wherein the original service process module comprises a main process module;

the original service process module is used for receiving an access request, and the access request is used for accessing the target service through the Nginx gateway; forwarding request information corresponding to the access request to the extended service process module;

The expansion service process module is used for carrying out corresponding expansion service processing on the request information and returning a processing result to the corresponding original service process module;

The original service process module is further configured to receive a processing result, and process the access request according to the processing result.

12. A computing device, comprising: a memory, a processor;

the memory is used for storing a computer program;

the processor executes the computer program for: