Computer NetworkNotes

第 29 章：服务网格与 Sidecar 网络

zjc 于 2026-01-29 发布

这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 服务网格把服务间通信的认证、加密、路由、重试、熔断、限流和观测从业务代码下沉到基础设施。常见形态是应用旁挂 Sidecar 代理，流量先经过出站代理，再进入对端入站代理，业务进程通常不直接感知这些策略。

29.1 为什么需要服务网格

微服务的通信治理需求：

  1. 服务发现；
  2. 负载均衡；
  3. TLS / mTLS；
  4. 重试；
  5. 超时；
  6. 熔断；
  7. 限流；
  8. 灰度路由；
  9. 链路追踪；
  10. 流量镜像。

SDK 模式的问题：

  1. 多语言重复实现；
  2. 升级依赖业务发版；
  3. 策略分散；
  4. 故障排查边界不清；
  5. 框架和业务耦合。

网格把通用能力放在代理和控制面。

29.2 Sidecar 流量劫持

以 Istio + Envoy 为例：

App A
  -> iptables / eBPF 劫持
     -> Envoy A outbound
        -> mTLS
           -> Envoy B inbound
              -> App B

控制面：

Istiod
  -> 服务发现
  -> 证书签发
  -> 配置分发

数据面：

Envoy
  -> 实际转发
  -> 执行路由和策略

29.3 mTLS

工作流程：

  1. 控制面为工作负载签发证书；
  2. 客户端 Sidecar 发起连接；
  3. 双方校验证书；
  4. 证书中身份对应 Service Account；
  5. 授权策略基于身份判断；
  6. 证书自动轮换。

价值：

  1. 防冒充；
  2. 加密链路；
  3. 服务身份；
  4. 细粒度授权；
  5. 审计调用双方。

注意：mTLS 只解决链路和身份，不代替业务授权。

29.4 流量治理

常见规则：

能力 示例
超时 请求 500ms 失败
重试 5xx 重试 2 次
熔断 错误率 50% 摘除
限流 每秒 1000 QPS
故障注入 1% 延迟 5s
灰度 10% 流量到 v2
镜像 复制流量到测试版本
区域感知 优先同 AZ

原则：

  1. 默认不盲目重试；
  2. 重试预算必须有总超时；
  3. 连接池和 outlier bounds 要设置；
  4. 策略变更可灰度；
  5. 观测配置生效版本；
  6. 避免多层代理重复重试。

29.5 Sidecar 生命周期

启动：

  1. Pod 创建；
  2. Sidecar 注入；
  3. Envoy 初始化；
  4. 监听端口就绪；
  5. 劫持规则生效；
  6. 配置同步；
  7. 应用开始收发流量。

关闭：

  1. Pod 进入 Terminating；
  2. Endpoint 摘除；
  3. 拒绝新请求；
  4. 等待存量请求；
  5. Sidecar 最后退出；
  6. 应用进程退出。

如果应用先退出而 Sidecar 仍在收请求，会出现 503；如果 Sidecar 先退出而应用仍外呼，外呼会失败。新版 Kubernetes Sidecar 生命周期和网格配置可以缓解，但要按集群版本验证。

29.6 性能影响

成本：

  1. 每跳增加两个代理；
  2. mTLS 握手和加解密 CPU；
  3. 连接劫持开销；
  4. 内存占用；
  5. 配置分发规模；
  6. 可观测数据量。

优化：

  1. 控制平面分域；
  2. 减少不必要规则；
  3. 合理设置日志采样；
  4. 连接复用；
  5. 只在需要链路启用 mTLS；
  6. 使用轻量代理；
  7. 评估 Ambient Mesh / eBPF 形态；
  8. 为代理设置资源上限。

29.7 排障

命令：

istioctl proxy-status
istioctl proxy-config listener <pod>.<namespace>
istioctl proxy-config cluster <pod>.<namespace>
istioctl proxy-config route <pod>.<namespace>
istioctl proxy-config log <pod>.<namespace> --level debug

抓包：

kubectl exec -it <pod> -c istio-proxy -- \
  tcpdump -i any -nn port 8080 -w /tmp/debug.pcap

Envoy 状态：

kubectl exec -it <pod> -c istio-proxy -- \
  curl localhost:15000/clusters

常见问题：

现象 排查
503 UC 上游连接失败、健康状态
mTLS 握手失败 证书、策略、身份
路由不生效 版本标签、规则优先级
偶发超时 重试叠加、后端慢
发布失败 Sidecar 生命周期
配置不一致 proxy-status、pilot 版本

29.8 是否使用服务网格

适合：

  1. 多语言服务多；
  2. 统一 mTLS 和授权需求强；
  3. 流量治理复杂；
  4. 服务数量大；
  5. 需要灰度和流量镜像；
  6. 平台团队具备运维能力。

不适合：

  1. 服务数量少；
  2. 团队无法承担复杂度；
  3. 延迟和资源极度敏感；
  4. SDK 已统一且稳定；
  5. 缺少观测和排障能力；
  6. 只是为了“看起来更云原生”。

本章小结

服务网格通过数据面代理和控制面配置，把服务发现、mTLS、路由、重试、熔断和观测从业务代码下沉到基础设施。Sidecar 模式带来统一治理能力，也增加延迟、资源、生命周期和排障复杂度。是否引入应基于服务规模、多语言需求、安全合规和平台能力，而不是流行程度。

思考题

  1. 服务网格和 SDK 治理的边界是什么？
  2. Sidecar 模式如何劫持应用流量？
  3. mTLS 中的服务身份来自哪里？
  4. Sidecar 启动和退出顺序会导致什么问题？
  5. 写一份服务网格灰度接入和回滚方案。