APISEVEN
和
Kong
EE
的性能评测
--
GigaOm
⾼性能API管理测试
产品评估：API7和Kong企业版
1
-
摘要3
2
-
云上的API
管理5
API76
图1.
API7技术架构7
Kong
企业版7
3
-
GigaOm
API负载测试设置9
API
压⼒测试9
测试环境10
单节点10
环境清单10
软件版本信息11
应⽤程序开发，且能降低计算成本的开销。 更重要的是，许多组织也依赖API和微服务来实现⾼性能和可⽤性。在本⽂中，我们将“⾼性能”定义 为每秒负载超过1000个交易且在整个API环境中最⼤延迟⼩于30毫秒。对公司⽽⾔，对性能的需求和 对管理的需求⼀样，因为公司依靠API交易速率来跟上业务发展速度。
API管理解决⽅案不能成为性能瓶颈。许多公司都在寻找跨多个API端点的负载均衡和⾼交易量吞吐的 解决⽅案 解决⽅案。如果业务每秒有1000个交易，⼀个⽉内就会有30亿次
API
调⽤。拥有⼤流量的公司通常每 ⽉API调⽤次数超过100亿次。因此，在选择API管理解决⽅案时，性能是⼀个关键因素。
在本⽂中，我们展⽰了使⽤2个全⽣命周期API管理平台完成的性能测试结果：API7
和
Kong
企业版 （Kong
EE)。
在我们的单节点设置中，API7所有的压⼒测试结果都优于Kong
EE。在每秒10,000个请求的情况下，

Apache APISIX 微服务⽹网关性能架构解析 --by Yuansheng 王院⽣生 通过写书开始交朋友 《OpenResty 最佳实践》 今年年 3 ⽉月和温铭创办深圳⽀支流科 技，专注微服务的开源技术公司。 Apache APISIX PPMC 成员。 公司刚起步，希望⼤大家⽀支持。 开源，开⼼心 开源，开⼼心 理理想主义者，想活的有理理想 Yuansheng why? ⾏行行业⽼老老⼤大：⼤大多基于 Java + JS，性能差，不不⽀支持⼆二 次开发。⽐比如 Apigee、3Scale、Amazon 等。 ⾏行行业远⻅见者：多基于 OpenResty + Golang，少数开 源，⽐比如：Tyk、Kong 等，代码量量较重。 Apache APISIX 机会：轻巧 + 极致性能 + 热插件 宣布开源 CNCF ⾸首个商业⽤用户 ⽣生产⽤用户上线 核⼼心代码量量，3892 ⾏行行 • 极致的动态转发性能 • 平均请求延迟： 740 us • 插件热加载/卸载 • 允许插件挂载任何阶段 • 路路由⾃自身也是插件 Apache APISIX ⾃自豪 • ⽀支持 ARM64 • 完整⽀支持 IPv6 • 物联⽹网 MQTT 协议 • 基于 OpenResty / Tengine • 极致性能 jsonschema • ASF

API
⽹关
1. ⽤于承载并处理业务流量，管理员在配置路由规则后，⽹关将根据预设规则将请求转发⾄上游服务。 此外，借助
API7
内置的
50
多种插件，可实现⾝份验证、安全防护、流量控制、分析监控、请求/响应 转换等常⻅业务需求；若内置插件⽆法满⾜需求，我们也⽀持使⽤
Lua、Java、Go、Python
语⾔⾃ 定义插件，可作⽤于请求进⼊、上游响应各个阶段。 Manager
API
RESTful
API
接⼝以实现对路由、上游、证书、全局插件、消 费者等资源的管理。 控制⾯板 3. 为了简化⽹关管理，管理员可以通过
Dashboard
控制⾯板以可视化形式操作⽹关，⽀持监控分析、⽇ 志审计、多租⼾管理、多集群切换、多⼯作分区等能⼒。 1.1
技术架构
数据平⾯ 1. 数据平⾯⽤于接收并处理调⽤⽅请求，使⽤
Lua
与
Nginx
动态控制请求流量。当请求进⼊时，将根据 TCD，但也⽀持
Consul、Nacos、Eureka
等， 可根据您的实际情况进⾏选择。此外，企业⽤⼾只需关注业务本⾝，与业务⽆关的⼤部分功能交给
API7
内置插件即可实现，如⾝份验证、性能分析等。
1.2
技术亮点
图
1-2
API7
技术亮点
云原⽣ 1. API7
是⼀个云原⽣⽹关，与平台⽆关，没有供应商锁定的⻛险。它⽀持裸⾦属、虚拟机、 Kubernetes、

04 下一步 CONTENT 网关选型 需求、场景与匹配度 01 安信技术平台演进 O U R B E G I N N I N G S 技术平台室成立 服务化平台建设（脚手架、 链路、监控、配置中心） 容器云建设 DevOps平台建设 2 0 1 9 2 0 2 0 容器云、服务化平台与 Devops推广，覆盖全部自研 系统 O U R B E G I N N I N 安信PaaS平台建设 中间件PaaS建设 DBaaS建设 API网关建设 信创容器云建设 ~ CICD工具链 Docker gRPC框架 为什么选择Apache APISIX 1、高性能 2、可扩展性强，对开发者友好 3、云原生发展规划与安信证券技术路线符合 4、社区活跃 W r i t e h e r e S o m e t h i n g a b o u t APISIX upms IAM skywalking prometheus kafka-logger ... APISIX在安信PaaS平台的应用 1、路由转发 2、认证 3、鉴权 4、链路 5、监控 6、日志 CAS 与 casbin 2、用户状态支持本地存储 3、用户状态支持redis存储 4、casbin 兼容 RBAC with domain 1、认证鉴权功能从业务代码剥离

