Talk about the API Gateway in Micro Services (API Gateway) -

21CTO Community Guide: In this article, let’s discuss the distribution of API gateways in the entire microservices A role in the architecture.

Background

< p style="max-width: 100%;min-height: 1em;color: rgb(62, 62, 62);font-size: 16px;white-space: normal;background-color: rgb(255, 255, 255);box-sizing: border-box !important;word-wrap: break-word !important;">
< /span>

We know that in the microservice architecture style, a large application is split into multiple small service systems. These Small systems can be self-contained, which means that these small systems can have their own databases, frameworks and even languages. These small systems usually provide Rest Api style interfaces to be used by H5, Android, IOS And third-party application calls.

But when displaying on the UI, we usually need to display a lot on one interface Data, these data may come from different microservices, for example.

In an e-commerce system, view a product detail page, which contains The title, price, inventory, comment, etc. of the product may be located in different microservice systems for the backend. Perhaps my backend system splits my service like this: p>

< /span>

Product Service-Responsible for providing the title, description, specifications, etc. of the product.
Price service-responsible for Product pricing, price strategy calculations, promotional prices, etc.
Inventory service-responsible for the product in stock.
Evaluation service-responsible user Comments, responses, etc. to the product.

Now, the product detail page needs to download from these microservices Pull the corresponding information, the problem is coming?

problem

Because of the service system architecture we use, there is no way to rely on the join query of the database to get the final result like a traditional monolithic application, so how can we access each service?

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

The service uses multiple protocols, because different protocols have different Application scenarios, such as HTTP, AMQP, gRPC, etc. may be used at the same time.
The division of services may vary Changes over time.
Service instance or Host+ The port may change dynamically.

Then, the front-end UI requirements may also be There are the following:

coarse-grained API, while micro-services usually provide fine-grained For the UI, if you want to call the fine-grained API, you may need to call many times, which is not a small problem.
Different client devices Different data may be required. Web,H5,APP
For the network performance of different devices, for multiple APIs, this access to the server that needs to be transferred will be much faster

The above are the problems we may encounter in the process of building microservices. So how to solve it?

In this case, we need something that we are going to talk about today, the API gateway (API Gataway).

API Gateway

The following is an introduction to the API gateway on Baidu:

API gateway is a server and a system The only entrance. From the point of view of object-oriented design, it is similar to the appearance model. The API gateway encapsulates the internal architecture of the system and provides a customized 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 method is that all clients and consumers access microservices through a unified gateway, and all non-business functions are handled at the gateway layer. Usually, the gateway also provides REST/HTTP access API. The server registers and manages services through API-GW.

Chris Richardson on his blog The API gateway is divided into the following two types:

Single node API Gateway
Backends for frontends gateway

Single-node gateway

The single-node API gateway provides different APIs for each client, instead of providing a versatile API.

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

More details will be explained below.

Backends for frontends gateway

This mode implements a different API gateway for different clients.

Landing plan

< br style="max-width: 100%;box-sizing: border-box !important;word-wrap: break-word !important;">

I have been thinking about an optimal API gateway implementation plan. What are the problems with the above two API gateways?

Usually, the API gateway has to do a lot of work, it serves as the back end of a system The total entrance, which carries the combined routing conversion of all services, etc. In addition, we generally also put security, current limiting, caching, logging, monitoring, retry, fuse, etc. on the API gateway to do it, then you can imagine In the case of high concurrency, a performance bottleneck may appear here.

另外，如果没有开源项目的支撑前提下，自己来做这样一套东西，是非常大的一个工作量，而且还要做API 网关本身的高可用等，如果一旦做不好，有可能最先挂掉的不是你的其他服务，而就是这个API网关。

这个时候，通常我们会去找一些开源的 API 网关项目，博主已经给你找好了，目前社区的关于 API Gataway 的项目有以下这些：

Tyk：Tyk是一个开放源码的API网关，它是快速、可扩展和现代的。 Tyk提供了一个API管理平台，其中包括API网关、API分析、开发人员门户和API管理面板。 Try 是一个基于Go实现的网关服务。

