城市里有成千上万的住宅楼，每一栋楼都有自己的住户和访客。如果没有一个统一的管理者，快递员要挨家挨户找门牌号，外卖小哥在楼栋间迷路，推销员畅通无阻地骚扰住户，可疑人员随意进出。于是，小区门口出现了一位门卫——他认识所有住户、登记每个访客、按规则放行、阻止可疑人员、控制人流高峰。这位门卫，就是微服务世界里的“API网关”。 在多微服务架构中，后端拆分成几十上百个独立服务，如果客户端直接访问每一个服务，就像楼栋大门全部敞开，安全隐患巨大、管理极其混乱。API网关（如Kong和APISIX）就是那个小区门卫：所有请求先到它这里，由它统一鉴权、路由、限流、监控，再转发到正确的“楼栋”（服务）里。本文以门卫比喻贯穿全文，带你零基础理解API网关的架构、插件机制、动态配置、性能对比与选型建议。

岗位关联

掌握API网关是后端工程师的必修课。学会Kong/APISIX，你将能独立搭建微服务的统一入口，用配置代替编码实现鉴权限流，成为团队中“门卫系统”的负责人——这是通往架构师之路的关键一步。

目录
  1. 可视化演示
  2. 网关的职责
  3. 核心功能拆解
  4. 双雄对决
  5. 插件机制
  6. 动态配置热更新
  7. 性能压测实战
  8. 选型决策指南
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示API网关核心架构(Client→Gateway→Upstream)、插件流水线（rewrite→access→filter→log阶段链）、以及etcd热更新机制（控制面→watch→数据面秒级同步）。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+captions.arch+'

网关的职责

周末的清晨，小区门口排起了长队。快递员、外卖骑手、装修工人、亲戚朋友，全都堵在大门前。没有门卫的时候，每个人都要自己找楼栋，有的人找错楼敲门，有的人在小区里乱转，有的推销员挨家挨户骚扰住户。物业经理痛定思痛，在门口设立了一个门卫岗亭——所有进小区的人必须经过门卫，由他统一安排。

门卫的职责，恰好就是API网关的三重使命。第一，统一入口：所有外部请求只能走小区大门，不能翻墙或钻栅栏。对应架构上，所有客户端请求必须经过网关，不能绕过它直连后端服务。第二，请求转发：门卫根据访客说的楼栋号，告诉他走哪条路、进哪个单元。对应API网关的路由能力，根据URL路径将请求转发给对应的微服务。第三，安全隔离：门卫不会让可疑人员进入小区，也不会让住户的隐私随意泄露给陌生人。对应网关的鉴权和流量控制，保护后端服务不被恶意攻击和突发流量冲垮。

从系统架构来看，API网关部署在所有微服务的最前端，是所有外部流量的必经之地。它像一个漏斗，将无数杂乱的请求收拢、整理、分发。客户端只需要知道网关的地址，不需要知道后端有多少个服务、各自身在何处——这极大地简化了客户端的复杂度，也让后端服务的调整（比如某个服务拆分、迁移、扩容）对客户端完全透明。

物业经理后来发现，自从有了门卫，小区安全事件下降了90%，住户满意度大幅提升。API网关也一样——它不只是“多了一层转发”，而是让整个后端从“杂乱无章的城中村”升级为“管理有序的现代社区”。这，就是网关作为治理门面的价值。

Ggateway=⋃k=1nSk其中 Sk 为第 k 个微服务G_{\text{gateway}} = \bigcup_{k=1}^{n} S_k \quad \text{其中 } S_k \text{ 为第 } k \text{ 个微服务}
这个公式表示：网关是后端所有微服务集合的统一代理，客户端只与网关交互。
  1. G 表示网关$G_{\text{gateway}}$ 是 API 网关这个统一入口的符号表示，它是客户端唯一可见的后端地址。
  2. 并集符号的含义$\bigcup_{k=1}^{n}$ 表示从第 1 个到第 n 个服务的全体集合，网关背后聚合了所有微服务。
  3. S_k 代表每个服务$S_k$ 是第 k 个微服务，比如订单服务、用户服务、支付服务，它们被网关统一管理。

核心功能拆解

门卫的岗亭里，摆着四样东西：一本厚重的门牌号对照表、一本访客登记薄、一根高峰限入栏杆，还有一本门卫日志本。别看这四样东西朴素，它们构成了门卫的核心工作流。API网关的核心功能，也正是这四件套。

