Higress 推出 Serverless 企业版，对比开源成本降低 90%，认证性能提升 30 倍

当网关遭遇“增长困境”：一个典型的技术债案例

去年年底，某 SaaS 平台的基础架构负责人老周发现事情不太对。他们的开放平台半年内从 200 多个 API 消费者涨到了将近 2 万，企业客户、ISV 合作伙伴、内部 Agent 应用都在排队接入。网关还是那套自建 Higress，但认证延迟曲线已经从平线变成陡坡：p50 从 1 ms 飙到 50 ms 以上，部分时段成功率跌破 80%；每次批量新增消费者，控制面下发的插件配置就膨胀一截，到后来单次配置逼近 1.2 MB，数据面同步延迟肉眼可见地变长。

老周碰到的这个问题，其实不是孤例。随着 API 数量、合作伙伴和终端应用持续增长，网关需要管理的消费者数量也会从几十、几百快速扩展到数万；进入 Agent 时代后，甚至可能进一步走向百万级。此时，认证能力面对的已不再只是“能否识别一个 API Key”，而是一个更现实的问题：

这篇文章通过一组本地对照实测，来看看开源自建 Higress 与阿里云云原生 API 网关（即 Higress 企业版）在大规模消费者场景下的真实差距。

先看结果：规模越大，性能差距越明显

在相同运行环境、上游服务和请求模型下，开源实现与企业版的差距集中体现在三组数据上：

• 延迟相差约 34 倍
  ：10000 个消费者下，企业版 p50 为

  1.47 ms
  ，开源实现为

  50.32 ms
  ；

• 成功率相差 22.86 个百分点
  ：20000 个消费者下，企业版保持

  100%
  ，开源实现下降至

  77.14%
  ；

• 配置体积相差 8457 倍
  ：20000 个消费者下，企业版为

  149 B
  ，开源实现达到

  1260089 B（约 1.23 MB）
  ，当消费者规模持续上升，多租网关中控制面到数据面到配置下发链路能够保持稳定，而开源实现会成为瓶颈。

这三组数据分别对应生产环境最关心的三个问题：请求是否足够快、流量是否足够稳，以及消费者持续增长时配置成本是否仍然可控。下面逐个展开。

为什么消费者增长会拉开性能差距？

从实测结果看，开源实现适合消费者规模较小的场景；随着消费者数量增长，其认证延迟和配置规模会明显增加。

企业版针对大规模消费者场景进行了专项优化。无论消费者从 100 增长到 10000，还是进一步增长到更大规模，单次认证都不需要承担与消费者总量等比例增长的处理成本。

这种设计把消费者规模从认证执行路径中解耦出来：

• 单次认证开销不会随消费者总量等比例增长；
• 消费者数据与认证执行配置分离，配置规模保持稳定；
• 新增消费者不会线性放大每次请求的认证成本；
• 可结合企业版产品规格和实例资源，承载十万级乃至百万级消费者。

这一差异直接反映在消费者规模增长后的性能、成功率和配置成本上。

延迟与成功率：两万消费者下仍保持稳定

对开源实现与企业版的 key-auth 认证场景进行了本地对照测试。两条链路使用相同的运行环境、上游服务和请求模型，并始终使用最后一个消费者的有效 API Key，以观察消费者规模增长时的性能变化。

测试覆盖 10、100、500、1000、5000、10000 和 20000 个消费者，固定目标 QPS 为 10，每组持续 20 秒。

结果相当直观：企业版在消费者数量从 10 增长到 20000 的过程中，p50 始终保持在约 1 ms 量级；在 20000 个消费者下，210 次请求全部成功。

开源实现的延迟则随消费者数量明显增长：10000 个消费者时，p50 已达到 50.32 ms，约为企业版的 34 倍；扩展到 20000 个消费者后，成功率下降到 77.14%，并进入秒级延迟区间。

对于生产网关而言，低延迟只是结果的一部分。更重要的是，当消费者规模继续扩大时，认证链路仍然具备可预期的性能曲线和稳定的请求成功率，避免业务增长反过来成为网关稳定性的风险。

开源控制面的隐性配置成本：随消费者列表膨胀

开源实现的控制面配置体积会随消费者数量增长。本次测试中，其配置体积从 10 个消费者时的 719 B，增长到 2 万个消费者时约 1.23 MB。这部分配置持续膨胀会导致下发链路瓶颈，例如遇到 K8s 对单个资源的 size 限制。而且这份配置在控制面实例化后，实际占用的资源也会变高，对控制面的资源开销带来很高的隐性成本。下图是压测到 1 万个消费者时开源控制面的 CPU 水平开销：

