服务网格：流量治理从应用代码中解脱

每个微服务都在重新发明轮子，服务网格把这个轮子造一次，放到基础设施层。

一、引言：每个微服务都在重新发明轮子

2013 年，Netflix 开源了 Hystrix——一个 Java 断路器类库。它解决了真实的问题：在微服务架构里，一个服务的慢响应会像多米诺骨牌一样拖垮整个调用链。Hystrix 的回答是在代码里插入熔断逻辑，用线程隔离防止级联故障。

这个答案有效，但它带来了新的问题。

你用 Java 写的服务可以用 Hystrix，Go 服务要找 gobreaker，Python 服务要找 pybreaker，Node.js 服务要找 opossum。每个实现行为不完全一致，配置方式各异，版本升级需要所有团队联动。更关键的是，这些逻辑本质上与业务无关——重试、超时、熔断、mTLS 加密是基础设施关心的事，不是业务代码关心的事。

服务网格的出现回答了一个根本问题：当你把一个整体拆成几十个微服务，谁来管流量之间的事情？

答案不是让每个服务自己管，而是把这件事从应用代码里抽出来，下沉到基础设施层，用一个通用的代理来统一处理。这个思路有一个优雅的名字：Sidecar 模式。

二、为什么需要服务网格

微服务时代的网络问题

单体时代，函数调用是内存操作，可靠性由语言运行时保证。微服务时代，服务调用跨越网络，而网络是不可靠的——包会丢，延迟会抖，下游服务会崩溃。

这意味着每个服务都需要处理：

• 重试：请求失败时是否重试，重试几次，退避策略是什么
• 超时：等多久算失败，全局超时还是分段超时
• 熔断：下游持续失败时快速返回错误，而不是等到超时
• 限流：保护自己不被突发流量打垮
• mTLS：服务间通信是否加密，如何管理证书
• 可观测性：每次调用的延迟、状态码、错误率怎么收集

如果每个服务各自实现，代码重复是小问题，行为不一致才是大问题——A 服务的熔断阈值是 50% 错误率，B 服务是 80%，C 服务根本没做熔断，排障时没有统一的基准。

类库方案的局限

Netflix OSS 代表了”类库方案”的最高水准：Hystrix（熔断）、Ribbon（负载均衡）、Feign（HTTP 客户端）、Eureka（服务发现）。在 Java 生态里它工作得相当好，但它有两个根本性局限：

语言绑定：这套类库是 Java 的。Go、Python、Rust、Node.js 需要各自的实现，而各自实现意味着各自的 bug、各自的功能缺失、各自的版本节奏。在 Polyglot 技术栈里，类库方案的维护成本是指数级的。

侵入性：类库方案需要开发者理解并正确配置每一个参数，它和业务代码耦合在一起。一个新的服务必须正确地初始化断路器、配置线程池、注册到服务发现……这是认知负担，也是出错的机会。

到 2018 年，Netflix 宣布 Hystrix 进入维护模式，不再主动开发新功能。类库方案走到了终点。

翻转：下沉到基础设施

服务网格的翻转思路与 Kubernetes 处理调度的方式如出一辙：把横切关注点从应用层下沉到基础设施层，让应用代码只关心业务逻辑。

实现方式是 Sidecar 模式：在每个服务 Pod 里注入一个代理容器（通常是 Envoy），所有进出服务的流量都经过这个代理。代理之间互相通信，形成一张”网”——这就是服务网格（Service Mesh）名字的由来。

应用代码完全不知道代理的存在。它认为自己在直接调用下游，实际上所有逻辑都在代理里悄悄完成了。

三、怎么设计：控制面与数据面

Envoy：为什么是它

服务网格选择 Envoy 作为数据面代理，不是偶然。Envoy 由 Lyft 在 2016 年开源，专门为微服务场景设计，有几个关键特性：

动态配置（xDS API）：传统代理（如 nginx、HAProxy）的配置是静态文件，改配置要重载进程。Envoy 通过 xDS API 实时接收控制面下发的配置，配置变更不需要重启，也不会有流量中断。这是服务网格能够做到实时流量管理的基础。

