Node RPC 与 Dedicated Clusters：为你的工作负载选择合适的基础设施

大多数链上工作负载在多租户基础设施上运行良好。但随着团队规模扩大，一些问题会随之出现：我们需要专用节点吗？是否应该隔离某些工作负载？实际的权衡取舍是什么？

本指南将说明 Alchemy 的两种基础设施模式——Node RPC（我们的共享基础设施方案）和 Dedicated Clusters——分别如何运作、各自适用于哪些场景，以及团队应如何思考这一决策。

Node RPC：适用于大多数工作负载的默认选择

Node RPC 是 Alchemy 面向生产环境的多租户基础设施，针对弹性伸缩和运维简便性做了优化。它由 Cortex 驱动——同一引擎每年支撑着包括 Robinhood、Stripe、Coinbase、Circle、Chainlink 和 Polymarket 在内的团队完成超过 1 万亿美元的年交易量。

在 Node RPC 上，扩容近乎即时完成。流量突增会由节点集群自动吸收。故障转移内置于多个区域之间。定价按用量计费，因此成本随实际流量变化，而非按预置容量计费。

关于各服务商当前共享 RPC 性能的对比，参见 Alchemy 的 RPC provider benchmarks。

Dedicated Clusters：高度可定制，全托管

Dedicated Clusters 提供由 Alchemy 部署、运维和维护、但按你的确切需求配置的专属节点基础设施。与单节点式专用方案不同，每个 cluster 会为每条链配置一组冗余节点，运行在 Cortex 之上——与 Node RPC 相同的引擎。你将获得相同的 API 和可靠性保证，但处于单租户环境中。

每个 cluster 都以零停机为目标构建。每个区域每条链两个或更多节点，使滚动维护得以在不中断服务的情况下进行。区块级一致性确保每个节点返回相同的链状态视图，消除了因读取到过期或冲突数据而产生的错误。实时 Grafana 仪表盘则让你全面掌握节点健康状况、请求模式和性能表现。

随着流量增长，我们会同步扩展你的 cluster——我们的自动化快照与部署能力能比业内任何团队更快地让新容量上线。对于超出合约容量的意外流量高峰，你可以选择启用自动回退至 Alchemy 的共享节点集群——不会丢失请求，也无需人工干预。

每个 cluster 都会按你的确切需求配置：

• 自定义 tracer 和二进制文件，直接部署在你的节点上，实现更快、更经济的模拟、追踪和索引
• 单租户隔离——符合 SOC 2 Type II 合规标准，你的环境中不存在任何其他客户的流量、代码或数据
• 区域化部署，可就近部署在靠近你的技术栈、链基础设施或用户的位置，实现低延迟
• 自定义硬件配置，根据你的流量特点调优以获得最佳性能
• 固定月度定价——不按请求计费，没有意外账单

何时应选择 Dedicated Clusters

Node RPC 能很好地应对绝大多数工作负载。Dedicated Clusters 专为那些多租户基础设施无法满足其特定需求的团队而设计。以下是四种常见场景。

自定义 tracer 或二进制文件。 依赖非标准节点软件（自定义 EVM tracer、客户端或二进制文件）的工作负载，需要能够向节点推送自定义代码。Dedicated Clusters 原生支持这一点，因此非常适合依赖自定义 tracer 进行索引和事件处理的安全与取证团队。

监管或内部隔离要求。 某些合规框架和内部安全策略要求环境中不得存在任何其他客户的流量、代码或数据。Dedicated Clusters 提供具备可审计控制的单租户隔离，并符合 SOC 2 Type II 合规标准——这是受监管金融机构的标准要求。

区域化部署要求。 Node RPC 本身已经覆盖了广泛区域，提供低延迟服务。但如果你的工作负载需要部署在该覆盖范围之外的特定地理位置——与你的技术栈、排序器（sequencer）或验证者节点部署在同一地点——Dedicated Clusters 可以部署在你所需的确切区域。这对交易公司、DeFi 协议以及每一毫秒都至关重要的高频交易业务尤其重要。

容量定价更具成本效益的高流量工作负载。 对于吞吐量非常高的多链工作负载，基于预置容量的固定月度成本可能比按请求计费更具可预测性。

如果以上需求均不适用于你，Node RPC 同样能提供业内最佳的性能和可靠性，且无需额外配置。

为什么不自建节点？

