API 网关的选型和持续集成

2019 年 8 月 31 日，OpenResty 社区联合又拍云，举办 OpenResty × Open Talk 全国巡回沙龙·成都站，APISIX 做者温铭在活动上作了《 API 网关的选型和持续集成 》的分享。

OpenResty x Open Talk 全国巡回沙龙是由 OpenResty 中国社区、又拍云发起，邀请业内资深的 OpenResty 技术专家，分享 OpenResty 实战经验，增进 OpenResty 使用者的交流与学习，推进 OpenResty 开源项目的发展。

温铭，深圳支流科技联合创始人，开源微服务 API 网关 APISIX PMC，OpenResty软件基金会发起人，《OpenResty 从入门到实战》专栏做者，创业以前在互联网安全公司工做了 10 年，主要从事服务端的开发和架构，负责开发过木马云查杀、反钓鱼系统和企业安全产品。曾在奇虎 360 担任架构师，开源委员会发起人、委员。

如下是分享全文：

我和院生在作的一个开源的 API 网关项目叫 APISIX，今天介绍这个项目涉及到 OpenResty 的技术和选型，主要包括三个方面：

• 第一， API 网关是什么，它有什么做用；
• 第二，如何去作 API 网关，如何作选型；
• 第三，APISIX 是一个开源项目，介绍咱们在只有两我的的状况下是怎么去作测试和持续集成，里面会涉及 OpenResty 的一些通用的东西，值得你们借鉴。

API 网关的做用

什么是 API 网关

以 Kong 为例，左图没有 API 网关，可是后面挂了不少服务，若是每一个服务都要实现包括认证、统计、安全校验等功能，会有不少重复的工做。API 网关的做用就是把这些公共的东西抽取出来，如右图，下面的这几个服务，每一个服务都只关心自身业务相关的东西，和业务无关的东西所有都丢到API 网关上，即 API 网关就是把公共的东西如统计、安全、限流、限速、缓存等提取出来作了一个中间层。

API 网关的传统功能

• 让 API 请求更安全、更高效的获得处理。传统的 API 网关有一些基本的功能直到如今都适用的，管理无论南北向的仍是东西向的 API 流量能够可以快速、安全地获得处理，这个是 API 网关最原始的目的。
• 覆盖 Nginx 的全部功能。API 的网关覆盖了 Nginx 的全部功能，包括反向代理、负载均衡以及基本的缓存、安全的认证、限流限速等。
• 支持 Nginx 等 Web 服务器实现不了的功能。如动态上游、动态 SSL 证书、动态限流限速，以及主动/被动健康检查、服务熔断等，这些动态的能力都是传统的 Nginx、Apache 这类Web 服务器支持不了的。
• 全生命周期管理。在 API 网关领域，最大的玩家是谷歌，谷歌在 2016 年收购了一家上市公司 Apigee，它如今把整个功能集成在谷歌云上。API 网关除了咱们熟悉的反向代理、负载均衡、限流限速的插件外，它还包括了 API 的设计、文档以及测试等，这一整套都属于 API 网关的功能，咱们叫作 API 的全生命周期管理，从项目设计到测试上线，全部的东西都在整个 API 网关的功能范畴内。

云原生下的新功能

为何如今包括 Kong、APISIX 还要把传统的东西再作一遍呢？这是由于在云原生和微服务体系下，用户和技术架构有了一些新的变化：

技术架构新变化

• 须要对接云原生里面像 Prometheus、Zipkin、Skywalking 等重要组件；
• gRPC 代理和协议转换（REST<=>gRPC）：HTTP 这种协议在微服务里面用的愈来愈少，不少人开始用 gRPC，那在从 HTTP 到 gRPC 协议的转换，这种功能也是须要的，包括 gRPC 的代理；
• 身份认证方式改变：在传统的 Nginx 里面，通常是流量进来后根据路由的规则去作反向代理、负载均衡，不多对发流量的客户端的身份作认证。可是在云原生里面就不同，由于不少是在微服务里的流量，这里面须要作严格的身份认证，包括加密、OpenID 之类的身份认证。这块就是一些新的功能，能够把本身企业里面须要作身份认证相关的东西放到第三方的外部认证的厂商去作；
• Serverless 也是最近几年很是火的一个概念，好比但愿在边缘节点上面动态地把一个函数跑起来或者把一个函数给停掉，或者动态地去改里面的内容，你能够把你的 API 网关部署在边缘节点上，具有了这种 FaaS 的功能，你的边缘节点就会更加地灵活。APISIX 里面最近就支持了 Serverless，可让你的一个 Lua 的函数动态地在边缘结点跑起来；
• 无状态、随意扩容和缩容：API 网关在十多年前性能要求没有那么高，由于当时互联网的流量更多地是从浏览器到服务端，没有手机和物联网的设备，也没有微服务、内网这些流量。可是如今的流量很大，包括 4G、5G下面有不少的手机、IoT 设备去访问服务端，流量特别地大。此时，就须要一个性能更高的 API 网关去作支撑。云原生的一个重要的标准是全部的服务均可以经过容器的方式随意地去扩容和缩容，对 Kubernetes 友好；
• 支持多云和混合云：如今上云已是一个趋势，可是咱们通常不太会把服务只放在一个云上，好比腾讯云、谷歌云、阿里云各放一部分，私有云再放一部分，根据它们的安全和价格作调整，私有的一些数据安全性更高的放在私有云上，资源好比和 CDN 相关的哪一个便宜就放哪一个云上，作动态的切换，那么此时就须要有一个和厂商无关的 API 网关放在前面作分发。