可观测性内建：Envoy 默认输出每个请求的详细 metrics（延迟分位数、错误率、连接数）和访问日志，支持 trace context 传播（Zipkin/Jaeger 格式）。不需要应用代码做任何事情，可观测性是免费的。

L4/L7 双栈：Envoy 能处理 TCP 流量（L4）和 HTTP/gRPC 流量（L7），并且 L7 处理性能极高，适合高吞吐场景。

Sidecar 模式：流量是如何被拦截的

Envoy 作为 Sidecar 和应用容器运行在同一个 Pod 里，共享同一个网络命名空间。但应用代码并没有主动把流量发给 Envoy——是 iptables 规则在背后做了重定向。

Istio 在 Pod 启动时会注入一个 init 容器（istio-init），它写入 iptables 规则，把所有进出 Pod 的流量重定向到 Envoy 的监听端口（15001 出站，15006 入站）。应用代码发出的 TCP 连接，在离开网络命名空间之前就被 iptables 劫持，交给 Envoy 处理。

应用代码  →  iptables 拦截  →  Envoy（出站代理）  →  网络  →  Envoy（对端入站代理）  →  目标服务

这个机制对应用完全透明，但它引入了两次额外的内核→用户空间上下文切换，这是 Sidecar 模式延迟开销的主要来源。

控制面 istiod

Istio 1.5 之后，控制面被合并为单一进程 istiod，内部包含三个功能模块：

模块	原来的名字	职责
Pilot	istio-pilot	路由规则管理，把 VirtualService/DestinationRule 翻译为 Envoy xDS 配置下发
Citadel	istio-citadel	证书颁发机构，自动为每个服务签发 mTLS 证书，管理轮换
Galley	istio-galley	配置验证与分发，接收 Kubernetes API 对象，做语义校验

istiod 监听 Kubernetes API Server，Watch 所有相关资源（Service、Endpoint、VirtualService 等），把这些信息汇聚后翻译成 Envoy 能理解的 xDS 配置，通过长连接推送给每个 Envoy sidecar。

xDS API：控制面的语言

xDS 是一组 API 协议，每个字母代表一类配置资源：

xDS	全称	含义
LDS	Listener Discovery Service	Envoy 监听哪些端口，接受哪类连接
RDS	Route Discovery Service	HTTP 路由规则（按 header/path/weight 分流）
CDS	Cluster Discovery Service	上游服务集群的配置（负载均衡策略、断路器参数）
EDS	Endpoint Discovery Service	每个集群里具体的实例 IP:Port 列表

控制面改变一条路由规则（比如把 v2 的权重从 10% 改到 50%），就是更新 RDS 配置并推送给所有相关 Envoy。这个过程是秒级的，不需要重启任何进程。

四、三大能力

流量管理：声明式的流量控制

服务网格最直观的能力是对流量的精细控制。Istio 用两个核心 CRD 来表达流量意图：

VirtualService：描述”流量怎么走”——路由规则、权重分流、故障注入、重试策略。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
    - match:
        - headers:
            end-user:
              exact: jason
      route:
        - destination:
            host: reviews
            subset: v2          # 特定用户路由到 v2
    - route:
        - destination:
            host: reviews
            subset: v1
          weight: 90
        - destination:
            host: reviews
            subset: v2
          weight: 10            # 其余流量 90/10 分流

DestinationRule：描述”到达目标后怎么处理”——负载均衡策略、断路器（outlier detection）、连接池限制、subset 定义。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5       # 连续 5 次 5xx 触发熔断
      interval: 30s
      baseEjectionTime: 30s         # 熔断后 30 秒内不发流量
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

这两个资源配合，可以实现金丝雀发布、A/B 测试、蓝绿切换、故障注入测试——全部声明式，不需要改应用代码，也不需要修改 Kubernetes Service。

Gateway 负责管理入口流量，相当于服务网格的边界路由器，可以配置 TLS 终止、主机名路由、协议升级。

安全：零信任的基础

mTLS（双向 TLS）是服务网格安全能力的核心。在 Kubernetes 里，Pod 之间的流量默认是明文的，任何能拿到网络访问权限的攻击者都可以嗅探或伪造流量。

