Theory · Microservice · API Gateway
把 N 个服务的横切关注点收敛到一个入口 —— 路由 · 认证 · 限流 · 灰度 · 聚合，一次做对处处生效
系统对外的唯一门面：外部请求先到网关，网关完成通用治理后按路由规则转发给后端服务
没有网关：每服务重复实现鉴权/限流/日志 ×N，且口径漂移；有网关：一处实现、集中管控、按路由生效
APISIX（Apache，3.18）、Kong、Envoy Gateway、云厂商网关；上游底座常见 Nginx/OpenResty/Envoy
Why
先算一笔账：3 个服务 × 认证/限流/日志/证书 4 件事 = 12 处实现；阈值从 100 调到 1000 要发 3 次版，第 4 个服务赶工上线时忘了接鉴权。这就是没有网关的日常。
Prerequisites & Glossary
| 术语 | 一句话理解（先记住这个，细节后面展开） |
|---|---|
| 反向代理 | 站在客户端和服务之间的"传话人"：客户端以为在跟它说话，它转头去问真正的服务，再把答案交回来 |
| 路由 Route | 一条"什么样的请求发给谁"的规则：按域名 / 路径 / 请求方法把请求分派到某个后端服务 |
| 上游 Upstream | 网关后面那批真正干活的服务实例。注意方向：越靠近用户越"下游"的说法也有，本 deck 统一称后端服务为上游 |
| 横切关注点 | 每个服务都需要、但跟业务无关的那些事（认证、限流、日志、TLS）——关键词是"每个服务都要" |
| TLS 终止 | HTTPS 的加密在网关这一层解开，网关到后端走内网；证书只需要在网关上管，不用 N 个服务各配一遍 |
| 控制面 / 数据面 | 控制面"决定规则"（控制台 + 配置存储），数据面"执行规则转发流量"。分开之后改规则才不用重启转发节点 |
| 插件流水线 | 一个请求在网关内部按顺序走过的处理步骤：改写 → 认证 → 限流 → 转发 → 记日志，按路由声明谁生效 |
| JWT | 一种"自带签名的凭证"：服务端签发给客户端，之后任何人都能验签确认它没被改过（只签名不加密） |
| 南北向 / 东西向 | 南北向 = 外部进出系统的流量（用户 → 服务）；东西向 = 系统内部服务之间的流量。网关管南北向，Mesh 管东西向 |
| BFF | Backend For Frontends：给某一个前端（App / Web）单独写的薄后端，只做聚合与裁剪，不写业务规则 |
HTTP 与 Protobuf → 请求长什么样、header/path/method 指什么
负载均衡 → 网关把请求转给"上游的哪一台"
服务注册与发现 → 上游实例列表从哪来
微服务总览 → 为什么会有 N 个服务需要被统一治理
后面统一说"网关挡在客户端和上游服务之间"。你只要记住一件事：网关做的事 = 所有服务都要做、但谁做都一样的事，搬到流量必经的那个入口去做一遍。
网关的所有能力都能拆成同一个动作的两半：先看请求是谁、要去哪（匹配路由），再决定放不放行、转发给谁（执行插件 + 转发）。认证、限流、灰度、日志全都只是"在这一步里多查一次表"。
Responsibilities
回到第 2 页那张"无网关 vs 有网关"的图：下面这六件事，正是图里从三个服务里被搬出来、集中到门口的那些活。
按 path/header/host/方法路由到服务集群；规则热更新不重启（控制面下发）；服务发现联动——后端实例变化自动跟随
JWT 验签、OIDC/OAuth2、API Key、HMAC 签名；会话在网关终止，下游只收内部用户上下文头（配合 mTLS/mesh 内部信任）
全局限流（按 IP/用户/API）、WAF、防爬虫、防重放；保护后端免于突发流量与攻击——细节见限流 deck
按权重/header/用户标签把流量切到新版本；金丝雀的前置设施——发布策略详见服务网格 deck 流量管理部分
BFF 聚合多后端响应减少客户端 RTT；REST↔gRPC 转码（grpc-gateway/Envoy transcoder）；对外统一 API 形态
入口统一埋点：生成 trace-id、打访问日志（审计）、输出指标（QPS/延迟/错误率）——全链路追踪的起点
Boundaries
上一页列的是"网关该做什么"；这一页是它的反面——知道不做什么，才知道它该摆在架构的哪一格。
同一职责可在多层实现：限流在网关（粗粒度防刷）+ 在服务（细粒度保护自身）+ 在客户端（自适应）；认证在网关（终止会话）+ 服务间 mTLS（内部零信任）。面试答"放哪层"先讲流量粒度与信任边界，再讲实现位置。
Positioning
Nginx 回答"请求怎么转发"；API 网关回答"API 怎么被管理"——路由只是其一，管控与生态才是差异
单团队 + 路由简单 → Nginx 足够；多团队 + API 数量百级以上 + 需要自助管理 → 上网关产品
APISIX = OpenResty(Nginx+LuaJIT) 数据面 + etcd 控制面；Kong = Nginx/OpenResty + Postgres/Redis 控制面——"网关 vs Nginx"实为"管理面有无"
Architecture
Landscape
| 产品 | 数据面引擎 | 配置存储 | 生态与特点 | 适用 |
|---|---|---|---|---|
| Nginx | 自有 C 模块 | 静态文件 reload | 性能/稳定性标杆；插件靠 C/Lua，管理面缺位 | 单团队、路由简单、入口静态 |
| Kong | Nginx/OpenResty | Postgres/DB-less | 最老牌网关产品，插件多（Lua/Go）；社区版功能受限较多 | 多语言插件需求、成熟生态 |
| APISIX | Nginx+LuaJIT | etcd（watch 热更） | Apache 项目；动态路由秒级生效；插件 Lua/多语言 Plugin Runner；控制台完善；3.18（2026-08） | 国内主流选择、云原生、需要极致动态性 |
| Envoy / Gateway API | Envoy（C++） | xDS（控制面下发） | 云原生标准数据面；xDS 协议被 Mesh 共用；配置复杂度高 | K8s 深度用户、与 Istio 统一数据面 |
| Traefik / Caddy | Go / Go | 自动发现（labels/CRD） | 轻量、易用；性能与插件生态弱于前四者 | 中小规模、开发友好 |
| 云厂商网关 | 托管 | 托管控制台 | 免运维、计费弹性；深度绑定云生态（鉴权/日志/监控） | 不养平台团队、云上优先 |
K8s 环境优先 Envoy 系（Gateway API + 与 Mesh 同底座）；国内自建多选 APISIX（动态性 + 控制台 + 社区）；需要大量定制插件且团队熟 Lua/Go → Kong 或 APISIX 都行；规模小直接 Nginx/云托管。
Ingress 注解语义碎片化 → Gateway API（SIG-Network）用角色分离重新设计：GatewayClass（平台方）/Gateway（运维方）/HTTPRoute（开发者）三层对象，厂商实现为数据面（Envoy/APISIX/Kong 都有实现）——新项目选型时的现代答案。
BFF
GraphQL 是 BFF 的一种强表达实现：客户端声明需要什么字段，服务端按 query 聚合——天然解决"多端字段差异"与"过度获取"。代价：缓存（HTTP 语义失效需 DataLoader/CDN 特殊处理）、N+1 与查询复杂度治理、权限模型更细。选型：字段组合爆炸时上 GraphQL，简单聚合用轻量 Go 服务即可。
风险：BFF 变厚——业务逻辑偷偷住进 BFF，改一端要动领域服务+BFF 两层；多团队 BFF 复制粘贴同样的聚合逻辑。收敛手段：聚合能力组件化（统一并行调用框架+熔断）、领域服务提供"聚合友好"的查询接口（面向视图的只读查询/CQRS 读模型）。
AuthN/AuthZ
header.payload.signature；payload 只签名不加密——敏感信息放不进 JWT；alg:none 与弱密钥是经典漏洞；吊销靠短有效期 + 黑名单/refresh token
OIDC 是"登录协议"（ID Token 证明你是谁），OAuth2 是"授权协议"（access token 允许干什么）；网关对接 IdP（Keycloak/企业 IdP）做 code 交换，bff/SPA 拿 token 再访问 API
开放平台：API Key + HMAC 签名（防篡改防重放：timestamp+nonce）；机器对机器：mTLS 或 OAuth2 client_credentials；配额与计费挂在 API Key 维度
答题结构：先分 AuthN（你是谁）/ AuthZ（你能干什么）——网关做 AuthN + 路由级粗粒度 AuthZ，数据级授权必须下沉服务；再讲方案 A/B 的取舍与内网信任假设。
Resilience
接入网关 → 业务网关 → API 网关层层叠加，每层加延迟、加配置分裂、加排障难度。原则：七层网关只过一次，特殊需求用插件扩展而不是再加一层；确需多级（如集团统一接入 + 事业部自治），每级职责要写进架构文档并被执行。
网关是"一改全站抖"的地方：路由/插件变更走预览+灰度生效（先灰一个节点/一条路由）；配置回滚要秒级；对配置存储（etcd）做变更审计——与配置中心 deck 的灰度与审计思想完全一致。
Cheat Sheet
| 本质 | 系统对外的唯一门面：横切关注点从 N 个服务搬到流量必经的入口 |
| 价值公式 | 没有网关：鉴权/限流/日志/TLS 各写 N 遍且口径漂移；有网关：一处实现、集中管控、按路由生效 |
| 三个"不做" | 不做业务逻辑、不做服务间治理、不存状态——边界感是懂架构的试金石 |
| 动态路由 | 按 path/host/header 转发，规则热更新，联动服务发现 |
| 认证鉴权 | 网关做 AuthN + 路由级粗粒度 AuthZ；数据级授权必须下沉服务 |
| 流量防护 | 按 IP/用户/API 全局限流 + WAF + 防重放（HMAC + timestamp/nonce） |
| 灰度发布 | 权重灰度（1% 到 v2）+ 标签灰度（按 uid/header 精准放量） |
| 聚合与转码 | BFF 聚合减 RTT；REST ↔ gRPC 转码；HTTP/2 透传要放行 metadata |
| 可观测与审计 | 入口生成/透传 trace-id；按路由打 RED 指标；访问日志脱敏 |
| 小规模 / 路由简单 | Nginx 或云托管网关足够 |
| K8s 深度用户 | Envoy 系 + Gateway API（与 Mesh 共用数据面） |
| 自建 / 要极致动态 | APISIX（etcd watch 秒级热更 + 控制台） |
| 定制插件多 | Kong / APISIX（Lua / Go Plugin Runner） |
| A 网关终止（主流） | 验签 → 剥离 token → 注入 x-user-id 等内部头；必须配内网隔离/mTLS，否则伪造头即越权 |
| B JWT 透传 | 每服务自验签，服务可独立对外；代价是密钥管理与验签成本 ×N |
Interview QA
先盖住答案自己答一遍，再往下对照——想不起来比看得顺眼记得牢；答不出的直接翻回上一页速查表。
反向代理解决"转发"（Nginx 的 location/proxy_pass，静态配置）；API 网关面向"API 的管理"：动态路由控制台、插件生态（认证/限流/灰度开箱即用）、多租户与审计。多数网关的数据面就是 Nginx/Envoy——差别在控制面与生态。规模判据：API 过百、多团队协作时网关产品收益才显现。
部署上无状态多副本 + L4 收敛 + 跨 AZ，横向扩容；架构上网关依赖（认证服务/配置中心）要设计成弱依赖：认证缓存本地、配置 last-known-good、下游发现列表缓存——任何依赖抖动网关都能先扛住。压测瓶颈常在连接数与 TLS 握手，用连接复用与会话恢复解决。
放网关：收敛实现、统一审计、下游减负，但要求内网隔离防伪造头。放服务：每服务自治（可独立对外），但密钥管理与验签成本 ×N。主流混合：网关做 AuthN+路由级 AuthZ，服务做数据级授权；敏感服务可要求 token 透传二次验签。判据是信任边界与团队边界。
聚合服务是技术视角（把 N 个响应拼起来）；BFF 是组织视角（为某个端、由该端团队拥有、按该端视图裁剪数据）。BFF 的纪律是只编排不写业务。没有多端差异与聚合 RTT 痛点时，不需要 BFF——别为了模式而模式。
控制面把路由/插件规则写进配置存储（etcd），数据面 watch 到变更后在内存里原子切换路由表（先构建新表再原子替换指针），请求无感。APISIX 用 etcd watch + Lua 热加载；Envoy 用 xDS 的 versioned config 原子应用。回滚 = 把版本指回去。
网关限流：粗粒度、面向调用方（IP/用户/API Key/租户），防刷防攻击、全站预算；服务层限流：细粒度、面向自身容量（按接口/按资源），防止某个接口打满服务。两层阈值独立调优，网关阈值 ≥ 服务层总和。算法与实现见限流 deck。
Interview QA · continued
同样先自答。这一页每题都需要"结论 + 一句代价/边界"才完整——只答结论会被追问。
两条路：透传（网关原生支持 HTTP/2 与 gRPC 帧，按 :path 路由，性能无损）；转码（Envoy transcoder/grpc-gateway 把 REST/JSON 翻成 gRPC，一份 proto 双协议）。注意：网关必须放行 grpc-timeout/traceparent 等 metadata 的传递，否则下游治理失效。
聚合接口必须定义部分失败语义：非关键数据失败 → 置空/占位返回（200 + degraded 标记）；关键数据失败 → 快速失败。并行调用共享 deadline 预算（谁慢谁先被砍），配熔断防止雪崩——聚合把 N 个依赖的故障域合并了，治理必须跟着升级。
两级：权重灰度（order 服务 1% 流量到 v2，网关按上游分组分流）；精准灰度（按 header/uid 白名单把指定用户导到新版本）。实现靠路由规则 + 后端版本分组（K8s 中两个 Deployment/Service 或 Mesh DestinationRule）。放量与回滚决策看错误率/P99，自动化触发。
按三条主线答：① 形态——K8s 深度用户选 Envoy/Gateway API 系，自建多选 APISIX（动态性+控制台），小规模 Nginx/云托管；② 插件需求——认证/限流/自定义逻辑的开箱程度与自研成本（Lua/Go Runner/WASM）；③ 运维能力——配置灰度、审计、监控、多集群。结论跟场景走，没有绝对最优。
开放 API 用签名方案：客户端对 method+path+body+timestamp+nonce 做 HMAC-SHA256 签名；网关重算比对（防篡改），校验 timestamp 窗口（如 5 分钟）+ nonce 短期存储去重（防重放）。HTTPS 只保护传输，签名保护的是"业务请求本身"——两者叠加才完整。
入口是 trace 起点：生成/透传 trace-id 进访问日志；指标按 RED 三元组（Rate 错误率、Errors、Duration P50/P95/P99）按路由维度打点；日志含 method/path/上游/code/延迟/用户维度（脱敏）。网关指标是"全站健康第一屏"——错误率突增先看入口再看服务。
Related & References