微服务网关选型：Kong、APISIX与Envoy对比

可视化演示

动态展示网关请求处理链路、Kong/APISIX/Envoy三方案对比、电商多协议路由场景与性能基准指标。

网关全景：小区为什么需要物业

假设你带着家人搬进一座新建的“微服务小区”。刚开始只有两三名住户，大家抄着楼号直接敲门就行。可当服务从个位数膨胀到几十个——用户服务、订单服务、支付服务各占一栋楼，住户们开始叫苦连天：记不住地址、排错队、被各楼保安反复查证件。物业公司应运而生：所有住户只从大门进出，物业替你带路、查证、限流、登记。这套“大门＋前台”的制度，在微服务世界里就叫网关（API Gateway）。

网关是微服务架构的“统一交通入口”。所有客户端请求先到这个入口，再由网关做路由转发（把请求带给正确服务）、认证鉴权（确认你是不是小区住户）、限流熔断（防止人群把楼挤垮）、日志审计（登记访客）。网关通常分为控制面与数据面两种角色：数据面是一线保安，真正处理每个请求；控制面是物业总台，制定规则并推送给保安。

本期考察的三位候选人各有出身。Kong 是最早把开源 API 管理做成产品化的老牌项目，基于 Nginx/OpenResty 构建，插件体系以 Lua 编写；APISIX 同样基于 Nginx/OpenResty，但出场更晚、理念更云原生，配置存储在 etcd，支持插件热更新；Envoy 则是 C++ 编写的高性能七层代理，本尊并不是“完整网关”，而是数据面特种兵，通常需要搭配 Istio 等服务网格控制面使用。

一个网关入口让住户无需再记几十个地址，相当于把请求集中收口再统一分派：

三家物业的做事风格差异很大：Kong 像正规物业公司，制度完整；APISIX 像新锐团队，工具常换常新；Envoy 像外包特种兵，能力顶尖却不带后勤。究竟哪家适合你的小区，我们分维度逐一考察。

性能基准：谁在洪峰期放行最快

小区早晨八点是高峰，住户刷脸进门的速度决定整体体验。有的物业门禁机安装的是顶级硬件（Envoy 的 C++ 引擎），再多的人涌入也从容不乱；有的门禁机用着经典感应系统（Kong/APISIX 背后的 Nginx），日常够用，但极端洪峰下会先到瓶颈。性能基准，就是在同一杆秤上称量三家的“单位时间放行能力”。

网关性能通常用两个指标衡量：吞吐量（QPS） 是每秒处理的请求数；延迟（Latency） 是单请求从进入到返回的耗时。业界常用 p99 延迟 代表极端体验——把所有请求耗时排序，第 99% 位置的耗时就是 p99。

在标准压测中，Envoy 凭借 C++ 事件驱动模型常能跑出最高的吞吐上限；Kong 与 APISIX 同源于 OpenResty，性能同源，但 APISIX 在配置读取、热加载上做了不少优化，小包请求下往往略优于 Kong。不过性能不只是峰值数字，还要看资源占用：Envoy 单实例内存占用通常略低；Kong 与 APISIX 在启用丰富插件后都需为插件进程预留额外内存。

p99 的数学表达式，是排序后取位置：

性能维度上，Envoy 像洪峰里也面不改色的特种兵，Kong 与 APISIX 类似普通门禁机但日常完全够用。值得注意的是，性能差距在绝大多数业务规模下不构成瓶颈，选型更要看后面几个维度。

插件生态：谁的工具箱最齐全

物业团队的工具箱决定它能承接多少服务。有的物业配备齐全的储物柜——门禁卡、快递架、宠物寄存箱一应俱全（Kong）；有的物业工具箱更科学，新增储物柜时不用关大门、即装即用（APISIX）；有的特种兵团队只发一把多功能军刀，想装宠物寄存柜得自己找供应商（Envoy Filter 链）。

网关插件（Plugin） 是扩展网关能力的“积木”，常见的有：密钥认证、IP 白名单、限流、熔断、CORS 跨域、日志采集、灰度分流等。插件生态越丰富，你需要自研的代码就越少。

