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

7
-
关于GigaOm19
8
-
关于API720
1
-
摘要
本报告重点介绍了部署在云上的API管理平台。云让企业通过微服务快速地构建差异和创新，在⼏分钟 内就能完成API节点的克隆和扩展。与本地部署相⽐，云有良好的扩展性，能更快地进⾏服务器部署和 应⽤程序开发，且能降低计算成本的开销。 更重要的是，许多组织也依赖API和微服务来实现⾼性能和可⽤性。在本⽂中，我们将“⾼性能”定义 为每秒负载超 由于
API
的激增，公司需要管理内外部所依赖的众多服务。API在协议、⽅法、授权/认证和使⽤⽅⾯ 差异很⼤。此外，IT部⻔需要对
API
进⾏精细化控制，限制速率、调⽤次数，制定策略和⽤⼾⾝份识 别来确保⾼可⽤性，防⽌滥⽤和安全漏洞。公开
API
为许多合作伙伴打开了⼤⻔，他们可以在不了解 底层技术的情况下共同创建和扩展核⼼平台。 根据企业需求和底层架构，云上管理
API
有很⼤差异。 布的时候改名为
Kong。Kong
是在
2015
年开源的，功能丰 富。Kong
利⽤
NGINX
的底层
API
⽹关，并增加了开源插件⽀持、负载平衡和服务发现等功能。Kong
企业版具有扩展的功能，如管理看板、可定制的开发者⻔⼾、安全插件、metrics和
7×24h
的服务⽀ 持。2019年，Kong
发布了⼀个完全托管的云产品，Kong
Cloud。我们没有测试
Kong
Cloud。

⼼，ETCD
天然⽀持分布式、⾼可⽤，并且在
K8s
等领域有⼤量实践 经验，使得
API7
可以轻松⽀持毫秒级配置更新、⽀撑数千⽹关节点；⽹关节点⽆状态，可任意扩容或 缩容； 协议转换 3. ⽀持丰富的协议类型，如
TCP/UDP、Dubbo、MQTT、gRPC、SOAP、WebSocket
等；
安全防护 4. 内置多种⾝份验证与安全防护能⼒，如
Basic
Auth、JSON
WS
8
核⼼服务器中，QPS
约为
140K，延迟约 为
0.2
ms；
全动态能⼒ 6. 修改⽹关配置、增加或修改插件等，⽆需重启⽹关服务即可实时⽣效；⽀持动态加载
SSL
证书；
扩展能⼒强 7. 借助灵活的插件机制，可针对内部业务完成功能定制；⽀持⾃定义负载均衡算法与路由算法，不受限 于
API
⽹关实现；通过运⾏时动态执⾏⽤⼾⾃定义函数⽅式来实现
Serverless，使⽹关边缘节点更加 请求中
Header、Query、Cookie
等参数进⾏分 流； • 协议转换：API7
⽀持丰富的协议，如
TCP/UDP、Dubbo、MQTT、gRPC、WebSocket
等，并能 够实现
HTTP
协议到后端服务其它协议的转换。API
⽹关对外暴露统⼀
HTTP
⼊⼝，管理员可通过 控制台界⾯完成协议转换设置，⽀持请求与后端服务的参数映射； • 服务治理：API7
⽀持熔断

插件热加载/卸载 • 允许插件挂载任何阶段 • 路路由⾃自身也是插件 Apache APISIX ⾃自豪 • ⽀支持 ARM64 • 完整⽀支持 IPv6 • 物联⽹网 MQTT 协议 • 基于 OpenResty / Tengine • 极致性能 jsonschema • ASF 第⼀一个 API ⽹网关项⽬目 微服务 API ⽹网关部署 client API Gateway draft6/draft7，性能提升5 - 10 倍 • 是 xeipuuv/gojsonschema 性能的 1000 倍 Apache APISIX 技术选型 • 必须⾼高性能 • 匹配条件灵活且易易扩展 • 必需：uri、host • 可选：IP 地址、请求参数、请求头、 Cookie等，可以做数值、字符串串以及正则 匹配。 • ⾃自定义函数 路路由是 API ⽹网关的⽣生命 Apache

站 APISIX 当前总结 • 多语⾔⽀持：⽐如 Java、Golang 等 • ⾼质量周边⽣态：resty-radixtree, jsonschema, ipmatcher 等 • 完备 7 层协议⽀持 • ⽣产⽤户使⽤量：⼏千节点的部署量，最⼤单⽤户⽇请求量80~100亿（7 台服务器，⽇常 CPU 占⽤率 8~10%） • 更多：https://apisix.apache.org 云 GA 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 服务⽹格 • Apache APISIX Mesh + Istio = Service Mesh • ⽀持 xDS 协议，APISIX vs Envoy • 状态：Q2 季度开源 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 APISIX Mesh • APISIX Mesh + Spring Cloud、Dubbo 等微服务框架良好集成 • APISIX Mesh：Q2 季度开源 • ⽀持更多配置中⼼：redis、nacos、PostgreSQL、MySQL 等 • ⾃定义 RPC 协议：⽀持多路复⽤，Q3-4 季度开源 APISIX 初步计划 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 APISIX：全流量数据⾯ • LB: APISIX • 南北

• 动态上游、动态 SSL 证书、动态限流限速 • 主动/被动健康检查、服务熔断 云原生下的新功能 • 对接 Prometheus、Zipkin、Skywalking • gRPC 代理和协议转换（REST <=> gRPC）、websocket • 身份认证：OpenID Relying Party、OP（Auth0、okta…） • Serverless • 高性能、无状态、随意扩容和缩容 多次的流量转发，不适合对性能要求高的场景 • 不如 Nginx 稳定 下一代微服务会是怎样？ • 分久必合，抛弃 sidecar • 走向中心节点或者集群的模式 • 也就是下一代网关：全动态、全协议支持、高性能、云原生友好 我希望 Apache APISIX 可以担此重任！ Q&A

• 动态上游、动态 SSL 证书、动态限流限速 • 主动/被动健康检查、服务熔断 云原生下的新功能 • 对接 Prometheus、Zipkin、Skywalking • gRPC 代理和协议转换（REST <=> gRPC）、websocket • 身份认证：OpenID Relying Party、OP（Auth0、okta…） • Serverless • 高性能、无状态、随意扩容和缩容 多次的流量转发，不适合对性能要求高的场景 • 不如 Nginx 稳定 下一代微服务会是怎样？ • 分久必合，抛弃 sidecar • 走向中心节点或者集群的模式 • 也就是下一代网关：全动态、全协议支持、高性能、云原生友好 我希望 Apache APISIX 可以担此重任！ Q&A

动态上游、动态 SSL 证书、动态限流限速 • 主动/被动健康检查、服务熔断 不同的云原生下的新功能 • 对接 Prometheus、Zipkin、Skywalking • gRPC 代理和协议转换（REST <=> gRPC） • 身份认证：OpenID Relying Party、OP（Auth0、okta…） • 高性能、无状态、随意扩容和缩容 • 动态配置，不用 reload 服务

安信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 在安信

rust 也可以。 • WASM/WASI？ rust 能够轻松地构建 WASM target，Apache APISIX 支持使用 WASM 做 plugin， 但本身不能轻易地使用 WASM 做扩展。另外 WASM 不是免费的，在极端情况下性 能可能只有 native 性能的50%。 感谢聆听 THANKS