关于网关:为什么说-Apache-APISIX-是最好的-API-网关

明天，咱们能够通过手机和各种 APP 实现各种各样的事件，比方社交，网购等。这些行为的背地，API 起到了要害的作用。作为 API 的使用者，咱们并不关怀 API 的稳固、平安和高效，然而通过 API 提供数据服务的企业则须要抉择一个适合的 API 网关，用来保障数千乃至数万的 API 为提供疾速和平安的服务。

在 CNCF 的 API Gateway landscape 中有靠近 20 个 API 网关的选型（不包含私有云厂商的产品），包含 Apache APISIX、Kong、Tyk 等等。很多网关都称本人是下一代 API 网关，是最受欢迎的开源 API 网关我的项目，那么事实如何呢？本文将通过开发者、知识产权和品牌、技术、生态等多个维度来看看 Apache APISIX 为什么是下一代 API 网关？

工程师的眼睛是雪亮的

工程师是 API 和 API 网关的使用者和开发者，更多工程师关注和参加的 API 网关我的项目，代表的就是技术的趋势。咱们从 GitHub 代码贡献者的维度，选取了 4 个开源 API 网关进行比照：Apache APISIX、Kong、Tyk 和 Gloo。

Kong 和 Tyk 都是 2015 年之前开始研发的，Apache APISIX 和基于 Envoy 的 Gloo 是在 2019 年左右开始研发的。从上图中的 Github Contributor Over Time 能够看出，Kong 通过近 7 年的倒退曾经有超过 250 个贡献者参加，远远超过了 Tyk 和 Gloo；而最年老的 Apache APISIX，曾经超过 320 个贡献者，数量和增速都远超 Kong，成为最多开发者参加奉献的 API 网关我的项目。

除了贡献者总数外，还有一个指标能够看到更深层次的数据：贡献者的月度沉闷。下图展现了以上四个开源 API 网关的月度沉闷的开发者数量：

Tyk 的贡献者月沉闷人数，长期都是在 5 集体左右，很少超过 10 集体；而 Kong 和 Gloo 的贡献者月沉闷人数均在 10 到 20 之间浮动；而 Apache APISIX 根本放弃在 20 人以上，最高靠近 40 人，是开发者最沉闷的 API 网关。

这四个开源 API 网关我的项目背地，都是有对应的商业化公司的，所以还有第三个指标数据，那就是开源我的项目贡献者和商业公司员工数的比照：

API Gateway	APISIX	Kong	Tyk	Gloo
monthly active contributors	38	20	8	24
employees(from LinkedIn)	40+	500+	200+	100+

以后（2022年第三季度）Kong 和 Tyk 的开源投入比例（月度沉闷贡献者/员工总数）是 4%，Gloo 是 24%，APISIX 则是靠近 100%。即便回到 2017 年，Kong 的月度沉闷贡献者也在 5 集体左右。

不言而喻，开源我的项目 Apache APISIX 和它背地的商业化公司 API7.ai 从创立伊始，就放弃了对于开源我的项目的继续投入，博得了泛滥开发者的青睐。

开源协定：企业用户抉择开源我的项目的首要思考因素

自从 MongoDB 批改了开源我的项目的 License 之后，在做根底软件的选型时，开源我的项目的 License 危险就是企业用户首要思考的因素。

从外表上看，Apache APISIX、Kong 和 Gloo 应用的都是商业敌对的 Apache License Version 2.0，Tyk 应用的是带有传染性的 Mozilla Public License Version 2.0。

更深刻的看，Kong、Gloo 和 Tyk 这三个都是齐全由商业公司管制的开源我的项目，它们能够像 MongoDB 一样随时在新版本中批改 License，限度私有云或者其余公司收费应用，进而要求你从开源用户转为付费客户来持续应用最新版本。

没有人晓得这样的事件是否会产生，以及产生的几率有多大。这种危险，就像达摩克利斯之剑一样，悬挂在企业用户的头上。

在这种状况下，应用 Apache 软件基金会或者 CNCF 的开源我的项目是最理智的。而 Apache APISIX 是寰球最大的软件基金会 -- Apache 软件基金会的顶级我的项目，所有的代码和品牌都归属于 Apache 软件基金会，任何商业公司都不能管制 Apache APISIX 我的项目，也不可能批改开源我的项目的 license。企业用户能够始终释怀的应用，而不必放心收到律师和合规部门的问询邮件。

性能测试比照

在社区中常常会有用户发问：基于 Envoy 的 Gloo，和基于 NGINX 的 APISIX，谁的性能更胜一筹？

尽管性能并不是选型中最重要的指标，但它的确是最间接的指标。下表的表格是 Apache APISIX 和 Gloo 的 Benchmark 后果。从表格中能够看到，Apache APISIX 的 QPS 是 Gloo 的 4.6 倍，同时 Apache APISIX 的提早还不到 Gloo 的 7%。

