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 G S upstream&API 应用模板 应用发布 安信PaaS平台如何管理APISIX 版本、节点数、资源、配置文件 链路、监控、日志、认证、流控 APISIX 告警模板 对接内部告警平台 初始化 upstream 和 API service1 service2 service3 service1/* service2/* service3/* DB 中间件 发布 环境选择 （sit、uat、prd）

间隔离、降低故障率 但是同样的带来的一些问题: 接口之间通用的功能重复开发、膨胀的 服务数量、难以管理 使用API网关模式 使用API网关进行API聚合 使用API网关实现灰度发布 使用API网关实现服务熔断 与传统API网关的功能 • 让 API 请求更安全、更高效的得到处理 • 覆盖 Nginx 的所有功能：反向代理、负载均衡 • 动态上游、动态 SSL 匹配库； • Apache APISIX 的路由匹配，接受 nginx 的所有变量作为条件，并且支持自定义函数；其他网关都是 内置的几个条件； • Apache APISIX 使用 etcd 作为配置中心，没有单点，任意宕掉一台机 器，网关集群还能正常运行。其他基于 mysql，postgres 的网关都会有单点 问题 • Apache APISIX 的配置下发只要 1 毫秒就能达到所有网关节点，使用的是 区 • 案例：Apache APISIX dashboard 的重构，社区对于 MySQL 的方案不满， “怨声载道”，然后来自 5 家公司的贡献者一起重构掉它 规划 • 2.0 版本（即将发布）：使用 etcd v3 替代 v2 • 3.0 版本：废弃 admin API，分离 DP 和 CP • 2021 年的 flag：Apache APISIX 的贡献者超过 200 位 最后

• 仁慈的独裁者：Python 如何加入 Apache 孵化器 • Champion：项目的引路人，进入孵化器后转为 Mentor 角色 • Mentor：项目的导师，帮助 PPMC 发布 Apache Release，并传授 Apache 文化 • Proposal：关键的文件，可以参考其他项目 • Discuss：邮件列表先讨论，达成共识 • Vote：一般需要投票一周的时间 • 每个微服务都要带 sidecar • 多次的流量转发，不适合对性能要求高的场景 • 不如 Nginx 稳定 下一代微服务会是怎样？ • 分久必合，抛弃 sidecar • 走向中心节点或者集群的模式 • 也就是下一代网关：全动态、全协议支持、高性能、云原生友好 我希望 Apache APISIX 可以担此重任！ Q&A

⽬前匹配路由速度最快的
API
⽹关。它⽀ 持全路径匹配、前缀匹配，也⽀持使⽤
Nginx
内置变量作为匹配条件，以此实现精细化路由。此 外，API7
⽀持流量镜像与⾼级路由匹配功能，可实现灰度发布等精细化路由管理功能。此外，它 也⽀持服务发现与多种注册中⼼，并有能⼒根据请求中
Header、Query、Cookie
等参数进⾏分 流； • 协议转换：API7
⽀持丰富的协议，如
TC ✔
✅
服务降级
✔
✔
✔
✖
✅
API
熔断
✔
✔
✖
✖
✅
超时
✔
✔
✔
✔
✅
流量管理
灰度发布
✔
✔
✖
✔
❌
蓝绿发布
✔
✔
✖
✔
❌
流量镜像
✔
✖
✖
✔
❌
故障注⼊
✔
✖
✖
✖
❌
API
管理
多
API
聚合
避 免请求被篡改、重放。 2.3
灰度发布
路由作为
API
⽹关的核⼼功能，⽤于对经过
API
⽹关的请求进⾏路由匹配，并转发⾄对应的上游服务 中。当上游服务完成处理后，结果将被返回⾄客⼾端。若请求未匹配到路由时，⽹关将返回
404
状态 码，这是由于路由未被发布到⽹关或未配置相关路由。 借助
API7
强⼤的路由功能，也可以实现灰度发布、蓝绿部署的需求，以便企业稳定地进⾏服务平滑升

高性能 • 动态 • 社区活跃 • 云原生架构 • 多语言 • 插件编排 • Loadbalancer • API 网关 • K8s Ingress • 服务网格 全流量 • 多种配置中心 • 智能诊断 易用 全生命周期生态 感谢聆听 THANKS

• 每个微服务都要带 sidecar • 多次的流量转发，不适合对性能要求高的场景 • 不如 Nginx 稳定 下一代微服务会是怎样？ • 分久必合，抛弃 sidecar • 走向中心节点或者集群的模式 • 也就是下一代网关：全动态、全协议支持、高性能、云原生友好 我希望 Apache APISIX 可以担此重任！ Q&A

Kong
的原名是
Mashape，在API
平台发布的时候改名为
Kong。Kong
是在
2015
年开源的，功能丰 富。Kong
利⽤
NGINX
的底层
API
⽹关，并增加了开源插件⽀持、负载平衡和服务发现等功能。Kong
企业版具有扩展的功能，如管理看板、可定制的开发者⻔⼾、安全插件、metrics和
7×24h
的服务⽀ 持。2019年，Kong
发布了⼀个完全托管的云产品，Kong
Cl 业务决策并推动数字化转型。 API7
的底层是APISIX，它是由深圳⽀流科技捐赠给Apache软件基⾦会的。它是新⼀代的云原⽣API⽹ 关，提供丰富的流量管理功能，如负载均衡、动态上游、灰度发布、服务熔断、⾝份验证、可观察性 等。 API7
包括多集群管理、多⼯作分区、权限管理、版本管理、审计、统计报告等企业产品，能够满⾜企 业⽤⼾的核⼼需求。 全球已有数百家企业⽤⼾在使⽤Apac

性能优（尤其是多路由场景）  生态丰富，80+ 插件开箱即用  兼容 xDS，方便迁移  自定义 CRD ，增量推送策略  支持多协议 https://github.com/api7/amesh 下一个版本发布时间 12 月 未来展望 概览  APISIX Ingress处理南北向入口流量  APISIX Service Mesh处理东西向流量  APISIX专用插件配置等通过Amesh 下发