21CTO导读:欧洲最大在线时尚零售商之一 Zalando 的工程团队近日分享了其高吞吐量 API 的设计与实现。通过引入进程内客户端负载均衡器(In-Process Client-Side Load Balancer),团队成功降低了系统延迟的不确定性,缩减了 75% 以上的基础设施成本,并大幅提升了深层故障的可观测性。
Zalando 的产品读取 API 旨在以个位数毫秒级的极低延迟,为 25 个市场的用户提供每秒数百万次的请求处理。然而,其批量查询节点需要将单个外部请求拆分成多达 100 个并行内部子调用,分别分发给不同的产品 Pod。
此前,所有流量(包括内部子调用)均需经过共享的集群边缘负载均衡器 Skipper。
此种架构带来了一个致命痛点:批量请求的整体延迟取决于这 100 个跃点中最慢的那一个(尾部延迟)。由于 Skipper 并不归属于该 API 团队管理,当发生延迟飙升时,团队无法区分是自身的业务逻辑瓶颈,还是共享负载均衡器 Skipper 产生的网络抖动。
为了彻底解决这一痛点,团队决定将高扇出的内部流量路由直接移至调用进程内部(In-Process),同时保留 Skipper 专门处理外部边缘流量和单次 GET 请求。
Zalando 高级首席工程师 Conor Gallagher 如此解释道:
“我们决定,对于高扇出的内部流量,路由决策应该在调用进程内部进行;而 Skipper 擅长的边缘流量则保持原状。我们并非要取代 Skipper,而是将内部扇出路径升级为直接运行在进程内部的客户端负载均衡器。”
为了保证迁移过程中的平滑过渡,团队在客户端库中精确重现了 Skipper 的一致性哈希算法(基于 xxHash64,每个端点配置 100 个虚拟节点)。通过单元测试验证,两条路径会将相同的 Key 路由到完全相同的 Pod:
最小化缓存变更:添加或删除节点时,仅需重新映射约 $1/N$ 的 Key,最大限度保护了 Pod 的本地缓存;
哈希环一致:由于算法与虚拟节点数完全一致,客户端与 Skipper 生成的是相同的哈希环。
取代轮询机制:用基于 Watch 机制的 Kubernetes Informer 替代了原有的轮询机制,避免了大规模扩展时控制平面的崩溃风险;
灰度切流与降本:通过 Feature Flag 将流量从 1% 逐步切至 100%,不仅将部署流水线从数小时缩短至秒级且可随时回滚,还将 Skipper 的 Pod 需求量从 50+ 缩减至 8 个,每日部署成本从 450 美元锐减至 110 美元;
冷启动预热(N-Ring 淡入):针对新 Pod 扩容时的延迟峰值,设计了“N-Ring 淡入”机制——在 30 秒内按 $t^{2.5}$ 曲线渐进切入流量,确保新 Pod 只预热其即将提供服务的产品缓存。
团队还放弃了跨可用区(AZ)感知路由(试验表明跨 AZ 优化会导致缓存碎片化并引发 DynamoDB 极高的读取爆炸),转而通过以下手段强化系统容错:
单次抖动重试(Jittered Retry);
先进先出(FIFO)过载丢弃策略;
节点级故障感知:借由更丰富的客户端日志,负载均衡器能够精准识别短暂的“节点级卡死/冻结(Node Freeze)”,并实现自动绕过。
这项出色的架构改造引发了业界顶级技术专家的关注与热议:
Werner Vogels(亚马逊 CTO):
“出于很多原因,我个人其实不太喜欢在客户端做这种复杂路由,但 Zalando 团队的工程实现确实令人印象深刻,我非常欣赏他们总结的‘经验教训’。”
Alexey Kuznetsov(AWS 首席工程师):
“从亚马逊跳槽到 Google 后,客户端负载均衡的威力对我来说简直是醍醐灌顶……我觉得这种设计理念应该得到更多重视。”
在 Hacker News 上,有开发者对 Zalando 重新开发独立的客户端负载均衡模块表示好奇:既然 Skipper 也是 Zalando 内部开源的项目,为什么不直接给 Skipper 贡献发现机制和相关优化?
对此,Conor Gallagher 强调,Zalando 之所以选择自研客户端负载均衡器,纯粹是因为其场景过于极端(高并发 + 100 倍高扇出),并给出了诚恳的建议:
“要不要自己搭建代理服务器?对几乎所有人来说,答案都是否定的。”
像 Skipper 或 Envoy 这样成熟的独立代理,开箱即用就能提供稳定的一致性哈希路由,不仅由专业团队维护,更经过了全球成千上万用户的生产环境检验。
目前,Skipper 作为开源项目可在 GitHub (https://github.com/zalando/skipper)找到,而 Zalando 这套专为高扇出场景设计的客户端负载均衡器仍属于内部闭源组件。
作者:场长
本篇文章为 @ 场长 创作并授权 21CTO 发布,未经许可,请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 微信公众号。
该文观点仅代表作者本人,21CTO 平台仅提供信息存储空间服务。
请扫描二维码,使用微信支付哦。