应用

举两个例子，介绍下新的 API 网关是作什么的。

• 替换 Nginx 的全部功能处理南北向的流量

它和 Nginx 比好处很明显，是彻底动态来实现的，无论是 Kong 或 APISIX，动态的都是最基本的点。在 Nginx 里面修改任何一个配置文件，都须要 reload 以后才能生效的。咱们设想一个场景，用 Nginx 作最前面的路由，作负载均衡，突发的流量来了，此时须要快速地增长不少上游服务器，就要不停地修改 Nginx 配置文件，而后 reload，等突发流量过了以后再把上游的服务摘掉，那么这时候还要再改 Nginx 文件并 reload 。这个代价是很大的，可是你若是用 Kong、APISIX 这种 Web 服务器，就不会有这样的问题，经过 API 能够很轻松地实时修改整个集群里面全部机器上游的配置、动态证书的配置，固然性能会比 Nginx 稍微低一点，可是这个低也是能够接受的，由于它带来了很大的灵活性。如今不少的厂商都是在作这样的替换，不只互联网公司，还有一些传统企业都在把 Nginx 慢慢地拿掉。

• 零信任网关

近两年安全领域里很火的概念就是零信任，即zero trust。在传统的安全领域里面，咱们认为边界防御很是重要，因此会用防火墙对进来的流量作一层校验，这个校验实际上是命中规则的校验，若是是黑的就把它拒绝掉。那么这个时候就会有一个问题：若是一些规则更新不及时，它就能够穿越防火墙，之前的安全更可能是基于边界的防御，过了边界内网是能够畅通无阻的。

可是零信任网关能够完全解决这个问题，它认为全部的流量都是不安全的，之前的边界防御是非黑即白。如今的零信任安全网关则是非白即黑，你不是白的，那么你就是黑的，因此它是彻底基于身份来认证的。一个 API 的请求过来会到身份认证的服务器，第三方的身份认证厂商好比 Author0、OKTA 的身份认证服务器认证你的身份，身份认证过了，请求才能够经过，否则就直接拒绝掉，这是是安全领域的一个趋势。

企业用户的需求

• 不锁定，可回退

全部企业用户的最大需求都是：不要锁定用户。API 网关是整个流量的入口，不能把用户锁定在里面。好比你用了阿里云的 API 网关，其实你就已经被它锁定了，由于它是流量的入口，你没有办法分发到其它云厂商上。此外还须要可回退，我使用了这个API 网关，好比原来是 Nginx，我能够很轻松地回退过去，这也是咱们在作 APISIX 会考虑到的。可能用户以为用了一段时间不爽，想退回 Nginx，咱们也能够支持这种能力。

• 保持核心的稳定

APISIX 虽然每月的迭代很是快，每月有 200 多个 commit，有 10 个左右大的功能，可是 APISIX 里面有一个叫 core 的目录变化是不多的，咱们会保持它的核心是稳定的。功能迭代能够很快，可是核心很稳定。

• 支持企业个性需求的开发

不管是国内仍是国外的企业，都没有办法拿产品去适应全部的需求。若是你适应了全部的需求，那么你就作成了一个巨无霸，会是个很大很杂的产品，它的性能、可扩展性就会降的很低。因此咱们就有插件，若是你须要有个性化的东西，就去定制本身的插件，须要什么功能就把这个插件放上去，不须要就把它拿掉。我能够保证最下面核心层是很稳定的，上面那层能够根据用户需求定制。

如何作网关的选型

行业现状了解

• 参考 Gartner 报告

