Istio Sidecar vs Ambient 模式对比
结论先行
- Ambient 不是"不要代理"，而是"默认轻代理，按需重代理"
- Sidecar 不是"过时"，在强 L7 场景仍然是稳定且成熟的选择
- 迁移建议：Ambient-first + 混合模式，不要一刀切
两种模式对比
Sidecar 模式
- 每个 Pod 旁挂一个 Envoy 代理
- 天生具备 L7 治理能力（路由、重试、镜像等）
- 代价：常驻资源开销 + 运维复杂度更高
Ambient 模式
- 流量默认经过节点级 Ztunnel（L4 代理）
- 只有需要 L7 策略时，才引入 Waypoint 代理
- 优势：基线更轻，成本更可控
本质区别：Sidecar 是"每 Pod 一个全功能代理"，Ambient 是"分层代理——L4 全覆盖，L7 按需"。
性能收益：L4 vs L7
L4 相比 L7 的资源节省（区间值，非定值）：
| 指标 | 节省幅度 |
|---|---|
| CPU | 20%~60% |
| P99 延迟 | 10%~40% |
| 内存 | 15%~40% |
影响因素：
- 协议类型（TCP / HTTP / gRPC）
- 连接模型（短连接越多，L7 越贵）
- 策略复杂度（路由匹配、镜像、重试、WASM）
零复制可能吗？
完全零复制做不到——代理执行治理逻辑需要读取数据，mTLS 加解密有 CPU 成本，跨进程数据路径无法完全共享内存。能做的是：少解析（L4 优先）、少策略（只开必要的）、少链路（避免不必要的镜像/过滤器）。
迁移决策
适合先转 Ambient
- 服务量大，成本压力明显
- 大量流量只需 L4 安全与连通
- 希望降低 Sidecar 常驻成本
建议继续 Sidecar（至少短期）
- 深度依赖复杂 L7 能力
- 当前 Sidecar 已长期稳定
- 迁移窗口和验证预算有限
落地策略
- 按业务域分层迁移：低风险域 → 中风险域 → 核心域
- 三个硬指标统一观察：
P99、5xx、CPU/内存 - 保留回滚路径：核心链路在一段时间内保留 Sidecar 兜底
- 先 L4 跑稳，再按需引入 Waypoint：不要一上来就开高级策略
常见误区
| 误区 | 事实 |
|---|---|
| "Ambient = 完全不代理" | 错，它是分层代理（Ztunnel + Waypoint） |
| "L4 一定比 L7 快很多" | 不绝对，取决于协议与策略复杂度 |
| "有了 Ambient 就应全量替换 Sidecar" | 风险过高，建议混合迁移 |
选型三问
做决策前回答这三个问题：
- 你的业务到底需要多少 L7 治理？
- 成本瓶颈在 CPU/内存，还是在稳定性与迁移风险？
- 是否有能力做分批迁移和可回滚验证？