微服务架构学习与思考(10):微服务网关和开源 API 网关01-以 Nginx 为基础的 API 网关详细介绍
一、为什么会有 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 里面:
(来自:https://github.com/Kong/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 企业级产品功能对比图,功能详细对比在这里 https://docs.konghq.com/gateway/latest/#features。
可以看到,企业级产品比开源产品提供了丰富得多的功能,这样才能给企业提供价值。
对比来看,开源功能相对企业版较少(开源产品功能也挺多),但是开源产品功能已经足够小公司用,还能自定义插件功能。如果你有预算费用可以使用企业版,这样更快还有官方咨询服务。如果没有预算,那开源也足够用,也可自己开发插件。
- 开源产品功能
开源产品除了提供一些基础功能:
包括 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,文档地址:https://docs.konghq.com/gateway/2.6.x/reference/external-plugins/。更老的版本应该也有支持的,得去看文档。
它还有一个编写插件的模板。
b. 插件市场 plugin hub
kong 也有自己的一个插件市场,也就是说你也可以给 kong 贡献第三方插件,是优质插件可能会被收录。
- 通过 admin-api 来管理 kong
详细看文档地址:https://docs.konghq.com/gateway/3.0.x/admin-api/
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 架构
整体架构图:
(from:https://apisix.apache.org/zh/docs/apisix/getting-started/)
从图上可以看出,APISIX 底层基座也是基于 Nginx 和 OpenResty。运行在基座之上的是 APISIX 软件。
-
底层技术基座:Nginx 和 OpenResty
-
APISIX软件:看上面架构图,
第一部分:APISIX Core,apisix 核心,包括 Lua 插件、多语言插件运行时(Plugin Runner)、Wasm 插件运行时等
第二部分:各种内置插件,包括可观测性、安全、流量控制等插件。
APISIX 多语言插件运行时提供多种开发语言的支持,比如 Golang、Java、Python、JS 等。
技术架构图:
从另外一个角度来看看apisix架构,分为数据面和控制面:
(from:https://github.com/apache/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 官网: orange 地址
github 地址:orange github
orange 的功能相对于前面的 kong 和 apisix,比较少。所以它的架构肯定比他们简单,可以作为学习之用。
如果你不需要那么多功能,可以试用下这款 API 网关。
四、API 网关缺点
- 让系统复杂度变高
在整个系统架构中,多一个了 API 网关,就多了一份维护工作,多了一处发生“危险”的地方。
- API 网关可能成为性能瓶颈
因为所有的流量都要经过 API 网关,可以通过扩展集群来解决。前面在加一组负载均衡设备等方法。
五、参考
- https://openresty.org/ openresty 官网
- https://github.com/openresty openresty github
- https://github.com/openresty/lua-nginx-module lua 模块
- https://openresty.com.cn/cn/edge/ openresty edge 企业级产品
- https://github.com/openresty/lua-nginx-module#nginx-api-for-lua nginx api for lua
- https://konghq.com/ kong 官网
- https://github.com/kong/kong kong github
- https://docs.konghq.com/gateway/3.0.x/ Kong 3.0.x 文档
- https://docs.konghq.com/gateway/3.0.x/plugin-development/ kong 插件文档
- https://docs.konghq.com/gateway/3.0.x/production/clustering/ Kong 3.0.x 的集群文档
- https://docs.konghq.com/hub/ kong 插件 hub
- https://github.com/Kong/kong-plugin 插件模板
- https://github.com/pantsel/konga kong web ui
- https://apisix.apache.org/zh/docs/apisix/getting-started/ apisix 文档
- https://apisix.apache.org/zh/docs/apisix/plugins/batch-requests 内置插件
- https://apisix.apache.org/zh/plugins/ 插件市场
- https://apisix.apache.org/zh/docs/apisix/control-api/
- http://orange.sumory.com/docs/ orange 地址