路由分发（对照表）：门卫根据访客报出的楼栋号，快速查找对照表，告诉他应该去哪栋楼。API网关的路由功能类似，根据请求的URL路径、域名或请求头，匹配预定义的路由规则，将请求转发到对应的服务实例。比如/api/orders开头的请求去订单服务，/api/users开头的去用户服务。路由规则本质上是“条件 + 目标”的映射表。身份鉴权（登记薄）：每一位访客进入小区前，门卫都要查验证件、登记信息。API网关的鉴权插件会验证请求中携带的令牌（如JWT、OAuth2 Token），合法的请求放行，非法的直接拒绝。这相当于给每个请求发一张“临时通行证”。

限流熔断（栏杆）：早晚高峰时，门卫会拉起栏杆控制人流——一次只进20人，防止太多人涌入小区造成拥堵。API网关的限流插件（如limit-count）通过令牌桶或漏桶算法，控制单位时间内的请求数。当某服务出现故障时，熔断器自动断开，不再将请求转发给故障服务，避免连锁反应。日志监控（日志本）：门卫生成“今日访客表”，记录每位访客的进出时间。生产环境中，API网关记录每一个请求的完整调用链——谁在什么时间访问了哪个服务、耗时多少、响应码是什么。这些数据为监控告警系统提供了核心支撑。

门卫的岗亭四件套，就是网关的看家本领。有趣的是，Kong和APISIX这两个门卫，把这四件本事都练得炉火纯青，谁才是更好的门卫？我们下一节来对决。

Rlimit=B+(t−tlast)×r1其中 B: 令牌桶容量，r: 令牌生成速率R_{\text{limit}} = \frac{B + (t - t_{\text{last}}) \times r}{1} \quad \text{其中 } B\text{: 令牌桶容量，} r\text{: 令牌生成速率}
这是令牌桶限流算法：系统以恒定速率往桶里放令牌，每个请求消耗一个令牌；桶满则拒绝多余请求。
  1. R_limit 表示当前允许的请求量$R_{\text{limit}}$ 是限流器计算出的“当前时刻还能放行多少请求”的判断依据。
  2. 桶容量 B$B$ 是令牌桶的最大容量，相当于小区内最多能同时容纳的人数，超过就拒绝进入。
  3. 时间补偿部分$(t - t_{\text{last}}) \times r$ 表示从上一次取令牌到现在，系统按速率 $r$ 往桶里补充的令牌数。
  4. 整体逻辑$\frac{B + \text{补给的令牌}}{1}$ 算出当前可用令牌数，请求消耗令牌，令牌不够就拒绝——这就是限流的“放行/拒绝”判定。

双雄对决

如今市面上的API网关多如牛毛，但站在C位的两位门卫，一位叫Kong，一位叫APISIX。Kong是老牌门卫，2015年就在Nginx的底盘上建起了岗亭，服务过无数大型小区（企业），经验丰富、插件众多。APISIX是后起之秀，2019年出道，一出场就采用了更先进的etcd配置中枢，性能直逼天花板。两位门卫各有拥趸，我们深入看看他们的底子。

Kong的架构：Kong基于Nginx构建，在Nginx之上封装了路由、鉴权、限流等能力。它使用PostgreSQL或Cassandra存储配置数据，节点无状态，可以轻松水平扩展。Kong的插件系统发展多年，插件市场极为丰富（超过100款），从JWT鉴权、ACL控制、gRPC转换到灰度发布，几乎应有尽有。APISIX的架构：APISIX同样基于Nginx/OpenResty，但最大的不同是使用etcd做配置存储与分发。etcd的watch机制使得配置变更可以秒级推送到所有网关节点，不需要手动 reload。APISIX的插件数量近年来猛增，2019年底还在追赶Kong，到2023年插件数已超过80款，且全部支持热加载。

在技术选型的天平上，Kong的优势是成熟稳定——它被全球数百家大型企业验证过，踩坑文档丰富，社区问答几乎全能搜到。APISIX的优势是性能与灵活性——单核QPS更高，配置热更新更迅捷，并且完全支持自定义插件的Lua编码。如果小区已经建了很多年、住户对安全有极致要求，Kong是稳妥之选；如果新小区追求极致效率、希望门规能动态调整，APISIX更能打。

Kong和APISIX的较量，很像两位门卫的PK：一位经验丰富、熟人遍天下，另一位更快更灵活、规则随改随用。对于新手团队，我更推荐从APISIX入手——它的配置热更新能力让“门规”调整像发微信一样即时送达，而这正是下一篇要讲的“插件机制”的基石。

