--- title: "我们如何构建低延迟 RPC 基础设施" description: "RPC 延迟是一个系统性问题，而非单一瓶颈。以下是 Alchemy 在边缘、路由、扩展、节点运维和测量方面降低延迟的方法。" --- # 我们如何构建低延迟 RPC 基础设施 钱包加载用户余额。交易应用在兑换前估算 gas。索引器在一次操作中回填数月的历史数据。以上每一个动作都是一次 RPC 调用,而每一毫秒的延迟都会被屏幕前的真实用户感知到。 RPC 延迟不是由单一因素造成的,因此也不能靠单一手段解决。它来自请求路径开销、可避免的内部网络往返、低效路由、突发流量峰值、链和节点的运维滞后、特定工作负载的瓶颈,以及测量不完整。解决其中一个而忽略其余的,只是把瓶颈转移了位置。因此我们把延迟当作一个系统性问题来处理,在我们所掌控的每一层都进行了投入,在我们支持的 100 多条链上,将 99.99% 的正常运行时间和低于 50ms 的平均响应时间作为基准线。 ## 我们构建了什么 Alchemy Edge Proxy', tooltip: "", icon: "", }, benefit: { title: "尾部响应最高提速 7.5 倍", tooltip: "", icon: "", }, id: 0, }, { cause: { title: "可避免的内部网络往返", tooltip: "", icon: "", }, built: { title: '集群内更近的服务部署', tooltip: "", icon: "", }, benefit: { title: "在我们的基础设施内部损耗的时间更少", tooltip: "", icon: "", }, id: 1, }, { cause: { title: "低效路由", tooltip: "", icon: "" }, built: { title: '上下文感知的智能路由', tooltip: "", icon: "", }, benefit: { title: "基础设施路径更短,查询最高提速 2.5 倍", tooltip: "", icon: "", }, id: 2, }, { cause: { title: "流量峰值", tooltip: "", icon: "" }, built: { title: '预测性扩容', tooltip: "", icon: "", }, benefit: { title: "在流量激增前就准备好容量(常态:30K RPS)", tooltip: "", icon: "", }, id: 3, }, { cause: { title: "高负载下吞吐量的可预测性", tooltip: "", icon: "" }, built: { title: '专门构建的弹性吞吐能力', tooltip: "", icon: "", }, benefit: { title: "流量攀升时性能依然稳定", tooltip: "", icon: "", }, id: 4, }, { cause: { title: "链和节点的运维滞后", tooltip: "", icon: "", }, built: { title: 'AI 管理的节点集群', tooltip: "", icon: "", }, benefit: { title: "升级被检测、测试并以更短延迟完成部署", tooltip: "", icon: "", }, id: 5, }, { cause: { title: "特定工作负载的瓶颈", tooltip: "", icon: "", }, built: { title: '针对具体产品的优化', tooltip: "", icon: "", }, benefit: { title: "完整的产品流程(World:挖矿提速 44%)和重查询(Solflare:归档查询最高提速 20 倍)都能保持快速", tooltip: "", icon: "", }, id: 6, }, { cause: { title: "测量不完整", tooltip: "", icon: "" }, built: { title: '基准测试方法', tooltip: "", icon: "", }, benefit: { title: "延迟与成功率、失败请求一并测量", tooltip: "", icon: "", }, id: 7, }, ], }} /> ## Alchemy Edge Proxy 降低请求路径开销 边缘节点是入口:它是请求触达的第一个由 Alchemy 掌控的入口点。在请求到达任何节点之前,它要经过连接建立、TLS 协商、身份验证和路由逻辑。每一步都会增加若干毫秒,而这些毫秒在尾部——也就是最慢的那些请求,用户真正能感知到的那些请求——累积得最多。 Alchemy Edge Proxy 是我们构建的一层,用来把这些开销从请求路径中剥离出来。通过在入口处而非更深的层级处理连接复用、认证和路由决策,它降低了每个请求都要付出的固定成本。结果是尾部 RPC 最高提速 7.5 倍。更深入的介绍请参见 [Alchemy Edge Proxy](/blog/alchemy-edge-proxy)。 在底层,边缘节点运行在微内核代理架构上,它是 [Cortex](/cortex) 的一部分:一个小而稳定的核心负责关键请求路径,而身份验证、限流、路由等模块则可以独立更新。由于边缘节点是我们端到端掌控的关键基础设施层之一,我们可以持续改进它,而无需等待任何第三方网络。 ## 基础设施内部:更近的部署、更智能的路由、稳定的吞吐 一旦请求进入我们的基础设施内部,距离和硬件仍然会消耗时间。如果处理一次调用的各个服务分布得较远,请求就要在它们之间花费若干毫秒进行传输,而这时还没有开始任何实际工作。而当流量攀升时,共享硬件会带来那种表现为延迟不稳定的变化性。 这正是 [Cortex](/cortex)(Alchemy 的智能区块链引擎)承担大部分工作的地方。Cortex 是支撑我们低延迟数字的核心基础设施投入,其中有几个具体部分在这里尤为关键: - 借助 Kubernetes 亲和性实现的 Pod 就近部署,让彼此通信最频繁的服务运行在同一台机器上,使请求保持本地化,而不是跨机架跳转。 - Istio 的位置感知路由把内部流量发送到最近可用的服务实例,在确实有帮助的情况下缩短基础设施路径。 - 数千台全球部署的裸金属服务器直接运行在专用硬件上,没有虚拟化开销,因此在高负载下吞吐量依然保持稳定。 - Java 虚拟线程让单台机器能够处理远多于传统线程所能承受的并发请求,而不产生传统线程那样的内存和 CPU 开销,这正是吸收流量激增而不让延迟攀升的关键。 这些手段合在一起,削减了用户从不会察觉、但始终能感受到的传输时间,并在流量上升时保持性能稳定。 ## 预测性扩容在流量峰值到来前准备好容量 链上流量的增长从不会有礼貌的节奏。一次发布、一次铸造或一次市场事件都可能在几秒内让负载成倍增长,而在峰值之后才到位的容量,就是来得太晚的容量。 我们的预测性扩容逻辑会在需求出现之前就准备好容量,而不是被动应对——它持续监测 CPU、内存、磁盘 I/O 和流量模式等信号,在峰值到来之前完成资源配置。Usual 就是证明:他们的峰值达到每秒 30,000 个请求,在第一个小时内处理了 3800 万个请求,并在 36 小时内突破了 10 亿个请求,而延迟在这场流量激增中并未失控。 > "Alchemy 为我们提供了近乎完美的可用性,在每秒处理海量请求(我们的峰值是每秒 30k 个请求,而且依然留有余量)的情况下,没有出现任何卡顿或宕机。而且这一切都是在很短的通知时间内完成的!" > > Adli Takkal-Bataille,来自 [Usual](/case-studies/scaling-to-30000-requests-per-second) ## AI 管理的节点集群自动化让节点运维保持最新 区块链在你脚下不断变化。客户端发布更新,网络安排硬分叉,而一个运行过时软件的节点,就是一个给出缓慢或错误答案的节点。手动处理这些事情,恰恰会在最需要精确的时刻引入延迟和风险。 我们的节点集群由一个全自动的智能体系统管理,负责处理升级、测试和监控。更新会被实时检测并应用,自动化测试也被内置在流程中,因此强制性的网络升级和硬分叉不会被遗漏。在我们运行的每一条链上手动完成这些工作是不可能保持最新的——这正是我们将其自动化的原因,也是我们能在 100 多条链上保持同样低延迟标准、而不只是对少数几条"重点链"如此的原因。这项自动化是 [Cortex](/cortex) 的一部分——Cortex 是支撑 Alchemy 平台的智能区块链引擎,涵盖 [RPC API](/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](/case-studies/world-onchain-performance) ## Solana 归档基础设施降低了重查询的延迟 历史和归档查询本身就是一类难题。拉取大范围的历史状态是繁重的工作,而在 Solana 这样高吞吐量的链上,如果没有专门为此构建的基础设施,查询速度会变得很慢。我们基于自研的多区域 HBase 架构,构建了 Solana 上最快的归档方法,它是我们 Solana 平台的一部分。 Solflare 运行了正是这种工作负载,结果归档查询最高提速 20 倍,在大型历史查询期间响应时间低于 200ms,钱包回填在一分钟以内完成。 > "Alchemy 的 Archival RPC 跟上了 Solflare 的吞吐量,同时保持了持续低于 <200ms 的响应时间。" > > Dusan K.,来自 [Solflare](/case-studies/solflare) ## 基准测试方法同时衡量速度与可靠性 如果不诚实地说明每一个请求的实际情况,速度数字就毫无意义。一个掩盖了失败或丢弃调用的漂亮平均值算不上快,那只是误导。 我们的基准测试方法将延迟与成功率、失败请求一并测量,使这些数字反映真实工作负载会经历的情况。这是我们对自己设定的标准,也是我们邀请你用来检验我们的标准。你可以查阅完整的[基准测试方法](/blog/how-we-benchmark-rpc-performance)。 ## 目标:让基础设施快到让人感觉不到它的存在 最好的基础设施是那种没人会注意到的。当延迟足够低、可靠性足够高时,钱包就是能加载出来,兑换就是能确认,回填就是能完成。这套体系中没有哪一层能单独解决延迟问题,但把它们加在一起,就构成了这种体验。 亲自查看这些数字。在 [Alchemy 基准测试页面](/benchmarks)上比较各家供应商,并阅读[我们如何进行 RPC 性能基准测试](/blog/how-we-benchmark-rpc-performance),以便你判断方法本身,而不只是结果。当你准备好在此基础上构建时,[免费开始使用](https://dashboard.alchemy.com/signup/)。 ## 常见问题 **是什么导致了 RPC 延迟?** RPC 延迟来自若干个相互独立的来源:入口处的请求路径开销、内部服务之间可避免的传输、低效路由、流量峰值、链和节点的运维滞后、特定工作负载的瓶颈,以及测量不完整。由于这些原因彼此独立,没有任何单一的修复手段能够全部消除它们。 **单一的优化手段能解决 RPC 延迟吗?** 不能。解决单一原因只会把瓶颈转移到下一个环节。要可靠地降低延迟,需要在请求路径的每一层都进行投入,从边缘节点到节点基础设施,再到性能的测量方式。 **RPC 基础设施中的"边缘"是什么?** 边缘是请求到达的第一个由供应商掌控的入口点,是 RPC 流量的入口。在这里而非更深的层级处理连接建立、身份验证和路由,能够消除每个请求原本都要承担的固定开销。 **Alchemy 如何诚实地测量 RPC 延迟?** Alchemy 将延迟与成功率、失败请求一并测量,而不是把延迟当作孤立的平均值。这样可以防止一个看起来很快的数字掩盖了被丢弃或失败的调用,使结果真实反映实际生产工作负载会经历的情况。 **预测性扩容如何应对流量峰值?** 预测性扩容会在需求出现之前准备好容量,而不是在峰值开始后再做出反应。正是这一点让 Usual 能够在 36 小时内维持每秒 30,000 个请求、总计超过 10 亿个请求,而延迟在流量激增期间没有恶化。 **为什么 Solana 的归档查询性能是一个单独的问题?** 归档查询要拉取大范围的历史状态,这本身就是繁重的工作,而 Solana 的高吞吐量又让这些范围变得更大。专门构建的归档基础设施正是让这些查询保持快速的关键,Solflare 归档查询最高提速 20 倍就是例证。