Kong：K ong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。 Kong 在任何RESTful API的前面运行，通过插件扩展，它提供了超越核心平台的额外功能和服务。

Orange ：和Kong类似也是基于OpenResty的一个API网关程序，是由国人开发的，学姐也是贡献者之一。

Netflix zuul：Zuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。 Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。

apiaxle：Nodejs 实现的一个 API 网关。

api-umbrella：Ruby 实现的一个 API 网关。

我们来说说上面的这些开源项目适不适合作为 API 网关来供我们使用。

拿单节点网关来说，这种网关相当于是处于 Web 层和 Service 之间，用来聚合服务的？注意，我们需要的是聚合服务，而以上这些开源项目都不具备这个功能，我说的聚合具体指的是开箱即用。我们要想使用这些服务需要来自己对API网关过一些扩展或者是开发一些插件，这个时候问题就来了。扩展Tyk我需要会Go语言，扩展Kong我需要会写lua脚本，使用 zuul 还得会Java，这对于开发人员来说是不太现实的，那么这个时候怎么办？

有些同学可能会说 ASP.NET Core 可以使用 Ocelot，说得没错，我们可以通过引入Ocelot来处理API聚合服务这一块的业务，但是，这中间有一个问题，就像我在上面说的一样，这很容易造成性能问题，另外一方面，Ocelot的功能相比上面的那些开源项目来说功能要弱很多，具体体现在哪些方面呢？

除了最重要的高性能的IO模型和集群方案外，比如会经常使用的 Dashboard 功能，这个对于运维来说是非常重要的，另外还有日志，监控，安全，服务发现，版本控制等。

但是上面的这些 API 网关缺少什么功能呢？比如超时，熔断，重试，聚合查询等。

注意： 以下内容的这些想法全是我个人对于 API 网关的理解而诞生的，如有错误还请指正。

聪明的同学可能想出来了，怎么办呢？我们可以充分来结合两者的优势来在我们的 ASP.NET Core 应用程序中实现一个“双重网关”。

下面是我画的一个 API 网关在微服务架构中的一个作用图：

应该大部分同学都可以看懂，我就简单解释一下。

OpenResty Api Gateway

从左至右 HTTP 请求先由DNS在拿到第一手流量后负载均衡到基于 OpenResty 的 API Gataway 网关集群，在这个流程我们可以使用像 Kong,Orage,Tyk 这些开源的支持高并发高访问量 API 网关程序在做第一层流量的防护，在这一级我们可以做一些像身份认证，安全，监控，日志，流控等策略。除了这些我们还可以做一些服务的发现和注册（这个要看不同网关的支持程度），接口的版本控制，路由重写等。

Aggr Api Gateway

然后再由这些 API 网关把请求再负载到不同的 Aggr Api Gateway，在这里我们做聚合服务这个操作，具体体现也就是图中的黄色区域是需要由各个语言的开发人员来需要写代码实现的。具体流程也就是我们可以引入像 Ocelot 这种和语言相关的 API 网关开源项目，然后通过 NuGet 包引入之后通过 Json配置+聚合代码的方式来整合后端的各个微服务提供聚合查询等操作。这期间对于有需求的接口，我们可以应用超时，缓存，熔断，重试等策略。

从 Aggr Api Gateway 到后端微服务集群这中间就属于内部的通讯了，我们可以使用对内部友好的通讯协议比如 gRPC 或者 AMQP 等，然后进行 RPC调用提高通讯性能。

注意： Aggr Api Gateway 这个网关对于一些接口来说的话并不是必须的，也可以由后端微服务直接提供REST API给第一层网关使用。

以上，就是我理解的 API 网关在整个微服务架构中的一个地位，承上启下，还是非常的重要。

我们知道，在 API 网关的后端是微服务的集群，那么除了聚合查询之外有时候我们有时候需要做一些跨不同服务的操作，比如一次电商系统的下单操作，可以会设计到产品、价格、库存等一系列跨微服务操作，在中间我们一般会采用集成事件(EventBus)来进行通讯这种解决方案，在这个过程中我们不仅仅的是需要通讯，那么这些操作还需要保证事务一致性，而一般分布式系统中的事务我们追求的是最终一致性。

