北京
欧洲大型时尚电商Zalando的工程团队近期披露了一项进程内客户端负载均衡器的设计与实现方案，该方案面向一个峰值流量约每秒100万个请求的高吞吐API。最终效果体现在三个方面：更可预测的延迟、基础设施成本的下降，以及对故障真实起源的更清晰洞察。
这套系统服务于Zalando的Product Read API，作为一家覆盖25个市场的零售商，该API需要在个位数毫秒级的延迟下应对每秒数百万次的请求量。其批量端点会将单次请求扇出至最多100路并行调用，每一路都指向独立的产品Pod，并且都需要穿过Skipper这一共享的集群边缘负载均衡器。
问题正出在这一跳转路径上。当一个批量请求必须等待100次经由Skipper的基础设施跳转中耗时最长的那一跳时，团队开始面临一个现实困境：他们无法将Skipper自身的延迟峰值与业务自身的延迟问题剥离开来。随着对基础设施这一环节失去控制权，延迟的可预测性也随之下降。
团队做出的核心调整，是将高扇出的内部流量路由逻辑直接挪入进程内部。Conor Gallagher等工程师给出的设计思路很明确：进程内负载均衡接管高并发的内部路由，而Skipper仍然保留在边缘流量和单一GET请求的路径上。这样一来，大批量内部调用不必再反复穿越边缘组件，延迟观察的粒度也因此提升。
从一个更宏观的角度看，这并非简单地替换掉Skipper，而是一次有选择的职责分离。边缘流量仍然需要统一的入口管理，而内部爆炸式扇出请求则更适合放在应用进程内就近解决。这种分离让延迟的可观测边界变得清晰，团队终于能够区分出“是自己的问题”还是“基础设施的抖动”。
从结果来看，这套自研方案带来的不只是性能上的改善。更透明的故障定位意味着运维成本被压缩，而更直接的调用路径也释放了部分基础设施资源，从而转向更经济的算力配置。对于日均需处理海量商品信息请求的电商场景而言，延迟的可控和成本的下降往往比单纯的峰值吞吐数字更具工程价值。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
