Apache APISIX 技术选型

–>

转自：https://zhuanlan.zhihu.com/p/95243076

Apache APISIX 技术选型

核心思路：技术选型时需要思考到底需要解决什么问题？

• 配置中心：高可用、增量订阅、历史记录
• 语言或开发平台：动态、高性能、网关的周边资源丰富
• 数据校验：开放标准、有一定的生态系统
• 加分项：*路由实现
• 选型捷径：学习竞对，从 Ganter 报告中获取前辈列表，做分析和比较，尝试站在巨人肩膀总是对的

配置中心：etcd why？

APISIX 配置中心并没有选择传统的关系型数据库，而是选用了 etcd，当时主要考虑到以下要素：

• 优雅的集群支持
• 支持历史，可以获取到历史的修改记录
• 要能够支持事务，有些数据的存放是有条件的
• 低于毫秒级别的变化通知

通过分析发现 etcd 非常适合我们，当真正看到官方的 why etcd 的说明列表时（如下图），我们就知道我们选对了。

语言和开发平台：OpenResty

新选型 API 网关开发平台基本只有两条路，一个是Lua，即 OpenResty，另一个就是 Golang。Golang 是静态语言，其动态能力不如 Lua ，所以最后选择 OpenResty。我个人从 2014 年到现在一直沉浸在 OpenResty 社区，对它的理解和把控力也会更好。

我们是全新的项目，所以我们直接基于最新的版本来做，OpenResty >= 1.15.8，Tengine>= 2.3.2，二者都是基于 Nginx，搭配他们任何一个作为运行时都可以运行 APISIX。

我们需要借助更通用的语言来吸纳它的周边生态，这方面 Lua 与 C/C++ 是不在一个量级，常见做法可以通过调用 C/C++ 的动态库来这么做。此外，也可以调用基于 Golang 的库。从这个角度看，我们选择 OpenResty 作为基础平台开展 APISIX 业务开发会很顺畅，不用担心周边库匮乏的问题。而且 OpenResty 这几年被用在 API 网关比较多，有很多现成组件也可以利用，APISIX 可能只需要拿过来做二次整合。当然整合过程中也发现了一些项目的开源版本写得不好，二次优化的事情也没少干。

数据校验：jsonschema

jsonschema 的数据校验规范 Google 排名第一，换而言之，如果有校验规范且已经排名第一，我们没有必要自己造一个，知识一定要可以复用，于是选择了 jsonschema 这个标准。这个校验标准几乎涵盖了 C、Java、JS 等主流语言，而且官方提供现成的压测结果。我们任何选型都会格外关注性能表现，如果有现成的压测框架和结果就非常棒。

当然，在实际操作中经历了一些波折：最开始选型在 jsonschema 官方找实现，结果发现没有适合我们的，他们大多都是开源库中用了一点便声称支持，实际上耦合度比较高。

我们找到的第一个选型是 lua-rapidjson，它并不在 jsonschema 官方的推荐列表里，是腾讯开源的。但 rapidjson 有一个比较大的问题是编译条件高，它是一个 C/C++ 的实现，而我们做的是开源的项目，简单易用是我们追求的。此外 rapidjson 只支持了 draft4 里 95% 的内容，有些特性也不支持，比如经常用到的 default 。

于是我们根据一个开源的方案进行改造，实现了新的 iresty / jsonschema，主要增加了下面一些点：

• 运行时支持 OpenResty
• 完整支持 draft4
• 完整支持 draft6、draft 7

这个库采用了编译器的思维方式。我们对其进行了测试：一个简单的对象里面有两个字段，分别是字符串和一个 int 类型，反复进行循环压力测试，跑一百万次，将跑完的时间做比较。iresty / jsonschema 的性能是 lua-rapidjson 的 5-10倍，是 gojsonschema(golang) 性能的 500-1000 倍。

路由：为什么造了 resty-radixtree 路由？

路由是 API 网关的生命，没有高性能的路由，就没有快速的匹配过程，API 网关的性能无法提升。只有路由是 100% 每次参与用户请求的，配置中心和参数校验也不是，因此路由必须要高性能。同时路由匹配条件也要足够灵活和强大，除了要支持最基本的 uri、host，其他可选的如 IP 地址、请求参数、请求头、Cookie 等也需要。

原本以为做到这一步就可以了，但开源项目的用户还是会有其他的需求，最后我添加了自定义函数，用户可以写 Lua 脚本，这也再次使用了 Lua 的动态特性。换而言之，用户完全可以创建判断规则，涉及特别不好表达或还未支持的逻辑，都可以用自定义函数方式先绕着走。

集大成者的路由 resty-radixtree，目前单核心每秒可以达到百万次的匹配，相比之前的选型 libr3，radixtree 的性能至少提升了一个数量级。并且它允许引用任意的 nginx 的内置变量，索引的*创建也让它轻松支持 uri 或 host+uri 的使用场景。

自此三个选型确定：路由 resty-radixtree，校验器 iresty / jsonschema，配置中心 etcd，Apache APISIX 雏形诞生。

Apache APISIX 架构

如上图，这是 Apache APISIX 目前的业务架构：左侧是管理员，右侧是用户请求。管理员把信息录入放到 etcd 里面缓存后，用户访问 APISIX 做路由，根据路由信息得到结果，匹配到路由交给具体的微服务、serverless 等。

如上图，APISIX 软件层面基本架构并没有采用传统的层层嵌套的方式，只有基础层和业务层，基础层完全脱离于 APISIX 内核，完全无业务绑定，大家可以在任何 OpenResty 项目中引用。

插件可以热插拔，不用重启服务。并且已经内置了常见的限流限速、身份认证、请求改写、URI 重定向、opentracing、serverless 等插件，开箱即用。APISIX 对插件的支持和友商不太一样，具体表现在以下几点：

• 按需“继承”
• 优先级排序
• 允许挂载 Nginx 所有阶段
• 插件热加载、卸载
• 插件临时禁⽤

总结 Apache APISIX 三板斧如下：

• 配置分发借助 etcd ，精简核心
• 基于 resty-radixtree 的高性能前缀匹配
• 高性能基础库apisix/core：Nginx 变量提取增强 ；错误日志优化；table 池优化

Apache APISIX 性能测试

Apache APISIX 目前已经具备 30 多个功能，已经基本超过大多开源竞品。通常来说，引入了前面提到的几十项功能，会伴随着性能的下降，那么究竟下降了多少呢？这里我做了一个性能的测试对比。

如上图，右侧是我为了测试写的一个虚假的服务，这个服务是空的，只是把 ngx_lua 里的一些变量拿出来，传给了什么都不做的 fake_fetch，后面的 http filter、log 阶段等一样，没有任何计算量。

随后对 APISIX 和右边的虚假服务分别跑压力测定，对比结果发现 APISIX 的性能仅仅下降了 15%，也就是说在接受了 15% 的性能下降的同时，就可以享受前面提到的所有功能。我们在阿里云的计算平台，单核下可以跑到 23-24k QPS，4 核可以跑到 68k 的 QPS。

欢迎大家通过 github 检索 APISIX 了解更多，同时我们也对外提供一对一的企业服务，欢迎感兴趣的同学和我们联系。

本文来源 互联网收集，文章内容系作者个人观点，不代表 本站 对观点赞同或支持。如需转载，请注明文章来源,如您发现有涉嫌抄袭侵权的内容，请联系本站核实处理。