这个是咱们选型的思路，咱们作选型并非先从技术上去作，而是先看整个行业，Gartner 的报告能够做为参考。如上图所示，谷歌、IBM、RedHat 等头部玩家吃掉全球大部分 API 市场，虽然技术圈都知道 Kong，但它其实处于远见者的地位，此外Kong 做为新兴的玩家仍是第一个将自身 API 网关开源出来的。

• 参考 CNCF 全景图

Gartner 的报告更偏商业化，能够在此基础之上参考开源社区中云原生软件基金会CNCF 维护的全景图，不少开源和闭源项目都被其分层、分功能地罗列出来。全景图中云原生领域有十几款软件是作 API 网关选型时能够选择的，其中有一半是大厂的产品，如 3SCALE 是Red Hat 的产品，剩下的 Kong、APISIX、TYK 等是开源项目，若是要作 API 选型能够在其中作选择。

产品选型比较

在参考 Gartner 报告和 CNCF 全景图以后，咱们比较了主流的 API 网关，决定不用已有的 API 网关而是要本身作一个。

• apigee

apigee 是最大的玩家，其优点在于全生命周期，即从 API 设计、开发、文档、测试以及上线等所有是谷歌全家桶。但 apigee 是闭源项目，没法进行定制化开发，并且是被谷歌云锁定的。

• Kong

Kong 解决了 apigee 的痛点，既不会锁定也支持自定义开发，但 Kong 是 2015 年开发的，当时是把数据都放在Postgres 比较重的关系性数据库里，代码繁杂，性能存在问题。Kong 的优点在于产品思路好，方向看得准。

• APISIX

APISIX 借鉴 Kong 的思路，选型时彻底基于 etcd，将全部的数据都放在 etcd 里面，完成 Kong 在postgres 上作的大量重复代码，例如消息分发、高可用和可扩展性都是基于 etcd 进行，操做更加简单。APISIX 的不足在于开源时间短，从 2019 年 6 月 6 号开源到如今还没有经受大用户的检验，但优点明显：二次开发难度比 Kong 小不少。以限流限速功能开发举例， 在 APISIX 的文件里增长六七十行代码就能完成，但 Kong 则须要修改五六个文件、两三百行代码。

如何作网关的技术选型?

API 网关的核心组件：

• 路由，路由能够认为是 Nginx 里面的各个 location，怎么把 location 分发到上游服务将各个插件加载起来是路由的一个功能。选择时须要思考的是作遍历仍是作一个树？两者须要的时间和复杂程度是不同的，咱们选择像 Kong 同样作遍历。
• 插件，插件是 API 网关的核心功能，有了插件就能够很轻松地开发属于本身的代码，而不用等开源社区增长相关功能。在作插件时须要思考要不要作成热加载，热加载的意义在于新增插件或者修改某一个插件时，不须要重启整个服务就能生效。咱们但愿作到修改或新增插件时，能够经过 API 的调用立刻生效。
• schema 的校验，schema 的校验指的是用户请求进来后须要校验上传的字段、类型等是否合法，若是本身写插件，其参数、输入值是否合法，这至关因而对 API 的描述，使得我的和前端的配合十分便利。
• 存储， 放在关系型数据库仍是键值数据库，亦或是放在 etcd 里等同因而在作技术选型，须要把这些都选好后才能像搭积木同样搭建起来。

选型原则：作云原生友好的、高性能的、开源的 API 网关

• 要对开发者友好。使用 API 网关的是开发者，咱们但愿无论是开发者看代码、学代码仍是修改插件都能很轻松，不用像我和院生当时看 Kong 的代码那样痛苦。
• 追求性能。虽然说 OpenResty 的性能高，可是真正动手写的时候会发现写出来的代码性能不高，由于在 OpenResty 里面代码都是很容易写，可是很难保证写出一个极致的代码，它里面有很是多的坑，这是大部分人很难去注意到的。

APISIX 的选型

• 路由：最开始选择 lua-resty-r3，最近新增路由 FFI；
• 插件：灵感来自 Kong，但架构和设计彻底不同，大幅简化编写难度，热加载；
• schema：借用腾讯开源的 rapidjson，在 rapidjson 实现 json schema，用 json schema标准作校验；
• 存储：选用 etcd，当时没有 Lua-resty-etcd 库，须要从头 lua 帮助 etcd 进行访问。

APISIX 独有的功能

• 超强性能，性能是主打标签，内部测试发现 APISIX 的性能是 Kong 的 10 倍；
• 插件热更新，修改或增长插件，不用重启服务，全部的更新都是热的；
• 路由能够实现插件化，若是不喜欢 r3 的复杂路由，可使用前缀匹配的路由；
• 支持版本变动控制，若是发布新版本出错能够轻松回退老版本；
• 以身份为基础的零信任，新合并的 future 能够支持外部身份认证，此时很容易实现零信任，能够接入全部外部身份认证厂商的服务。使用时只需简单调配部分参数，就能够将身份认证功能直接加入 API 中。Kong 的商业版也支持此功能，但 APISIX 直接开源。

