一、为什么会有 API Gateway 网关#

随着微服务架构的流行，很多公司把原有的单体架构改造成了微服务架构。

第一步：拆分

微服务架构就是把一个大单体改造成一个一个小的应用。比如把一个电商网站，从单体改造成微服务架构，如下图：

改造成微服务后，用户通过 PC 和手机访问电商应用，都是调用后面的微服务 API，而且各自要调用多个后端 API 服务才能拿到需要的数据。业务量小的时候，这种访问方式没有多大问题。用户多了访问量大了呢？这种方式就不能持续。

第二步：API 功能逐渐增多

如果后面业务发展较快，用户需要的功能越来越多，那么相应的后端微服务的数量也会越来越多，用上面这种方式来访问，调用的微服务 API 数量越来越多，如果访问量大服务器压力就会加大，那能不能缩减下调用 API 的数量，减轻服务器访问压力？聚合服务，内部聚合一些 API 服务接口形成一个聚合服务，PC 或手机客户端访问这个聚合服务，是不是就减少了访问次数？提高访问性能，提升用户体验。

为了提高 API 服务的可用性，还会给 API 加上限流控制，超时控制，熔断降级，API 隔离等功能。

为了提高 API 服务访问安全性，还会给 API 加上访问控制，比如进行 JWT 验证，黑白名单机制。如下图：

第三步：API 网关

想一想，每一个 API 服务都需要这些功能，那能不能把这些功能集和在一起？后面就不需要给每个 API 添加同样的功能。减少开发时间。

这些功能都可以集成到 API Gateway 网关中，如下图：

还有，要上线服务或重构 API 服务时，这种用户直接访问后端的方式，就会造成用户访问出现错误，对用户体验是很大伤害。API 网关屏蔽用户直接访问后端服务，它就可以平滑过渡这种发布需求或重构 API 需求。

它还有负载均衡，后端服务可以进行相应扩展。

二、API 网关功能#

通过上面介绍可以看到，API 网关可以统一后端的访问，也就是用户访问后端服务必须通过 API 网关才能够访问到。API 网关统一管理了后端的服务接入服务。

它就相当于一尊门神，守护着后端的所有服务。

API 网关的功能：

API 管理：API 上线、下线，API 路由转发服务治理：限流控制，超时控制，熔断降级安全策略：统一身份认证，黑白名单机制协议转换：REST、gRPC、Dubbo 不同协议转换API 发布策略：灰度发布，流量染色负载均衡：服务扩展，服务伸缩

其他一些功能：监控报警、链路追踪、日志收集审查等。

三、常见开源 API 网关介绍#

在前面写的关于微服务文章：微服务架构学习与思考(04)：微服务技术体系 一文中又提到过一些开源网关软件。这次再来详细介绍下开源 API 网关软件。

3.1 以 Nginx 为基础的网关#

以 Nginx 为基础，在加上 Lua 语言来进行扩展编程的网关。

3.1.1 OpenResty#

介绍：OpenResty® 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。

OpenResty 官网：官网地址

github：OpenResty github

看这个介绍，OpenResty 的功能不止于网关功能，还有高性能动态 Web 应用和服务。

它内部集成了大量精良的 Lua 库，库地址 。

有很多 Nginx API for lua，你可以自己用 lua 来编写相关功能。

当然，它还提供一个企业级(收费服务)产品，提供了很多关于 API 网关功能，Web 界面的操作。

没有找到与开源产品功能对比，只有企业级产品功能介绍。

3.1.2 Kong#Kong 网关介绍#

kong 是一个高性能高可用易扩展的 API 网关和 API 服务管理的软件，它基于 OpenResty(Nginx+Lua)。

它可以在物理机上运行也可以在 kubernetes 上运行。

kong 官网：官网地址

github地址：kong github

kong 也提供了一张使用网关前后的对比图，可以直观看到使用 API 网关的变化，API 自身的功能明显减少，都集成到 kong 里面：

一些通用的功能都集成到 kong 里，而后面 API/RPC 只需要编写业务相关功能就可以了，简化了 API 开发。

kong 架构#

kong 架构图：

Admin API：通过 admin api 来管理 kong 的功能Plugins：插件，默认插件和用户自定义插件Clustering & Database：存储 kong 集群节点信息，API 信息，插件信息等。目前提供了 PostgreSQL 和 Cassandra 2 种支持，如果需要高可用建议使用 Cassandra。OpenResty：处理插件、运行插件程序Nginx：处理底层操作功能简介#开源产品和企业产品功能对比

kong 也提供了企业级产品，它还给出了 kong 开源产品和 kong 企业级产品功能对比图，功能详细对比在这里 。

可以看到，企业级产品比开源产品提供了丰富得多的功能，这样才能给企业提供价值。

对比来看，开源功能相对企业版较少(开源产品功能也挺多)，但是开源产品功能已经足够小公司用，还能自定义插件功能。如果你有预算费用可以使用企业版，这样更快还有官方咨询服务。如果没有预算，那开源也足够用，也可自己开发插件。

