Meta推出ZGateway这一无状态代理层，针对ZippyDB在超过100万客户端带来的连接与可靠性挑战进行优化。该网关每秒处理超10亿次操作，承担约40%流量，依托预估架构可将持久连接总数降至1/19。ZippyDB可支撑产品元数据、计数器及各类工作负载的分布式处理。为解决多对多密集连接问题，ZGateway部署托管代理层，通过ServiceRouter实现客户端与网关的粘性连接，使客户端始终贴近网关。该架构以现有C++客户端为引擎，兼顾代理与读透缓存功能，从整体降低连接与持久连接复杂度。连接池、服务网格等已有场景均采用类似代理模式，但各有不同优化方向。相较于ZippyDB原生托管功能，ZGateway额外添加流量管理，虽增加网络跳数，但可消除数据库节点连接开销，显著提升整体延迟。在测试场景中，6个租户因CPU超限被分流，其余99.9%请求正常处理，无拒绝情况。Meta计划全面路由ZippyDB流量，探索代理控制机制、ZServer共置与多进程架构，进一步提升系统稳定性与扩展性。
--91likeyou---
连接池、服务网格、CDN 和 API 网关也使用该代理模式，不过它们的职责和可扩展性权衡各不相同。Meta 之前对 ZippyDB 的描述表明，数据库本身已经提供了托管分片、复制、故障检测和容量管理功能，而 ZGateway 则在这些功能之前添加了一个共享的流量管理层。
额外增加的网络跳数是有意做出的权衡。在 LinkedIn 的一篇博文中，Sherbrook 架构师 Md Shuvo 特别强调了这一点：
实际上，额外增加一个网络跳数能改善整体延迟，因为这可以使数据库节点免于承受连接管理带来的巨大开销。
ZGateway 还为负载均衡、跨区域容错、缓存和过载保护提供了集中管理平台。在 CPU 利用率超过 90% 的受控测试中，约 1350 个租户存储桶中有 6 个将流量分流，而其余租户处理了 99.9% 的请求且未出现任何拒绝处理的情况。Meta 可以按服务、分片前缀、百分比或区域逐步路由流量，并配备了用于回滚的全球紧急关闭开关。
Meta 计划将所有 ZippyDB 流量通过 ZGateway 进行路由，同时探索基于代理的控制机制、与 ZServer 的选择性共置，以及采用多进程架构来实现更强的故障隔离。
：
🔥 热词：#Meta · #ZippyDB · #ZGateway · #10 · #在每秒处理超过 · #亿次操作的同时 · #的连接数减少了 · #19