我们如何构建低延迟 RPC 基础设施

钱包加载用户余额。交易应用在兑换前估算 gas。索引器在一次操作中回填数月的历史数据。以上每一个动作都是一次 RPC 调用,而每一毫秒的延迟都会被屏幕前的真实用户感知到。

RPC 延迟不是由单一因素造成的,因此也不能靠单一手段解决。它来自请求路径开销、可避免的内部网络往返、低效路由、突发流量峰值、链和节点的运维滞后、特定工作负载的瓶颈,以及测量不完整。解决其中一个而忽略其余的,只是把瓶颈转移了位置。因此我们把延迟当作一个系统性问题来处理,在我们所掌控的每一层都进行了投入,在我们支持的 100 多条链上,将 99.99% 的正常运行时间和低于 50ms 的平均响应时间作为基准线。

我们构建了什么

Alchemy Edge Proxy 降低请求路径开销

边缘节点是入口:它是请求触达的第一个由 Alchemy 掌控的入口点。在请求到达任何节点之前,它要经过连接建立、TLS 协商、身份验证和路由逻辑。每一步都会增加若干毫秒,而这些毫秒在尾部——也就是最慢的那些请求,用户真正能感知到的那些请求——累积得最多。

Alchemy Edge Proxy 是我们构建的一层,用来把这些开销从请求路径中剥离出来。通过在入口处而非更深的层级处理连接复用、认证和路由决策,它降低了每个请求都要付出的固定成本。结果是尾部 RPC 最高提速 7.5 倍。更深入的介绍请参见 Alchemy Edge Proxy。

在底层,边缘节点运行在微内核代理架构上,它是 Cortex 的一部分:一个小而稳定的核心负责关键请求路径,而身份验证、限流、路由等模块则可以独立更新。由于边缘节点是我们端到端掌控的关键基础设施层之一,我们可以持续改进它,而无需等待任何第三方网络。

基础设施内部:更近的部署、更智能的路由、稳定的吞吐

一旦请求进入我们的基础设施内部,距离和硬件仍然会消耗时间。如果处理一次调用的各个服务分布得较远,请求就要在它们之间花费若干毫秒进行传输,而这时还没有开始任何实际工作。而当流量攀升时,共享硬件会带来那种表现为延迟不稳定的变化性。

这正是 Cortex(Alchemy 的智能区块链引擎)承担大部分工作的地方。Cortex 是支撑我们低延迟数字的核心基础设施投入,其中有几个具体部分在这里尤为关键:

• 借助 Kubernetes 亲和性实现的 Pod 就近部署,让彼此通信最频繁的服务运行在同一台机器上,使请求保持本地化,而不是跨机架跳转。
• Istio 的位置感知路由把内部流量发送到最近可用的服务实例,在确实有帮助的情况下缩短基础设施路径。
• 数千台全球部署的裸金属服务器直接运行在专用硬件上,没有虚拟化开销,因此在高负载下吞吐量依然保持稳定。
• Java 虚拟线程让单台机器能够处理远多于传统线程所能承受的并发请求,而不产生传统线程那样的内存和 CPU 开销,这正是吸收流量激增而不让延迟攀升的关键。

这些手段合在一起,削减了用户从不会察觉、但始终能感受到的传输时间,并在流量上升时保持性能稳定。

预测性扩容在流量峰值到来前准备好容量

链上流量的增长从不会有礼貌的节奏。一次发布、一次铸造或一次市场事件都可能在几秒内让负载成倍增长,而在峰值之后才到位的容量,就是来得太晚的容量。

我们的预测性扩容逻辑会在需求出现之前就准备好容量,而不是被动应对——它持续监测 CPU、内存、磁盘 I/O 和流量模式等信号,在峰值到来之前完成资源配置。Usual 就是证明:他们的峰值达到每秒 30,000 个请求,在第一个小时内处理了 3800 万个请求,并在 36 小时内突破了 10 亿个请求,而延迟在这场流量激增中并未失控。

"Alchemy 为我们提供了近乎完美的可用性,在每秒处理海量请求(我们的峰值是每秒 30k 个请求,而且依然留有余量)的情况下,没有出现任何卡顿或宕机。而且这一切都是在很短的通知时间内完成的!"

Adli Takkal-Bataille,来自 Usual

AI 管理的节点集群自动化让节点运维保持最新

区块链在你脚下不断变化。客户端发布更新,网络安排硬分叉,而一个运行过时软件的节点,就是一个给出缓慢或错误答案的节点。手动处理这些事情,恰恰会在最需要精确的时刻引入延迟和风险。

