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)，因此前缀树的最坏效率与哈希算法是一样的。