Zalando 如何构建了一个每秒能够处理 100 万次请求的客户端进程内负载均衡器

最近，Zalando 的工程团队详细介绍了一个为高吞吐量 API 而设计的 客户端进程内负载均衡器的设计与实现 "。它每秒可以处理约 100 万次请求。该方案使延迟更可预测，基础设施成本更低，对故障实际来源的洞察更清晰。 Zalando 的 Product Read API " 旨在为欧洲最大在线时尚零售商之一的 25 个市场提供每秒数百万次请求的服务，而延迟要控制在个位数毫秒内。其批次端点将单个请求拆分为多达 100 个并行调用，分别发送至各个产品 Pod，每个调用都会经过 Skipper "（一个共享的集群边缘负载均衡器）。当一个批次在非本团队管理的基础设施中等待 100 个跳点中最慢的一个时，团队便无法将 Skipper 的延迟峰值与其自身的延迟区分开来。为了解决这一问题，他们将高扇出内部流量的路由转移至进程内部进行处理，同时保留 Skipper 用于边缘和单次 GET 请求的流量。Zalando 高级首席工程师 Conor Gallagher " 解释道： 我们决定，对于高扇出量的内部流量，路由决策应由调用进程自身来完成。而 Skipper 最擅长处理的边缘流量，则应保持原状。我们并非要取代 Skipper，而是将内部扇出路径迁移到了一个在进程内部运行的客户端负载均衡器上。 产品集可以直接路由到产品 Pod（图片来源：Zalando 博客） 该团队重新实现了 Skipper 的精确算法（xxHash64，每个端点 100 个虚拟节点），因此在迁移过程中，两条路径会将相同的键路由到相同的 Pod，从而避免了缓存分裂，并且这一行为通过单元测试得到了验证。Gallagher 写道： 这意味着添加或移除一个端点时，仅需重新映射约 1/N 的键，从而最大限度地减少了缓存波动。而且，由于 Skipper 和我们的库使用相同的哈希函数和相同的虚拟节点数量，所以它们针对同一组 Pod 生成的环结构完全一致。 本文介绍了客户端路由的工程决策与挑战，包括一致性哈希、基于占用率的负载均衡、缓存的弹性扩展、分阶段部署策略、可观测性改进，以及可用区路由实验。 该团队用基于监听机制的 Kubernetes informer 取代了会导致控制平面崩溃的轮询机制，将原本耗时数小时的管道重构为快速且可逆的部署流程，并通过开关将负载均衡器从 1% 逐步提升至 100%，从而将 Skipper 的 Pod 集群从 50 多个缩减至 8 个，并将每日部署成本从 450 美元降至 110 美元。为消除纵向扩展的延迟峰值，他们采用了基于^2.5 曲线的 30 秒 N 环渐进启动机制，确保新 Pod 仅预热其实际需要服务的产品。亚马逊首席技术官 Werner Vogels 写道 "： 出于种种原因，我并不太赞成在客户端实现这种方案，但 Zalando 团队的这项工程设计确实令人印象深刻。我喜欢他们的经验教训总结。 亚马逊云科技首席工程师 Alexey Kuznetsov 评论道 "： 当我从亚马逊云科技跳槽到谷歌时，客户端负载均衡对我来说堪称一次启示……我认为这种思路应该得到更多的重视。 虽然 Zalando 尝试采用“AZ 感知路由”来降低跨可用区（AZ）的成本，但这会导致缓存碎片化，并引发 DynamoDB 读取量激增。通过新方法，他们通过单次带抖动的重试机制、FIFO 过载卸载以及更丰富的日志记录强化了路由路径。其中，这些日志记录揭示了短暂的节点级冻结现象，而现在，负载均衡器能够自动绕过这些节点。 Gallagher 强调，Zalando 之所以构建了自己的客户端负载均衡器，仅仅是因为他们面临的是一个真正的极端边缘案例，他总结道： 你应该自己构建吗？对于绝大多数人来说，答案是否定的。像 Skipper 或 Envoy 这样的成熟代理，开箱即用地提供一致性哈希路由，由他人维护，并经过成千上万其他用户的验证。 在 Hacker News 上，有位用户对 开发独立的负载均衡（LB）模块这一选择 "提出了质疑： 文中描述的方法很巧妙，成果也令人印象深刻，所以要向该团队致敬！不过，在阅读过程中，我感到有些奇怪的是，他们竟然将 Skipper 视为第三方依赖项，尽管它是由他们的同事开发和运维的。我的意思是，他们本可以尝试为 Skipper 贡献一些更新和改进，或许还可以复用 Skipper 的发现机制。 虽然 Skipper 是开源的，而且可从 GitHub 上获取，但这个新的客户端负载均衡器并未公开发布，仍然仅在 Zalando 内部使用。 原文链接： https://www.infoq.com/news/2026/07/client-side-load-balancer/ "