API Gateway is not an open source component, but an architectural pattern. It integrates the common functions of some services and deploys them independently as a separate layer to solve some service governance problems. You can think of it as the boundary of the system, which can uniformly control the traffic entering and leaving the system. In my opinion, API gateways can be divided into two categories: one is called ingress gateway, and the other is called egress gateway.

The ingress gateway is usually located between the load balancing server and the application server and has several important functions. First, it provides a unified access address for the client, so that the client does not need to care about the specific deployment address and protocol details of each microservice, thus bringing convenience. Secondly, the API gateway can dynamically route client requests to different business services and perform necessary protocol conversion work, such as converting HTTP requests into RPC requests. In addition, API gateway can also implement service governance strategies, such as circuit breaker, downgrade, flow control and diversion, etc. In addition, the client's authentication and authorization functions can also be implemented in the API gateway, so that different types of clients using different authentication methods can be processed uniformly. Functions such as black and white list management and logging can also be completed in the API gateway.

picture

The egress gateway may have fewer functions and functions than the ingress gateway. In system development, we usually rely on many external third-party systems, such as third-party account logins, payment tools, etc. To simplify interaction with these external systems, we can deploy an egress gateway between the application server and the third-party system. In the exit gateway, unified authentication, authorization, auditing and access control for calling external APIs can be implemented, thereby improving the security and stability of the system.

picture

How to implement API gateway

After understanding the role of API gateway, you need to pay attention to several key points in its implementation and common open source API gateways. When implementing an API gateway, the primary consideration is performance. Because the API entry gateway is responsible for all traffic from the client, performance directly affects the user experience. For example, if the business service processing time is 10ms, and the API gateway takes 1ms, then the response time of each interface will increase by 10%, which has a huge impact on performance. The key to API gateway performance optimization lies in the I/O model. For example, Netflix's open source API gateway Zuul used a synchronous blocking I/O model in version 1.0, but was transformed into a Netty-based non-blocking I/O model in version 2.0, improving performance by about 20%.

In addition, operations in the API gateway can be pre-defined, such as black and white list settings, interface dynamic routing, or defined according to business needs. Therefore, the design of the API gateway needs to pay attention to scalability, that is, some logic can be dynamically added or removed, making the execution link of the gateway more flexible. Generally speaking, you can define each operation as a filter, and then use the chain of responsibility pattern to string these filters together. The chain of responsibility can dynamically organize filters and decouple the relationship between filters so that adding or subtracting filters will not affect the operation of other filters.

In practice, the design and optimization of API gateways need to comprehensively consider factors such as performance, scalability, and flexibility to provide efficient and reliable services.

How to introduce API gateway into your system

On the one hand, the API gateway is responsible for aggregating service layer interface data. For example, the interface of the product details page may need to call multiple service interfaces to obtain data such as product information, user information, store information, and user comments. The API gateway can be responsible for aggregating these data and returning them to the front end.

On the other hand, the web layer needs to convert HTTP requests into RPC requests and restrict front-end traffic, such as adding device ID blacklists to certain requests. Therefore, during system transformation, the API gateway can be separated from the Web layer, and functions such as protocol conversion, current limiting, and black and white lists can be migrated to the API gateway for processing, forming an independent entrance gateway layer.

For the operation of service interface data aggregation, there are usually two solutions:

A set of independent gateways are created to handle tasks such as service aggregation and timeout control. Among them, one type of gateway is called a traffic gateway, which is responsible for processing tasks such as flow control and protocol conversion; the other type of gateway is called a business gateway, which is responsible for processing business-related tasks such as timeout control.

Extract an independent service layer specifically responsible for the operation of interface aggregation. In this way, the service layer can be roughly divided into two parts: the atomic service layer and the aggregation service layer. The atomic service layer provides a single-function atomic service interface, while the aggregation service layer is responsible for calling multiple atomic service interfaces and performing data aggregation.

I believe that interface data aggregation is a business operation. Instead of implementing it on a general gateway layer, it is better to implement it on a service layer that is closer to the business. Therefore, I prefer the second option.

picture

At the same time, we can deploy export gateway services between the system and third-party payment services and login services. In the past, operations such as encryption and signature of the data required by the third-party payment interface were usually completed in the separated payment service, and then the third-party payment interface was called to complete the payment request. Now, we put operations such as encryption and signature of data in the egress gateway. In this way, the payment service only needs to call the unified payment interface of the export gateway to complete the payment request, which greatly simplifies the payment service calling process.

After introducing the API gateway, our system architecture became as follows:

picture

Summarize:

API gateways are divided into two categories: ingress gateways and egress gateways. The functions of the entry gateway include isolating clients and microservices, providing protocol conversion, security policy, authentication, current limiting, circuit breaker, etc.; while the exit gateway is mainly used to uniformly call third-party services and provide unified authentication, authorization, auditing and access control.

When implementing an API gateway, performance and scalability are key points. You can use the multi-channel I/O multiplexing model and thread pool concurrent processing to improve performance, and use the responsibility chain model to improve scalability. The thread pool can isolate and protect different interfaces or services to improve the availability of the gateway.

API gateway can replace the original Web layer in the system, migrate the functions in the Web layer such as protocol conversion, authentication, current limiting, etc. to the API gateway, and sink the logic of service aggregation to the service layer.