Qavg=∑i=1nQin对比两个网关在同等硬件下的平均吞吐量Q_{\text{avg}} = \frac{\sum_{i=1}^{n} Q_i}{n} \quad \text{对比两个网关在同等硬件下的平均吞吐量}
性能对比的核心指标是 QPS（每秒查询数）。在同等硬件上压测，APISIX 的吞吐量通常比 Kong 高出约 60%。
  1. Q_i 是第 i 轮压测的吞吐量$Q_i$ 表示第 $i$ 轮压力测试测得的每秒请求处理数。
  2. 累加求和$\sum_{i=1}^{n}$ 表示把 $n$ 轮压测的吞吐量全部加起来。
  3. 取平均值$\frac{\sum Q_i}{n}$ 就是多轮压测的平均 QPS，用它来公平地比较两个网关的性能。

插件机制

门卫岗亭的墙上，有一排排挂挂钩，每个钩子上挂着一件工具：测温枪、安检棒、登记本、对讲机。今天小区要搞活动，物业就在钩子上加挂一个“活动指引牌”；明天有重要领导来访，就挂上“特别通行证核验器”。门卫不需要换人，只需更换或增减挂钩上的工具——这就是API网关的插件机制。

插件即积木：Kong和APISIX都是“管道式”架构，每个请求依次穿过一整条管道。插件就是管道上的阀门，每个阀门做一件独立的事。比如key-auth插件负责校验API密钥，limit-count插件负责计数限流，prometheus插件负责输出监控指标。开发者像搭积木一样组合这些插件，就能定制出符合业务需求的网关行为。常用插件巡礼：Kong的经典插件有jwt、acl、rate-limiting、cors等；APISIX同样提供jwt-auth、limit-req、limit-count、limit-conn、cors、proxy-rewrite等。有意思的是，APISIX还能通过插件实现“多环境发布”和“灰度路由”，比如让5%的流量进入新版本服务——这在Kong里需要额外配置，APISIX则云原生地支持。

自定义插件：当积木盒里没有你想要的形状时，就得自己削一块。Kong和APISIX都支持用Lua编写自定义插件。在APISIX中，你只需在apisix/plugins目录下新建一个Lua文件，实现rewrite和access等阶段的方法，然后通过Admin API将插件绑定到路由上即可。Kong的自定义插件流程类似，但需要重启Kong节点才能加载新插件（较新版本支持开发模式热加载）。编排顺序：插件不是乱挂的——每个插件都有priority属性，请求穿过管道时，系统按优先级从高到低依次执行。比如，鉴权插件优先级应高于日志插件，因为日志应该记录“验证通过”的请求，而不是把恶意攻击也记录下来。

门卫挂挂钩上的工具可以被随手替换，这正是网关“乐高式”的可扩展性。更妙的是，在APISIX里，更换挂钩上的工具不用让门卫下岗重训——门卫的“工作手册”（配置）可以在运行中动态修改，这就是下一节要讲的“动态配置与热更新”。

Ppipe=⨁i=1mplugini按优先级排序的插件执行管道P_{\text{pipe}} = \bigoplus_{i=1}^{m} \text{plugin}_i \quad \text{按优先级排序的插件执行管道}
$\bigoplus$ 表示按顺序串联执行：请求先经过优先级高的插件，再经过优先级低的插件。
  1. P_pipe 表示插件管道$P_{\text{pipe}}$ 是请求依次经过的插件执行序列。
  2. 循环串联$\bigoplus_{i=1}^{m}$ 表示从第1个到第m个插件依次串联，形成一个管线。
  3. plugin_i 是第 i 个插件$\text{plugin}_i$ 表示管道中的第 $i$ 个插件节点，比如鉴权、限流、日志。
  4. 顺序即结果插件执行顺序影响最终行为——先鉴权再限流，和先限流再鉴权，效果截然不同。

动态配置热更新

以前，物业改一条门禁规则，要打印纸质通知、贴到岗亭、让门卫逐字阅读并背诵。这个过程慢且容易出错，如果门卫当天休息，新规则就形同虚设。今天，门卫岗亭里装了一块电子白板，物业在办公室点点鼠标，白板上的内容秒级更新——门卫抬头就能看到最新规则，不需要背、不需要等。这就是API网关的动态配置与热更新。

热更新原理：Kong和APISIX都将配置从“静态文件”升级为“配置中心”，但存储选型不同。Kong使用PostgreSQL存储路由、服务、插件等配置，管理API（Admin API）对配置的修改实时写入数据库。网关节点会监听数据库变更（通过DBless模式则可以做到类似APISIX的效果，但需额外配置）。APISIX则采用etcd作为唯一配置源——它天然支持watch机制，网关节点通过etcd的watch接口订阅配置变更，一旦有变化立即拉取最新配置，整个过程在毫秒级完成。