Istio 的 Citadel 为每个服务自动签发 SPIFFE 格式的证书（基于 Kubernetes ServiceAccount），Envoy sidecar 持有这个证书，建立连接时自动进行双向认证。整个过程对应用透明，证书也会自动轮换。

PeerAuthentication 控制 mTLS 策略：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT    # 该 namespace 内所有流量必须走 mTLS

AuthorizationPolicy 在 mTLS 身份认证的基础上做细粒度授权：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-reviews
  namespace: production
spec:
  selector:
    matchLabels:
      app: reviews
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/productpage"]
      to:
        - operation:
            methods: ["GET"]

只有 productpage 服务才能访问 reviews 服务的 GET 接口，其他所有流量被拒绝。这是零信任网络模型的基础实现。

可观测性：不改代码的遥测

这是服务网格最容易被低估的能力。Envoy sidecar 自动收集每次请求的：

• Metrics：请求数、延迟（P50/P95/P99）、错误率，直接暴露给 Prometheus
• Trace：自动传播 x-b3-traceid 等 header（应用只需要透传，不需要生成），配合 Jaeger 或 Zipkin 还原完整调用链
• 访问日志：每次请求的源/目标 IP、响应码、响应时间、传输字节数

在没有服务网格的时候，要做到这一层需要每个服务集成 SDK，还要统一上报格式。服务网格让可观测性变成了基础设施，开发者从第一天起就拥有完整的请求级别遥测数据。

Kiali 是 Istio 的配套可视化工具，能把 Prometheus metrics 渲染成实时服务拓扑图，一眼看出哪条调用链出现了错误率上升。

五、Sidecar 的代价与 Ambient Mesh 的回应

Sidecar 的三个代价

Sidecar 模式优雅，但不是免费的。

资源开销：每个 Pod 都要运行一个 Envoy 进程，典型配置下 Envoy sidecar 消耗约 50MB 内存和一定量的 CPU。在一个有 500 个 Pod 的集群里，这意味着额外 25GB 内存专门用于代理。这个开销在大规模集群里相当显著。

爆炸半径：Sidecar 和应用容器共享 Pod 生命周期。如果 Envoy 崩溃或者 OOM 被 Kill，整个 Pod 的网络都会受影响。更麻烦的是，sidecar 升级（比如 Istio 版本升级）需要重启所有注入了 sidecar 的 Pod——这是一个影响面极广的操作。

强制 L7 解析：Sidecar 模式下，即使你只需要 mTLS 加密（L4 操作），Envoy 也会做完整的 HTTP 解析（L7 操作）。L7 解析有不可忽略的 CPU 开销，对于只需要加密传输的场景是浪费。

Ambient Mesh：移除 Sidecar 的重新设计

Istio 在 2022 年提出 Ambient Mesh，2024 年 GA，它的核心思路是把数据面从 Pod 内部移到节点层，彻底消除 Sidecar。

Ambient Mesh 的数据面由两层组成：

ztunnel（零信任隧道）：以 DaemonSet 形式在每个节点上运行，负责 L4 流量拦截（通过 eBPF 做重定向，上一篇 06-eBPF-内核变成可编程的基础设施 中提到的伏笔在这里兑现）、mTLS 加密、基础的遥测收集。它只做 L4，不解析 HTTP 协议，开销极低。

Waypoint Proxy：基于 Envoy，按需部署在 namespace 或 service 粒度。只有真正需要 L7 能力（HTTP 路由、故障注入、细粒度授权）的服务才需要 Waypoint。大多数服务只需要 ztunnel，享受 mTLS 保护，不承担 L7 解析开销。

flowchart TB
    subgraph Sidecar["Sidecar 模式（每 Pod 一个代理）"]
        direction LR
        subgraph PA["Pod A"]
            AppA[App] --> EnvoyA[Envoy Sidecar]
        end
        subgraph PB["Pod B"]
            EnvoyB[Envoy Sidecar] --> AppB[App]
        end
        EnvoyA -- "mTLS" --> EnvoyB
    end

    subgraph Ambient["Ambient 模式（代理下沉到节点层）"]
        direction LR
        subgraph PC["Pod C"]
            AppC[App]
        end
        subgraph PD["Pod D"]
            AppD[App]
        end
        AppC -- "eBPF 重定向" --> ZT1["ztunnel\n节点 DaemonSet"]
        ZT1 -- "mTLS L4" --> ZT2["ztunnel\n另一节点"]
        ZT2 --> AppD
        ZT1 -. "L7 按需" .-> WP["Waypoint Proxy\n(可选，按 namespace/service 部署)"]
        WP -. "HTTP 路由\n故障注入\n细粒度授权" .-> ZT2
    end

