Apache APISIX借助ServiceMesh 实现统一技术栈的全流量管理 金卫（API7 解决方案架构师） • 支流科技 - 解决方案架构师 • Apache APISIX PMC • Apache APISIX Ingress Controller Founder • Apache skywalking committer • Github: https://github.com/gxthrj 将通用能力下沉  应用专注于业务逻辑  注册发现  流量管理  可观测性  安全防护 服务网格的痛点  方案众多，各有缺陷  与基础设施整合成本高  性能损耗  资源的额外消耗  扩展难度高 理想的服务网格应该是什么样？ 易于扩展 理想的服务网格 业务无感知 落地成本低 动态且增量配置 安全管控 可观测 流量精细化管理 跨集群部署 性能损耗低 资源消耗低 按需下发配置 是当前最为流行的服务网格方案  社区活跃  几乎所有主流云厂商都对 istio 有支持  基于 istio 做商业支持的公司也很多，比如 tetrate， solo APISIX作为Istio数据面  使用动态库的方式加载到APISIX 与APISIX生命周期一致 转换 xDS 协议  资源消耗可控  APISIX原生支持 增加了xds discovery  配合CRD进行扩展 Apache APISIX

任一请求都会负载到整个的单体服务集群上 在微服务架构上, 对应请求会负载到对应的微服务子服务集群上 微服务的精细管理带来服务的弹性伸缩、开发团队变得敏捷、服务之 间隔离、降低故障率 但是同样的带来的一些问题: 接口之间通用的功能重复开发、膨胀的 服务数量、难以管理 使用API网关模式 使用API网关进行API聚合 使用API网关实现灰度发布 使用API网关实现服务熔断 O(n)，随着路由数量线性增长。 • Apache APISIX 的 IP 匹配时间复杂度是 O(1)，不会随着大量 IP 判断而导致 cpu 资源跑满；kong 的最 新版本也换用了 Apache APISIX 的 IP 匹配库； • Apache APISIX 的路由匹配，接受 nginx 的所有变量作为条件，并且支持自定义函数；其他网关都是 内置的几个条件； • Apache APISIX 使用 etcd 作为配置中心，没有单点，任意宕掉一台机 器，网关集群还能正常运行。其他基于 mysql，postgres 的网关都会有单点 问题 • Apache APISIX 的配置下发只要 1 毫秒就能达到所有网关节点，使用的是 etcd 的 watch；其他网关是 定期轮询数据库，一般需要 5 秒才能获取到最新配置 • 只有 Apache APISIX 开放了自定义负载均衡的挂载点，其他网关都不支持 独创的插件编排/低代码 API 网关 Plugin Orchestration

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
000
rps时的1,000条路由的对⽐14
5
-
结论15
6
-
附录16
7
-
关于GigaOm19
8
-
关于API720
1
-
摘要
本报告重点介绍了部署在云上的API管理平台。云让企业通过微服务快速地构建差异和创新，在⼏分钟 内就能完成API节点的克隆和扩展。与本地部署相⽐，云有良好的扩展性，能更快地进⾏服务器部署和 应⽤程序开发，且能降低计算成本的开销。 更 毫秒。对公司⽽⾔，对性能的需求和 对管理的需求⼀样，因为公司依靠API交易速率来跟上业务发展速度。
API管理解决⽅案不能成为性能瓶颈。许多公司都在寻找跨多个API端点的负载均衡和⾼交易量吞吐的 解决⽅案。如果业务每秒有1000个交易，⼀个⽉内就会有30亿次
API
调⽤。拥有⼤流量的公司通常每 ⽉API调⽤次数超过100亿次。因此，在选择API管理解决⽅案时，性能是⼀个关键因素。

e e t u p 第 四 期 · ⼴ 州 站 Nginx 问题 • 低活跃度的社区 • 社区不友好：提交代码困难 • 静态配置 + reload • 路由太弱 • gRPC 周边弱 • ⽆统⼀管理控制⾯ 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 Kong 问题 • 架构选型：Nginx + PostgreSQL • 云原⽣ API ⽹关 • 代码臃肿 + Kong 的问题 • NGINX -> LB • Kong -> API Gateway • 针对不同应⽤场景 • CP 控制⾯ • NGINX 没有 • Kong + PostgreSQL 数据库是单点 + 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 Apache APISIX 当前总结 云 原 ⽣ 社 区 M e e t u p 第 四 期 ·

