Talk about API Gateways in MicroServices (API Gateway)

Objective

It is a long time not to write a blog, recently for a new job, relatively busy, so did not take out too much time to pay attention to my fans write some dry, someone asked me how recently did not update the blog, here to everyone sorry.

So, in this article, let's explore the role of API gateways in the entire microservices distributed architecture.

Background

We know that in the MicroServices architecture style, a large application has been split into a number of small service systems, and these small systems can be self-contained, which means that these small systems can have their own databases, frameworks and even languages, and these small systems are often H5 by providing a Rest API-style interface. Calls to Android, IOS, and third-party applications.

But when it comes to displaying on the UI, we usually need to show a lot of data in one interface, which may come from different microservices, for example.

In an e-commerce system, look at a Product Details page, this product Details page contains the title of the product, price, inventory, comments, etc., this data for the backend may be located in a different microservices system, perhaps my backend system is to split my service:

• Product Service-responsible for providing the product title, description, specifications, etc.
• Price Service-Responsible for the product pricing, price strategy calculation, promotional prices and so on.
• Inventory Service-Responsible for product inventory.
• Evaluation Service-Responsible for the user's comments on the product, reply and so on.

Now that the product detail page needs to pull the appropriate information from these microservices, is the question coming?

Problem

Because of the service system architecture we use, there is no way to rely on database join queries to get the end result like traditional monolithic applications, so how can we access individual services?

In accordance with the guidelines for microservices design, our microservices may have the following issues:

• The service uses a variety of protocols because different protocols have different scenarios to use, such as HTTP, AMQP, Grpc, and so on.
• The Division of services can vary over time.
• Instances of the service or host+ ports may change dynamically.

There are also several possible UI requirements for the front-end:

• Coarse-grained APIs, and microservices typically provide a fine-grained API, which is a big problem for the UI if you want to call a fine-grained API many times.
• Different client devices may require different data. Web,h5,app
• The network performance of different devices, for multiple APIs, this access needs to transfer the service side will be much faster

These are some of the problems that we may encounter in the process of building microservices. So how to solve it?

In this case, we need an API Gateway (API Gataway) for this thing to talk about today.

API Gateway

Here is the introduction of Baidu on the API gateway:

An API gateway is a server that is the only portal to the system. From an object-oriented design perspective, it is similar to the appearance pattern. The API gateway encapsulates the system's internal architecture and provides a custom API for each client. It may also have other responsibilities, such as authentication, monitoring, load balancing, caching, request fragmentation and management, and static response processing.
The core point of the API Gateway approach is that all clients and consumers handle all non-business functions at the gateway layer through a unified Gateway service. Typically, a gateway is also an Access API that provides rest/http. The server registers and manages services through API-GW.

Chris Richardson the API gateways in his blog in the following two categories:

• Single-node API gateway
• Backends for Frontends Gateway

Single-node gateways

A single-node API gateway provides a different API for each client, rather than a universal-style API.

This gateway is consistent with the gateway recommended by Microsoft in the EShop project.

For more details I will explain below.

Backends for Frontends Gateway

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

Floor plan

I've been thinking about one of the best API gateway scenarios, what's the problem with both of these API gateways?

Usually, the API gateway to do a lot of work, it as a system of the back end of the total portal, carrying all the services of the combined route transformation, etc., in addition, we will generally put the security, current limit, cache, log, monitor, retry, fuse and so on to the API gateway to do, then you can imagine high concurrency in the case, There may be a performance bottleneck here.

In addition, if there is no open source project support premise, oneself to do such a thing, is a very large workload, but also to do the API gateway itself is highly available, etc., if once do not good, it is possible to hang up the first is not your other services, but this API gateway.

At this time, usually we will find some open Source API Gateway project, the blogger has already found you, the community of the API Gataway project has the following:

Tyk:tyk is an open source API gateway that is fast, extensible, and modern. Tyk provides an API management platform that includes API gateways, API analytics, developer portals, and API management dashboards. Try is a gateway service based on GO implementation.

Kong:kong is an extensible open Source API Layer (also known as API Gateway or API middleware). Kong runs in front of any restful API and expands through plugins, providing additional functionality and services beyond the core platform.

Orange: Similar to Kong is also based on a Openresty API Gateway program, is developed by the Chinese, sister is also one of the contributors.

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

