每秒超过10亿次操作，同时把持久连接总数压到原来的约1/19。Meta 给自家分布式键值存储 ZippyDB 加了一层无状态代理 ZGateway，交出的就是这份成绩单。
这套网关目前承担了 ZippyDB 约40%的流量。按照 Meta 的模型估算，每个主机的连接数会减少约97%至98%。一个每秒十亿级操作的存储系统，靠一层代理把连接网格拆开了。
问题出在"多对多"
ZippyDB 支撑着 Meta 全球分布式基础设施上的产品元数据、计数器、配置等工作负载。在直接访问模型下，客户端会连到提供所需分片的数据库主机上。
麻烦在于规模：单个客户端可能访问分布在数十万台数据库主机上的数万个分片。超过100万个客户端主机，就这样织成了一张密集的"多对多"连接网格。
Meta 表示，连接风暴可能导致文件描述符耗尽和内存不足。这不是性能调优能绕过去的问题，是连接模型本身撑不住了。
代理层怎么拆掉这张网
ZGateway 部署在客户端与 ZippyDB 服务器之间，充当托管代理层。客户端与区域网关主机之间保持粘性连接，数据库服务器则从受控的网关集群接收连接。
它作为区域层运行，通过 Meta 的超大规模服务网格解决方案 ServiceRouter 被发现，客户端因此始终位于自己的网关附近。请求引擎复用的是 Meta 现有的 C++ ZippyDB 客户端，同时支持纯代理和读透式缓存层两种模式。
流量管理的位置也随之改变。ZGateway 可以对请求做身份验证和授权，应用基于租户的准入控制，解析分片，使用本地缓存，并在转发至 ZServer 副本之前对请求进行批处理或合并。
一个细节值得注意：网关能看到来自多个客户端的流量，因此可以把单个客户端库在不同进程间无法观察到的请求合并起来。这种合并，客户端自己做不到。
多一跳，反而更快
连接池、服务网格、CDN 和 API 网关都使用类似的代理模式，只是职责和可扩展性权衡各不相同。Meta 此前对 ZippyDB 的描述显示，数据库本身已提供托管分片、复制、故障检测和容量管理，ZGateway 是在这些能力之前加了一层共享的流量管理。
额外增加的网络跳数是有意做出的权衡。Sherbrook 架构师 Md Shuvo 在一篇博文中特别强调了这一点：
"实际上，额外增加一个网络跳数能改善整体延迟，因为这可以使数据库节点免于承受连接管理带来的巨大开销。"
ZGateway 还为负载均衡、跨区域容错、缓存和过载保护提供了集中管理平台。在 CPU 利用率超过90%的受控测试中，约1350个租户存储桶里有6个将流量分流，其余租户处理了99.9%的请求，未出现任何拒绝处理的情况。
Meta 可以按服务、分片前缀、百分比或区域逐步路由流量，并配备了用于回滚的全球紧急关闭开关。
下一步，Meta 计划将所有 ZippyDB 流量通过 ZGateway 路由，同时探索基于代理的控制机制、与 ZServer 的选择性共置，以及采用多进程架构来实现更强的故障隔离。
热门跟贴