Shulou(Shulou.com)06/01 Report--

How to understand the API gateway pattern, I believe that many inexperienced people do not know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

What is a gateway?

The word Gateway comes from the definition of computer network. Gateway is also called inter-network connector and protocol converter. A gateway is precisely defined as a connection between two computer programs or systems. As a portal between two programs, a gateway allows them to share information through protocol communication between different computers. As the name implies, the API gateway is the barrier and barrier for API to call each other.

Why Gateways are needed between API

Imagine that we are implementing a very large business system, which is divided into different business domain and subsystems, each domain and subsystem provide API for processing business, and different systems exchange data in the way of API. In general, we may integrate all the API that implements the business function (API Center) to provide data processing capabilities to the Portal of different Channel. When one day our system needs to interact with third parties, we not only need to expose the public API of external system calls, but also need to call external API to achieve our own business requirements. At this time, we will consider many problems, such as authorization and authentication of access between services, security and performance monitoring, cache and log processing, timeout Retry, load and circuit breaker processing, query request aggregation and so on. At this point, you need someone who can centrally handle all the things that may need to be handled between service invocations, just like the property and security of the community, and you need to deal with everything within the scope of responsibility for all the owners of the community.

This is usually the thing that the API gateway needs to help us deal with. With the increasing complexity of the system business, the larger our system is, the more complex the API interaction is. At this point, we may consider splitting this large system into several small domain, each providing the API of each domain. This is the most popular topic nowadays: micro-services. When our system evolves to a micro-service architecture, the API gateway will be an essential part of the system. In a micro-service architecture, client applications usually need to use the functionality of multiple micro-services. If the client consumes a service directly, it will usually need to process and coordinate multiple micro-service endpoint. What happens when an application introduces a new microservice or updates an existing microservice? Imagine that if your application has many microservices, it would be a nightmare for the system to process and coordinate so many endpoint requests from the client, and because the client application will be coupled with these endpoint, it will confuse our system side.

Therefore, we need an intermediate layer or indirect layer (Gateway) to handle requests for API from different client, which will make it very convenient for our application to handle. If there is no API gateway, the client application must send requests directly to the microservice, which will cause a lot of confusion, such as:

Coupling: if there is no API gateway, the client's application will be coupled with the internal microservice. The client order needs to know which parts of the service are scattered by the API that implements the business requirements. When we develop and restructure the internal service, it will affect the client application and is difficult to maintain, because the client application needs to track the endpoint of multiple services.

Multiple requests: a page in a client application may need to invoke multiple services to complete a function, which may result in multiple round-trip requests between the client and the server, adding significant delays. We know that aggregations handled at the intermediate level can improve the performance and user experience of client applications.

Security issues: without gateways, all services must be exposed to the "outside world", making the attack surface larger than hiding internal services that are not directly used by client applications. The smaller the attack surface, the more secure the application.

Crosscutting concerns: every publicly published service must deal with issues such as authorization, SSL, and so on. In many cases these concerns can be addressed in one layer so that internal services can be simplified, which reminds me of aspect-oriented programming (AOP)

What is Gateway Mode?

When we use multiple client applications to design and build large or complex micro-service-based applications, we can consider using the API gateway, which provides a single entry point for some micro-service groups, which is similar to the Facade (facade class) pattern designed by object-oriented design, but is part of the system in micro-services. A variant of the API gateway pattern is also known as "Backend for front-end" (BFF) because you may create multiple API gateways based on the different needs of each client application. So the API gateway sits between the client application and the microservice, acting as a reverse proxy to route requests from the client to the service, and it can also provide additional crosscutting features such as authentication, SSL termination, and caching.

The following figure shows how a custom API gateway fits into a micro-service-based architecture.

In the above example, the API gateway will run as a container for a custom Web API or ASP.NET WebHost service

