一句话结论
Meta 推出 ZippyDB 无状态代理层 ZGateway，以处理 10 亿次/秒流量为背景，将持久连接总数减少约 19 倍。
关键要点
- ZGateway 承担 Meta 分布式键值存储系统 ZippyDB 约 40% 的流量，且每秒处理超过 10 亿次操作。
- 该架构设计将数据库主机的连接数降低约 97% 至 98%，持久连接总数缩减为原有模式的约 1/19。
- 网关通过 ServiceRouter 发现并运行在区域层，支持纯代理转发与读透式缓存两种工作模式。
- 在 CPU 利用率超过 90% 的受控测试中，仅 1350 个租户存储桶中的 6 个发生流量分流，其余处理了 99.9% 的请求。
- 该方案通过增加一层网络跳数换取连接管理开销的显著降低，并集中处理负载均衡、租户隔离与过载保护。
背景与事实
Meta 的分布式键值存储系统 ZippyDB 在全球基础设施中承担产品元数据、计数器、配置信息及多类工作负载的读写需求。在 ZGateway 部署前的直接访问模型中，超过 100 万个客户端主机直接连接至提供分片的数据库主机。由于单个客户端可能访问分布在数十万台数据库主机上的数万个分片，系统内部形成了密集的“多对多”连接网格。Meta 的技术团队指出，这种架构容易引发连接风暴，进而导致主机端文件描述符耗尽与内存不足等可靠性问题。
ZGateway 作为部署在客户端与 ZippyDB 服务器之间的无状态托管代理层，彻底改变了流量管理模式。客户端仅需与所在区域的网关主机维持粘性连接，数据库服务器则集中接收来自受控网关集群的连接。ZGateway 依托 Meta 的超大规模服务网格解决方案 ServiceRouter 实现服务发现，确保客户端总是能够连接至地理位置最近的网关。该网关直接复用 Meta 现有的 C++ ZippyDB 客户端作为请求处理引擎，并具备纯代理与读透式缓存（Read-Through Cache）双重能力。在流量管理上，ZGateway 集中承担了请求的身份验证、基于租户的准入控制、分片路由解析以及请求批处理与合并工作。由于网关能够统一观测来自多个客户端的流量，它可以识别并合并同一客户端库在不同进程间原本无法共享的请求。
根据 Meta 内部模型估算，ZGateway 的引入使每个数据库主机的连接数下降约 97% 至 98%，全局持久连接总数缩减至原来的约 1/19。目前，该网关已承担 ZippyDB 约 40% 的总流量，每秒处理超过 10 亿次操作。在受控的过载测试中，当系统 CPU 利用率被推高至 90% 以上时，ZGateway 展现了极强的流量保护能力：在 1350 个租户存储桶中，仅 6 个被分流，剩余租户依然正常处理了 99.9% 的请求且未触发任何请求拒绝机制。此外，ZGateway 为全球紧急回滚提供了集中式的流量关闭开关，并支持按服务、分片前缀、百分比或区域进行逐步的流量路由切换。
影响分析
对于中文开发者与企业从业者而言，这一架构演进明确了“连接池化”在超大规模系统中的工程价值与可行边界。分析判断表明，传统的“每个客户端直连每个数据节点”模式在节点规模超过十万级时将遭遇不可持续的连接管理开销，而 ZGateway 展示的代理层能够将这种非线性开销转化为线性或近似固定的常量开销。这提示国内从事分布式存储与中间件研发的团队，在处理百万级主机连接时，可以考虑引入无状态的托管代理层，以集中化方式解决网络资源瓶颈。此外，ZGateway 对“基于租户的准入控制”与“请求合并”能力的集中化，也对国内多租户 SaaS 数据库平台的限流策略与资源隔离设计提供了具体的工程参考样本，有助于从业者优化现有的高并发场景处理方案。
适用边界
该架构带来的 1/19 连接缩减效益与性能提升，高度依赖于系统具备“客户端基数极大（百万级）且连接数远超数据处理需求”的底层拓扑结构。分析判断指出，若业务场景的客户端数量在千级或万级以下，或者数据库节点数量不足千台，直接在客户端部署连接池并直连数据库节点通常能提供更好的延迟表现，此时引入 ZGateway 带来的额外网络跳数反而会成为性能瓶颈。此外，ZGateway 基于 Meta 内部高度集成的 C++ 客户端与服务网格 ServiceRouter 构建，国内企业若缺乏同等规模的超大型自研基础设施底座，盲目复制该跨层架构可能带来极高的开发与运维成本，且未必能获得同等的规模化收益。
孤本观察
编辑观察认为，ZGateway 的核心创新并非在于代理技术本身，而在于其将多租户流量在“网关共享视角”下完成了跨进程聚合，这一操作模式是消除海量客户端连接矩阵的关键逻辑。基于当前信息判断，在超大规模数据中心网络中，通过有意的网络跳数增加来换取集中式的控制平面的可扩展性，已成为比单纯追求单节点极限吞吐更为务实的系统设计演进方向。
常见问题
ZGateway 部署后，ZippyDB 数据库主机的连接数减少了多少比例？
连接数下降约 97% 至 98%，全局持久连接总数缩减至原有模式的约 1/19。
在 CPU 利用率超过 90% 的过载测试中，ZGateway 对租户请求的处理结果如何？
在 1350 个租户存储桶中仅 6 个发生流量分流，其余租户正常处理了 99.9% 的请求且未触发拒绝。
ZGateway 适用于哪种规模的客户端与数据库节点场景？
适用于客户端基数极大（百万级）且连接数远超数据处理需求的场景；若客户端在千级或万级以下，建议直接连接池。
ZGateway 支持哪两种主要的工作模式？
支持纯代理转发与读透式缓存（Read-Through Cache）两种工作模式。
ZGateway 是通过什么机制实现服务发现并连接到最近的网关？
依托 Meta 的超大规模服务网格解决方案 ServiceRouter 实现服务发现，确保客户端连接至地理位置最近的网关。
来源：InfoQ 中文 AI