开源产品功能

开源产品除了提供一些基础功能:

包括 HTTP 基本认证、密钥认证、CORS、监控、文件日志、API 请求限流、请求转发、缓存、SSL设置等基本功能，这些功能都是通过插件机制实现。

在 kong 3.0.x 文档中，还看到了蓝绿部署、cluster等功能，更多功能可以看文档。

还有一些其他重要功能特性:

集群

kong 支持单节点集群和多节点集群。

单节点集群：连接到数据库（Cassandra 或 PostgreSQL）的单个 Kong 节点创建一个节点的 Kong 群集。通过此节点的 Admin API 应用的任何更改都将立即生效。

多节点集群：多节点集群它是通过定期后台作业与其他节点进行数据同步。可以通过配置参数 db_update_frequency(默认 5 秒) 更改频率，这个频率更新有点慢。所以 kong 集群数据一致性是最终一致性。

kong 也给用户提供了自定义插件的功能，如果你有需要，自己可以编写插件来扩展 kong 的功能。

扩展功能-编写插件

用户可以编写插件来对 kong 功能进行扩展，kong 的插件是在 API 请求响应循环的生命周期中被执行的。

kong 插件文档，默认用 lua 语言来编写插件，也可以用其它语言。

a. 编写插件可以使用的语言 lua，Go，python，js

kong 在 2.6.x 支持了其他语言编写插件，有 Go，python，js，文档地址：。更老的版本应该也有支持的，得去看文档。

它还有一个编写插件的模板。

b. 插件市场 plugin hub

kong 也有自己的一个插件市场，也就是说你也可以给 kong 贡献第三方插件，是优质插件可能会被收录。

通过 admin-api 来管理 kong

详细看文档地址：

web UI 界面管理#

kong 企业版提供了管理 UI，开源版本没有管理 UI。但是程序员是多么的勤奋也崇尚开源，所以就有很多开源贡献的管理 UI，其中比较好用的，介绍 1 个， konga。

konga 看 github 上的更新时间，也是 3 年前了，也算比较老的了。

3.1.3 APISIX 网关#APISIX 介绍#

Apache APISIX 是 Apache 软件基金会下的云原生 API 网关，它兼具动态、实时、高性能等特点，提供了负载均衡、动态上游、灰度发布（金丝雀发布）、服务熔断、身份认证、可观测性等丰富的流量管理功能。我们可以使用 Apache APISIX 来处理传统的南北向流量，也可以处理服务间的东西向流量。同时，它也支持作为 K8s Ingress Controller 来使用。

apisix 也是基于 nginx，openresty 的。

apisix 文档：apisix doc

apisix github：apisix github

APISIX 架构#

整体架构图：

从图上可以看出，APISIX 底层基座也是基于 Nginx 和 OpenResty。运行在基座之上的是 APISIX 软件。

底层技术基座：Nginx 和 OpenRestyAPISIX软件：看上面架构图，第一部分：APISIX Core，apisix 核心，包括 Lua 插件、多语言插件运行时（Plugin Runner）、Wasm 插件运行时等第二部分：各种内置插件，包括可观测性、安全、流量控制等插件。

APISIX 多语言插件运行时提供多种开发语言的支持，比如 Golang、Java、Python、JS 等。

技术架构图：

从另外一个角度来看看apisix架构，分为数据面和控制面：

apisix 使用 etcd 作为配置中心来进行数据信息保存和同步配置。特性功能#

可以到 github 上看它的 Features，列举了很多功能特性。

扩展能力-插件功能

a）apisix 内置了很多插件，可以看文档 Plugins。

b）它也有一个插件市场，plugin hub。

c）当然你也可以自定义插件。这些看起来与 kong 开源版本拥有扩展功能差不多。

高可用集群Apache APISIX 的数据平面是无状态的，可以进行随意的弹性伸缩，前面加一层负载均衡即可Apache APISIX 的控制平面是依赖于 etcd cluster 的高可用实现的，不需要任何关系型数据库的依赖

与 kong 区别：

这第二点与 Kong 集群有区别，Kong 集群依赖的是 Postgre 和 Cassandra。

Web UI#

通过RESTful API 来管理 apisix，通过 Admin API 来管理 apisix 节点。通过 Control API 控制单个 apisix 数据平面行为。

官方还提供了一个 Dashboard，通过 UI 管理 apisix。

与 kong 区别：

kong 开源版本没有这个 Dashboard 功能，企业版本有。

3.1.4 Orange 网关#

这个 orange 也是一 OpenResty 为基础开发的网关，

orange 的功能相对于前面的 kong 和 apisix，比较少。所以它的架构肯定比他们简单，可以作为学习之用。

如果你不需要那么多功能，可以试用下这款 API 网关。

四、API 网关缺点#让系统复杂度变高

在整个系统架构中，多一个了 API 网关，就多了一份维护工作，多了一处发生“危险”的地方。

API 网关可能成为性能瓶颈

因为所有的流量都要经过 API 网关，可以通过扩展集群来解决。前面在加一组负载均衡设备等方法。