摘要
Solana 的吞吐量和账户模型对 RPC 基础设施造成了异常压力,因此那些超出共享端点承载能力的团队通常会转向专用节点。专用 Solana 节点为您自己的工作负载提供隔离的计算和带宽,而不是在共享池中与其他租户竞争。本文解释了如何评估提供专用 Solana 节点的提供商、在承诺之前需要测试什么,以及如何安全迁移。OnFinality 提供 Solana RPC API 访问和专用节点基础设施,您可以使用下面的检查清单与其他选项进行比较。
Solana RPC 不是通用的 EVM 端点。该链持续产生区块,账户状态不断变化,许多应用依赖 WebSocket 订阅而非一次性读取。这种组合意味着共享公共端点可以用于原型,但一旦您拥有真实用户、后台索引器或交易逻辑,它通常就不再适合。专用 Solana 节点改变了经济性:您为自己的流量获得隔离资源,而不是与其他租户共享池。
本文重点介绍如何评估提供专用 Solana 节点的提供商,而不是列出单一赢家。正确的提供商取决于您的工作负载形态、您对运维工作的容忍度,以及您需要对节点本身有多少控制权。
何时适合使用专用 Solana 节点
在比较提供商之前,先决定您是否真的需要专用节点。专用节点通常在以下一种或多种情况属实时是合理的:
- 您的应用发送高且可预测的请求量,而共享速率限制是瓶颈。
- 您依赖 WebSocket 订阅,如
accountSubscribe、logsSubscribe或programSubscribe,并且需要稳定的连接行为。 - 您运行索引器、回填作业或分析,扫描大量历史范围。
- 您需要在网络拥塞期间保持一致的行为,此时共享端点可能会限流或降级。
- 您想要一个不暴露于公共互联网且可以加入允许列表的私有端点。
如果您仍在验证想法、运行低流量 dApp,或仅偶尔读取账户余额,专用节点通常不是第一步。在这些情况下,托管的共享 RPC API 更便宜且更简单。OnFinality 提供两种模式,因此您可以从共享 RPC API 开始,当工作负载证明合理时再迁移到专用节点。
“专用”在不同提供商中的实际含义
“专用”一词使用得很宽泛。两个提供商可能都宣传专用 Solana 节点,但提供的东西却大不相同。询问实际隔离了什么:
| 层级 | 共享 RPC API | 专用节点 |
|---|---|---|
| 计算和内存 | 跨租户共享 | 为您的工作负载预留 |
| 请求吞吐量 | 池化限制 | 根据您的计划调整大小 |
| WebSocket 连接 | 共享网关 | 直接连接到您的节点 |
| 端点可见性 | 公共或带密钥的 URL | 私有,通常加入允许列表 |
| 节点版本控制 | 提供商管理 | 提供商管理,有时可配置 |
| 故障影响范围 | 影响所有租户 | 仅限于您的节点 |
真正专用的 Solana 节点应该为您提供自己的进程和自己的连接预算。如果提供商只给您一个仍然通过共享后端路由的私有 URL,那么您购买的是私有标签,而不是隔离。
Solana 专用节点的提供商评估矩阵
使用此矩阵在特别针对 Solana 重要的维度上比较提供商。按提供商填写,而不是依赖营销页面。
| 评估领域 | 需要验证的内容 | 为什么在 Solana 上重要 |
|---|---|---|
| 节点类型 | 全节点 vs 归档节点,以及历史状态是否可用 | 回填和分析需要更旧的 slot |
| 方法覆盖 | 支持 getProgramAccounts、getSignaturesForAddress、带完整编码的 getTransaction | 许多应用依赖这些进行索引 |
| WebSocket 支持 | accountSubscribe、logsSubscribe、programSubscribe、slotSubscribe | 没有稳定的订阅,实时功能会中断 |
| 传输 | HTTP 和 WebSocket 端点、TLS、私有网络选项 | 不同的客户端需要不同的传输 |
| 速率和连接限制 | 每秒请求数、并发连接数、订阅上限 | 决定计划是否适合您的流量 |
| 故障转移 | 是否可以运行第二个节点或端点以实现冗余 | 单点故障是生产风险 |
| 可观测性 | 向您公开的指标、日志和告警 | 无法看到就无法操作 |
| 支持模式 | 响应渠道和升级路径 | 节点问题需要快速的人工响应 |
| 迁移路径 | 端点变更如何推出 | 避免切换期间停机 |
OnFinality 在此处首先出现,因为它同时提供托管的 Solana RPC API 和专用节点基础设施,因此您可以在两种模式下评估同一供应商。将其他提供商与相同的行进行比较,而不是与功能列表进行比较。
需要测试的 Solana 特定方法和限制
Solana 的 JSON-RPC 接口很广泛,某些方法比其他方法昂贵得多。在您承诺使用提供商之前,测试您的应用实际使用的方法。一个最小的连接检查如下所示:
curl -s https://solana.api.onfinality.io/public \
-X POST -H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "getLatestBlockhash",
"params": [{"commitment": "confirmed"}]
}'
对于专用节点,针对您的私有端点重复相同的调用,然后测试更重的方法:
curl -s "$SOLANA_DEDICATED_ENDPOINT" \
-X POST -H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 2,
"method": "getSignaturesForAddress",
"params": ["<ACCOUNT_PUBKEY>", {"limit": 100}]
}'
注意提供商如何处理带过滤器的 getProgramAccounts,因为此方法可能很昂贵,并且通常与简单读取的速率限制不同。还要确认交易响应是否包含完整元数据或仅包含签名,因为索引器通常需要完整形式。
WebSocket 行为是许多提供商差异所在
实时 Solana 应用通常更依赖订阅而非 HTTP 调用。明确测试 WebSocket 行为:
import WebSocket from "ws";
const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");
ws.on("open", () => {
ws.send(JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "logsSubscribe",
params: [{ mentions: ["<PROGRAM_ID>"] }, { commitment: "confirmed" }]
}));
});
ws.on("message", (data) => {
const msg = JSON.parse(data.toString());
if (msg.method === "logsNotification") {
console.log("slot", msg.params.result.context.slot);
}
});
与任何提供商一起检查的事项:
- 连接在负载下是否保持打开,还是会断开并需要重连逻辑?
- 订阅限制是按连接还是按账户?
- 是否有文档化的重连和重放策略?
- 丢失的 slot 或间隙如何呈现给客户端?
如果提供商无法清楚地回答这些问题,请将其视为任何实时功能的风险。
切换前的迁移检查点
从共享端点迁移到专用 Solana 节点是配置更改,但会触及每个客户端。规划切换:
- 清点配置 RPC URL 的每个位置,包括前端钱包、后端服务、cron 作业和 CI。
- 将新端点与旧端点一起添加,以便在过渡期间两者都可访问。
- 运行影子期,让非关键服务从专用节点读取,并比较响应。
- 验证环境之间的 commitment 级别匹配,因为
processed、confirmed和finalized行为不同。 - 更新 WebSocket 客户端,并确认重连逻辑对新端点有效。
- 保留旧端点作为回退,直到您对新端点有信心。
基于环境的简单配置使这易于管理:
const SOLANA_RPC =
process.env.SOLANA_RPC_URL ?? "https://solana.api.onfinality.io/public";
const SOLANA_WS =
process.env.SOLANA_WS_URL ?? "wss://solana.api.onfinality.io/public-ws";
对于钱包或应用网络配置,保持链身份与 Solana mainnet 一致:原生货币 SOL 有 9 位小数,浏览器位于 https://explorer.solana.com。如果您先测试,请使用 Solana Devnet,并将 devnet 和 mainnet 配置分开。
成本和运维权衡
专用节点将成本从按请求定价转向预留容量。当您的流量稳定且高时,这通常有利;当流量突发或低时,则不太有利。考虑:
- 预留容量是可预测的,但即使在安静时期您也要付费。
- 共享 RPC API 在空闲时可缩减至零成本,适合早期项目。
- 运行自己的 Solana 节点提供最大控制权,但增加了大量运维工作:硬件、升级、监控和事件响应。
- 托管的专用节点介于这些极端之间:您获得隔离,而无需承担全部运维负担。
对于大多数团队,实际顺序是先共享 RPC API,然后在流量和可靠性要求明确后再使用专用节点。查看 RPC 定价 以比较模式,如果您还需要其他链,请查看支持的 RPC 网络。
上线后的运维检查清单
一旦专用节点开始服务生产流量,请保持以下措施:
- 监控请求延迟、错误率和 WebSocket 连接数。
- 对 slot 滞后设置告警,以便在节点落后于集群时注意到。
- 跟踪订阅流失,以捕捉过于频繁重连的客户端。
- 保留文档化的回退端点并定期测试。
- 与您的提供商审查节点版本和升级窗口。
一个轻量级监控探针可以及早发现回归:
#!/usr/bin/env bash
set -euo pipefail
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" "$SOLANA_DEDICATED_ENDPOINT" \
-X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}')
echo "solana rpc http status: $RESPONSE"
关键要点
- 专用 Solana 节点由稳定的高流量、WebSocket 依赖、索引工作负载或对私有端点的需求证明合理。
- “专用”因提供商而异;在比较价格之前,验证实际隔离了什么。
- 测试 Solana 特定方法,如
getProgramAccounts和getSignaturesForAddress,而不仅仅是简单读取。 - WebSocket 订阅行为通常是实时应用的决定性因素。
- 通过影子期和回退端点规划迁移,而不是硬切换。
- OnFinality 同时提供 Solana RPC API 和专用节点基础设施,因此您可以将模式与工作负载匹配。
常见问题
小型 dApp 需要专用 Solana 节点吗?
通常不需要。托管的共享 RPC API 是更好的起点,直到流量、WebSocket 使用或可靠性要求证明预留容量合理。
专用节点和私有 RPC 端点有什么区别?
私有端点仍可能通过共享后端基础设施路由。专用节点为您的工作负载提供自己的计算和连接预算,这才是真正减少争用的原因。
在选择提供商之前,我应该对哪些 Solana 方法进行基准测试?
测试您的应用依赖的方法,尤其是 getProgramAccounts、getSignaturesForAddress、getTransaction 以及实时功能使用的任何订阅方法。
我可以对 HTTP 和 WebSocket 使用同一个端点吗?
不可以。Solana 使用单独的 HTTP 和 WebSocket URL。OnFinality 公开两者,您应该在客户端中明确配置每种传输。
迁移到专用节点时如何避免停机?
将新端点与旧端点一起运行,从非关键服务影子流量,验证 commitment 级别和 WebSocket 行为,然后在回退仍然到位的情况下切换。
在哪里可以看到 OnFinality 支持哪些网络?
查看支持的 RPC 网络获取当前列表,查看 RPC 定价了解计划详情。