Meta推出ZGateway：每秒处理超10亿操作的无状态代理层

为何ZippyDB需要代理层

ZippyDB是Meta最广泛使用的键值存储，支撑产品元数据、计数器和配置服务，峰值吞吐达数十亿次操作/秒。在直连架构下，每个客户端需与所需的所有数据库主机建立TLS连接；单个客户端可能访问数十万个主机上的数万个分片，导致客户端与数据库主机两端均维持数万条空闲TLS连接。每条空闲连接消耗内存、CPU及文件描述符，而新客户端批次上线常引发重连风暴——曾因路由缺陷触发全量分片建连，致集群陷入重启循环。由于客户端由数百个团队分散维护，客户端侧修复不可行。

ZGateway的设计与部署

ZGateway是部署于ZippyDB客户端与ZServer数据库集群之间的无状态代理层。当前处理超10亿次操作/秒，承载约40%的ZippyDB流量（预计升至60%），平均计算开销仅约6%。它以区域化方式部署，通过Meta自研服务网格ServiceRouter发现，提供两种形态：纯代理与读穿透缓存。其核心引擎复用Meta成熟的C++版ZippyDB客户端，本质是将该客户端以托管服务形式运行。客户端通过粘性连接发送请求至区域ZGateway节点，后者完成TLS终止、ACL鉴权、租户级准入控制与流量塑形、分片解析、缓存查询（缓存节点）、跨分片请求批处理，并转发至对应副本；响应则被解复用，同时采集各租户维度的指标、追踪与配额使用数据。TLS仍由Thrift/ServiceRouter栈处理，副本选择逻辑保留在嵌入式客户端中。

连接规模的数学优化

Meta采用‘球入箱’模型分析连接负载：设B为分片总数、H为主机数，则单主机预期连接数为E(H,B) = H(1 − e⁻ᴮ⁄ᴴ)。基于模拟参数（20个区域、50万数据库主机、3万代理主机、100万客户端、单客户端平均5万份分片），每主机连接数下降97–98%，全局持久连接总数减少约19倍。更关键的是扩展性提升：直连模式下扇入（fan-in）随客户端数量线性增长；而ZGateway将扇入收敛为‘区域数 × 单主机分片密度’，与客户端及数据库主机规模解耦。

演进能力：从迁移安全到韧性增强

• 安全灰度迁移：支持按服务与分片前缀配置开关，实现百分比渐进、区域过滤及全局熔断。
• 判别式负载卸载（DLS）：请求按租户与优先级映射至独立桶，轮询排空；在CPU超90%的受控过载测试中（约1350个租户桶），仅6个噪声租户被限流，其余租户请求成功率保持99.9%，有效吞吐率稳定在97–98%，机制自身CPU开销约8%。
• 读缓存：缓存节点在进程内服务热点读请求，未命中时对键加填充锁，并通过变更数据捕获（CDC）事件更新，保障有界陈旧性（bounded staleness）。
• 动态负载均衡：代理主机CPU负载由控制平面实时监测，ServiceRouter权重与之反向调节（高负载→低权重）。
• 跨区域弹性：依托全局路由、超大区域（mega-regions）与环形拓扑，饱和区域可自动故障转移至邻近健康容量。
• 事务支持：原客户端侧的事务簿记逻辑迁移至网关，经九阶段重构后覆盖100%事务流量，可靠性零退化。

核心价值与适用边界

ZGateway并非通用开源组件，其深度耦合Meta内部基础设施（ServiceRouter、Thrift、ZippyDB协议栈等），不具备外部部署可行性。其真正价值在于验证了一套可复用的工程范式：通过无状态代理层收束扇入、实施租户隔离、融合批处理与缓存、以数学模型指导容量设计——这些模式对超大规模分布式存储系统的架构演进具有普适参考意义。

> 编者观点：对于中国头部互联网企业及云服务商而言，ZGateway所体现的“以可控代理层替代客户端直连”的思路，在应对微服务爆炸式增长、多租户资源争抢与连接治理难题时，具备强借鉴价值；但落地需同步构建配套的服务网格、细粒度配额体系与变更感知缓存机制。