摘要
Dwellir 是一个多链 RPC 基础设施提供商,宣称可访问超过 150 个区块链网络。开发者在比较 API 提供商或为 Ethereum、Polkadot、Base 等链寻找可靠的 HTTPS 和 WebSocket 端点时,通常会搜索到它。本页面可帮助你根据真实生产需求评估 Dwellir 的服务:链覆盖、归档数据、故障转移行为以及定价透明度。
不要将任何单一提供商视为默认选择,最终决策取决于你的工作负载。如果你需要广泛的测试网覆盖、可预测的定价和简单的故障转移,像 OnFinality 这样的 RPC 平台可能是一个有力的替代方案。使用下面的清单,按照实际影响 dApp 可靠性和成本的标准来比较 Dwellir 与其他提供商。
Dwellir 决策清单
在选择任何 RPC 提供商之前,请通过提供商的文档或支持团队确认以下几点:
- 链覆盖: 该提供商是否提供你在主网和测试网所需的精确网络?例如,如果你的目标是 Base 和 Polkadot,请确认两者都可用。
- 端点类型: 你是否可以获得用于 JSON-RPC 调用的 HTTPS 和用于实时订阅的 WSS?是否提供归档节点以访问历史状态?
- 身份验证: 你如何访问端点?API 密钥、白名单,还是两者都支持?密钥模型是否适合你的服务端后端?
- 速率限制和配额: 超出免费层后会发生什么?定价是按请求、按月还是基于带宽?
- 故障转移选项: 提供商是否提供多个端点或负载均衡 URL?如果某个节点发生故障,回退行为是什么?
- 数据保真度: 你读取的是全节点还是归档节点的数据?某些查询需要归档数据。
- 支持与文档: 是否有清晰的文档、状态页和响应迅速的支持渠道?
- 锁定风险: 你是否能以最小的代码改动迁移到其他提供商?标准 JSON-RPC 应该是可移植的。
使用此清单来筛选提供商,它还能帮你梳理在试用期内需要测试的内容。
Dwellir 作为 RPC 提供商提供什么
Dwellir 将自己定位为一家稳健的区块链基础设施公司。根据其公开网站,它提供对超过 150 个区块链网络的 API 访问,包括 Ethereum、Arbitrum、Base、Polygon、BNB Smart Chain、Polkadot、Moonbeam 和 Sui。该服务同时提供 HTTPS 和 WebSocket (WSS) 端点,并在多个网络上提供归档节点和全节点选项。
例如,Dwellir 首页上类似文档的列表显示了如下端点 URL:
https://api-base-mainnet-archive.n.dwellir.com/{API_KEY}
wss://api-base-mainnet-archive.n.dwellir.com/{API_KEY}
这些端点需要密钥,这暗示其采用基于 API 密钥的身份验证模型。部分网络似乎也提供公共端点,但公共端点通常是共享的,并且可能受到速率限制。
该公司将可靠性和可扩展性作为其核心价值主张。这种说法在 RPC 提供商中很常见,因此你的评估不应停留在着陆页,而应关注具体的指标和行为。
如何在投入时间之前验证提供商的声明
RPC 提供商的营销页面听起来都很相似:“可靠”、“可扩展”、“一流”。你需要通过自己的测试和社区反馈来验证这些说法。
- 进行试用负载测试: 生成你的 dApp 将产生的流量类型。使用
hey或wrk等工具发送大量请求,观察延迟、错误率和限流行为。 - 检查状态页: 提供商是否维护事件历史和公开状态页?过去的事件可以让你了解故障发生的频率以及他们的透明程度。
- 申请测试网端点: 提供测试网访问的提供商允许你在不冒主网资金风险的情况下验证功能。
- 阅读文档了解速率限制的具体细节: 寻找诸如“每秒 100 个请求”或“每月 100 万个请求”这样的具体数字。“合理使用”等模糊措辞是一个警示信号。
- 搜索社区讨论: 开发者论坛和 Discord 频道中通常包含关于正常运行时间和支持响应速度的真实经验。
这些验证步骤适用于 Dwellir、OnFinality 以及你评估的任何其他提供商。
如何评估像 Dwellir 这样的 RPC 提供商
比较 RPC 提供商不仅仅是看谁的链列表最长。下表将评估标准映射到生产环境中真正重要的问题。
| 评估标准 | 要检查什么 | 为什么重要 |
|---|---|---|
| 网络覆盖 | 它是否列出了你需要的所有链,包括测试网? | 缺少链会迫使你使用第二个提供商,增加复杂性。 |
| 归档状态 | Ethereum、Polkadot 或其他链是否提供归档节点? | 历史余额和状态查询在全节点上会失败。 |
| WebSocket 支持 | WSS 是否与 HTTPS 一样使用相同的密钥并提供相同的可靠性? | 待处理交易等订阅需要稳定的 WebSocket 连接。 |
| 端点设计 | 你的 API 密钥是嵌入在 URL 中还是通过请求头传递? | 嵌入 URL 的密钥可能会在日志中泄露,需要更小心的机密处理。 |
| 速率限制披露 | 提供商是否公布每小时或每秒的限制? | 不透明的限制使容量规划变得困难。 |
| 故障转移行为 | 是否有多个端点或 DNS 级别的负载均衡器? | 没有故障转移,节点故障可能导致你的 dApp 宕机。 |
| 定价透明度 | 你能否在集成前估算每月成本? | 意外账单是 API 服务的常见痛点。 |
| 迁移摩擦 | 提供商是否使用标准 JSON-RPC 方法? | 自定义端点和非标准行为会使切换提供商变得复杂。 |
向你筛选出的提供商申请试用权限,并逐行测试。如果某个提供商无法清楚回答这些问题,请将其视为一个警示信号。
对比 Dwellir 与 OnFinality 等替代方案
Dwellir 是 Web3 基础设施领域中众多 RPC 平台之一。其他平台也采用类似方法,包括 OnFinality,它提供公共 RPC API 服务和专用节点。
在将 Dwellir 与 OnFinality 等替代方案进行比较时,请考虑:
- 网络列表: 两家提供商都支持许多热门链,但具体列表会随时间变化。查看 OnFinality 当前支持的 RPC 网络,确认你需要的链是否在列。
- 节点类型: 检查提供商是否提供归档、全节点和 WebSocket 端点的访问。OnFinality 支持跨网络的各种节点配置。
- 专用节点: 如果你需要隔离容量,专用节点可能比按请求付费更具成本效益。OnFinality 为希望拥有自己的端点但不想自行运行节点的团队提供专用节点基础设施。
- 定价: RPC 成本有多种形式:免费层、按量付费或月度订阅。根据你的流量模式比较定价模型。查看 OnFinality 当前的RPC 定价结构。
不存在普遍意义上“最好”的提供商。正确的选择取决于你的链覆盖需求、预算,以及你愿意承担多少运营开销。
实际的 RPC 测试
获得端点后,在编写应用程序代码之前先测试其行为。一个简单的 curl 请求就足以检查端点是否接受你的 API 密钥并返回预期的响应。
对于兼容 Ethereum 的网络,你可以调用 eth_chainId:
curl -X POST "https://api-base-mainnet-archive.n.dwellir.com/YOUR_API_KEY" \
-H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
成功的响应如下所示:
{"jsonrpc":"2.0","id":1,"result":"0x2105"}
如果你正在评估 OnFinality 的端点,可以在网络页面上找到每条链的 HTTPS 和 WSS URL。相同的 curl 模式适用于 OnFinality 端点。
对于基于 Substrate 的网络(如 Polkadot),请使用 system_health 或 chain_getHeader 等方法:
curl -X POST "https://api-polkadot.n.dwellir.com/YOUR_API_KEY" \
-H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"system_health","params":[],"id":1}'
始终验证端点是否支持你的 dApp 实际使用的方法。像 eth_getBalance 这样带有历史区块编号的归档查询,只有在提供商运行归档节点时才可靠。
集成 RPC 提供商时的常见陷阱
即使选择了可靠的提供商,集成错误也可能导致服务中断或数据偏差。请注意以下陷阱:
- 泄露 API 密钥: 如果密钥是 URL 的一部分,而你又记录了 URL,密钥就会暴露。请使用服务端代理,或在记录前移除查询参数。
- 假设所有节点都是归档节点: 许多提供商混合运行全节点和归档节点。历史状态查询在非归档端点上会失败。请确认每个网络所需节点的类型。
- 忽略 WebSocket 重连: 网络中断后,通过 WSS 建立的订阅会断开。请实现带有指数退避的重连逻辑,并重新订阅之前的所有主题。
- 不尽早测试速率限制: 在试用期内进行负载测试。单个
curl响应良好的提供商可能在你 dApp 规模化后对你进行限流。 - 构建自定义提供商客户端: 请坚持使用标准的 JSON-RPC 库。自定义客户端会让迁移变得更加困难,并引入边缘情况 bug。
使用多个提供商以提高弹性
即使拥有良好的 HTTP 端点,生产级 dApp 有时也需要第二个数据源。一种常见模式是将一个提供商设为主提供商,另一个设为备用提供商。这样,如果主提供商发生故障或触发速率限制,你的应用可以以最小的干扰进行切换。
Dwellir 和 OnFinality 都提供标准 JSON-RPC 端点,因此可以通过一个小型包装器在客户端实现故障转移逻辑。例如,你可以根据偏好先尝试 OnFinality,然后回退到 Dwellir,反之亦然。
当你使用多个提供商时,请注意数据一致性。如果其中一个提供商是归档节点,而另一个不是,你需要将归档查询路由到归档端点。同样,当你切换提供商时,通常需要重新建立 WebSocket 订阅。
关键要点
- Dwellir 是一个多链 RPC 提供商,宣称提供广泛的网络覆盖以及 HTTPS 和 WSS 端点。
- 评估提供商需要检查链覆盖、归档支持、速率限制、故障转移和定价透明度。
- 使用决策清单来比较 Dwellir 与 OnFinality 等替代方案,后者提供可直接查阅的 RPC 定价 和 支持的网络。
- 在投入之前先用
curl测试端点,并验证归档方法能否满足你的数据需求。 - 在你的应用程序架构中规划好 API 密钥安全、WebSocket 重连和速率限制。
- 当你需要隔离容量而不是共享公共端点时,请考虑使用专用节点。
常见问题
Dwellir 是免费的 RPC 提供商吗?
Dwellir 的网站显示部分网络提供公共端点,但大多数端点似乎需要 API 密钥。公共端点通常是共享的,并且受到速率限制。请查看 Dwellir 当前的定价页面,了解免费层和付费层的详细信息。
Dwellir 支持 Polkadot 吗?
是的,Dwellir 将 Polkadot 列为其支持的网络之一,并为其提供 WSS 端点。这些端点上应该可以使用 Substrate 特定的方法。
在生产级 dApp 方面,Dwellir 与 OnFinality 相比如何?
两家提供商都提供多链 RPC 访问。OnFinality 还提供公共 RPC 端点、API 密钥仪表盘和专用节点基础设施。最佳选择取决于你的链列表、流量和预算。查看 OnFinality 的支持的网络,看看它是否覆盖你需要的区块链。
我可以在移动应用中使用 Dwellir 端点吗?
可以,但要注意避免暴露 API 密钥。推荐的做法是通过你自己的后端代理转发请求,这样密钥就保存在服务端。