Kong 是最早建立插件市场的项目，官方与社区插件数量庞大，企业版还有额外增强，但配置变更往往需要 reload 才生效；APISIX 同样基于 OpenResty，但推出了“插件热加载”——增删改插件无需重启网关，对流量零中断；Envoy 则采用 C++ 过滤器链（Filter Chain） 机制，功能上可以无限自定义，但每个过滤器都要编写并编译进二进制，开发门槛高出一个量级。

用“需求覆盖率”量化计算：

插件生态这一项，Kong 和 APISIX 明显甩开 Envoy 一截。如果你需要“买回来就能用”的工具箱，Kong 和 APISIX 更顺手；如果你的团队 C++ 能力强、愿意为极致灵活性投入，Envoy 的过滤器链也可以定制一切。

配置模式：如何下达新规矩

物业改管理制度的方式，决定了业主体验。老牌物业公司改一条规则要写申请单、局长签字、发公文、贴公告栏，第二天才生效（Kong 改配置要 reload）；新锐物业用数字化系统，管理员在后台点个按钮，门禁立刻按新规则执行（APISIX 热更新＋etcd 下发）；特种兵团队则不发公告，只给保安下无线电指令，指令格式还得你自己定（Envoy 通过 xDS 协议从控制面拉取）。

网关配置模式即“管理员如何把规则下发给数据面”。常见模式有：管理 REST API（调接口改配置）、声明式配置（YAML 描述期望状态，控制面监听并执行）、DB-less 模式（配置文件加载，无数据库依赖）。配置生效方式分为需 reload（重启 worker 进程）与热加载（新 worker 增量生效）。

Kong 传统上依赖 PostgreSQL 保存配置，管理 API 修改后需发送 reload 信号让 Nginx worker 重载；DB-less 模式下则要重新生成配置文件部署。APISIX 采用 etcd 存储＋配置监听机制，变更实时推送到各节点，无需 reload。Envoy 定义了 xDS 接口（CDS/EDS/RDS 等），由控制面（如 Istio）通过 gRPC 流推送配置，数据面增量更新。Kong 也有声明式配置和 decK 工具，但历史包袱相对更重。

一次配置发布的总耗时可拆成三段：

配置模式这一项，APISIX 最贴近“点一下立即生效”的理想物业体验，Kong 是传统但成熟的流程，Envoy 则把话语权交给你、一切自定义。若业务要求频繁调整网关规则，热更新能力需要重点考察。

运维复杂度：日常照料谁最省心

物业好招，难养。选物业除了看门禁质量，还要看日常开销：物业费多少（资源占用）、是否需要专门配一个“物业管理员”盯着（控制面组件）、换新制度时业主是否要停工一上午（升级与灰度）。

运维复杂度包含部署拓扑、组件依赖、升级策略、监控可观测性。网关部署简单可以省出大量人工；升级能否灰度、回滚是否容易，直接影响稳定性。

Kong 部署最“重”：传统模式要同时运维 PostgreSQL，Kong 节点本身无状态，加上控制面组件，零件较多但文档成熟。APISIX 依赖 etcd 作为配置中心，节点同样无状态，容器化部署非常顺滑，APISIX Ingress Controller 可直接对接 Kubernetes。Envoy 本身只是进程，要构成生产级网关方案必须自己维护或引入控制面（如 Istio、Gloo），学习曲线陡峭。

用可用性指标衡量“省心程度”：

运维复杂度上，Kong 是“配置齐全但零件多”，APISIX 是“轻装上阵、云原生友好”，Envoy 是“能打但后勤自理”。团队越小，越倾向选择 APISIX；团队有专职基础架构专家且追求极致可定制时，Envoy 才划算。

容错恢复：突发状况谁靠得住

真正的物业好不好，要看断电、暴雨、电梯故障时怎么应对。有的物业有备用发电机（内置熔断器），有的靠临时工搬沙袋（外部插件），有的保安本身就是急救专家（原生机制），反应速度和恢复质量差别很大。

网关的容错能力指面对下游服务故障、突发流量、网络抖动时，能否保护整个系统。关键能力包括：熔断（Circuit Breaking）——下游快挂了就自动开门分流或拒绝；限流（Rate Limiting）——控制单位时间进场人数；重试（Retry）、超时控制、健康检查。

