微服务中的 API 网关（API Gateway）

API 网关（API Gateway）提供高性能、高可用的 API 托管服务，帮助用户对外开放其部署在 ECS、容器服务等云产品上的应用，提供完整的 API 发布、管理、维护生命周期管理。用户只需进行简单的操做，便可快速、低成本、低风险地开放数据或服务。

---

 

背景

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

可是在UI上进行展现的时候，咱们一般须要在一个界面上展现不少数据，这些数据可能来自于不一样的微服务中，举个例子。

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

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

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

问题

因为咱们使用的服务系统架构，因此没办法像传统单体应用同样依靠数据库的 join 查询来获得最终结果，那么如何才能访问各个服务呢？

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

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

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

• 粗粒度的API，而微服务一般提供的细粒度的API，对于UI来讲若是要调用细粒度的api可能须要调用不少次，这是个不小的问题。
• 不一样的客户端设备可能须要不一样的数据。Web,H5,APP
• 不一样设备的网络性能，对于多个api来讲，这个访问须要转移的服务端会快得多

以上，就是咱们构建微服务的过程当中可能会遇到的问题。那么如何解决呢？

这种状况下，咱们就须要一个今天要讲的这个东西， 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网关。

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

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

Kong：Kong是一个可扩展的开放源码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。

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

 

有关分布式事务能够查看个人这篇文章。

感兴趣的同窗能够给CAP一个 Star 以表支持，偷偷告诉你 Ocelot的做者也Star了哦。 :)

总结

经过本文咱们了解到了什么是 API 网关以及API网关的做用和其在微服务架构中所处的地位。而后咱们了解到了 API 网关的一些开源项目以及博主介绍的落地方案，在实际的实践中仍是多但愿你们可以多多思考总结，这样咱们才可以变得更增强大。

 

若是你对 .NET Core 有兴趣的话能够关注我，我会按期的在博客分享个人学习心得。