服务网格 33：无网格、Sidecar 和 Ambient 性能怎样公平比较
Ambient L4 比 Sidecar 更快，这个结论缺什么前提
先补功能等价。对 orders → inventory-v1/v2 的同一请求，无网格、sidecar、ambient L4、ambient 加 waypoint 可能承担不同的 mTLS、请求头路由、JWT/授权、重试、遥测和连接池任务。仅把四组在某台机器上打出 p99 排名，通常是在比较不同工作。前面的章节分别要求真实代理路由与策略证据；只有所有组满足同一业务与安全门禁的部分，才有可比较的延迟。无法使 ambient L4 执行 HTTP 头路由时，应把这项能力标 N/A，而不是令其绕过规则后参与“同功能”排名。
性能测量也不能修复语义差异：没有策略的低延迟不能替代受约束流量的可用性；应用完成一次报价与代理可能进行两次上游尝试也不能用同一个请求数作分母。报告至少分为四列：发起的逻辑请求数、代理上游尝试数、应用处理数、客户端成功数；记录请求 ID 映射。若启用错误身份拒绝，拒绝请求占到哪一种分母要事先说明。
锁定参数再看分位数
| 组别 | 提供的能力 | 对照前需要固定的差异 |
|---|---|---|
| 无网格 | 应用本身及可选的应用传输保护 | 是否额外提供同级别 mTLS、七层路由、授权；不满足者标 N/A |
| Sidecar | 每 Pod 代理，依实际策略执行 L4/L7 | 路由、重试、采样、代理资源限额与连接池 |
| Ambient L4 | CNI/ztunnel 的四层通路 | 不把缺失的 HTTP 路由/七层授权算作“更快” |
| Ambient + waypoint | L4 加共享 L7 代理 | waypoint 实际绑定、请求是否经过、共享容量与 placement |
在每一可比能力组里，固定 SKU、请求体大小、并发模型和客户端连接复用；用同样的 frontend → orders 调用链（orders 先调用 inventory，成功后再调用 external-stub） 链路部署到同种节点、同一可用区拓扑，并记录节点型号、内核、Kubernetes/CNI、实际代理镜像 digest、证书配置、采样率和预热。不要把原有 loadgen 的一次 GET 当压测：它只做功能调用；使用下节固定到达率负载发生器时，要分别保留发起时刻、结束时刻、失败码、每跳服务版本及账本。低负载、接近饱和和受控慢依赖各测一组，使用多个独立轮次而不是重复解读某一段幸运窗口。
报告吞吐（完成/发起）、错误比例（写明哪类错误）、客户端 p50/p95/p99、分布及最大尾延迟、各组件 CPU/内存和节点网络指标；分位数不能把每个实例 p99 直接平均。Prometheus histogram 可在统一桶边界、同一窗口合并原始 bucket 后估计集群分位数；定时压测若重试放大，客户端总等待与上游每尝试耗时应拆开。采样不足时只报告样本量/窗口，不写毫秒级优劣或不确定的因果结论。
两道门禁：功能与故障
在 examples/service-mesh/ 先只读确认具名隔离 context：
1 | |
随后在冻结版隔离集群中对四模式分别采正常路径与错误身份、错误请求头、慢库存、单端点失效；先按资源提交→代理活跃配置→实际请求路径→后端版本/账本验收，有缺口的组不进入功能等价组。再逐组预热、在固定速率及固定连接复用条件下测量；受控失败路径中预期身份拒绝却放行、账本重复或请求错误率超出预设门禁时断言非零。对于无网格基线，若没有同等安全能力，就明确报告“非等价能力下的纯进程参考”，不能用它代表产品性能赢输。所有数据必须保存原始请求与测量脚本，而不是手工摘录官方产品图表。
负载发生器已经提供，尚未部署四个真实数据面；四组性能数值与排名全部 NOT_RUN。本篇不填未经测量的延迟或百分比；Go 测试只证明应用逻辑。
固定到达率发生器与原始结果格式
本轮新增 mainline/33/load.py，只依赖 Python 标准库，不再依赖历史段落中尚未实现的压测设想。它按 rate 调度逻辑请求，线程容量耗尽时记录 generator_capacity，不会无限排队或偷偷降低报告中的发起数。每个请求最多一次 HTTP 尝试，不做自动业务重试；--keepalive 控制每个工作线程的连接复用。
1 | |
相同命令分别把 mode 改为 sidecar、ambient、waypoint，目标换成对应实际入口，输出目录不能覆盖。mode 只是记录标签，不安装数据面也不证明路径。如果使用 kubectl port-forward，它的进程与隧道会进入测量路径，结果只能标作该路径参考，不能当成 Pod 间网格转发性能。正式对照应把发生器放在同一规格的集群内负载 Pod，经同一 Service 调用真实工作负载，并确认来源身份满足策略。
四模式至少分成两种问题：无安全功能的纯传输开销参考，以及满足业务安全门禁的功能组。当前累计应用没有自行提供与网格等价的 mTLS 和 L7 授权，因此 bare 不进入完整安全功能组，ambient L4 也不进入要求 header 路由的组。需要全功能四方对照时，先为缺失组实现并验证等价功能；本章不把这项尚未完成的工作隐去。
settings.json 保存 URL、速率、时长、线程、超时和复用设置。requests.jsonl 每行包含请求 ID、计划发送时刻、实际起止时刻、队列延迟、HTTP 状态或异常、响应体。summary.json 保存计划总量、成功、错误、发生器丢弃量与 nearest-rank p50/p95/p99。分位数按真正尝试的全部请求计算，包含失败尝试耗时；被发生器丢弃的请求没有虚构延迟，单独计数。需要只看成功分布时，应从原始行筛选并明确写出条件。
1 | |
上面仅说明字段，不是实验观测。时间戳使用同进程 monotonic 时钟的相对值，不能跨主机直接相减；summary 的 unix 起点用于与外部指标对齐。吞吐分母至少覆盖完整计划窗口，若最后请求仍未结束则包含排空时间。线程队列延迟和发生器丢弃过高意味着负载端不足，应先扩容负载端再解释服务端饱和。
正常实验先低速预热并丢弃预热轮，随后固定负载跑三个独立轮次。失败实验使用第 34 篇慢库存或缩掉一个端点，保持请求总量与超时不变，保存同一窗口代理 upstream attempts 和应用日志。恢复后重跑完整负载，比较错误消失与分布恢复，不能只发一个探测请求就宣布性能恢复。
1 | |
发生器环回 HTTP 自检通过：验证请求数、原始行数与分位数函数；证据在 examples/service-mesh/evidence/verification/26-35/load-check.log。它没有部署四种网格，真实网格性能仍全部 NOT_RUN，本章不提供排名。清理结束时删除自己启动的负载 Pod/port-forward，保留 raw JSONL 与 settings，临时服务随自检退出回收。可复用原则是先证明功能相同，再证明发生器忠实记录所有计划输入，最后解释性能。Istio 固定版本性能文档源码 只用作测量维度参考，不作为本仓库结果。
练习与参考解答
- 测试显示 ambient L4 的 p99 小于 waypoint 组，而请求头分流和方法拒绝只在 waypoint 组启用；能称 ambient L4 性能更好且可替换 waypoint 吗？参考解答：不能。L4 组没做同样的七层工作，先把未满足功能标
N/A；如需求要求七层治理，只在满足相同能力的组内比较，注明硬件、采样和负载条件。 - 把每个实例的 p99 相加除实例数，会得到集群 p99 吗？参考解答：不会。构造 99 个快请求由 v1 处理、1 个极慢请求由 v2 处理的非均匀样本即可反例；分位数不满足可加性。需要聚合原始请求分布或同边界 histogram buckets，固定窗口与观测点重新计算。
官方参考与系列导航
- Istio performance and scalability：官方测量条件入口，不能把官方图当成本仓库测量。
- Prometheus histogram practice：聚合桶与分位数估计。
- Istio ambient data plane：L4 与 waypoint L7 能力边界。
