一次路由错误，暴露了直连模式的上限

ZippyDB承载着Meta产品元数据、计数器和配置，是一个每秒处理数十亿次操作的全球分布式键值存储。问题并不只是请求量大，而是访问者太多、归属太分散：ZippyDB客户端分布在超过一百万台主机上，由数百个团队维护。单个客户端可能访问数万个分片，而这些分片又分布在数十万台数据库主机上，于是系统形成了密集的多对多TLS连接网。

这种连接关系会把看似空闲的资源也变成故障放大器。每条连接都要在客户端和数据库主机两端占用内存、CPU和文件描述符，重连时还会突然放大资源需求。Meta材料提到，一次路由错误曾让客户端为每个分片分别建立连接，最终因为文件描述符耗尽和内存不足，整个集群陷入反复重启。更棘手的是，客户端属于数百个团队，平台团队无法用一次库升级迅速修复所有行为。

因此，ZGateway的出发点不是把数据库访问“优化得更快”，而是把一个无法统一修改的客户端生态，重新放进一个可以由平台团队控制的边界里。

两跳结构改变的，不只是连接数量

ZGateway位于客户端应用和ZServer数据库舰队之间。客户端不再直接连接每个需要访问的数据库主机，而是通过粘性连接接入区域代理。代理终止TLS，根据用例ACL完成授权，执行租户级准入和流量整形，解析目标分片，再由内置的厚版ZippyDB客户端选择副本并转发请求。返回路径则把结果重新分发给对应客户端，同时记录用例级指标、追踪信息和配额使用情况。

这套设计的关键变化，是把后端看到的连接来源从“所有客户端”缩减为“由平台管理的代理节点”。不同客户端发往同一分片的请求可以在代理处合并和批处理，缓存层还可以在本地命中热读，并通过变更数据捕获事件维持有界陈旧度。代理因此不再只是网络转发器，而成为数据库流量的集中控制面。

按照Meta给出的模拟模型，包含20个区域、50万台数据库主机、3万台代理主机和100万客户端时，单主机连接数可下降约97%至98%，持久连接总量约减少19倍。这里真正重要的不是某个具体比例，而是扩展关系发生了改变：后端扇入主要由区域数量和代理上的分片密度决定，不再随客户端数量线性增加。

代理层开始承担数据库平台的职责

集中流量之后，许多原本必须散落在客户端库里的能力，才有了统一落点。ZGateway支持按服务和分片前缀逐步迁移，可以进行百分比放量、区域筛选，并保留全局关闭开关。对于过载保护，它使用Discriminant Load Shedding，将请求按租户和优先级划入独立桶，再以轮转方式消化，避免单个噪声租户占满所有共享资源。

Meta材料给出的受控过载测试中，系统在约1350个租户桶、CPU超过90%的条件下，只对6个噪声租户削减负载，其余请求仍有99.9%执行且没有被拒绝，goodput保持在约97%至98%。这套机制本身约消耗8%的CPU。这个结果说明集中治理可以隔离租户噪声，但也说明治理能力不是免费的：代理需要额外计算、内存和调度逻辑。

同样的集中位置还承载了异构机器的负载均衡、跨区域故障转移，以及事务编排。Meta称事务侧的客户端记录工作已迁入网关，并分九个阶段覆盖全部事务流量，且没有出现可靠性下降。ZGateway的“无状态”描述，不能理解为这一层没有运行时状态；缓存、批处理、事务协调和观测数据仍然会消耗资源，只是它们不再以每个客户端各自维护的方式存在。

这套架构的边界，恰好在它的数字之外

Meta称ZGateway目前处理超过每秒10亿次操作，承载约40%的ZippyDB流量，并预计超过60%，平均用例的计算开销约为6%。但这些数字不能直接被解读为ZGateway独立的峰值性能。现有材料同时把ZippyDB描述为能够服务每秒数十亿次操作，且没有给出统一口径下的延迟、代理规模或容量测试，因此“每秒超过十亿”更适合作为部署规模信号，而不是可横向比较的基准。

代理层还明确引入了新的代价。请求多经过一次网络跳转，缓存读需要接受由CDC和有界陈旧度定义的一致性边界，跨区域切换也需要验证路由、容量和故障域是否真的按预期工作。材料没有披露具体的缓存陈旧时间、p99延迟变化，或跨区域故障切换的验证细节，因此不能仅凭连接下降和吞吐数字，推断所有业务都能获得同样收益。

对技术负责人而言，ZGateway最值得借鉴的不是“在数据库前面加代理”这条表面做法，而是一个架构判断：当客户端数量、归属和升级节奏已经让分布式治理失效时，应把后端扇入、准入控制和故障隔离迁移到一个受控层。若系统规模较小、客户端可以统一升级，或者业务对最低延迟极端敏感，额外一跳可能不值得。反过来，如果连接数、文件描述符、重连风暴和租户噪声已经成为主要故障来源，那么首先应检查的不是代理能否达到“每秒十亿次”，而是能否让后端复杂度不再跟着客户端数量一起增长。