这并不仅仅是 NGINX 和 Envoy 之间的差别造成的，而是因为 APISIX 在底层做了大量的优化，所以同样基于 NGINX 的 APSIX 绝对于 Kong 也有微小的性能劣势。

为什么 APISIX 的性能劣势如何之大？在代码背后，没有任何机密。让咱们从技术的角度来详细分析下。

APISIX 的技术劣势

以下内容是 Apache APISIX 和 Kong、Gloo 相比在技术方面的次要劣势，大部分都是在底层模块上的优化和翻新。在简略的 PoC 上并不一定可能体现出这些技术的劣势，但在简单的生产环境中，Apache APISIX 的这些劣势将会造成微小的差距。

无数据库依赖

在 APISIX 我的项目呈现之前，也有十分多的商业 API 网关或开源 API 网关产品，但这些产品大多数都把 API 数据、路由、证书和配置等信息寄存在一个关系型数据库中。

将这些数据存储在关系型数据库的劣势非常明显，用户能够更加不便地应用 SQL 语句进行灵便查问，也不便用户进行备份及后续保护。

然而网关作为一个根底中间件，它解决了所有来自客户端的流量，这种状况下对于可用性的要求便会十分高。如果你的 API 网关依赖了一个关系型数据库，也就意味着关系型数据库一旦呈现了故障（比方宕机、失落数据），API 网关也会因而受到影响，整个业务零碎的可用性也会大打折扣。

而 APISIX 在设计之初，就从底层架构上防止了宕机、失落数据等状况的产生。因为在管制面上，APISIX 应用了 etcd 存储配置信息，而不是应用关系型数据库，这样做的益处次要有以下几点：

与产品架构的云原生技术体系更对立；
更贴合 API 网关寄存的数据类型；
能更好地体现高可用个性；
领有低于毫秒级别的变动告诉。

应用 etcd 存储配置信息后，对于数据面而言只需监听 etcd 的变动即可。如果采纳轮询数据库的形式，可能须要 5-10 秒能力获取到最新的配置信息；如果监听 etcd 的配置信息变更，APISIX 就能够将获取最新配置的工夫管制在毫秒级别之内，达到实时失效。

因而应用 etcd 作为存储，不仅让 APISIX 在底层上更加贴合云原生，也让它在零碎高可用的体现上带来了更多劣势。

高性能路由匹配算法

API 网关须要从每个申请的 Host、URI、HTTP 办法等特色中匹配到指标规定，以决定如何对该申请进行解决，因而一个优良的匹配算法是必不可少的。Hash 算法性能不错，但无奈实现含糊匹配；正则能够含糊匹配，但性能不好，因而 Apache APISIX 抉择应用树这样一种高效且反对含糊匹配的搜寻数据结构。精确一些，Apache APISIX 应用的是 RadixTree，它提供了 KV 存储查找的数据结构并对只有一个子节点的两头节点进行了压缩，因而它又被称为压缩前缀树。此外，在已知 API 网关产品中 Apache APISIX 首次将 RadixTree 利用到了路由匹配中，反对一个前缀下有多个不同路由的场景，具体实现见 lua-`resty-radixtree`。

当对某个申请进行匹配时，RadixTree 将采纳层层递进的形式进行匹配，其复杂度为 O(K)（K 是路由中 URI 的长度，与 API 数量多少无关），该算法非常适合私有云、CDN以及路由数量比拟多的场景，能够很好地满足路由数量快速增长的需要。

高性能 IP 匹配算法

IP 地址有 2 种记法：规范 IP 示意办法与 CIDR 示意办法，以 32 位的 IPv4 为例：

规范 IP 记法：192.168.1.1
CIDR 记法：192.168.1.1/8

Apache APISIX 的 IP 匹配算法与路由匹配算法所应用的原理以及原始数据是不一样的。以 192.168.1.1 这个 IP 为例，因为每个 IP 段的范畴是 0 到 255，因而在对 IP 进行匹配时咱们能够认为 IP 地址是由 4 个16 位整数型的数形成的，IP 长度是固定的。那么咱们能够采纳更高效的算法实现匹配。

假如当初有一个蕴含 500 条 IPv4 记录的 IP 库，APISIX 会将 500 条 IPv4 的记录缓存在 Hash 表中，当进行 IP 匹配时应用 Hash 的形式进行查找，工夫复杂度为 O(1)。而其余 API 网关则是通过遍历的形式实现 IP 匹配，发送到网关每个申请将一一遍历最多 500 次是否相等后能力晓得计算结果。所以 APISIX 的高精度 IP 匹配算法大大提高了须要进行海量 IP 黑白名单匹配场景（如 WAF）的效率。