Envoy 在容错上是“科班出身”，内置非常精细的熔断器、重试预算、异常点检测（Outlier Detection），不依赖插件就具备很强的自愈能力；Kong 和 APISIX 通过插件实现限流和熔断——Kong 有 rate-limiting、proxy-cache 等插件，APISIX 提供 limit-count、limit-req，并依托 etcd 的分布式一致性降低配置丢失概率。Kong 依赖的 PostgreSQL 则需要额外做高可用。

故障总时间可分解为：

容错维度上，Envoy 是原始天赋最强的特种兵，Kong/APISIX 则像靠纪律与流程取胜的物业队。如果你下游系统本身比较脆弱，网关的容错能力必须放在选型优先级的前列。

选型实践：不同小区该怎么挑

没有最好的物业，只有最适合小区现状的物业。老小区求稳，新小区求方便，科技园区追求定制化。选型本质是权衡：把性能、生态、配置、运维、容错五个维度按你的业务权重加权，算出一个综合分。

选型建议一般按业务规模与技术栈划分：中小团队/创业期优先考虑上手速度与运维成本；中大型企业看重治理能力与插件生态；云原生重度用户关注 Kubernetes 集成度；已有服务网格的团队则应避免重复建设网关。

不同场景的侧重点也一目了然：

• 中小团队、Kubernetes 原生：优先 APISIX，热更新＋etcd＋Ingress Controller 一套带走，运维成本最低。

• 大型企业已有统一 API 治理体系：Kong 更稳妥，插件市场和成熟文档让团队容易上手。

• 已深度使用 Istio/服务网格：Envoy 已经是数据面，直接在其上扩展即可，不必再引入独立网关。

• 超高并发、极低延迟业务（如金融高频）：Envoy 性能优势明显，但需配专业控制面。

把多维评分用加权求和统一：

把加权公式套进你家小区的需求，答案自然浮现。选型不是选“最强”，而是选“最合拍”——这也是本篇文章最想传递的一句话。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""网关选型评分器:从五个维度为候选网关加权打分""" GATEWAYS = {    'Kong':   {'perf': 0.78, 'eco': 0.92, 'cfg': 0.72, 'ops': 0.82, 'ft': 0.75},    'APISIX': {'perf': 0.88, 'eco': 0.90, 'cfg': 0.85, 'ops': 0.74, 'ft': 0.84},    'Envoy':  {'perf': 0.95, 'eco': 0.62, 'cfg': 0.58, 'ops': 0.55, 'ft': 0.92},} WEIGHTS = {'perf': 0.30, 'eco': 0.20, 'cfg': 0.20, 'ops': 0.15, 'ft': 0.15} DIM_NAME = {'perf': '性能', 'eco': '生态', 'cfg': '配置', 'ops': '运维', 'ft': '容错'}  def total_score(name, weights=None):    w = weights or WEIGHTS    d = GATEWAYS[name]    return sum(w[k] * d[k] for k in w)  def recommend(weights=None):    results = [(name, total_score(name, weights)) for name in GATEWAYS]    results.sort(key=lambda x: x[1], reverse=True)    return results  def show_detail(name):    d = GATEWAYS[name]    return {DIM_NAME[k]: v for k, v in d.items()}  def main():    print('默认权重:', {DIM_NAME[k]: v for k, v in WEIGHTS.items()})    for name, s in recommend():        print('{}: {:.2f}'.format(name, s))    print('评分详情 - APISIX:', show_detail('APISIX'))  if __name__ == '__main__':    main()

1. GATEWAYS = {...}用字典保存三种网关在五个维度上的经验分数，分数范围 0~1。
2. def total_score(name, weights=None)接收网关名与权重表，返回该网关的综合分。
3. return sum(w[k] * d[k] for k in w)生成器对每个维度做“权重×得分”再求和，即公式 S 的实现。
4. w = weights or WEIGHTS如果没有传入定制权重，则使用默认权重表。
5. results.sort(key=lambda x: x[1], reverse=True)按综合分从高到低排序，输出选型排名。
6. def main():程序入口，打印默认权重、各网关排名与 APISIX 的评分明细。

常见误区

面试题