渐进式采纳是 Ambient 的重要设计目标：给 namespace 打一个 label（istio.io/dataplane-mode: ambient），节点上的 ztunnel 自动接管该 namespace 的流量，立刻获得 mTLS 和基础遥测，不需要重启任何 Pod。再按需为特定服务部署 Waypoint Proxy，启用 L7 能力。整个迁移过程不需要停机。

六、上手：给一个应用装上服务网格

安装 Istio

# 下载 istioctl
curl -L https://istio.io/downloadIstio | sh -
export PATH=$PWD/istio-*/bin:$PATH
 
# 安装 demo profile（包含 Kiali、Prometheus、Jaeger、Grafana）
istioctl install --set profile=demo -y
 
# 验证安装
istioctl verify-install
kubectl get pods -n istio-system

注入 Sidecar

# 给 namespace 打标签，后续在该 namespace 创建的 Pod 自动注入 sidecar
kubectl label namespace default istio-injection=enabled
 
# 部署示例应用（Istio 自带的 Bookinfo）
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
 
# 验证 sidecar 注入（READY 列应该是 2/2，而不是 1/1）
kubectl get pods
# NAME                              READY   STATUS    RESTARTS
# productpage-v1-6b746f74dc-4r77t   2/2     Running   0
# reviews-v1-545db77b95-jkgbc       2/2     Running   0

第一个 VirtualService：金丝雀分流

# 先创建 DestinationRule，定义 v1/v2/v3 subset
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
    - name: v1
      labels: {version: v1}
    - name: v2
      labels: {version: v2}
    - name: v3
      labels: {version: v3}
EOF
 
# 创建 VirtualService：90% 流量到 v1，10% 到 v3
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
    - route:
        - destination:
            host: reviews
            subset: v1
          weight: 90
        - destination:
            host: reviews
            subset: v3
          weight: 10
EOF

持续刷新页面，大约 10% 的请求会路由到 v3（带红色星级），90% 到 v1（无星级）。

观测效果

# 打开 Kiali 服务拓扑图
istioctl dashboard kiali
 
# 打开 Jaeger 追踪
istioctl dashboard jaeger
 
# 查看 Prometheus metrics（HTTP 请求成功率）
kubectl -n istio-system port-forward svc/prometheus 9090:9090
# 查询：istio_requests_total{destination_service="reviews.default.svc.cluster.local"}

Kiali 的图形界面会实时显示每条调用链的请求速率和错误率，金丝雀分流的效果一目了然。

七、故障剧场

剧场一：mTLS STRICT 模式突然启用，服务被拒绝

场景：集群里有部分老服务没有注入 sidecar，应用了 STRICT mTLS 策略后，这些服务的调用全部被拒绝。

# 启用 STRICT mTLS
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT
EOF
 
# 没有 sidecar 的服务发起调用，报错
# upstream connect error or disconnect/reset before headers. reset reason: connection failure

定位：

# 检查哪些 Pod 没有 sidecar
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].name}{"\n"}{end}'
 
# 没有 istio-proxy 容器的 Pod 无法通过 mTLS 握手
# 解决：要么注入 sidecar，要么先用 PERMISSIVE 模式过渡

教训：STRICT 模式不能一步到位，应该先用 PERMISSIVE（同时接受 mTLS 和明文），确认所有服务都正确注入后再切换到 STRICT。

剧场二：VirtualService host 写错，流量黑洞

# 错误写法：host 用了完整 FQDN，但 namespace 不匹配
spec:
  hosts:
    - reviews.production.svc.cluster.local  # 当前 namespace 是 default

现象：请求直接 404 或超时，没有任何错误日志提示配置错误。

定位：