精细化路由

API 网关通过申请中的流量特色实现预设规定的匹配，常见特色蕴含了申请中的 Host、URI 门路、URI 查问参数、URI 门路参数、HTTP 申请办法、申请头等，这些特色是大部分 API 网关产品所反对的。相较于其它产品，Apache APISIX 反对了更多特色以解决复杂多变的应用场景。

首先，Apache APISIX 反对 NGINX 内置变量，意味着咱们能够将诸如 uri、server_name 、server_addr、request_uri、remote_port、remote_addr、query_string、host、hostname、arg_name等数十种 Nginx 内置变量作为匹配参数，以反对更复杂多变的匹配场景。NGINX 内置变量列表请参考 NGINX 变量。

其次，Apache APISIX 反对将条件表达式作为匹配规定，其构造是 [var, operator, val], ...]]，其中：

var 值可应用 Nginx 内置变量；
operator 反对相等、不等、大于、小于、正则、蕴含等操作符。

假如表达式为 ["arg_name", "==", "json"]，它意味着以后申请的 URI 查问参数中，是否有一个为 name 的参数值等于 json。Apache APISIX 是通过自研的库 lua-resty-expr 实现该能力的，具体请参考 lua-resty-expr。该个性将选择权交给了用户，可扩展性强。

此外，Apache APISIX 反对设置路由 ttl 存活工夫：

$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '{    "uri": "/aa/index.html",    "upstream": {        "type": "roundrobin",        "nodes": {            "39.97.63.215:80": 1        }    }}'

以上配置示意，在 60s 后 APISIX 会主动删除该路由配置，非常适合一些长期验证的场景，比方金丝雀公布、监控输入等。对于线上的流量分流十分不便，是其它网关产品所不具备的能力。

最初一点是 Apache APISIX 反对自定义过滤函数，你能够通过在 filter_func 参数中编写自定义 Lua 函数，例如：

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '{    "uri": "/index.html",    "hosts": ["foo.com", "*.bar.com"],    "filter_func": "function(vars)                    return vars['host'] == 'api7.ai'                end",    "upstream": {        "type": "roundrobin",        "nodes": {            "127.0.0.1:1980": 1        }    }}'

其中 filter_func 入参是 vars，可从 vars 获取 Nginx 变量，而后实现自定义过滤逻辑。

反对多语言插件

尽管 API 网关、数据库或其余中间件都属于根底组件，然而更多时候用户是依据应用场景对 API 网关进行一些定制化地开发和系统集成。

APISIX 目前曾经反对了 80 多种插件，但依然难以涵盖用户的所有应用场景。在理论应用场景中，很多企业都会针对具体业务进行定制化的插件开发，通过网关去集成更多的协定或者零碎，最终在网关层实现对立治理。

在 APISIX 晚期版本中，开发者仅能应用 Lua 语言开发插件。尽管通过原生计算语言开发的插件具备十分高的性能，然而学习 Lua 这门新的开发语言是须要工夫和了解老本的。

针对这种状况，APISIX 提供了两种形式来解决：

第一种形式是通过 Plugin Runner 来反对更多的支流编程语言（比方 Java、Python、Go 等等）。通过这样的形式，能够让后端工程师通过本地 RPC 通信，应用相熟的编程语言开发 APISIX 的插件。

这样做的益处是缩小了开发成本，进步了开发效率，然而在性能上会有一些损失。那么，有没有一种既能达到 Lua 原生性能，同时又兼顾高级编程语言的开发效率计划呢？

第二种形式是应用 Wasm 开发插件，也就是上图左侧局部。Wasm（WebAssembly）最早是用在前端和浏览器上的一个技术，然而当初在服务端它也逐步展现进去它的劣势。咱们将 Wasm 嵌入到了 APISIX 中，用户就能够应用 Wasm 去编译成 Wasm 的字节码在 APISIX 中运行。最终达到的成果就是利用高效率，开发出了一个既有高性能又应用高级计算语言编写的 APISIX 插件。

因而，在以后 APISIX 版本中，用户能够应用 Lua、Go、Python 和 Wasm 等多种形式，基于 APISIX 编写自定义插件。通过这样的形式，升高了开发者的应用门槛，也为 APISIX 的性能提供了更多的可能性。

总结

本文从工程师、开源协定、性能评测、技术、生态系统等多个角度剖析和比拟了一些 API 网关产品，能够看出 Apache APISIX 是其中的佼佼者，引领了 API 网关畛域的翻新。

Apache APISIX 不仅是一个能够解决南北向流量的 API 网关，同时也有 APISIX Ingress Controller、Service Mesh 等开源产品。预计在本月底，APISIX 也将公布 3.0 预览版，带来全新性能与全方位产品晋升，敬请期待！