2019 年 10 月 27 日,又拍云联合 Apache APISIX 社区举办 API 网关与高性能服务最佳实践丨Open Talk 杭州站活动,Apache APISIX PPMC 成员王院生做了题为《 Apache APISIX 微服务网关极致性能架构解析》的分享。本次活动,邀请了来自阿里巴巴、蚂蚁金服、Apache APISIX、PolarisTech、又拍云等企业的技术专家,分享网关和高性能服务的实战经验。

image.png

王院生,深圳支流科技创始人,Apache APISIX PPMC 成员,OpenResty 社区发起人,《 OpenResty 最佳实践》作者。

 

以下是分享全文:

前言

大家好,我是来自深圳支流科技的王院生。今年 3 月份,我和志同道合的伙伴一起创业,发起了 APISIX 项目,目前这个项目已进入 Apache 孵化器。Apache APISIX 是一个高性能、可扩展的微服务 API 网关。它是基于 Nginx 和 etcd 来实现,和传统 API 网关相比,APISIX 具备动态路由、插件热加载、gRPC 协议转换等功能,特别适合微服务体系下的 API 管理。

image.png

Apache APISIX 是一个蓬勃发展的开源项目,在 2019 年 6 月 6 号开源后,很快就获得了开发者的关注和兴趣,并在开源一个月后被收录到 CNCF(云原生软件基金会) 的全景图中。现在 Apache APISIX 在 GitHub 有 1500 多个 star,近40 多名贡献者,是一个聚集了 800 多人的开发者社区。从开源之初,APISIX 保持每个月发布一个版本,并坚持测试驱动开发、自动化 CI/CD 等理念,以保证代码的质量和稳定性。

Apache APISIX 微服务网关

微服务 API 网关

API 网关并非一个新兴的概念,在十几年前就已经存在了,它的作用主要是作为流量的入口,统一处理和业务相关的请求,让 API 更加安全、快速和准确的得到处理,它有以下传统功能:

  • 反向代理和负载均衡,这和 Nginx 的定位和功能是一致的;

  • 动态上游、动态 SSL 证书和动态限流限速等运行时的动态功能,这是开源版本 Nginx 并不具备的功能;

  • 上游的主动和被动健康检查,以及服务熔断;

  • 在 API 网关的基础之上进行扩展,成为全生命周期的 API 管理平台。

最近几年,业务相关的流量不再仅仅是由 PC 客户端和浏览器发起,更多的来自手机、IoT 设备等,未来随着 5G 的普及,这些流量会越来越多。同时,随着微服务架构的结构变迁,服务之间的流量也开始爆发性的增长。在这种新的业务场景下,对 API 网关有了更多新需求:

  • 云原生友好,架构要轻巧,便于容器化;

  • 对接 Prometheus、Zipkin、Skywalking 等监控组件;

  • 支持 gRPC、Dubbo、websocket、MQTT 等协议的代理,以及 http 到 gRPC 之间的协议转换,以便适应更广泛的场景;

  • 做身份验证,与 Auth0、okta 等身份认证提供商的服务对接,把流量的安全作为头等大事;

  • 通过运行时动态执行用户函数的方式来实现 serverless,让网关的边缘节点更加灵活;

  • 支持插件的热加载,新增、删除和修改插件,都不用重启服务;

  • 开源不锁定用户,支持混合云的部署架构;

  • 最后是网关节点自身要无状态,可以随意的扩容和缩容。

image.png

有了这些功能,微服务只需关心业务本身,而与业务相关的周边管理功能,比如服务发现、服务熔断、身份认证、限流限速、统计、性能分析等,均可以在独立的网关层面解决。从这个角度来看,API 网关既可以替代 Nginx 的所有功能处理南北向的流量,也可以胜任 Istio 控制面和 Envoy 数据面的角色,处理东西向的流量。

目前已经有很多可选的网关产品,为什么我们还要进入这个行业进行摸索?我们对现有的产品进行了分析:

  • ⾏业老大:大多基于 Java + JS,闭源性能差,不支持⼆次开发

行业老大们的技术方案大多基于 Java + JS 无一例外,因为他们都是十几年前起步,倒退到那个年代能选的方案也只有 Java 。如果阿里是现在才起步的,我相信他也会有不同的技术选择,但是在那个年代做大应用,只有 Java 可选。如果要做动态,基本也就只有 JS 这条路,最后的组合均为 JAVA + JS 技术方案。它的问题也比较明显:性能差,体态臃肿,二次开发较困难。

  • 行业远见者:多基于 OpenResty 或 Golang,少数开源

在 Ganter 中远见者行列采用的技术方案目前多是基于 OpenResty 和 Golang,能够看到这些行业远见者在具体实现上,整体都比较重。代码量重往往代表结构复杂,最后也发现他们确实效率不高。

  • Apache APISIX 机会:轻巧 + 极致性能 + 热插件

在起步之初,我们意识到必须要比远见者还要好十倍以上,我们才有成功的可能。此时我们看清了要走的一条路:第一要轻巧,第二需要性能极致。最后如果再有丰富的插件生态,就更完美了。

Apache APISIX 发展历程

image.png

4 月初,我们开始第一行代码,我们选择在 6 月 6 日开源,因为产品名叫 APISIX,我们希望它容易被大家记住。

7 月,APISIX 进入 CNCF 全景图,这是目前最火的软件基金会。

8 月,我们拥有了第一家商业用户,搞定商业用户的过程确实非常爽,借助 APISIX 内核前两周,就帮用户把 QPS 提升了一倍。

