background

As we all know, in the microservices architecture style, an application is broken up into several small service systems, and these small systems can be self-contained, can have their own database, framework language, etc. They often provide interfaces that can be invoked by various applications.

However, when presenting on the UI, we often need to present a lot of data on one interface, which may come from different microservices.

For example: To view the product details page of an e-commerce platform, the product details page includes title, price, inventory, reviews, etc. These data may be in different micro-service systems, as follows:

  • Product – Responsible for providing product titles, descriptions, specifications, etc.
  • Pricing – Responsible for product pricing, pricing strategy calculation, promotional pricing, etc.
  • Inventory – Responsible for product inventory.
  • Evaluation – Responsible for users’ comments and replies on products.

Now, the product details page needs to pull information from these microservices. The question is, right?

Since the architecture of multiple service systems is used, it is not feasible to rely on the join query results of a single database. Then how to access each service?

According to the guiding principles of microservice design, our microservice may have the following problems:

  • The service uses multiple protocols because different protocols have different application scenarios, such as HTTP, AMQP, gRPC, and so on.
  • The partitioning of services may change over time.
  • Service instances or Host+ ports may change dynamically.

Therefore, there may be the following UI requirements for the front end:

  • Coarse-grained apis, while microservices typically provide fine-grained apis that can be called many times by a UI, which is not a small problem.
  • Different client devices may require different data. Web,H5,APP
  • Network performance for different devices, for multiple apis, this access to the server that needs to be transferred is much faster

So how to solve it?

In that case, we need something that we’re going to talk about today, API Gataway.

API gateway

The following is the introduction of API gateway on Baidu:

The API gateway is a server that is a unique entry point to the system. From an object-oriented design perspective, it is similar to the appearance pattern. The API gateway encapsulates the internal architecture of the system and provides a custom API for each client. It may also have other responsibilities, such as authentication, monitoring, load balancing, caching, request sharding and management, and static response processing.

The core point of the API gateway approach is that all clients and consumers access microservices through a unified gateway and handle all non-business functions at the gateway layer. Typically, gateways also provide REST/HTTP access apis. The server registers and manages services through API-GW.

In his blog, Chris Richardson divides API gateways into the following two categories:

  • Single-node API gateway
  • Backends for fronends

Single node gateway

A single-node API gateway provides a different API for each client, rather than providing a one-size-fits-all style API. This gateway is the same gateway recommended by Microsoft in the eShop project.

Backends for fronends

This pattern is to implement a different API gateway for different clients.

The ground plan

What’s wrong with these two API gateways?

Normally, API gateway to do a lot of work, it is considered as a backend system total entrance, bearing the weight of the combination of all service routing switch, etc, in addition, we also can make safety, usually current limiting, caching, logging, monitoring, retry, fusing into API gateway etc. To do, then you can imagine that in the case of high concurrency, There may be a performance bottleneck here.

In addition, without the support of open source projects, it is a very large workload to build such a set of things, and also need to do the HIGH availability of THE API gateway itself, if not done well, it may be the first to fail, not your other services, but the API gateway. At this time, we usually look for some open source API gateway projects. The blogger has already found them for you. Currently, API Gataway projects in the community include the following:

Goku: Goku is an extensible open source API Layer(also known as API gateway or API middleware). Out-of-the-box, full-interface configuration, easy to operate, and plug-in extensions provide additional functions and services beyond the core platform.

Orange: an API gateway program based on OpenResty, also developed by Chinese.

Netflix Zuul: Zuul is an edge service that provides dynamic routing, monitoring, resiliency, security and more. Zuul is a Netflix load balancer based on JVM routing and server side.

Apiaxle: an API gateway implemented by Nodejs.

Api-umbrella: An API gateway implemented by Ruby.

conclusion

In this article we learned what an API gateway is and what it does and where it fits into the microservices architecture. Then we learned about some open source projects of API gateway and the implementation schemes introduced by bloggers. In practical practice, we still hope that we can think more and summarize, so that we can become more powerful.

Author: Java introduction to into the grave links: www.jianshu.com/p/097ff82e2… The copyright of the book belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please indicate the source.