2025-12-06 DoorDash 从生产故障出发，用自研控制平面 + Envoy 数据平面构建服务网格，支撑峰值 8000 万 QPS。

🔬

技术洞察

1. 故障驱动架构演进：2021 年支付服务重试风暴引发的级联故障，直接推动了服务网格立项，而非盲目追技术趋势。 2. 技术选型务实：明确拒绝 Istio（运维复杂度太高）和 Linkerd2（功能不足且需上游贡献），选择 Envoy 数据平面 搭配自研控制平面，用两人团队实现三个月 MVP 交付。 3. MVP 架构设计：通过 Kubernetes Mutating Webhook 实现 Sidecar 自动注入，开发者仅需添加标签即可接入；初期采用文件配置 + S3 分发 + 热重启机制，规避了 xDS API 的复杂性。 4. 金丝雀发布策略复用生产 Service 的 label selector，使 canary pod 自动纳入现有服务发现体系，通过调整副本数控制流量比例，无需修改客户端。 5. 大规模推广关键：从手动配置切换到 配置模板化，配合集中式 Grafana 告警和标准化 Runbook，将单服务接入时间从天级压缩到小时级。 6. 架构持续演进：引入 Zone-Aware Routing 降低跨 AZ 流量成本，通过 EDS API 动态推送端点元数据；支持基于 Header 的沙箱路由和基于 gRPC 方法名的实体缓存路由。

⚠️

值得注意

1. 自研控制平面的隐性成本被低估：文章轻描淡写"两人团队"，但后续团队扩张到 8 人，且需持续维护与 Consul 的集成、配置模板生成器、xDS 控制面等组件。这种 技术债转移 对中小团队极不友好。 2. 文件配置 + S3 分发的"伪静态"方案存在一致性风险：DaemonSet 拉取配置的时延、S3 与 Envoy 热重启之间的竞态条件在生产环境可能引发配置漂移，文章未提及如何处理。 3. 移除 Envoy Sidecar 的 CPU 限制是个危险操作：虽然避免了 throttling，但在共享节点上可能导致 Noisy Neighbor 问题，影响同节点其他关键服务的 P99 延迟。 4. OpenTelemetry 集成仅用于"spot-checking"，说明分布式追踪仍未成为一线排障的标准路径，更多是事后分析工具。

原文

◆

Helm通过六年来最大规模的版本发布，提升了Kubernetes的包管理能力

InfoQ - 云计算•发布于 12月6日

知识洞察型•云计算与后端•评分: 7/10

Helm 4KubernetesServer-Side ApplyWASM插件