# Istio 提供了配置检查工具
istioctl analyze
 
# 输出会提示：
# Warning [IST0101] (VirtualService reviews.default) Referenced host+subset in destinationrule
# not found: "reviews.production.svc.cluster.local"
 
# 检查实际生效的路由配置
istioctl proxy-config route <productpage-pod> --name 9080

教训：VirtualService 的 hosts 字段使用 Kubernetes 短名（reviews）即可，Istio 会自动解析到当前 namespace。跨 namespace 访问要用 FQDN，但要确保 namespace 正确。

剧场三：断路器触发，503 连环

场景：reviews 服务出现间歇性慢响应，outlier detection 熔断后，大量请求返回 503。

# 查看断路器触发情况
kubectl logs <productpage-pod> -c istio-proxy | grep "UO\|UF\|UH"
# UO = Upstream Overflow（连接池满）
# UF = Upstream Connection Failure
# UH = No Healthy Upstream（所有实例被熔断）
 
# 查看哪些 endpoint 被熔断
istioctl proxy-config endpoint <productpage-pod> | grep reviews
# 被熔断的实例状态会显示为 UNHEALTHY

关键：断路器触发是保护措施，不是故障原因。真正需要排查的是 reviews 服务本身为什么慢，503 只是结果。用 istioctl dashboard kiali 观察 reviews 的 P99 延迟趋势，再结合 Jaeger 找到具体的慢请求 trace。

剧场四：sidecar 注入前已有 Pod，策略生效时间差

现象：给 namespace 打了 istio-injection=enabled 标签，也应用了 AuthorizationPolicy，但部分 Pod 的调用仍然能通过——因为它们是在打标签之前创建的，没有 sidecar。

# 检查 Pod 是否有 sidecar
kubectl get pod <old-pod> -o jsonpath='{.spec.containers[*].name}'
# 如果只有 app 容器名，没有 istio-proxy，说明没有注入
 
# 强制滚动重启，让新 Pod 自动注入 sidecar
kubectl rollout restart deployment/<deployment-name>

教训：服务网格的策略生效依赖 sidecar 的存在。namespace 打标签只影响后续创建的 Pod，存量 Pod 必须重启才能注入。在安全敏感的场景里，启用 STRICT mTLS 之前要确认所有 Pod 都已注入。

八、日常排障

istioctl proxy-status：控制面同步状态

istioctl proxy-status
 
# 正常输出：
# NAME                             CLUSTER  CDS  LDS  EDS  RDS  ECDS  ISTIOD                  VERSION
# productpage-v1-xxx.default       ...      SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-xxx   1.20.0
# reviews-v1-xxx.default           ...      SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-xxx   1.20.0
 
# 如果某列显示 STALE 或 NOT SENT，说明该 Envoy 没有收到最新配置
# 通常是 istiod 与该 Pod 的 xDS 连接断开，检查 istiod 日志

istioctl proxy-config：查看实际生效的配置

# 查看路由配置（最常用）
istioctl proxy-config route <pod-name> --name 9080 -o json
 
# 查看 cluster（上游服务）配置
istioctl proxy-config cluster <pod-name>
 
# 查看 endpoint（实际的 IP:Port 列表）
istioctl proxy-config endpoint <pod-name>
 
# 查看 listener（监听端口配置）
istioctl proxy-config listener <pod-name>

这四个命令对应 xDS 的四类配置，遇到路由问题先看 route，遇到连接问题先看 endpoint 和 cluster。

Envoy access log 解读

kubectl logs <pod-name> -c istio-proxy | tail -20
 
# 典型格式：
# [2024-01-15T10:23:45.123Z] "GET /api/v1/products HTTP/1.1" 200 - via_upstream - "-" 0 1234 45 44
# 字段：时间 | 方法 路径 协议 | 响应码 | 响应标志 | 上游集群 | ...

响应标志（Response Flags）是关键：

标志	含义	常见原因
UF	Upstream Connection Failure	下游服务不可达或 mTLS 握手失败
UO	Upstream Overflow	连接池满，触发限流
UH	No Healthy Upstream	所有实例被熔断
NR	No Route	VirtualService 配置错误或 host 不匹配
UMSDR	Upstream Max Stream Duration Reached	请求超时
DC	Downstream Connection Termination	客户端主动断开