What needs to be emphasized in this figure is that we will use a custom API gateway service for multiple different clients. This can be an important risk because your API gateway service will grow and evolve according to client needs, and eventually it will become bloated because of these different requirements, and in fact it may be very similar to a monolithic application or monolithic service. This is why we highly recommend splitting API gateways into multiple services or smaller API gateways.

We also have to be very careful when using the API gateway pattern, it is usually not a good practice to aggregate all the internal micro services of the application using a single API gateway, because once it does, it acts as an overall aggregator or coordinator and violates the micro service autonomy by coupling all the micro services. Therefore, API gateways should be isolated based on business boundaries and client applications, rather than acting as a single aggregator for all internal micro services. When decomposing the API gateway layer into multiple API gateways, if your application has multiple clients, this can be a major hub to identify multiple API gateway types, so that you can have different appearance classes to meet the needs of each client. This is what we call a "Backend for front-end" BFF, where each API gateway can provide a different API for each client, and may even implement specific adapter code based on the client's specific needs, which invokes multiple internal microservices below, as shown in the following figure:

The figure above shows a simplified architecture with multiple fine-grained API gateways, in which case identifying the boundaries of each API GateWay is purely based on the BFF pattern, so it is only based on each client to provide its own required API, but in larger applications it should also go a step further to create a business boundary-based gateway as a secondary design measure.

Main features in API gateway mode

API gateways can provide a variety of features depending on the product, and it may provide richer or simpler features, but the most important and basic features for any API gateway are the following design methods:

Reverse proxy or gateway routing: API gateways provide reverse proxies that redirect or route requests (usually Http requests) to endpoints of internal microservices. The gateway provides an endpoint or URL for the client application, and then internally maps the request to a set of internal micro-services. This routing feature helps to decouple clients from micro-services, and it is also convenient to implement gateway control between a single API and the client, so that you can add a new API as a new microservices while still using a legacy single API until it is divided into many microservices in the future. Because of the existence of the API gateway, the client application will not notice that the API implementation used is an internal microservices or a single API. When evolving and refactoring our single API to microservices, it will not bring about a change in the URI of the Client request because of the existence of the API gateway route. If you want to know more about gateway routing, please poke here.

Request aggregation: as part of the gateway pattern, you can aggregate multiple client requests (usually Http requests) for multiple internal microservices into a single client request. This mode is especially convenient when client pages need to invoke data from multiple microservices. Using this method, the client sends a request to the API gateway, which is then responsible for sending multiple requests to get the internal microservices and then aggregating the results and sending them back to the client. The main advantage and goal of this design pattern is to reduce the gap between client applications and back-end API, which is particularly important for remote applications outside the data center where microservices are located, such as mobile applications or requests from SPA applications from Javascript in the client remote browser. For regular web applications (such as ASP) that execute requests in a server environment, this pattern is not important because the latency is much smaller than that of remote client applications. The ability to perform this aggregation depends on the API gateway product you use, but in many cases it is more flexible to create aggregation microservices within the scope of the API gateway, so you can also define aggregations (that is, c # code) in your code. To learn more about the request for aggregation, please poke here.

Crosscutting concerns or gateway offloading: depending on the features provided by each API gateway product, you can transfer functionality from a single microservice to the gateway, simplifying the implementation of each microservice by merging crosscutting concerns into one layer. This is especially convenient for complex special functions that can be correctly implemented in each internal microservice, such as the following functions.

Authentication and authorization

Service discovery integration

Response caching

Retry strategy, circuit breaker and QoS.

Speed limit and throttling

Load balancing

Logging, tracking, correlation

Header files, query strings, and declaration conversions

IP whitelist

More crosscutting concerns can be provided per implementation API gateway product, but these are the most common features. For example, Azure API management provides most of these features, as well as many advanced features that are very useful for commercial API. But for simpler methods, lightweight API gateways like Ocelot are quite flexible because you can deploy it to your environment of choice and to your microservices.

After reading the above, have you mastered how to understand the API gateway pattern? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.