background

We know that in the microservices architecture style, a large application is broken up into several small services that are self-contained, that is, these small systems can have their own databases, frameworks, and even languages. These small systems are often called by H5, Android, IOS, and third-party applications by providing A Rest API-style interface. In the article shallow in and shallow out message Queues, I mentioned that message queues are convenientBetween services, as shown in the figure below:Then the question arises, what if an external application (browser, App) wants to access the big application? It’s very easy to make a request through HTTP.

The problem

Is it really that simple? Let’s take taobao’s product details page as an example:As shown in the figure above, this page contains video, inventory, commodity price, commodity evaluation and other contents. All these data come from different micro-services, so it cannot rely on join query of database to get the final result like traditional single application, so it needs to be called several times to retrieve data, as shown in the figure below:This raises several serious questions:

  • Different client devices may require different data. Web,H5,APP, need to write a separate set of apis
  • Multiple client requests result in poor user experience. Mobile networks have lower bandwidth and higher latency than lans between services, which is fine if you can execute requests simultaneously, but can make the user experience worse if the client has to execute them sequentially.
  • Lack of encapsulation leads to miscoordination at the front and back ends. Excessive splitting of the API will lead to excessive coupling between the client and the server, and the new version of the mobile APP will take a long time to iterate to each mobile user, which will make it difficult for the back end to change the service API.

That’s obviously bad design, and that’s where this episode of “Falling Man” comes in — the API Gateway.

API gateway

Before we move on to THE API gateway, let’s first introduce a design pattern — the appearance pattern. Facade Pattern it adds an interface to an existing system to hide the complexity of the system. The class diagram is as follows:I’m going to talk about appearance patterns before I talk about API gateways because the design philosophy is similar. Similar to the facade pattern, an API gateway encapsulates the internal architecture of an application and provides apis for its clients, which may also have other responsibilities such asAuthentication, monitoring, load balancing, caching, request sharding and management, static response processing. The following figure shows the relationship between the client, API gateway, and service.All clients and consumers access microservices through a unified gateway and handle all non-business functions at the gateway layer. Its appearance also carries out the “high cohesion, low coupling” philosophy in software engineering.

A central role

The API gateway is responsible for request routing, API composition, and protocol transformation. All API requests from external clients are first routed to the API gateway, which routes requests to the appropriate service. The API gateway uses the API composite pattern to process additional requests, invoke multiple services and aggregate the results. It can also convert between client-friendly protocols (such as HTTP) and client-unfriendly ones.

Request routing

When the API gateway receives a request, the opportunity queries a routing map that specifies which service the request is routed to. For example, route mapping can map HTTP methods and paths to the HTTP URL of a service, which is similar to the reverse proxy provided by Nginx, which we will compare later. Since there is a routing map, where to store it is a problem. We need to set up a storage location for the API gateway. Zookeeper may be used as a registry, and some drawbacks will be mentioned at the end of this article.

API composite

In addition to the reverse proxy function, the API gateway also provides API composition operations. Taobao page for details of the above, for example, if we get alone the information such as video, commodity prices, product reviews, need to send multiple requests (getVideo, getPrice, getComments). With the API gateway, we can combine THE API interfaces and obtain the required information through one request (getItemDetail), as shown in the figure below, which can greatly improve the poor user experience caused by network delay.

Protocol conversion

API gateways can provide RESTful apis for external clients, even if internal services use mixed communication protocols, such as REST, gRPC, and so on. The advantage of this is that the server is more like an invisible black box to external clients.

API gateway and Nginx

Nginx can also do request forwarding. What’s the difference between the two? It’s easy to understand in one picture.When Nginx does load balancing, considering that there is more than one API gateway in the system (in a clustered way to do high availability), we can put Nginx in front of the API gateway, responsible for the load balancing of the API gateway, and then let the gateway decide which real Web server to enter. This makes the division of labor clearer:API gateway aggregation service, Nginx request forwarding

Pros and cons of API gateways

The API gateway encapsulates the internal structure of the application so that clients only need to interact with the gateway without invoking specific services. At the same time, THE API gateway provides a specific API for each type of client, thus reducing the number of interactions between the client and the application program and simplifying the processing of the client code. But like all middleware, they share a common problem: the presence of an API gateway adds a highly available component that must be developed, deployed, and maintained. If this component is not handled well, then the API gateway becomes a performance bottleneck for the application. And in order to expose each microservice, developers must update the API gateway, so it is possible to use middleware with other service discovery classes, such as ZooKeeper, which introduces new middleware. So we need to keep the API gateway update process as simple as possible, otherwise developers will have to wait in line to update the gateway. Therefore, API gateway is not a “silver bullet”, we still need to combine the actual situation of the project in the choice of middleware, do not pursue novelty just abuse middleware, suitable for their own is the best. However, API gateways, while still lacking, make sense for most real-world applications.