测试、持续集成的最佳实践

测试

大公司都有专门的 QA 团队作测试，开发部门只须要写完代码简单自测后提交给 QA 团队。但开源项目没有 QA 团队，甚至连开发团队都是兼职，此时就必须用自动化的测试，即测试驱动开发的方式才能玩转开源项目。

OpenResty 的开源项目将近 70 个，其商业公司有将近 100 个闭源的项目，总共将近 200 个项目不到 10 我的维护。若是手工测试，那就什么都作不了，因此要想办法实现解决这个问题。

• 开发即测试

刚开始较慢，由于开发完一个新功能须要一块提交对应的测试案例，不然PR 不会被合并。例如给 OpenResty 贡献一个功能却没有提交对应的测试案例，或者提交了测试案例但不全，无论功能写的有多好，此PR 必定不会被合并，由于破坏了整个开源项目的原则，测试须要是自动化跑起来的。

APISIX 多引入一个条件，即代码的覆盖率不能低于70%，如今已经改成不能低于 80%。若是你的改动引入新代码，也增长了测试案例，可是下降了原有测试案例的覆盖率，那也不能被接受合并。

• 单元测试彻底基于 test:nginx

测试案例彻底基于 test:nginx ，能够认为 test:Nginx 是一个小语言或者一个DSL，文档较少，学习门槛比较高，我和院生对它比较熟悉才彻底基于此进行测试。

• 代码风格检测：luackeck 和 lua-relang

Luackeck 很是好用，能够用于 Lua 和 OpenResty，提供有几个参数进行选择，还可使用春哥写的 lua-relang。咱们是两个程序都跑起来作代码风格检测，以确保无论是新的提交者仍是咱们本身的代码风格的一致性。

• 代码覆盖率检测：luacov

代码覆盖率检测使用luacov，这是标准 lua 的一个功能，能够将代码覆盖率跑起来。

合并 PR 是在上述测试即 test:nginx 测试、代码风格测试、代码覆盖率测试都跑过的前提下进行，每个月 6 号发行新版本时进行性能测试，比较新老版本之间性能的差别。通常会跑火焰图，同时按期作fuzzing 测试，混乱输入如 uri、args 等作压力测试。毕竟 APISIX 是一个 API 网关，做为流量的入口要保证足够的稳定。

持续集成

测试不能依赖于人，不然总有一天会跑不下去。那么如何让单元测试、性能测试、代码风格检测等测试不依赖于人稳定地运行呢？

• 强依赖 GitHub:issue、Milestone、code review、PR approved。GitHub 的 code review 很是好用，它能够评论每一行代码，若是它以为这行代码必需要改动，而实际没有修改，是没有办法合并 approved。
• 强依赖 travis CI：单元测试、代码风格检测、多平台测试(ubuntu 和 mac)、前端打包、自动提交。travis 是 GitHub 的持续集成插件，APISIX 并无用本身的服务器资源去跑测试，而是跑在云端的，如今自带APISIX 的前端，其打包、提交都是自动化进行。由于咱们要从vue 的代码编译为 html，这一切都是经过 travis 来作的。
• http://coveralls.io，将代码覆盖率的结果上传到http://coveralls.io 网站，以可视化的方式呈现全部和代码覆盖率相关的东西，例如哪一行代码没有被检测到，和上一个版本有什么变化等，使得代码覆盖率检测自动化进行。前文曾提到要始终保证 APISIX 的核心稳定，这就须要保证core 目录里全部文件代码覆盖率可以达到 100%，即核心板块的每一行代码都被测试到。

总结

• 资源少不必定是坏事。无论是开源项目仍是商业公司，只有在资源少的时候，才会思考如何借助外部的力量或者是想出一些鬼点子解决问题；
• APISIX 的选型、测试和 CI 都是找“取巧”和自动化的方式，借助巧用外部力量的方式去作，没有造轮子；
• APISIX 的选型、测试和 CI 三者很是重要，比性能重要。虽然咱们主打性能，但更值得你们琢磨的不仅是代码，而是选型怎么测试和 CI 的，你们能够将其运用到业务中，即便不用 OpenResty 和 APISIX，仍是能够学习开源项目是怎么作的；
• GitHub 和 SaaS 能提供的服务，绝对不会本身去造，克制住本身造轮子的冲动。

查看演讲PPT及视频：

API 网关的选型 测试和持续集成

本文由博客一文多发平台 OpenWrite 发布！