服务网格API延迟诊断：gRPC与HTTP协议延迟特征分析 - 第1节
1.1 服务网格架构概述
服务网格（Service Mesh）是云原生时代处理服务间通信的基础设施层，它将通信逻辑从业务代码中剥离，下沉为独立的代理层。在 Kubernetes 生态中，服务网格通常以 Sidecar 模式部署：每个业务 Pod 旁挂一个轻量级代理（如 Envoy），所有进出流量都经过该代理。
核心价值：服务网格将重试、超时、熔断、负载均衡、可观测性等分布式系统痛点统一在代理层解决，业务代码只需关注业务逻辑。
服务网格的分层模型
| 层次 | 组件 | 职责 |
|---|---|---|
| 数据平面 | Sidecar 代理（Envoy） | 拦截所有进出流量，执行路由、重试、熔断、指标采集 |
| 控制平面 | Pilot、Citadel、Galley | 服务发现、证书管理、配置分发、策略下发 |
| 管理平面 | Kiali、Grafana、Jaeger | 可视化拓扑、指标监控、分布式追踪 |
1.2 API 延迟诊断的重要性
在微服务架构中，一次用户请求往往跨越 5~15 个服务节点。每个节点上的代理层都会引入额外的处理延迟。延迟诊断的核心目标是：快速定位延迟瓶颈是发生在业务代码内部，还是发生在服务网格的数据平面。
常见延迟陷阱：Sidecar 代理的启动延迟、TLS 握手开销、协议转换（HTTP/1.1 ↔ HTTP/2）的序列化损耗、以及 gRPC 流式调用的背压问题，都可能在网格层产生非预期的延迟尖刺。
延迟诊断的关键指标
- P50 / P95 / P99 延迟：区分典型延迟与尾部延迟，P99 超过 500ms 通常需要立即关注。
- 请求成功率：高延迟往往伴随超时重试，导致成功率下降。
- Sidecar CPU / 内存：代理资源耗尽会直接增加排队延迟。
- 连接池状态：连接耗尽或空闲连接超时都会引发握手延迟。
1.3 gRPC 与 HTTP 协议对比总览
gRPC 和 HTTP（主要指 HTTP/1.1 和 HTTP/2）是服务网格中最常见的两种应用层协议。它们在延迟特征上存在本质差异，直接影响诊断策略。
| 对比维度 | gRPC | HTTP/1.1 | HTTP/2 |
|---|---|---|---|
| 传输协议 | HTTP/2（二进制） | TCP（文本） | TCP（二进制） |
| 序列化 | Protocol Buffers | JSON / XML | JSON / XML |
| 连接复用 | 多路复用（一个连接多个流） | 无（通常需连接池） | 多路复用 |
| 流式支持 | 原生支持（双向流） | 不支持 | Server Push（有限） |
| 首字节延迟 | 低（二进制头部小） | 高（文本头部大） | 中（HPACK 压缩） |
| Sidecar 开销 | 中等（流处理复杂） | 低 | 中等 |
| 典型场景 | 内部微服务、实时通信 | REST API、浏览器 | API 网关、移动端 |
课程路线提示：后续章节将深入 gRPC 的 HTTP/2 帧级别延迟分析、HTTP 队头阻塞（HOL）在网格中的表现、以及如何通过分布式追踪（如 Jaeger）和代理指标（如 Envoy 的 cluster.upstream_rq_time）精准定位延迟根因。