再谈 APISIX 高性能实践

2019 年 8 月 31 日，OpenResty 社区联合又拍云，举办 OpenResty × Open Talk 全国巡回沙龙・成都站，APISIX 主要作者王院生在活动上做了《APISIX 高性能实践》的分享。

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

王院生，APISIX 项目发起人和主要作者，OpenResty 社区、OpenResty 软件基金会发起人，《OpenResty 最佳实践》主要作者。

以下是分享全文：

首先做下自我介绍，我大学毕业后在传统金融行业工作九年，2014 年加入奇虎 360，期间撰写了《OpenResty 最佳实践》。我个人比较喜欢研究技术和开源，可能是受老罗影响，喜欢尝试理想化的事情。今年 3 月份与志同道合的伙伴一起创办了深圳支流科技公司，这是一家以开源方式创业的科技公司，在国内屈指可数，APISIX 是我们目前的主要项目。

APISIX 是微服务 API 网关产品，今年 7 月份我在上海做过一次关于“ APISIX 高性能实践”的分享，这次的内容是在上次分享的基础上，并会将最近的新积累分享给大家。

API 网关的地位越来越重要，它是所有流量的出入口，从图中可以看到请求方可能来自于浏览器、loT 设备以及移动设备等，API 网关作为中间管控层需要做安全控制、流量以及日志记录等。越来越多的企业采用了微服务的方式，以此完成内部解耦、灵活部署、弹性伸缩等技术特性从而满足业务需求。微服务的数量和复杂度也都随之水涨船高，通过 API 网关来完成统一的流量管理调度就非常必要，并对 API 网关提出了更高要求。

上图是 APISIX 的基本构架，由于要支持集群和高可用，所以在任何一个节点都需要包含 adminAPI 或 APISIX 内核，使用时可以只启用其中一部分或都启用。admin API 主要用于接收管理员的提交信息，通过 json schema 完成参数的校验，防止非法参数落到存储的配置中心。APISIX 内部部分处理外部请求，根据请求特征，匹配到具体路由规则，执行插件，然后把流量转发到指定上游服务。

APISIX 每个月会发布一个版本，在 0.7 版本支持了路由插件化，很自豪地说这是目前唯一允许自定义路由的 API 网关实现。除了之前已有的 r3 路由，APISIX 新增了专门高性能的前缀匹配 radixtree，radixtree 是由 Redix 的作者开源出来的。radixtree 代码的匹配效率是 r3 的 10 倍甚至更高，一些生产用户升级 radixtree 后 CPU 使用率确实下降明显。

上图显示的是两个月前 APISIX 已有的功能。

最近的两个月，APISIX 增加了以上新功能，每个月大概都会有 5、6 个大的新特性，如果我只准备 APISIX 里的一些新特性与大家分享，各位受益可能会比较小，所以今天我给大家分享一些通用的 OpenResty 编程技巧。

APISIX 主打的是高性能，我们与 OpenResty 对比性能，这样更能突出 APISIX 性能的极致。首先用 APISIX 完整服务来压测，对比一个没有任何功能的空 OpenResty 服务，发现 APISIX 在加载了所有功能的情况下只下降了 15% 的性能。换言之，你如果能接受 15% 的性能下降，就可以直接享受上图的所有功能。

既然已经有了 r3 ，为什么我们还要继续用 resty-radixtree 实现新的路由呢？

先介绍 r3 的问题：r3 的学习复杂度比较高（正则本身就有学习难度），并且不支持通过迭代器的方式迭代匹配结果，效率相比前缀树实现低不少。相反这些问题在 resty-radixtree 上都有完美解决方案，性能、稳定性自然也就提升很多。目前的 resty-radixtree 是基于 antirez/rax 实现的，也是 Redis 的作者写的，站在巨人肩膀可以让我们少走不少弯路。

从数据结构上看，前缀树理论上是比哈希算法更快，原因是哈希算法的真正复杂度是O(K)，K 是指查询的 Key 的长度，Key 越长哈希算法把字符串变成整数就越复杂，而前缀树是层层递进，最坏的复杂度就是 O(K)，因此前缀树的最坏效率与哈希算法是一样的。

当然这只是原理上的，经过专门测试发现 Lua table 的哈希查找速度秒杀前缀树，这是因为在编译 LuaJIT 的时候，它使用了 CPU 指令集来计算哈希值，这样可以完美的做到 O(1)，所以 LuaJIT table 的哈希是效率是最高的，其次才是前缀树。

在 LuaJIT 世界匹配效率最高，永远都是先优先使用 Lua table 的哈希匹配。我们最终也没直接使用前缀树（trietree），因为它比较消耗内存，而是采用了基数树（radixtree），在性能相差不多的情况下，内存占用更小。

OpenResty VS Golang、HTTP VS gRPC

2015 年我没有选择 Golang 而选择 OpenResty，原因是我认为 OpenResty 可以思考地更深入，而 Golang 只能站在应用层去解决问题，出于这个原因我选择了 OpenResty。

APISIX 支持了这样一个场景：HTTP(s) -> APISIX -> gRPC server，把 REST API 转成 gRPC 请求。完成该功能后，需要做些压力测试验证效果。为了方便对比，用 Golang 的方式也写了一个协议转换网关。测试发现 APISIX 的版本比 Golang 的版本性能略还好一点，我的电脑上都是单核 1 万左右的 QPS。本以为在 gRPC 领域 Golang 的性能应当是最好的，没想到 APISIX 有机会略胜一筹。