如果是在 .NET Core 中，我们可以使用博主开源的 EventBus + 分布式事务解决方案 CAP（https://github.com/dotnetcore/CAP） .

GitHub：https://github.com/dotnetcore/CAP

CAP 介绍：http://www.cnblogs.com/savorboard/p/cap.html

有关分布式事务可以查看我的这篇文章（http://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html）。

感兴趣的同学可以给CAP一个 Star 以表支持，偷偷告诉你 Ocelot的作者也Star了哦。 🙂

总结

通过本文我们了解到了什么是 API 网关以及API网关的作用和其在微服务架构中所处的地位。然后我们了解到了 API 网关的一些开源项目以及博主介绍的落地方案，在实际的实践中还是多希望大家能够多多思考总结，这样我们才能够变得更加强大。

出处：http://www.cnblogs.com/savorboard/p/api-gateway.html

21CTO社区导读：在本篇文章中，我们就一起来探讨一下 API 网关在整个微服务分布式架构中的一个作用。

背景

我们知道在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的系统他们可以自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。

但是在UI上进行展示的时候，我们通常需要在一个界面上展示很多数据，这些数据可能来自于不同的微服务中，举个例子。

在一个电商系统中，查看一个商品详情页，这个商品详情页包含商品的标题，价格，库存，评论等，这些数据对于后端来说可能是位于不同的微服务系统之中，可能我后台的系统是这样来拆分我的服务的：

产品服务 – 负责提供商品的标题，描述，规格等。
价格服务 – 负责对产品进行定价，价格策略计算，促销价等。
库存服务 – 负责产品库存。
评价服务 – 负责用户对商品的评论，回复等。

现在，商品详情页需要从这些微服务中拉取相应的信息，问题来了？

问题

由于我们使用的服务系统架构，所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果，那么如何才能访问各个服务呢？

按照微服务设计的指导原则，我们的微服务可能存在下面的问题：

服务使用了多种协议，因为不同的协议有不同的应场景用，比如可能同时使用 HTTP, AMQP, gRPC 等。
服务的划分可能随着时间而变化。
服务的实例或者Host+端口可能会动态的变化。

那么，对于前端的UI需求也可能会有以下几种：

粗粒度的API，而微服务通常提供的细粒度的API，对于UI来说如果要调用细粒度的api可能需要调用很多次，这是个不小的问题。
不同的客户端设备可能需要不同的数据。 Web,H5,APP
不同设备的网络性能，对于多个api来说，这个访问需要转移的服务端会快得多

以上，就是我们构建微服务的过程中可能会遇到的问题。 So how to solve it?

这种情况下，我们就需要一个今天要讲的这个东西， API 网关（API Gataway）。

API 网关

下面是百度上针对于 API 网关的介绍：

API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。 API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。

API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

Chris Richardson 在他的博客中把 API 网关划分为以下两种：

单节点 API 网关
Backends for frontends 网关

单节点网关

单节点的 API网关为每个客户端提供不同的API，而不是提供一种万能风格的API。

这个网关和微软在 eShop 项目中推荐的网关是一致的。

更多详细信息我会在下文进行说明。

Backends for frontends 网关

这种模式是针对不同的客户端来实现一个不同的API网关。

落地方案

我一直在寻思一种最佳的 API 网关的落地方案，以上两种 API 网关有什么问题呢？

通常情况下， API 网关要做很多工作，它作为一个系统的后端总入口，承载着所有服务的组合路由转换等工作，除此之外，我们一般也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做，那么可以试想在高并发的情况下，这里可能会出现一个性能瓶颈。

另外，如果没有开源项目的支撑前提下，自己来做这样一套东西，是非常大的一个工作量，而且还要做 API 网关本身的高可用等，如果一旦做不好，有可能最先挂掉的不是你的其他服务，而就是这个API网关。