第 29 章：服务网格

这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 服务网格把重试、超时、熔断、TLS、鉴权、流量拆分和遥测下沉到基础设施层，常见形态是 sidecar 代理或透明节点代理。

29.1 架构

App Pod
  App container
  Sidecar proxy

控制面：

Policy / configuration -> proxy

29.2 能力

29.3 代价

1. sidecar 资源；
2. 延迟；
3. 运维复杂度；
4. 排障链路变长；
5. 应用仍需处理业务幂等；
6. 升级风险。

不是所有团队都需要服务网格。中小系统可以先在 SDK、网关和 Kubernetes 原生对象中实现关键能力。

29.4 流量切分

VirtualService 示例：

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
    - order-service
  http:
    - route:
        - destination:
            host: order-service
            subset: stable
          weight: 90
        - destination:
            host: order-service
            subset: canary
          weight: 10

29.5 可观测性

网格可以统一输出：

1. 请求 QPS；
2. 错误率；
3. 延迟分布； 4.上下游关系；
4. 连接错误；
5. 重试次数。

业务语义错误仍需应用日志和业务指标判断。

本章小结

服务网格适合多语言、多团队、统一流量治理和安全策略的规模场景。引入前要评估延迟、资源、运维和排障成本。

思考题

1. sidecar 模式的优点和代价是什么？
2. mTLS 解决什么问题？
3. 网络重试为什么要求业务幂等？
4. 流量切分如何支持金丝雀？
5. 什么时候不引入服务网格？