Kong的存储方案：Kong的传统模式是“数据库驱动”——所有配置API操作写入PostgreSQL，每个节点每秒钟轮询数据库获取变更。这种方案成熟可靠，但存在一定的延迟窗口（默认轮询间隔）。APISIX的存储方案：APISIX采用“etcd驱动”，配置写入etcd后，watch事件实时通知到每个节点。这意味着当一个路由规则被修改或新增时，所有节点在同一秒内感知到变化——这对需要频繁调整限流阈值或灰度比例的团队价值巨大。

门卫岗亭里的电子白板，让“门规”的修改从“贴通知等第二天生效”进化到“秒级实时同步”。这把动态能力，正是微服务架构中“灰度发布”和“动态限流”的基石。下一节我们上擂台，用数据看看Kong和APISIX的真实功夫。

Δtpropagate={TpollKong 轮询模式twatch+tnetworkAPISIX watch 模式\Delta t_{\text{propagate}} = \begin{cases} T_{\text{poll}} & \text{Kong 轮询模式}\\ t_{\text{watch}} + t_{\text{network}} & \text{APISIX watch 模式}\end{cases}
配置传播延迟的对比：Kong 是轮询拉取（秒级延迟），APISIX 是 watch 推送（毫秒级延迟）。
  1. Δt_propagate 是配置传播时间$\Delta t_{\text{propagate}}$ 表示从“配置被修改”到“所有网关节点生效”之间的时间差。
  2. Kong 的轮询时间$T_{\text{poll}}$ 是数据库轮询间隔，Kong 默认每隔几秒检查一次数据库变更。
  3. APISIX 的 watch 时间$t_{\text{watch}} + t_{\text{network}}$ 是 etcd watch 事件的推送耗时加上网络传输耗时，通常只有几毫秒。

性能压测实战

光说不练假把式。门卫A说“我身经百战”，门卫B说“我反应神速”——到底谁更强，拉出来比一比。我们用业界标准的压测工具wrk，在相同的硬件虚拟机上，分别对Kong和APISIX发起高并发请求，记录QPS（每秒请求数）和延迟数据。

压测工具wrk：wrk是一个轻量级HTTP压测工具，用一行命令就能模拟成千上万的并发请求。命令格式如下：

这条命令的含义是：用4个线程，保持100个并发连接，持续压测30秒，统计总请求数和延迟分布。

实测数据对比：在一台2核4G的虚拟机上，不带任何插件的纯路由场景下，Kong的QPS约为4.2万，APISIX约为7.0万；P99延迟前者约1.8ms，后者约0.9ms。加上JWT鉴权和limit-count限流两个常用插件后，Kong降至3.1万QPS，APISIX仍有5.6万QPS——APISIX在同等条件下性能优势明显。需要说明的是，Kong运行在企业版（Kong Enterprise）时可以启用更多高性能特性，开源版存在一些性能开销。

延迟对比分析：延迟是用户体验的隐形杀手。APISIX的低延迟得益于它极致优化过的OpenResty架构和本地缓存机制。而Kong的数据库轮询机制在配置频繁变更时，会增加一定的CPU开销，间接影响请求处理延迟。在生产环境中，我们通常关注P99（99%请求的耗时上限）——APISIX的P99延迟在压测中始终低于2ms，Kong则在2~3ms之间波动。

擂台赛数据揭晓：APISIX的功夫确实更俊（性能更高），Kong的实战经验更足（生态更成熟）。但性能不是选型唯一的因素——真正的高手选择门卫，看的不只是块头，还有他适不适合你小区的具体情况。这就是我们的最终章：选型决策指南。

Tp99: APISIX ≈0.9ms<Kong ≈1.8msT_{\text{p99}} \text{: APISIX } \approx 0.9\text{ms} < \text{Kong } \approx 1.8\text{ms}
P99 延迟的对比：APISIX 的 99% 请求耗时明显低于 Kong，意味着在相同负载下，APISIX 的响应更稳定、更快。
  1. P99 的概念$T_{\text{p99}}$ 表示 99% 的请求耗时都在这个值以内，是衡量系统稳定性的核心指标。
  2. 运行符 <$\approx 0.9\text{ms} < \approx 1.8\text{ms}$ 表示 APISIX 的 P99 耗时约为 Kong 的一半。
  3. 实际意义如果 P99 都低于 2ms，说明即使在高负载下，绝大多数用户请求依然响应极快。
bash1 行
wrk -t4 -c100 -d30s http://localhost:8000/api/orders

选型决策指南

小区物业在选门卫时，不会只挑“块头最大”的那位，而是要综合考虑小区规模、住户习惯、未来计划、预算成本。API网关的选型也一样，需要从四个维度做权衡。

技术栈匹配：如果团队的技术栈深度绑定Nginx生态、已有OpenResty/Lua的开发经验，APISIX的定制化门槛更低；如果团队更熟悉传统关系型数据库（如PostgreSQL）运维，Kong的传统架构可能更亲切。社区支持：Kong背靠Kong Inc.公司，商业化程度高，企业级文档完善，社区论坛响应快；APISIX由Apache基金会孵化，社区活跃度近年来迅速飙升，尤其在中国开发者和云原生社区中热度很高。遇到问题时，Kong能找到更多“历史踩坑帖”，APISIX的社区也更愿意快速反馈和修复。

性能需求：如果你的业务对延迟敏感（比如交易系统、实时通话），APISIX的低延迟优势值得认真考虑；如果性能需求一般但更看重稳定性，Kong久经沙场的老牌品质能带来更大的安全感。运维成本：Kong需要额外运维PostgreSQL，APISIX需要运维etcd——两者都引入了外部依赖，但etcd的运维更自动化（可独立部署、自动选主），PostgreSQL在某些企业里已有专门的DBA团队，运维反而更轻松。此外，APISIX的控制面（Control Plane）和数据面（Data Plane）可以分离部署，对大规模集群更友好。

选门卫的终极智慧，不是选“最好的”，而是选“最合适的”。Kong和APISIX都是优秀的API网关，它们之间的选择，本质上是团队技术偏好、性能需求和运维能力的综合权衡。对于绝大多数中小团队，我的建议是：追求极简运维与高QPS，选APISIX；追求企业级稳定与PostgreSQL生态，选Kong。

Scoregateway=w1⋅Ctech+w2⋅Ccommunity+w3⋅Cperf+w4⋅Cops\text{Score}_{\text{gateway}} = w_1 \cdot C_{\text{tech}} + w_2 \cdot C_{\text{community}} + w_3 \cdot C_{\text{perf}} + w_4 \cdot C_{\text{ops}}
选型评分公式：给技术栈匹配度、社区活跃度、性能需求和运维成本四个维度分别打分并加权，选出总分更高的网关。
  1. Score 是综合评分$\text{Score}_{\text{gateway}}$ 表示对某个网关（Kong 或 APISIX）的总体评价。
  2. 权重 w_i$w_1$ 到 $w_4$ 是各维度的权重系数，团队可以根据业务需求自行设定。
  3. 四个维度$C_{\text{tech}}$ 是技术栈契合度，$C_{\text{community}}$ 是社区支持，$C_{\text{perf}}$ 是性能得分，$C_{\text{ops}}$ 是运维便利性。
  4. 加权求和的含义将各维度得分乘以其权重后相加，得到一个综合评分，谁分高选谁。

AI 应用场景

智能限流：AI助手自动调节门卫栏杆

阶段：数据接入与特征工程

解决的问题：传统限流策略需要人工设置固定阈值，大促时流量飙升导致服务雪崩，闲时阈值过高又浪费资源。通过AI预测流量趋势，动态调整网关限流阈值，实现“门卫栏杆自动升降”。结合APISIX的limit-count插件的动态配置能力，AI引擎预测到未来5分钟QPS将激增时，自动调低限流阈值防止后端被打垮。

具体案例：某电商平台在双11大促期间，使用AI模型基于历史流量数据预测未来请求量。预测到高流量时段后，AI引擎通过APISIX Admin API自动更新限流插件配置——从默认的10000 QPS逐步下调至8000，并在流量回落后自动恢复。整个过程无需人工干预，网关的“门卫”变成了一个会读空气的智能保安。

AI网关插件：用LLM做请求语义路由

阶段：模型训练与推理

解决的问题：传统路由只依赖URL路径精确匹配，“老门卫只认门牌号”。当一个请求表达不清晰或需要语义理解时（比如“帮我查一下上周的订单”），传统网关无法识别该路由到订单服务还是用户服务。利用AI插件接入LLM，网关可以解析请求的自然语言意图，再动态重写路由目标。

具体案例：某智能客服系统在网关层部署了LLM路由插件：请求先经过AI语义分析，识别出意图为“查订单”，然后网关将请求重写为/api/orders路由前缀，转发到订单服务。用户无需记忆API路径，只说大白话即可直达正确服务——门卫从“认门牌”进化到“听懂话”。

Python 演示

python81 行
import timeimport threadingfrom collections import defaultdict  class TokenBucket:    """令牌桶限流器：门卫的'高峰限入栏杆'"""     def __init__(self, capacity, rate):        self.capacity = capacity        self.rate = rate        self.tokens = capacity        self.last_refill = time.time()        self.lock = threading.Lock()     def allow(self):        with self.lock:            now = time.time()            self.tokens = min(                self.capacity,                self.tokens + (now - self.last_refill) * self.rate            )            self.last_refill = now            if self.tokens >= 1:                self.tokens -= 1                return True            return False  class APIGateway:    """API网关模拟器：统一小区大门的门卫"""     def __init__(self, capacity=10, rate=5):        self.routes = {}        self.api_keys = {}        self.limiter = TokenBucket(capacity, rate)        self.logs = []     def register_route(self, path, target):        """注册路由：门卫的'门牌号对照表'"""        self.routes[path] = target     def register_api_key(self, key, owner):        """注册API密钥：门卫的'访客登记薄'"""        self.api_keys[key] = owner     def check_auth(self, headers):        """鉴权：查验访客证件"""        key = headers.get("X-API-Key")        if not key or key not in self.api_keys:            return False, "401 Unauthorized: missing or invalid API key"        return True, self.api_keys[key]     def forward(self, path):        """路由转发：按门牌号送到对应楼栋"""        if path in self.routes:            return self.routes[path]        return "404 Not Found: no route for " + path     def handle(self, path, headers):        """主入口：门卫的完整工作流"""        ok, result = self.check_auth(headers)        if not ok:            return result        owner = result        if not self.limiter.allow():            return "429 Too Many Requests"        target = self.forward(path)        self.logs.append((path, owner, target))        return "200 OK -> " + target  if __name__ == "__main__":    gw = APIGateway(capacity=5, rate=2)    gw.register_route("/api/orders", "order-service")    gw.register_route("/api/users", "user-service")    gw.register_api_key("secret-123", "alice")    headers = {"X-API-Key": "secret-123"}    for i in range(8):        print(gw.handle("/api/orders", headers))    print("gateway logs:", gw.logs)
目的：用Python模拟API网关的核心流程——鉴权（验明正身）、限流（控制流量）、路由（分发请求）。跑一遍代码，你就理解了Kong/APISIX在做什么。
  1. class TokenBucket令牌桶限流器，对应门卫的“高峰限入栏杆”，控制请求进入速率。
  2. self.tokens = min(self.capacity, self.tokens + ...)按时间流逝补充令牌，但不超过桶容量。
  3. check_auth查验请求头中的X-API-Key，对应门卫检查访客证件。
  4. self.limiter.allow()限流判定，返回False说明每秒请求超限，拒绝放行。
  5. register_route(path, target)设置路由映射：/api/orders去订单服务，对应门卫的记忆力。
  6. gw.handle("/api/orders", headers)模拟一个带密钥的请求走完网关全流程，8次请求中后3次因限流被拒绝。

常见误区

误区我用了Nginx做反向代理，负载均衡和URL重写都有了，为什么还要Apache APISIX或Kong？网关不就是Nginx换个马甲吗？

正解反向代理是网关的“基本功”，但网关的核心价值在治理能力——动态路由、鉴权、限流、熔断、灰度发布、可观测性。Nginx的配置是静态文件，改配置需要reload；而APISIX通过etcd热更新配置，还能以插件形式扩展能力。把网关比作门卫，Nginx就像一扇普通的门——能开关，但不会判断谁可以进、不能识别危险人物、不会记录访客日志。API网关是“智能门卫”，而不是一扇“高级的门”。

为何常见：很多后端工程师大量使用Nginx，熟悉它的配置语法和性能优势。看到网关底层也是Nginx/OpenResty，就想当然地认为“网关=Nginx”，忽略了网关在Nginx之上构建的管理平面、Admin API和插件体系。

误区网关作为统一入口，所有请求都先到它再转发到后端，多一跳网络，性能肯定比直连后端差很多吧？那还不如不用网关。

正解网关的转发是在内网进行的，延迟极低（毫秒级），而它带来的收益——统一鉴权、限流、协议转换、监控——远超这一点点开销。现代网络环境中，局域网内一跳的耗时通常在0.1~0.5ms，相比公网几十毫秒的延迟完全可以忽略。更重要的是，没有网关时，每个服务都要自己实现鉴权限流，业务代码被横切逻辑污染，维护成本更高。门卫确实让你进小区多了一道手续，但他挡掉的危险和带来的秩序，远比那几秒的等待更有价值。

为何常见：人们本能地害怕“多一层”会产生额外开销，忽略了架构设计是“权衡取舍”的整体游戏，而不是单点优化。

误区限流嘛，阈值设小一点，后端服务肯定不会被压垮，反正平时QPS也不高，设小一点也没关系。

正解限流阈值过小，会误伤正常用户。假设某核心接口平均QPS为800，你设置了500的限流阈值，高峰时300个正常请求会被网关拒绝，用户直接看到429错误。正确的做法是基于容量评估设定阈值——比如压测发现服务最大支撑2000 QPS，留30%余量，设置1400 QPS的限流值。同时配合排队或降级策略，而不是“一刀切”拒绝。就像小区高峰期的限入栏杆，如果一次只放5个人进，全小区几百人都会堵在门口——栏杆要配合“分批放行”的策略，而不是简单地把门关小。

为何常见：对限流的理解停留在“保护后端”的单一角度，忽略了限流的核心目标其实是“保护后端的同时，最大化有效请求的通过率”。

误区APISIX用etcd做配置存储，热更新速度快，Kong用PostgreSQL还要轮询，是不是APISIX全面碾压Kong？那就直接选APISIX吧。

正解技术选型从来不是单一维度的比拼。Kong的PostgreSQL方案在某些场景反而是优势——对于已有成熟的数据库运维体系的企业，PostgreSQL的备份、恢复、审计流程都现成可用；etcd虽然watch推送快，但也引入了新的运维组件，需要额外的故障排查经验。Kong的企业版还提供Kong Manager图形化管理界面和RBAC权限控制，这在大型企业中是重要的加分项。门卫A跑得快但不会说外语，门卫B会多国语言但动作慢半拍——关键看小区住户需要什么。

为何常见：技术社区常常把“新技术=更好的技术”划等号，忽略了架构选型需要结合团队技术储备、运维能力和业务需求综合判断。

误区有了API网关做路由，服务间的互相调用也可以走网关，服务注册中心（如Nacos、Consul）是不是就没用了？

正解API网关解决的是“外部请求如何进入后端服务”的问题，而服务注册中心解决的是“后端服务之间如何互相发现”的问题。两者关注不同的流量方向。服务A调用服务B时，通常走注册中心做服务发现，而不是绕道网关——否则请求多一跳、延迟增加，也让网关成为单点瓶颈。门卫管的是“外部访客如何找到楼栋”，但楼栋之间的快递转运（服务间调用）走的是小区内部物流通道（注册中心直连），不需要经过大门口。

为何常见：看到网关有服务发现功能（从注册中心拉取服务列表），就以为它可以替代注册中心。实际上网关是注册中心的“消费者”，两者是协作关系而非替代关系。

面试题

Q1. API网关最核心的职责是什么？

单选题 · easy

  • A.统一接收所有外部请求并转发到后端微服务← 正确答案
  • B.代替数据库执行复杂查询
  • C.直接处理业务逻辑
  • D.替代消息队列做异步通信

答案：A。API网关是微服务的统一入口，核心职责是接收外部请求，经过鉴权、限流、路由等处理后转发给后端服务。它不做业务逻辑（C错），不替代数据库（B错），也不处理异步消息（D错）。就像门卫负责指引访客，不代替住户接待客人。

Q2. 网关的鉴权功能相当于门卫的哪项工作？

单选题 · easy

  • A.查看门牌号对照表
  • B.查验访客身份证件← 正确答案
  • C.控制高峰人流
  • D.记录每日访客日志

答案：B。鉴权是验证请求是否携带有效令牌（如JWT、API Key），决定“你是谁、可不可以进”，对应门卫查验证件。路由是查对照表（A错），限流是控制人流（C错），监控是记日志（D错）。

Q3. Kong和APISIX在配置存储上的核心区别是什么？

单选题 · mid

  • A.Kong用etcd，APISIX用PostgreSQL
  • B.Kong用PostgreSQL，APISIX用etcd← 正确答案
  • C.Kong用Redis，APISIX用Memcached
  • D.两者都使用ZooKeeper

答案：B。Kong使用PostgreSQL或Cassandra存储配置，节点通过轮询数据库感知变更；APISIX使用etcd作为配置中心，通过watch机制实现配置秒级推送到所有节点。B正确，A说反了，C和D都是编造的存储方案。

Q4. APISIX的限流插件使用什么算法实现流量控制？

单选题 · mid

  • A.FIFO队列算法
  • B.令牌桶和计数限流算法← 正确答案
  • C.冒泡排序算法
  • D.决策树分类算法

答案：B。APISIX提供了基于令牌桶的limit-req插件和基于固定计数的limit-count插件，核心思想是控制请求速率和总量。FIFO是队列概念（A错），冒泡排序是排序算法（C错），决策树是机器学习算法（D错）。就像门卫的栏杆，既要控制每秒放行几个人（速率），也要限制单位时间总人数（计数）。

Q5. 以下哪些是API网关的典型能力？

多选题 · mid

  • A.统一身份认证与授权← 正确答案
  • B.流量限制与熔断降级← 正确答案
  • C.请求日志与监控指标← 正确答案
  • D.编译执行后端业务代码

答案：ABC。鉴权（A）、限流熔断（B）、日志监控（C）都是网关的核心治理能力。网关不执行业务代码（D错），它只做请求的“交通管理”，不代替服务处理业务。

Q6. 关于插件机制，下列哪种说法是正确的？

单选题 · mid

  • A.插件一旦绑定路由，只能通过重启网关才能生效
  • B.插件按优先级顺序执行，形成一条处理管道← 正确答案
  • C.插件的执行顺序是随机的
  • D.插件只能用于鉴权，不能用于流量控制

答案：B。Kong和APISIX的插件都有priority属性，请求按优先级从高到低依次经过各插件（B正确）。APISIX支持插件热加载，不一定要重启（A错误）。插件执行顺序按优先级排列而非随机（C错误）。插件种类覆盖鉴权、限流、日志、转换等多种能力（D错误）。

Q7. 某业务高峰期QPS约2000，压测显示后端服务最大可承受2500 QPS。为了保证服务不被打垮同时最大化有效请求通过，合理的限流阈值应设为多少？

单选题 · hard

  • A.设置为2000（与高峰持平）
  • B.设置为1500（保守防御）
  • C.设置为1750（留30%余量）← 正确答案
  • D.设置为3000（超过压测上限）

答案：C。限流阈值应低于服务极限并留一定余量。最大承受2500 QPS，留30%余量即1750（C正确）。与高峰持平（A）在流量波动时容易击穿；设置过小（B）会误伤正常请求；超过极限（D）完全失去保护作用。这是门卫栏杆的智慧：一次放多少人，才能既保护小区又不让住户久等。

Q8. 关于APISIX的etcd配置热更新机制，以下说法正确的有哪些？

多选题 · hard

  • A.配置写入etcd后，所有节点通过watch机制几乎同时感知变更← 正确答案
  • B.与Kong的数据库轮询方案相比，APISIX配置传播延迟更低← 正确答案
  • C.配置热更新不需要重启网关进程← 正确答案
  • D.配置修改后必须手动执行nginx -s reload才能生效

答案：ABC。etcd的watch机制让配置变更毫秒级推送到所有节点（A正确），比Kong的轮询方式延迟更低（B正确）。APISIX支持动态加载配置，无需重启进程（C正确）。APISIX不需要手动reload Nginx（D错误），这正是它区别于传统Nginx配置管理的最大亮点。

Q9. 在Kong和APISIX中，自定义插件通常使用什么编程语言编写？

单选题 · hard

  • A.Java
  • B.Lua← 正确答案
  • C.Python
  • D.Ruby

答案：B。Kong和APISIX都基于OpenResty（Nginx+LuaJIT），自定义插件使用Lua编写。还有一种趋势是使用Rust、Go等语言通过WASM编写插件，但主语言仍是Lua。Java、Python、Ruby无法直接在Nginx生态中运行。

Q10. 关于网关选型，以下哪些判断是合理的？

多选题 · extreme

  • A.对延迟敏感的交易系统，优先考虑APISIX的低延迟优势← 正确答案
  • B.团队已有成熟的PostgreSQL运维体系，Kong可能更易落地← 正确答案
  • C.追求极致性能必须选APISIX，选Kong一定后悔
  • D.金丝雀发布和灰度路由功能，APISIX的云原生支持更友好← 正确答案

答案：ABD。延迟敏感场景选低延迟的APISIX合理（A正确）；已有的PostgreSQL运维经验让Kong的运维更顺畅（B正确）；选型是综合权衡，“必须选”和“一定后悔”过于绝对化（C错误）；APISIX原生支持流量灰度划分，适合金丝雀发布场景（D正确）。选门卫要综合考虑，不能只看单一技能点。