我们之前粗浅地认为 HTTP 的性能一定没有 gRPC 的性能好，现在看有点武断。gRPC 的很多优势是 HTTP 不具备的，比如它的体积更小且内置 schema 检查等。但如果你的请求体比较小，在 HTTP 上使用 json 加 json schema，它们俩的性能几乎相同，尤其是在内网环境下相差还是非常小的。如果请求体比较大编码复杂，那么 gRPC 会有明显优势。

对获取 Nginx 变量的加速，最简单的就是用 iresty/lua-var-nginx-module 仓库，把它作为一个 lua module 编译到 OpenResty 项目里。当我们提取对应的 ngx.var 的时，使用库里提供的方法来获取，可以让 APISIX 整体有 5% 的性能提升，单纯某个变量性能对比，至少有 10 倍差别。当然也可以把这个模块编译成动态库，然后用动态方式加载，这样就不用重新编译 OpenResty。

APISIX 网关会从 ngx.var 里获取大量变量信息，比如 host 地址等变量更是可能会被反复获取，每次都与 Nginx 交互效率会比较低。因此我们在 APISIX/core 里加了一层 ctx 缓存，也就是第一次与 Nginx 交互获取变量，后面将直接使用缓存。

题外篇：再次推荐大家多参考借鉴 APISIX/core 中的代码，这些代码是通用的，对大多数项目都应该有借鉴意义。

fail to json encode

当我们用 json 的方式去 encode 一个 table时，可能会失败。失败原因有以下几种：比如 table 中包含 cdata 或者 userdata 无法 encode ，又或者包含 function 等，但实际上我们做 encode 并不是想要一个可以完美支持序列化/反序列化的结果，有时候只是为了调试。

所以我在 APISIX 的 core/json_encode 增加了一个布尔参数，表示是否进行强制转码，这样当遇到不能转码时就把强制它变成一个字符串。此外 table 套 table 是一个常见的情况，即有一个 table A，在 A 的 table 里面的内部又引用了A 自身，形成了一个循环嵌套。这个问题的解决比较简单，在发生嵌套时，到达某一个位置点后就不要再往里嵌了。这两个场景下允许强制 table encode 对我们开发调试非常有用。

在调试时，如果需要打一下 table 结果，当日志级别不够时，不应该触发无意义的 jsonencode 行为，这时候推荐使用 delay_encode 来调试日志，只有当日志真正需要写到磁盘上时，才会触发 json encode，避免那些不需要 encode 。这个问题在APISIX 里面效果非常好，终于不需要注释代码就可以完成不同级别日志的测试，有点 C 语言中宏定义的味道，对性能和易用是个极好的平衡。

目前 APISIX 进行 CI 回归，都会运行代码检查工具进行检查：Lua -check 和 lj-releng。对当前代码目录的内容做静态检测，比如有没有加全局的变量，代码行的长度是不是超了等。

调试过程中发现的一个特别有意思的关于 rapid json 声明周期的 bug。关于这个周期的原因可以看一下上图的最后一行，我们真正使用的是 validator，而且只调用了validator 的一个验证，它是从上边的 create-validator 得来的。这里值得注意的是，为什么用一个数组缓存住另一个叫 sd 的对象呢？

因为 validator 是个 cdata ，内部有对 sd 对象的指针引用依赖，他们两个也就必须要有相同的声明周期，不能有某一项提前释放的情况。如果我们需要让两个对象有相同的生命周期，那么把它们放到同一个 table 中是最简单的方法。

如果你选择效率最高的 C 库，而这个 C 库里还引用了 pcre 这个库，那就需要考虑到一个问题，这个对象的跨请求就会有非常大的风险，为此必须要单独给这个库创建独立的内存池，决不能使用当前请求的内存池，因为当前请求很快就被释放。

怎么解决这个问题呢？如果现在 OpenResty 有相关的 API，那么直接去申请内存池是最好的，但是可惜 OpenResty 并不具备。看看 Ningx 源码，可以看到创建 Nginx 的内存池函数定义是 ngx_create_pool(size_tsize, void *log) ，只要能获取到全局日志句柄即可。

我们选择从全局的 ngx_cycle 获取 log 对象，这里我定义了一个虚假的 fake_ngx_cycle 结构体，这个结构体和 Nginx 的 ngx_cycle 构体的前三项是一样的，但是截掉了后面的部分，然后我们做内存拷贝，从而得到了 log 对象指针位置。

我当时在研究 Kong 的 prometheus 插件时粗略看了一下它的代码，发现他的实现逻辑是有问题的，会非常影响性能。所以没有直接使用 Kong 的方式，在 APISIX 中开启这个插件，性能只会下降5% 左右。这个插件我们比 Kong 高近 10 倍性能。我也和 Kong 的技术负责人聊过这里，后续会把 APISIX 的一些做法贡献给 Kong，相互学习一起成长。

以上是我今天的全部分享，谢谢大家！

演讲PPT下载及视频观看：

Apache APISIX 微服务网关极致性能架构解析