4. 云原生网关架构：Ingress Gateway、API Gateway、Service Mesh Sidecar 的角色
在云原生环境中，网关不再是单一组件，而是由多个层次共同构成的流量入口体系。理解 Ingress Gateway、API Gateway 与 Service Mesh Sidecar 的角色差异与协作关系，是进行延迟诊断的前提。三者分别承担南北向流量接入、API 策略执行与东西向流量治理的职责。
4.1 三层网关的角色定义与职责边界
| 网关层次 | 流量方向 | 核心职责 | 典型实现 | 延迟关注点 |
|---|---|---|---|---|
| Ingress Gateway | 南北向（外部 → 集群） | TLS 终止、域名路由、基础负载均衡 | K8s Ingress Controller、Envoy Proxy | 连接建立、TLS 握手、路由匹配 |
| API Gateway | 南北向（外部 → 服务） | 认证鉴权、限流熔断、请求/响应转换、API 版本管理 | Kong、APISIX、Gloo Edge | 策略执行、缓存命中、序列化/反序列化 |
| Sidecar Proxy | 东西向（服务 → 服务） | 服务发现、重试超时、流量分割、mTLS、可观测性数据采集 | Istio Sidecar (Envoy)、Linkerd-proxy | 转发延迟、协议转换、遥测注入 |
诊断视角提示： 一次用户请求的端到端延迟，往往是三层网关延迟的叠加。Ingress Gateway 的 TLS 握手耗时、API Gateway 的限流排队耗时、Sidecar 的 mTLS 握手与遥测上报耗时，都可能成为瓶颈。火焰图交接时，必须明确每一层归属的团队与组件。
4.2 三层网关的协作流程
一个典型的云原生请求路径如下：
- 外部客户端 发起 HTTPS 请求到 Ingress Gateway。
- Ingress Gateway 完成 TLS 终止，根据 Host/Path 规则将请求转发至 API Gateway 的 ClusterIP。
- API Gateway 执行认证、限流、请求转换，将请求路由至目标 Service 的 ClusterIP。
- 目标 Pod 的 Sidecar 拦截入站流量，执行 mTLS 握手、服务鉴权，将请求转发至应用容器。
- 应用容器 处理业务逻辑，可能发起出站调用，再次经过本 Pod 的 Sidecar 出站拦截。
延迟交接关键点： 在火焰图中，每一层网关的耗时通常表现为独立的“平顶”或“锯齿”区域。Ingress Gateway 的延迟集中在连接建立阶段；API Gateway 的延迟集中在策略执行阶段；Sidecar 的延迟则分散在每次服务间调用的首包与尾包处理中。
4.3 三层网关架构的延迟拓扑
下图展示了三层网关在请求路径中的位置与延迟贡献点。每个网关节点都标注了典型的延迟来源，便于多团队在火焰图交接时快速定位责任边界。
4.4 多团队视角下的延迟责任矩阵
在延迟诊断的火焰图交接中，不同团队关注不同的网关层次。下表明确了各团队的责任范围与典型延迟指标：
| 团队 | 负责网关层 | 典型延迟指标 | 火焰图特征 |
|---|---|---|---|
| 基础设施团队 | Ingress Gateway | P99 TLS 握手耗时、连接池等待时间 | 请求起始处的宽平顶 |
| API 平台团队 | API Gateway | P99 策略执行耗时、限流排队深度 | 请求中段的锯齿状堆栈 |
| 服务网格团队 | Sidecar Proxy | P99 mTLS 握手耗时、遥测注入延迟 | 每次服务间调用的尖刺 |
| 业务开发团队 | 应用容器 | P99 业务逻辑处理耗时 | 火焰图主体区域的深色宽条 |
常见误区： 不要将 Sidecar 的延迟简单归因于“网格开销”。在火焰图中，Sidecar 的 mTLS 握手延迟通常只出现在连接建立阶段，长连接下的后续请求几乎不受影响。诊断时应区分“首次连接延迟”与“稳态转发延迟”。
4.5 三层网关的延迟叠加模型
端到端延迟可以表示为各层网关延迟的累加，但需要注意并非简单算术和。由于连接复用、异步处理等因素，实际延迟模型为：
端到端延迟 = Ingress 处理延迟 + API 处理延迟 + Σ(每次服务调用的 Sidecar 延迟) + 业务处理延迟其中，Σ(每次服务调用的 Sidecar 延迟) 是诊断中最容易被忽略的部分。在微服务调用链较长的场景中，Sidecar 延迟的累加效应可能超过 Ingress 与 API 网关的总和。
火焰图交接实践： 当多团队协作分析延迟时，建议在火焰图上使用不同颜色标注三层网关的耗时区域。例如：红色标注 Ingress 域、橙色标注 API 域、紫色标注 Sidecar 域、绿色标注业务域。这样在交接时，每个团队可以快速定位自己负责的“色块”，避免责任推诿。