由、上游、证书、全局插件、消 费者等资源的管理。 控制⾯板 3. 为了简化⽹关管理，管理员可以通过
Dashboard
控制⾯板以可视化形式操作⽹关，⽀持监控分析、⽇ 志审计、多租⼾管理、多集群切换、多⼯作分区等能⼒。 1.1
技术架构
数据平⾯ 1. 数据平⾯⽤于接收并处理调⽤⽅请求，使⽤
Lua
与
Nginx
动态控制请求流量。当请求进⼊时，将根据 预设路由规则进⾏匹配，匹 ⽤⼾与⻆⾊绑定，可实现针对某类⽤⼾细粒度的权限管控； • 多租⼾（多⼯作分区）：⽀持基于⼯作分区隔离的多租⼾模型，管理员可创建不同的⼯作分区，并 指定哪些⽤⼾对⼯作分区有哪些资源的访问权限； • 多环境：⽀持多
ETCD
集群，集群之间数据不共享；
• ⾝份验证：包含多种认证类插件，如
basic-auth、jwt-auth、key-auth、wolf-rbac
等。此外，借 助内置的
HMAC
插件，可使⽤
AK/S 服务路由：API7
基于
Radixtree
实现⾼效的路由匹配，是⽬前匹配路由速度最快的
API
⽹关。它⽀ 持全路径匹配、前缀匹配，也⽀持使⽤
Nginx
内置变量作为匹配条件，以此实现精细化路由。此 外，API7
⽀持流量镜像与⾼级路由匹配功能，可实现灰度发布等精细化路由管理功能。此外，它 也⽀持服务发现与多种注册中⼼，并有能⼒根据请求中
Header、Query、Cookie
等参数进⾏分 流； • 协议转换：

一些思考 03 落地实践、用户反馈 独立集群：提供镜像，用户自主管理；学习成本高；运维成本高 共享集群：降低运维成本；故障风险扩大；用户信息安全 短小、精悍；匹配标准场景 非标准场景适配 worker_processes ingress做网关入口可能产生的问题 1、独立集群 or 共享集群 2、插件场景匹配 3、云原生环境下的问题 下一步 04 共享集群、API市场、请求数据分析... 资源共享、工作分区隔离 资源共享、工作分区隔离 中台系统的公共接口，比如日志平台、监控平台、告警平台等的对外接口 接口权限统一管理、流量控制 调用量、异常响应、延迟 Top N... 1、共享集群建设 2、API 市场 3、请求数据分析 4、APISIX-Ingress、APISIX+Istio 感谢聆听 THANKS

pache
APISIX
来处理传统的南北流量，以及服务之间的东 西向流量。它也可以作为⼀个
k8s
ingress
controller。
API7
是
APISIX
的企业版，其功能包括多集群管理、多分区、权限管理、版本管理、审计、统计报告 等，满⾜企业⽤⼾的核⼼需求。 以下是API7基于Apache
APISIX的技术架构（图1）。
图1.
API7技术架构
API7是混合 loudFormation
选项。
Kong
可以作为⼀个单节点运⾏，也可以作为多节点集群。在集群中，负载均衡器（如开源的
NGINX）被⽤在边缘节点为客⼾端提供单个地址，并使⽤选定的策略（例如循环或加权）在
Kong
节 点之间分发请求。横向扩展
Kong
很简单。Kong
是⽆状态的，所以向集群添加新节点需要将新节点指 向外部数据库（PostgreSQL
或
Cassandra）， 3
-
GigaOm
API负载测试设置
API
压⼒测试
GigaOm
API
Workload
Field
Test
是⼀个简单的压⼒测试，⽤⼀连串相同的
GET
请求
API
或
API
管理 节点（或管理节点集群前的负载均衡器），每秒的请求数不变。 为了进⾏压⼒测试，我们使⽤了
HTTP
压⼒测试⼯具
WRK21，这是
Github
上⼀个免费的压⼒测试套 件。
WRK2
⼯具返回每个测试的延迟分布和状

微服务和 API 网关的演进 从2014-2015年, 谷歌搜索引擎上"微服务"关键字的搜索趋势直线上 升 在单体架构上, 任一请求都会负载到整个的单体服务集群上 在微服务架构上, 对应请求会负载到对应的微服务子服务集群上 微服务的精细管理带来服务的弹性伸缩、开发团队变得敏捷、服务之 间隔离、降低故障率 但是同样的带来的一些问题: 接口之间通用的功能重复开发、膨胀的 服务数量、难以管理 的路由匹配，接受 nginx 的所有变量作为条件，并且支持自定义函数；其他网关都是 内置的几个条件； • Apache APISIX 使用 etcd 作为配置中心，没有单点，任意宕掉一台机 器，网关集群还能正常运行。其他基于 mysql，postgres 的网关都会有单点 问题 • Apache APISIX 的配置下发只要 1 毫秒就能达到所有网关节点，使用的是 etcd 的 watch；其他网关是

与基础设施整合成本高  性能损耗  资源的额外消耗  扩展难度高 理想的服务网格应该是什么样？ 易于扩展 理想的服务网格 业务无感知 落地成本低 动态且增量配置 安全管控 可观测 流量精细化管理 跨集群部署 性能损耗低 资源消耗低 按需下发配置 理想的服务网格 整体使用体验上 • 学习和上手成本低 • 社区开放、活跃度高 且快速响应 理想的服务网格 控制面 • 易于上手 • 权限安全管控 • 覆盖Istio各类场景/配置  降低用户迁移成本 Apache APISIX Ingress  一种Kubernetes Ingress controller实现  Kubernetes集群南北向流量网关  控制面和数据面分离 https://github.com/apache/apisix-ingress-controller 总结 服务网格是未来 正在螺旋上升的状态 APISIX

Gateway Admin APISIX Admin APISIX Gateway All In One 节点⽆无状态特性 • ⾼高可⽤用 • 弹性伸缩 • 分布式 • 集群 • 故障⾃自动转移 API ⽹网关基本架构 admin API router ??? plugins administrator client upstream Configuration 数据校验：开放标准、有⼀一定的⽣生态系统 • 学习竞对：从 Ganter 报告中获取前辈列列表，做分 析、⽐比较 Apache APISIX 技术选型 配置中⼼心 why etcd? • 集群⽀支持 • 历史+事务 • 低于毫秒的变化通知 Apache APISIX 技术选型 开发平台：Lua 或 Golang •OpenResty >= 1.15.8 •Tengine

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

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

Gateway (1) • 基于 Nginx，⽀持 Nginx -> APISIX 灰度迁移 • 全动态，⽆需 reload • HTTP(S) 精细化路由 • 内置 40+ 插件，功能强⼤ • ⾃带集群⽅案和控制⾯ 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 LB / API Gateway (2) • 基⾦会项⽬，不⽤担⼼被商业公司锁定 • 全世界最活跃的 API