⽤于承载并处理业务流量，管理员在配置路由规则后，⽹关将根据预设规则将请求转发⾄上游服务。 此外，借助
API7
内置的
50
多种插件，可实现⾝份验证、安全防护、流量控制、分析监控、请求/响应 转换等常⻅业务需求；若内置插件⽆法满⾜需求，我们也⽀持使⽤
Lua、Java、Go、Python
语⾔⾃ 定义插件，可作⽤于请求进⼊、上游响应各个阶段。 Manager
API
2. ⽤于管理
API
⽹关 ⽤于管理
API
⽹关，通过访问其暴露的
RESTful
API
接⼝以实现对路由、上游、证书、全局插件、消 费者等资源的管理。 控制⾯板 3. 为了简化⽹关管理，管理员可以通过
Dashboard
控制⾯板以可视化形式操作⽹关，⽀持监控分析、⽇ 志审计、多租⼾管理、多集群切换、多⼯作分区等能⼒。 1.1
技术架构
数据平⾯ 1. 数据平⾯⽤于接收并处理调⽤⽅请求，使⽤
Lua
与
Nginx
动态控制请求流量。当请求进⼊时，将根据 控制平⾯包含了
ManagerAPI
与默认配置中⼼
ETCD。管理员在访问并操作控制台时，控制台将调⽤
ManagerAPI
下发配置到
ETCD，借助
ETCD
Watch
机制，配置将在⽹关中实时⽣效。例如：管理员可 增加⼀条路由，并配置限速插件，当触发到限速阈值后，⽹关将会暂时阻⽌后续匹配到该路由的请求 进⼊。借助
ETCD
的
Watch
机制，当管理员在控制⾯板更新配置后，API7
将在毫秒级别内通知到各个

Apache APISIX 技术选型 开发平台：Lua 或 Golang •OpenResty >= 1.15.8 •Tengine >= 2.3.2 •基于 Nginx •调⽤用动态库：C/C++，Golang 等 Apache APISIX 技术选型 数据校验：jsonschema • 数据校验规范：Google 排名第⼀一 • 有多个不不同语⾔言客户端，涵盖了了⼏几乎⽬目前主流的 plugins redirect Apache APISIX 三板斧 • 配置分发借助 etcd ，精简核⼼心 • 基于 radixtree 前缀树路路由 • apisix/core：⾼高性能基础库 • Nginx 变量量提取增强 • 错误⽇日志优化 • table 池优化 Apache APISIX 功能 Apache APISIX 功能 • Cloud-Native • 的 QPS 4 worker：68k 的 QPS 平台：alicloud ecs.ic5.3xlarge vs Q & A • github.com/iresty/apisix • 基础库推荐：apisix/core • QQ 交流群：552030619 • 提供企业⼀一对⼀一服务对接

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 在安信 PaaS 平台的应用 既是使用者，也是管理者 02 front cas casbin eaas appcenter upms IAM skywalking prometheus kafka-logger ... APISIX在安信PaaS平台的应用 with domain 1、认证鉴权功能从业务代码剥离 APISIX helm模板 APISIX 插件模板 APISIX upstream&API 应用模板 应用发布 安信PaaS平台如何管理APISIX 版本、节点数、资源、配置文件 链路、监控、日志、认证、流控 APISIX 告警模板 对接内部告警平台 初始化 upstream 和 API service1 service2 service3 service2/* service3/* DB 中间件 发布 环境选择 （sit、uat、prd） APISIX 初始化 一些思考 03 落地实践、用户反馈 独立集群：提供镜像，用户自主管理；学习成本高；运维成本高 共享集群：降低运维成本；故障风险扩大；用户信息安全 短小、精悍；匹配标准场景 非标准场景适配 worker_processes ingress做网关入口可能产生的问题

插件作为 IoT 网关 • 借助 IdP 插件成为零信任网关 愿景：快速处理所有业务流量 微服务的演进史 1. 从单体到微服务 痛点：大量的重复开发 技术变革：容器 2. 微服务从类库到 proxy • Spring CLoud • Dubbo 痛点：语言绑定、升级难 3. 微服务从 proxy 到 sidecar • 技术变革：云原生 • proxy 的痛点：路由、上游、证书等不能动态

插件作为 IoT 网关 • 借助 IdP 插件成为零信任网关 愿景：快速处理所有业务流量 微服务的演进史 1. 从单体到微服务 痛点：大量的重复开发 技术变革：容器 2. 微服务从类库到 proxy • Spring CLoud • Dubbo 痛点：语言绑定、升级难 3. 微服务从 proxy 到 sidecar • 技术变革：云原生 • proxy 的痛点：路由、上游、证书等不能动态