Service Mesh 入门：用 Istio 给微服务加上流量管理与 mTLS

介绍 Service Mesh 的价值，用 Istio 演示灰度发布、熔断限流与 mTLS 自动加密，讲清它与传统微服务框架的分工。

微服务多了之后，「服务间通信」的逻辑（重试、超时、鉴权、加密）散落在每个业务里，重复又难维护。Service Mesh 的思路是把这些横切逻辑下沉到「边车」里，业务代码不用改。Istio 是目前事实标准。

架构一句话： 每个 Pod 注入一个 Envoy 边车，进出流量全走它。你的应用照常写代码，流量治理在边车层完成。

灰度发布（Istio 最能打的场景）。 同一个 Service 挂两个版本，用 VirtualService 按 header/比例分流：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  hosts: [payments]
  http:
  - route:
    - destination: { host: payments, subset: v1 }
      weight: 90
    - destination: { host: payments, subset: v2 }
      weight: 10

上线 10% 流量验证没问题，再把权重加到 100%，全程零改代码、随时可回滚。

mTLS 自动加密。 默认开启后，服务间流量全走 mTLS，证书自动签发轮换，业务无感。审计和安全合规时，「内部流量全加密」这一项直接达标。

熔断限流。 配 DestinationRule 的 outlierDetection 自动摘除不健康实例；配 EnvoyFilter 或用 Kiali 做限流规则。

分工提醒： Service Mesh 管「流量」，不管「业务」。超时时间、重试策略放 mesh；业务鉴权、限流逻辑放应用。它不是万金油，小服务量（<10 个）时引入 mesh 的复杂度可能不划算，先评估再上。