我们的节点集群由一个全自动的智能体系统管理,负责处理升级、测试和监控。更新会被实时检测并应用,自动化测试也被内置在流程中,因此强制性的网络升级和硬分叉不会被遗漏。在我们运行的每一条链上手动完成这些工作是不可能保持最新的——这正是我们将其自动化的原因,也是我们能在 100 多条链上保持同样低延迟标准、而不只是对少数几条"重点链"如此的原因。这项自动化是 Cortex 的一部分——Cortex 是支撑 Alchemy 平台的智能区块链引擎,涵盖 RPC API、数据 API、rollup 以及开发者技术栈的其余部分。

针对具体产品的优化改善了完整的用户流程

延迟不仅仅关乎单次调用。真实的产品会把多次调用串联起来,而整条流程的速度取决于其中最慢的一环。用户真正感受到的是整条路径,而不是任何单一方法。

由 Tools for Humanity 构建、运行在 World Chain 上的 World,挖矿耗时提速 44%,从 5.5 秒降至 3.1 秒,alchemy_requestGasAndPaymasterAndData 的 gas 估算延迟降低了 74%,从约 380ms 降至 100ms。

"在寻找基础设施供应商时,我们最看重的是企业级规模和支持。在我们需要的每一个产品上,Alchemy 都是毫无疑问的领先者——是唯一合乎逻辑的选择。"

Steven,来自 Tools For Humanity

Solana 归档基础设施降低了重查询的延迟

历史和归档查询本身就是一类难题。拉取大范围的历史状态是繁重的工作,而在 Solana 这样高吞吐量的链上,如果没有专门为此构建的基础设施,查询速度会变得很慢。我们基于自研的多区域 HBase 架构,构建了 Solana 上最快的归档方法,它是我们 Solana 平台的一部分。

Solflare 运行了正是这种工作负载,结果归档查询最高提速 20 倍,在大型历史查询期间响应时间低于 200ms,钱包回填在一分钟以内完成。

"Alchemy 的 Archival RPC 跟上了 Solflare 的吞吐量,同时保持了持续低于 <200ms 的响应时间。"

Dusan K.,来自 Solflare

基准测试方法同时衡量速度与可靠性

如果不诚实地说明每一个请求的实际情况,速度数字就毫无意义。一个掩盖了失败或丢弃调用的漂亮平均值算不上快,那只是误导。

我们的基准测试方法将延迟与成功率、失败请求一并测量,使这些数字反映真实工作负载会经历的情况。这是我们对自己设定的标准,也是我们邀请你用来检验我们的标准。你可以查阅完整的基准测试方法。

目标:让基础设施快到让人感觉不到它的存在

最好的基础设施是那种没人会注意到的。当延迟足够低、可靠性足够高时,钱包就是能加载出来,兑换就是能确认,回填就是能完成。这套体系中没有哪一层能单独解决延迟问题,但把它们加在一起,就构成了这种体验。

亲自查看这些数字。在 Alchemy 基准测试页面上比较各家供应商,并阅读我们如何进行 RPC 性能基准测试,以便你判断方法本身,而不只是结果。当你准备好在此基础上构建时,免费开始使用。

常见问题

是什么导致了 RPC 延迟?

RPC 延迟来自若干个相互独立的来源:入口处的请求路径开销、内部服务之间可避免的传输、低效路由、流量峰值、链和节点的运维滞后、特定工作负载的瓶颈,以及测量不完整。由于这些原因彼此独立,没有任何单一的修复手段能够全部消除它们。

单一的优化手段能解决 RPC 延迟吗?

不能。解决单一原因只会把瓶颈转移到下一个环节。要可靠地降低延迟,需要在请求路径的每一层都进行投入,从边缘节点到节点基础设施,再到性能的测量方式。

RPC 基础设施中的"边缘"是什么?

边缘是请求到达的第一个由供应商掌控的入口点,是 RPC 流量的入口。在这里而非更深的层级处理连接建立、身份验证和路由,能够消除每个请求原本都要承担的固定开销。

Alchemy 如何诚实地测量 RPC 延迟?

Alchemy 将延迟与成功率、失败请求一并测量,而不是把延迟当作孤立的平均值。这样可以防止一个看起来很快的数字掩盖了被丢弃或失败的调用,使结果真实反映实际生产工作负载会经历的情况。

预测性扩容如何应对流量峰值?

预测性扩容会在需求出现之前准备好容量,而不是在峰值开始后再做出反应。正是这一点让 Usual 能够在 36 小时内维持每秒 30,000 个请求、总计超过 10 亿个请求,而延迟在流量激增期间没有恶化。

为什么 Solana 的归档查询性能是一个单独的问题?

归档查询要拉取大范围的历史状态,这本身就是繁重的工作,而 Solana 的高吞吐量又让这些范围变得更大。专门构建的归档基础设施正是让这些查询保持快速的关键,Solflare 归档查询最高提速 20 倍就是例证。