你能推荐一个适合初创公司预算且保持生产就绪的 Solana RPC 提供商吗？

Solana RPC 是初创公司从第一天起就能真正合理调整的基础设施项目之一。你不需要为钱包后端、读密集型 dApp 和交易机器人使用相同的端点。诀窍是根据工作负载匹配方案层级，而不是根据团队规模。

本页面直接回答预算问题，然后提供一种评估提供商的方法，这样你就不会在早期多付费用，也不会在流量增长后陷入困境。

快速推荐

如果你处于预收入或早期阶段，请从包含 HTTP 和 WebSocket 的共享或按需付费 Solana RPC 方案开始，然后一旦你能测量，就将任何需要稳定吞吐量的工作负载隔离到专用节点上。OnFinality 为 Solana 提供这两个层级，因此你可以保持相同的端点形态并在它们之间移动工作负载，而无需重写客户端。

将此作为起始规则：

如果不确定，请从共享开始，并记录你的请求组合两周。数据会比猜测更可靠地告诉你是否需要专用节点。

真正驱动 Solana RPC 成本的因素

Solana 定价不仅仅是“每月请求数”。提供商根据多种因素定价，了解哪些因素适用于你可以防止意外账单。

• 请求量和方法权重。 getLatestBlockhash 调用和 getProgramAccounts 扫描并不相等。重方法通常成本更高或受到不同的速率限制。
• 计算单元 (CU)。 Solana RPC 提供商通常按计算单元而非原始调用次数计量，因为某些方法比其他方法做的工作多得多。
• WebSocket 订阅。 持久订阅（accountSubscribe、logsSubscribe、slotSubscribe）占用服务器资源，并与 HTTP 调用分开定价或限制。
• 归档和历史数据。 如果你查询旧插槽或交易，可能需要支持归档的节点，这属于与标准节点不同的层级。
• 专用容量。 专用节点是固定月费而非计量费用，这更容易预算，但仅在超过一定利用率时才有意义。

对于初创公司，目标是在计量层级比专用节点更便宜时保持使用它，然后在不便宜时干净地切换。查看当前的 RPC 定价 以了解适用于你工作负载的层级。

评估提供商而不过度设计

你不需要 40 行的评分卡。你需要回答五个直接映射到初创公司风险的问题。

OnFinality 支持 Solana 的 HTTP 和 WebSocket，这意味着你可以针对同一提供商运行标准 JSON-RPC 调用和订阅，而不是拆分你的技术栈。有关端点详细信息，请参阅 Solana RPC API 页面。

连接到 Solana RPC 端点

一旦你有了方案，连接本身很简单。Solana 客户端使用 HTTP URL 进行标准调用，使用 WebSocket URL 进行订阅。

# Standard JSON-RPC call over HTTP
curl https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getLatestBlockhash",
    "params": [{"commitment": "confirmed"}]
  }'

在 JavaScript 客户端（如 @solana/web3.js）中，你将连接指向你的端点，并传递与一致性需求匹配的 commitment 级别：

import { Connection, PublicKey } from "@solana/web3.js";

const connection = new Connection(
  "https://solana.api.onfinality.io/public",
  "confirmed"
);

const slot = await connection.getSlot();
console.log("Current slot:", slot);

对于实时更新，请使用 WebSocket 端点而不是轮询：

const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");

ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "logsSubscribe",
    params: [{ mentions: ["<PROGRAM_ID>"] }, { commitment: "confirmed" }]
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  // handle log notification
};

将程序 ID 替换为你自己的。如果你在 mainnet 之前进行测试，请使用 Solana Devnet 网络页面获取匹配的端点和配置。

初创公司在 Solana RPC 上超支的地方

最常见的预算错误不是选择错误的提供商，而是为工作负载选择了错误的层级。

1. 在测量之前购买专用节点。 专用节点是固定成本。如果你的流量是突发性的且较低，计量共享方案几乎总是更便宜。
2. 轮询而不是订阅。 在循环中轮询 getSlot 或 getSignaturesForAddress 会快速消耗计算单元。WebSocket 订阅通常对于变更检测更高效。
3. 忽略方法权重。 单个无界的 getProgramAccounts 调用可能比数千次轻量调用花费更多。尽可能添加过滤器并使用 dataSlice。
4. 没有故障转移计划。 运行单个端点是单点故障。即使是一个便宜的辅助端点，对于任何面向用户的东西都是值得的。
5. 跳过 commitment 调优。 在所有地方使用 finalized 更安全但更慢，并可能增加重试。将 commitment 与功能匹配。

何时从共享 RPC 迁移到专用节点

共享 RPC 不是你必须立即超越的妥协。它是正确的默认值，直到出现以下信号之一：

• 你的 p95 延迟在高峰时段变得不一致。
• 你经常在重方法上达到速率限制或 CU 上限。
• 你运行需要持续吞吐量的索引器或回填作业。
• 你需要归档数据或特定的方法保证。
• 你想要可预测的固定月费而不是计量计费。

当这些信号出现时，仅将受影响的工作负载迁移到 专用节点，其余部分保留在共享 RPC 上。这种混合方法可以保持低成本，同时保护需要稳定容量的应用部分。

一个简单的监控设置

如果不测量，你就无法合理调整方案。一个检查延迟和错误率的最小探针就足以做出共享与专用的决定。

# Lightweight health probe for a Solana RPC endpoint
for i in 1 2 3; do
  curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
    https://solana.api.onfinality.io/public \
    -X POST -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'
done

跟踪三个数字随时间的变化：错误率、p95 延迟和每天消耗的计算单元。当计算单元接近专用节点更便宜的点时，切换。在此之前，保持计量。

关键要点

• 从共享或按需付费 Solana RPC 方案开始，仅当你能测量需求时，才将特定工作负载迁移到专用节点。
• 成本由方法权重、计算单元、WebSocket 订阅、归档访问以及容量是计量还是固定决定。
• 在承诺提供商之前，确认方法覆盖、WebSocket 支持、传输、故障转移和计费模式。
• OnFinality 支持 Solana 的 HTTP 和 WebSocket，因此你可以将标准调用和订阅保留在一个提供商上。
• 在升级层级之前，监测错误率、p95 延迟和计算单元使用情况。
• 查看 RPC 定价 和 支持的 RPC 网络 以比较适合你工作负载的内容。

常见问题

免费的或公共的 Solana RPC 端点对初创公司足够吗？ 对于原型和内部工具，是的。对于任何有真实流量的面向用户的东西，付费共享方案提供更可预测的限制和 WebSocket 支持，而公共端点通常不保证这些。

我需要从第一天就使用专用的 Solana 节点吗？ 通常不需要。专用节点是固定成本，一旦你的持续使用量或延迟要求超过共享方案舒适处理的范围，它才有意义。先测量。

为什么 Solana RPC 定价使用计算单元而不是请求计数？ 因为方法的成本差异很大。按计算单元计量反映了调用执行的实际工作，因此轻量调用和重量扫描的定价不同。

我可以为 HTTP 和 WebSocket 使用同一个提供商吗？ 可以。OnFinality 为 Solana 提供 HTTP 和 WebSocket 端点，这避免了为标准和订阅调用拼接两个供应商。

在 mainnet 之前如何测试？ 使用 Solana Devnet 网络页面获取测试网端点，并在切换到 mainnet 之前验证你的客户端配置。