An API gateway implemented by Apiaxle:nodejs.

An API gateway implemented by Api-umbrella:ruby.

Let's say that these open source projects are not suitable for us to work with as API gateways.

For a single-node gateway, this gateway is equivalent to the Web tier and service, which is used to aggregate services. Note that what we need is aggregation services , and none of these open source projects have this feature, and I mean aggregation specifically refers to out-of-the-box. The problem comes when we want to use these services to have some extensions to API gateways or to develop plugins. Extended Tyk I need to go language, expand Kong I need to write Lua scripts, use Zuul and Java, which is not very realistic for developers, then what to do?

Some students might say that ASP. NET Core can use Ocelot, which is right, we can handle the business of API aggregation service by introducing Ocelot, but there is a problem, as I said above, which is very easy to cause performance problems, on the other hand, Ocelot's function is much weaker than those open source projects above, what is the specific aspect?

In addition to the most important high-performance IO models and cluster scenarios, such as the Dashboard features that will be used frequently, this is important for operations, including logging, monitoring, security, service discovery, versioning, and more.

But what is missing from the API gateways above? such as timeout, Fuse, retry, aggregate query.

Note : These ideas are all my personal understanding of the API Gateway is born, if there are errors, please correct me.

The clever classmate may think out, how to do? We can fully combine the advantages of both to implement a "dual gateway" in our ASP. NET Core application.

Here is a diagram of an API gateway that I drew in the MicroServices architecture:

Should most of the students can understand, I will explain briefly.

• Openresty Api Gateway

Left-to-right HTTP requests are first received by DNS after receiving first-hand traffic after load balancing to the Openresty-based API Gataway Gateway cluster, where we can use the high concurrency High Traffic API Gateway program like the Kong,orage,tyk these open source support to make a tier one flow Protection, at this level we can do something like identity authentication, security, monitoring, logging, flow control and other strategies. In addition to these we can also do some service discovery and registration (this depends on the level of support for different gateways), interface versioning, routing rewriting, and so on.

• Aggr Api Gateway

These API gateways then load the request to a different AGGR API gateway, where we do the aggregation service , specifically that the yellow areas in the diagram are needed by the developers of each language to write code to implement. The process is that we can introduce an open source project like Ocelot, a language-related API gateway, and then integrate the various microservices from the backend to provide aggregate queries through the introduction of the NuGet package and then through the JSON configuration + aggregation code. During this time, we can apply time-outs, caches, fuses, retries and other policies for the required interfaces.

From the Aggr Api Gateway to the back-end microservices Cluster This is the internal communication, we can use the internal friendly communication protocol such as GRPC or AMQP, and then make RPC calls to improve communication performance.

Note : The AGGR API Gateway is not required for some interfaces, or it can be used by backend microservices to provide the rest Api directly to the first tier gateway.

Above, is I understand the API gateway in the entire micro-service architecture, a status, connecting, or very important.

Advertising

We know that in the backend of the API gateway is a microservices cluster, in addition to aggregate queries sometimes we need to do some operations across different services, such as a single e-commerce system, can be designed to product, price, inventory and a series of cross-micro services operations, in the middle we generally adopt integration events ( Eventbus) to communicate this solution, in this process we are not only need to communicate, then these operations also need to ensure transactional consistency, and the general distributed system of transactions we pursue is final consistency.

If you are in. NET Core, we can use the Eventbus + Distributed transaction solution CAP for Blogger Open source.

Github:https://github.com/dotnetcore/cap

CAP Introduction:
Http://www.cnblogs.com/savorboard/p/cap.html

For a distributed transaction, you can view this article for me.

Interested students can give the CAP a star to support the table, secretly told you Ocelot's author also star Oh. :)

Summarize

Through this article we learned what the API gateway and API Gateway are and what it does in the microservices architecture. Then we learned about the API Gateway of some open source projects and bloggers introduced the landing plan, in the actual practice is still much hope that we can think a lot of summary, so that we can become more powerful.

If you feel that this article is helpful to you, thank you for your "recommendation".

If you are interested in. NET Core, you can pay attention to me, I will regularly share my learning experience in the blog.

This address: http://www.cnblogs.com/savorboard/p/api-gateway.html
Author Blog: Savorboard
Welcome reprint, please give the source and link in obvious position

Talk about API Gateways in MicroServices (API Gateway)