对于企业版 Higress 的实现，新增消费者不会再等同于持续放大插件配置。对于消费者频繁创建、轮换凭证或批量变更的企业，这有助于降低大配置解析、分发和更新带来的数据面压力，使消费者管理更适合长期增长。

话说回来，这种优化的价值并不止于万级消费者。开源实现的认证成本和配置体积会随消费者规模继续增长；企业版则让单次认证开销和执行配置不再与消费者总量等比例增长，因此能够支持十万级乃至百万级消费者管理。

从自建 Higress 迁移，获得的不只是性能

企业版认证能力解决的是消费者规模增长后的核心性能问题，而企业版产品进一步把这项能力放在完整的托管体系中交付。

对自建 Higress 用户而言，迁移到阿里云云原生 API 网关可以同时获得：

• 面向百万级消费者优化的认证能力
  ：认证开销和执行配置不再随消费者总量等比例增长，更适合大规模生产场景。

• 产品化的消费者治理
  ：提供消费者启停、描述与独立 ID、消费者组、批量分组、独立密钥资源以及面向 API/路由的显式授权关系。

• 更丰富的生产级凭证管理
  ：支持 API Key 的引用、系统生成与自定义，支持 HMAC，并提供 JWKS 获取、密钥类型、Token 透传和 Claims 到 Headers 映射等 JWT 高级配置。

• 与 Higress 生态兼容的迁移基础
  ：延续 Higress 和 Kubernetes 的使用方式，降低网关替换带来的改造成本。

• 托管式网关运维
  ：将版本升级、实例维护、弹性和故障恢复等工作交给云服务，减少企业自建网关的长期运维投入。

• 生产级可观测与高可用能力
  ：统一查看实例、流量和日志状态，并使用企业版产品提供的高可用保障能力。

• 持续演进的插件能力
  ：在认证之外，继续使用 Higress 官方及社区插件，并通过产品化方式完成安装、配置和版本管理。

成本账：不只是性能提升，费用也在下降

性能和功能之外，成本往往是企业决策时最直观的考量。自建 Higress 看似“软件免费”，但实际持有成本并不低：哪怕只是跑一个最小生产部署——比如 2 台 2C4G ECS、1 个公网 NLB、2 个 EIP——全年固定开支就在

左右，无论有没有流量都要照付。消费者规模增长后，为了维持认证性能往往还需扩容数据面实例，进一步推高资源开支，更不必说版本升级、故障恢复和日常运维的人力投入。

阿里云云原生 API 网关 Serverless 版采用“固定实例费 + 按实际调用量阶梯计费”的模式，无需为峰值流量常驻大量计算资源。以目录价测算，同样三档调用量下的年度直接成本对比如下：

日调用量	自建方案（年）	Serverless 版（年）	年节省
1 万次	5,242 元	1,419 元	3,823 元
10 万次	5,244 元	1,419 元	3,825 元
100 万次	5,268 元	1,945 元	3,324 元

可以看到一个有意思的现象：自建方案的成本几乎不随调用量变化，因为资源始终固定在那里；而企业 Serverless 版从日调用 1 万到 10 万，年成本几乎纹丝不动（同为 1,419 元），即便涨到 100 万次/天，也只增加到 1,945 元，约为自建方案的

。

从更广泛的客户场景看，根据大量的实际部署经验，企业 Serverless 版对比开源自建 Higress，中小规模用户的综合费用能降低

，大规模用户也能降低 。而且调用量波动越大、峰谷比越明显，Serverless 弹性计费相对于固定集群资源的成本优势就越突出。

整体来看，迁移到企业版 Serverless 版本，企业获得的不只是认证性能和消费者治理能力的升级，还可以把原本花在网关冗余资源和运维人力上的预算，重新投入到业务本身——这笔账算下来，确实是性价比最高的选择。

关于阿里云云原生 API 网关 Serverless 版

阿里云云原生 API 网关 Serverless 版是 Higress 的企业版托管形态，兼容 Higress 及 Kubernetes Ingress / Gateway API 的使用方式，同时提供免运维、按量付费的 Serverless 弹性能力。它在开源 Higress 的基础上，针对大规模生产场景进行了系统性增强：认证链路支持百万级消费者且性能不随规模线性退化；消费者、密钥、消费者组和 API 授权关系作为独立产品对象提供完整的生命周期治理；内置可观测、高可用和插件市场等企业级能力。对于正在使用或计划使用 Higress 的团队，Serverless 版提供了一条从“能用”到“好用、省心、省钱”的平滑升级路径。