PaaS 平台的应用 卢勇辉 安信证券网关产品负责人 01 网关选型 02 APISIX 在安信 PaaS 平台的应用 03 一些思考 04 下一步 CONTENT 网关选型 需求、场景与匹配度 01 安信技术平台演进 O U R B E G I N N I N G S 技术平台室成立 服务化平台建设（脚手架、 链路、监控、配置中心） 容器云建设 DevOps平台建设 独立集群：提供镜像，用户自主管理；学习成本高；运维成本高 共享集群：降低运维成本；故障风险扩大；用户信息安全 短小、精悍；匹配标准场景 非标准场景适配 worker_processes ingress做网关入口可能产生的问题 1、独立集群 or 共享集群 2、插件场景匹配 3、云原生环境下的问题 下一步 04 共享集群、API市场、请求数据分析... 资源共享、工作分区隔离 中台系统的

golang  python  java  wasm  ...... 满足多协议的需求 APISIX Service Mesh  上手成本低  开发及扩展相当容易  性能优（尤其是多路由场景）  生态丰富，80+ 插件开箱即用  兼容 xDS，方便迁移  自定义 CRD ，增量推送策略  支持多协议 https://github.com/api7/amesh 下一个版本发布时间 下发 APISIX 全流量代理的价值  节约成本  统一技术栈  统一管理  复用技术经验 未来  结合APISIX xRPC实现  原生异构多协议支持  覆盖Istio各类场景/配置  降低用户迁移成本 Apache APISIX Ingress  一种Kubernetes Ingress controller实现  Kubernetes集群南北向流量网关 

Mesh 想做为基础设施下沉 • Istio + Envoy：控制面和数据面 Service Mesh 不是银弹 • 每个微服务都要带 sidecar • 多次的流量转发，不适合对性能要求高的场景 • 不如 Nginx 稳定 下一代微服务会是怎样？ • 分久必合，抛弃 sidecar • 走向中心节点或者集群的模式 • 也就是下一代网关：全动态、全协议支持、高性能、云原生友好

Mesh 想做为基础设施下沉 • Istio + Envoy：控制面和数据面 Service Mesh 不是银弹 • 每个微服务都要带 sidecar • 多次的流量转发，不适合对性能要求高的场景 • 不如 Nginx 稳定 下一代微服务会是怎样？ • 分久必合，抛弃 sidecar • 走向中心节点或者集群的模式 • 也就是下一代网关：全动态、全协议支持、高性能、云原生友好

所有语⾔言实现。 • 有现成的压测结果供参考供对⽐比 Apache APISIX 技术选型 validator：iresty/jsonschema • 刚需：draft4（可满⾜足 99% 的场景）， draft6 和 draft7 是未来 • 经历：lua-rapidjson -> iresty/jsonschema • 后者⽀支持 draft6/draft7，性能提升5 - 10

云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 NGINX + Kong 的问题 • NGINX -> LB • Kong -> API Gateway • 针对不同应⽤场景 • CP 控制⾯ • NGINX 没有 • Kong + PostgreSQL 数据库是单点 + 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 Apache APISIX

。在 本次测试中，我们没有测试完全托管的云计算产品。 API
管理供应商提供⾃建或完全托管的云部署，少数的供应商同时提供这两种⽅式。虽然有很多平台 可以提供管理
API
的功能，但我们对⾼性能场景更感兴趣。同样，为了本报告的测试⽬标，我们将"⾼ 性能"
定义为每秒负载超过
1000
个交易，并在后端
API
和微服务中的最⼤延迟⼩于
30
毫秒。
本⽂的⽬的是探讨⾼性能要求下的
API
管理产品。

功能摘要介绍
2.1
插件列表
API7
内置50多种常⽤插件，涵盖⾝份验证、安全防护、流量控制、分析监控、请求/响应转换等多个 分类。下表中列出了⼀些流⾏的插件。 分类
名称
作⽤
场景
⾝份验证插件可以有效地保护
Route、Service，以避免⾮法、⽆权限的访问。
authz-keycloak
启⽤该插件后，将⽀持配合
KeyCloak
认证服务完成⾝份鉴 权。