常见问题速查

现象	第一步排查	常见原因
503 Via Upstream	proxy-config endpoint 看实例健康状态	断路器触发 / mTLS 握手失败
404 Not Found	istioctl analyze / proxy-config route	VirtualService host 错误
Connection refused	检查 Pod 是否有 sidecar	mTLS STRICT 但无 sidecar
流量没有按权重分流	proxy-config route 看实际规则	DestinationRule subset 标签不匹配
Kiali 拓扑图部分服务不显示	检查 sidecar 注入状态	缺少 sidecar，无 metrics 上报
AuthorizationPolicy 不生效	确认 Pod 有 sidecar + 重启存量 Pod	注入时间差问题

九、往哪走

Ambient Mesh 的成熟路径

Istio 1.24（2024 年底）宣布 Ambient Mesh GA。主要云厂商的托管 Istio（GKE Managed Istio、AWS App Mesh）正在跟进支持。Ambient Mesh 是 Istio 的战略方向，Sidecar 模式不会消失，但新集群的推荐模式会逐渐转向 Ambient。

对于已有集群的迁移路径：Sidecar 模式和 Ambient 模式可以在同一集群共存（通过 namespace 标签区分），可以逐步迁移，不需要一次性切换。

WASM 扩展：在 Envoy 里运行自定义逻辑

Envoy 支持以 WebAssembly 模块的形式动态加载自定义插件，在请求处理链路上插入自定义逻辑——比如自定义鉴权、请求转换、特殊的限流策略——而不需要修改 Envoy 本身或应用代码。

WASM 模块可以用 Go、Rust、C++ 编写，通过 Istio 的 WasmPlugin CRD 动态部署到 Envoy sidecar。这是一个还在成熟的领域，性能开销高于原生 Envoy filter，但灵活性远超静态配置。

Cilium Service Mesh：无 Envoy，纯 eBPF

Cilium 在 1.12 版本引入了 Service Mesh 功能，把传统上由 Envoy sidecar 做的 mTLS、HTTP 路由、负载均衡直接下沉到内核的 eBPF 层完成。

与 Istio Ambient 的区别：Ambient 的 ztunnel 仍然是用户空间进程（只是改为 DaemonSet 而不是 Sidecar），而 Cilium 的路由和加密一部分直接在内核 eBPF 里完成，完全绕过用户空间。在延迟和吞吐量上，Cilium Service Mesh 有明显优势，但 L7 能力不如 Istio 成熟，生态工具（Kiali、Jaeger 集成）也相对简单。

两者并不是非此即彼：已经使用 Cilium 作为 CNI 的集群，可以把 Cilium Service Mesh 作为轻量级起点；需要完整 L7 治理能力的场景，Istio 仍然是更成熟的选择。

服务网格的边界

服务网格不是银弹，它有清晰的适用边界：

• 适合：内部服务间通信治理、mTLS 零信任网络、统一的可观测性基础
• 不一定需要：服务数量少于 20 个的中小系统（维护 Istio 本身的成本可能高于收益）
• 不负责：入口流量治理（这是 Gateway/Ingress 的职责）、DNS 解析、外部服务的连接管理

判断是否引入服务网格的核心问题：你的流量治理问题是否已经复杂到用代码维护不可持续？ 如果答案是肯定的，服务网格是正确的抽象层；如果还没到这一步，过早引入只会增加认知负担。

关联

• → 02-Kubernetes-声明意图，控制器维持世界：服务网格构建在 Kubernetes 之上，CRD（VirtualService/DestinationRule）是声明式模型的延伸
• → 06-eBPF-内核变成可编程的基础设施：Ambient Mesh 的 ztunnel 用 eBPF 做流量重定向，Cilium Service Mesh 用 eBPF 替代 Envoy sidecar
• → 04-GitOps-Git成为系统运行时的真相之源：VirtualService 权重变更、mTLS 策略更新都应该走 GitOps 流程，而非手动 kubectl apply
• → 10）：sidecar/ztunnel 在代理层零代码采集黄金信号，是”不改代码的遥测”在可观测性侧的展开