区 M e e t u p 第 四 期 · ⼴ 州 站 后端架构演变史 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 后端架构演变 -- 7 层处理 • 动态、性能、功能，不可兼得 • 控制⾯能⼒弱 • 技术栈不统⼀ • ⽆标准化⾼可⽤⽅案 • ⼆次开发成本 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 Nginx 和 Kong ⽆统⼀管理控制⾯ 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 Kong 问题 • 架构选型：Nginx + PostgreSQL • 云原⽣ API ⽹关 • 代码臃肿 • 性能⼀般 • 官⽅没 Dashboard 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 NGINX + Kong 的问题 • NGINX -> LB • Kong -> t u p 第 四 期 · ⼴ 州 站 APISIX 当前总结 • 全世界最活跃的 API ⽹关项⽬ • Apache 顶级开源项⽬ • Apache 中国最快毕业项⽬ • 顶级性能，⾼稳定性 • ⽣产可⽤，功能、性能、架构全⾯优于于 Kong 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 https://www.apiseven.com/en/contributor-graph

可观测性  安全防护 服务网格的痛点  方案众多，各有缺陷  与基础设施整合成本高  性能损耗  资源的额外消耗  扩展难度高 理想的服务网格应该是什么样？ 易于扩展 理想的服务网格 业务无感知 落地成本低 动态且增量配置 安全管控 可观测 流量精细化管理 跨集群部署 性能损耗低 资源消耗低 按需下发配置 理想的服务网格 整体使用体验上 • 学习和上手成本低 • 社区开放、活跃度高 社区开放、活跃度高 且快速响应 理想的服务网格 控制面 • 易于上手 • 权限安全管控 • 配置方式被大众接受 理想的服务网格 数据面 • 支持多种协议，甚至是自定义协议 • 性能损耗低 • 资源占用在可控范围 • 启动速度快 • 方便定位问题 • 扩展能力强 APISIX 在 Service Mesh 上的尝试 控制面的抉择 控制面 - 拥抱 Istio  Istio 是当前最为流行的服务网格方案 APISIX  高性能云原生网关  数据面和控制面分离  强大的扩展能力  丰富的生态集成 Apache APISIX的应用案例 https://apisix.apache.org/zh/blog/tags/case-studies/ APISIX Service Mesh Amesh 基于 Apache APISIX 实现 Service Mesh 解决方案 性能提升 • QPS

worker phase background timer SkyWalking client share dict Nginx + Lua http(s) ⼆次优化实践 ⼆次优化实践 - ⾼性能调优利器，⽕焰图 ⼆次优化实践 - 去掉不必要的共享内存交换 rewrite phase bodyfiler phase log phase init worker phase background phase init worker phase background timer client share dict Nginx + Lua http(s) ⼆次优化实践 ➤ Nginx 性能很⾼，⽽⾼性能的代码有时候是不优雅的 ➤ reuse the temporary Lua table object ➤ use `ngx.var.http_****` to fetch specific header value ➤ cached the required object at top level ➤ avoid useless `json.encode` ➤ 只使⽤上⾯部分优化，单核⼼性能已提升 20-30% ，后⾯会有更好表现 ➤ PR：https://github.com/apache/skywalking-nginx-lua/pull/49 为什么要参与开源项⽬

基于 Apache APISIX 破局 在 Luajit 上引入动态 lib 的性能考虑 • C/Rust to Lua的context switch • 参数和结果的类型转换 • jit下无需担心 ASLR / PLT，但也是indirect call 基于 Apache APISIX 破局 性能对比 OpenResty 下，解析config.yaml 1000次 W r i t 解决 Nginx 带来的问题 When Not To • 类型转换开销： • 不要在 rust 中做分配大段内存再同步回 lua 的操作 • 不要在 rust 中通过指针回调 lua • 做好性能测试 解决 Nginx 带来的问题 为什么不考虑... ... • C/C++？ 没有 rust 的内存安全，既然要解决 lua 的人因问题就不要引入另一个。rust 和它们 是 ABI 兼容的，它们能做的能用的 WASM target，Apache APISIX 支持使用 WASM 做 plugin， 但本身不能轻易地使用 WASM 做扩展。另外 WASM 不是免费的，在极端情况下性 能可能只有 native 性能的50%。 感谢聆听 THANKS

代理和协议转换（REST <=> gRPC）、websocket • 身份认证：OpenID Relying Party、OP（Auth0、okta…） • Serverless • 高性能、无状态、随意扩容和缩容 • 支持多云、混合云 • 容器优先，Kubernetes 友好 Apache APISIX 能做什么？ • 处理 L4、L7 层流量：HTTP、HTTPS、TC Service Mesh 不是银弹 • 每个微服务都要带 sidecar • 多次的流量转发，不适合对性能要求高的场景 • 不如 Nginx 稳定 下一代微服务会是怎样？ • 分久必合，抛弃 sidecar • 走向中心节点或者集群的模式 • 也就是下一代网关：全动态、全协议支持、高性能、云原生友好 我希望 Apache APISIX 可以担此重任！ Q&A

代理和协议转换（REST <=> gRPC）、websocket • 身份认证：OpenID Relying Party、OP（Auth0、okta…） • Serverless • 高性能、无状态、随意扩容和缩容 • 支持多云、混合云 • 容器优先，Kubernetes 友好 Apache APISIX 能做什么？ • 处理 L4、L7 层流量：HTTP、HTTPS、TC Service Mesh 不是银弹 • 每个微服务都要带 sidecar • 多次的流量转发，不适合对性能要求高的场景 • 不如 Nginx 稳定 下一代微服务会是怎样？ • 分久必合，抛弃 sidecar • 走向中心节点或者集群的模式 • 也就是下一代网关：全动态、全协议支持、高性能、云原生友好 我希望 Apache APISIX 可以担此重任！ Q&A