我们接触过的许多团队都曾考虑过——或正在维护——自己的节点基础设施。这类经历往往遵循相似的轨迹：先是在招聘、工具建设和监控方面投入大量资源，随后是来自客户端升级、网络变更以及每条支持链的值班轮换所带来的持续运维负担。关于这一权衡的更深入探讨，参见我们关于自建节点利弊的概述。

这种风险会随时间累积。一次未能及时完成的升级会导致节点落后，请求开始失败，面向用户的交易随之中断——用户无法完成交易，不满情绪累积，每一分钟的停机都意味着收入和信任的流失。此外，本可用于产品开发的工程资源，反而被用于维护无法为业务带来差异化优势的基础设施。

这正是 Dedicated Clusters 旨在解决的问题。Alchemy 端到端负责部署、升级、监控和事件响应。

混合方案

需要 Dedicated Clusters 处理某些工作负载的团队，通常并不需要将其应用于全部工作负载。最常见的生产环境配置是混合模式：将需要单租户控制的链或工作负载放在 Dedicated Clusters 上，其余部分使用 Node RPC。

两者之间的迁移十分简单。两者使用相同的 Alchemy API——将工作负载路由到 Dedicated，只需将请求指向不同的端点 URL 即可，无需修改代码，也无需重新架构。

这种方案让团队能够在关键之处获得单租户控制，同时对其余流量保留 Node RPC 的弹性和成本效益。

对比

如何决策

这一决策可归结为四个问题。你的工作负载是否需要自定义 tracer 或二进制文件？你是否有监管或政策上对单租户隔离的强制要求？你是否需要部署在 Node RPC 目前尚未覆盖的区域？对你的流量规模而言，按容量计费是否更具成本效益？

如果以上任一问题的答案是肯定的，那么 Dedicated Clusters 或混合方案值得评估。如果所有问题的答案都是否定的，Node RPC 就是合适的选择。

无论哪种情况，前进路径都是灵活的。团队可以先从 Node RPC 起步，之后再将特定工作负载迁移到 Dedicated，而不会影响现有基础设施。

常见问题

什么是 Alchemy Node RPC？

Node RPC 是 Alchemy 由 Cortex 驱动的多租户基础设施。它针对弹性伸缩和运维简便性做了优化：扩容近乎即时完成，故障转移内置于多个区域之间，定价按用量计费。

什么是 Alchemy Dedicated Clusters？

Dedicated Clusters 为你提供由 Alchemy 全托管、但按你的确切需求配置的专属节点基础设施。它们运行在单租户环境中，支持自定义 tracer、区域化部署、自定义硬件以及固定月度定价。

Node RPC 和 Dedicated Clusters 的主要区别是什么？

Node RPC 是按用量计费的共享基础设施，适用于大多数工作负载。Dedicated Clusters 提供带有自定义配置的单租户隔离，适合有特定合规、性能或定制化控制需求的团队。

我应该在什么情况下选择 Dedicated Clusters 而非 Node RPC？

如果你需要自定义 tracer 或二进制文件、有监管或内部隔离要求、需要在特定区域部署，或运行按容量计费更具效率的高流量工作负载，Dedicated Clusters 会是合适的选择。

我可以同时使用 Node RPC 和 Dedicated Clusters 吗？

可以。常见的生产环境配置是混合模式：将需要单租户控制的工作负载放在 Dedicated Clusters 上，其余使用 Node RPC。迁移只需更改端点 URL，无需修改代码。

Dedicated Clusters 是否比 Node RPC 更难维护？

不会。两者都由 Alchemy 全权托管。部署、升级、监控和事件响应均由我们端到端处理。你无需承担任何维护工作。

Node RPC 和 Dedicated Clusters 是否支持相同的 API？

是的。两者都运行在相同的 Alchemy API 之上，因此在两者之间路由工作负载无需修改代码或重新架构。

为什么不自建节点，而要使用 Alchemy？

自建节点意味着在招聘、工具建设方面的大量投入，以及持续的运维负担：客户端升级、网络变更、覆盖每条支持链的值班轮换。Alchemy 为你处理这一切，让你的工程团队能够专注于产品开发，而非基础设施维护。

开始使用

超过 70% 的顶级链上应用运行在 Alchemy 之上。如果你正在评估基础设施选项——无论是整合服务商、替换自建方案，还是为规模扩张做准备——欢迎联系我们的团队，为你的工作负载找到合适的配置方案。