9 月,开源用户贝壳找房正式上线,现在每天至少有 1 亿的流量需要处理(截止目前已经有 2.5 亿日流量),它的 CPU 大约 1% 左右。

9 月我们也开始和 Apache 接触,着手准备捐赠,10 月就真正成功了。这应该是国内第一家由初创公司捐赠的 Apache 项目。通常一个项目要进入 Apache 基本都是以年为单位,但我们只用了一个月。

10 月,我们在继续奔跑,已实现了全平台支持。除了常见的操作系统,两大主流 X86 架构和 ARM64 架构也均全部支持,并经过完整用例回归。APISIX 是一个测试驱动的项目,测试覆盖率到 80% 以上,只要测试用例能完整运行,可以确保在生产中正常使用。

Apache APISIX 的优势

以下是 Apache APISIX 引以为傲的点,它们大多是是竞品完全没有的:

  • ASF 第一个 API ⽹关类项⽬

  • 极简核⼼代码量,不到  4000 ⾏,去除空行、注释行数甚至不到 3000 行

  • 极致的动态转发性能,测试报告显示属于 NO.1

  • 最低的平均请求延迟:740 us

  • 插件热加载/卸载,新旧插件均可,同类竞品中独一无二

  • 允许插件挂载 Nginx 任何阶段

  • 所有的组件都是插件,包括路由自身,这在业内是独一份的,把自由交给用户

  • 完整支持 ARM64

  • 完整支持 IPv6

  • 动态转发物联⽹ MQTT 协议

  • 运行时可以是 OpenResty / Tengine ,自由选择

  • 极致性能校验器 iresty / jsonschema ,已知 jsonschema 校验器实现方案中性能最高


Apache APISIX 技术选型

API 网关产品形态演化

image.png

如上图所示,图 ① 为网关最初的产品形态,左侧是客户端,右侧是服务,网关在他们中间;由于服务会做聚集分类,如图 ② 中服务分成两类,此时 API 网关的重要性就体现出来,它需要对外做无感知,需要根据用户请求的流量信息做分发,此时 API 网关就会成为单点故障;由此演化出图 ③ 的形态,有两个 API 网关,它们都可以访问后面的任何一个服务集群,互为备份,是一个高可用的基本形态,客户端可以请求任意一个网关;在图 ④ 中,API Gateway 负责流量转发,etcd 负责配置存储,API Gateway 是管理人员的控制台,所以如果只有 API Gateway 高可用是远远不够的。

image.png

真正能够让用户安心的方案应该是 API Gateway、配置中心、控制中心都能够完整支持高可用,作为一个微服务 API 网关需要部署灵活,API Gateway、etcd、管理控制台均需要满足任意数量伸缩,需要多少就部署多少。

这对我们的开源版本提出了一个非常高的挑战,安装形态到底应该什么样子?

image.png

我们需要有上图中的三种形态都允许用户去部署:Admin、Gateway、Gateway+Admin。我们的解决方案首先是 All In One,即只有一个 “Gateway+Admin” 的包,当用户需要将 Gateway 和 Admin 分别部署时,只需修改配置,是否启用 Admin 就可以实现。

我们通过配置的方式简单区分节点类型,而任何一个节点里面,既可以单独包含一部分,如 Admin 或者 Gateway,也可以同时包含二者,这种方式让用户能够很容易地解决一堆问题,实现高可用、弹性伸缩、分布式、集群以及故障自动转移。

API 网关基本架构

下面介绍 API 网关的基本架构,这里简单对它做了拆分:

image.png

整个流程是管理员通过 admin API 告诉网关需要做什么并保存下来,这也就是我们常说的控制面。相对的是数据面部分处理外部用户真实请求,要根据管理员的规则,对当前请求根据路由匹配得到配置,然后执行配置中的插件并转发到指定上游。

这里涉及三个最基本问题

  • 路由:匹配用户请求,需要功能强大,并且性能足够好

  • 校验器:校验用户请求数据是否合法,需要通用、高性能

  • 配置中心:存储配置,高可用易用,支持增量订阅

如果这三个基本问题回答好,那么这个网关质量也就基本确定了。

Apache APISIX 技术选型

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

  • 配置中心:高可用、增量订阅、历史记录

  • 语言或开发平台:动态、高性能、网关的周边资源丰富

  • 数据校验:开放标准、有一定的生态系统

  • 加分项:顶级路由实现

  • 选型捷径:学习竞对,从 Ganter 报告中获取前辈列表,做分析和比较,尝试站在巨人肩膀总是对的

配置中心:etcd why?

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

  • 优雅的集群支持

  • 支持历史,可以获取到历史的修改记录

  • 要能够支持事务,有些数据的存放是有条件的

  • 低于毫秒级别的变化通知

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

image.png

语言和开发平台: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 架构

image.png

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

image.png

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

image.png

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

  • 按需“继承”

  • 优先级排序

  • 允许挂载 Nginx 所有阶段

  • 插件热加载、卸载

  • 插件临时禁⽤

总结 Apache APISIX 三板斧如下:

  • 配置分发借助 etcd ,精简核心 

  • 基于 resty-radixtree 的高性能前缀匹配

  • 高性能基础库apisix/core:Nginx 变量提取增强 ;错误日志优化;table 池优化

 

Apache APISIX 性能测试

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

image.png

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

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

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

 

今天的分享就到这里,谢谢大家!