边车代理模式如何在不改业务代码前提下接管流量治理

Kubernetes把分布式治理问题下沉到基础设施层后，仍有一类问题处理不了：粒度 太粗。例如微服务A调用B服务的两个接口B1、B2，若B1正常但B2持续报错，理想的 熔断应该只切断到B2的调用，但基础设施只能感知到整个容器，要么切断A到B的全部 网络（连累B1），要么完全不切（放任B2的错误持续影响A）——这类”应用系统与 基础设施边界处”的问题，很难单靠粗粒度的容器管理解决。边车代理模式（服务 网格的核心机制）的解法是：系统自动在服务容器里注入一个通信代理（”边车”）， 用类似中间人攻击的方式接管应用的全部对外通信，业务代码对此完全无感知。这个 代理一边处理正常的服务间通信（数据平面），一边接收来自控制器的配置指令 （控制平面），根据配置对流量做熔断、认证、度量、负载均衡等精细化处理—— 相当于把”程序代码能做到的精细管理能力”下放到了应用之外，代价是多了一层 代理转发的开销。

结构图：

flowchart LR
    App[业务应用容器] -->|全部出站流量被劫持| Sidecar[边车代理]
    Sidecar -->|数据平面: 正常服务间通信| Other[目标服务的边车]
    Control[控制平面/控制器] -->|下发熔断/认证/负载均衡配置| Sidecar
    Sidecar -->|据配置精细化处理| Decision{按B1/B2等具体接口粒度决策}
    Decision -->|B1正常放行| B1[服务B的接口B1]
    Decision -->|B2持续报错熔断| B2[服务B的接口B2]