如何检查 Optimism 的可用性，这对你的 dApp 意味着什么？

快速回答：在哪里检查 Optimism 可用性

如果你需要快速回答，官方 Optimism 状态页面 是网络级可用性的权威来源。它跟踪公共 API、存款、取款、交易排序、批量提交和节点同步等组件。要更细粒度地了解 RPC 端点的健康状况，你可以使用第三方聚合器或自己的监控探针。

但问题是：网络可用性和 RPC 可用性并不相同。即使 Optimism 网络完全正常运行，你使用的 RPC 提供商也可能遇到停机、速率限制或性能下降。本文帮助你理解差异，并决定为你的 dApp 监控什么。

决策指南：为你的 dApp 监控什么

在开始检查可用性数字之前，问问自己实际需要监控什么。答案取决于你的应用架构和用户期望。

• 如果你正在构建一个简单的读取数据的前端：你需要可靠的公共 RPC 端点，但如果你有备用方案，可以容忍偶尔的短暂中断。
• 如果你正在运行 DeFi 协议或交易机器人：你需要低延迟、高可用性的 RPC，并具有自动故障转移。几秒钟的停机可能意味着错失交易或财务损失。
• 如果你正在索引数据或运行分析：你需要一致地访问归档数据和 WebSocket 流。可用性至关重要，但数据完整性也很重要。

对于大多数生产应用，我们推荐多提供商策略。使用一个主要 RPC 提供商，并配置一个备用提供商或公共端点。这样，如果一个提供商发生事件，你的应用可以继续运行。

官方 Optimism 状态页面跟踪的内容

官方状态页面提供了网络健康状况的高层视图。它通常显示以下组件：

你可以查看此页面以了解是否有正在进行的故障。但是，它不会告诉你第三方 RPC 提供商的性能，而你的应用实际使用的是这些提供商。

为什么 RPC 可用性比网络可用性更重要

你的 dApp 通过 RPC 端点与 Optimism 交互。如果该端点宕机，你的应用将无法读取或写入数据，无论网络的整体健康状况如何。因此，在评估 Optimism 可用性时，你应该关注 RPC 提供商的可用性，而不仅仅是网络的可用性。

RPC 可用性通常以一段时间内的百分比来衡量（例如，过去 30 天内的高可用性）。但原始可用性数字可能具有误导性。提供商可能具有高可用性，但仍然经历频繁的短暂中断，导致请求失败。你还应该考虑：

• 延迟：提供商响应速度有多快？高延迟会让你的应用感觉缓慢。
• 速率限制：提供商是否会限制请求？如果你超过限制，可能会收到错误。
• 数据一致性：提供商是否返回过时数据？如果节点落后，可能会发生这种情况。
• WebSocket 可靠性：对于实时更新，WebSocket 连接必须稳定。

如何自行监控 Optimism RPC 可用性

你可以设置自己的监控来跟踪 RPC 端点的可用性和性能。以下是一种简单的方法，使用脚本发送 JSON-RPC 请求并测量响应时间。

#!/bin/bash
# 简单的 Optimism RPC 可用性检查

RPC_URL="https://mainnet.optimism.io"

response=$(curl -s -o /dev/null -w "%{http_code} %{time_total}" -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  $RPC_URL)

http_code=$(echo $response | cut -d' ' -f1)
time_total=$(echo $response | cut -d' ' -f2)

if [ "$http_code" -eq 200 ]; then
  echo "RPC 正常。响应时间：${time_total}s"
else
  echo "RPC 宕机。HTTP 代码：$http_code"
fi

你可以定期运行此脚本（例如，每分钟）并记录结果。对于更高级的监控，可以使用 UptimeRobot 或 Grafana 与 Prometheus 等服务来跟踪可用性并设置警报。

在 RPC 提供商的可用性中应关注什么

在比较 RPC 提供商时，不要只看标题中的可用性百分比。询问或检查以下内容：

• 不同时期的可用性：24 小时、7 天、30 天、90 天。提供商可能具有出色的 90 天可用性，但最近出现问题。
• 故障历史：故障发生的频率如何？持续时间多长？一次长时间故障可能比几次短暂故障更糟糕。
• 状态页面：提供商是否有公共状态页面？他们更新速度有多快？
• SLA（服务级别协议）：提供商是否提供 SLA？如果违反 SLA，会发生什么？
• 冗余：提供商是否拥有多个节点和数据中心？这降低了单点故障的风险。

在 OnFinality，我们在多个地区运营专用节点和 RPC 端点。你可以查看我们的 支持的网络 以了解 Optimism 是否可用，并查看我们的 RPC 定价 以了解服务级别的详细信息。

依赖公共 RPC 端点时的常见陷阱

公共 RPC 端点（如 Optimism 提供的端点）对于开发和轻量使用很方便，但它们存在局限性：

• 速率限制：公共端点通常有严格的速率限制。如果你的应用发出太多请求，你会收到 429 Too Many Requests 等错误。
• 无 SLA：公共端点按原样提供，不保证可用性或性能。
• 共享基础设施：公共端点被许多开发人员使用，因此在高峰时段可能会变得拥塞。
• 方法有限：某些公共端点可能不支持某些方法，例如大范围的 eth_getLogs 或 trace_* 方法。

如果你的应用已投入生产，你应该考虑使用提供更高可靠性和更多功能的专用 RPC 提供商。

如何为你的 dApp 构建弹性

即使使用可靠的 RPC 提供商，你也应该设计你的 dApp 以优雅地处理 RPC 故障。以下是一些最佳实践：

• 使用多个 RPC 端点：配置你的应用，在主端点失败时尝试备用端点。
• 实现重试逻辑：对于关键请求，使用指数退避重试。
• 缓存数据：缓存频繁访问的数据以减少 RPC 调用次数。
• 监控你的应用：使用 Sentry 或 Datadog 等工具跟踪错误和性能。

以下是在 ethers.js 中设置备用 RPC 的示例：

const { ethers } = require("ethers");

const primaryProvider = new ethers.JsonRpcProvider("https://mainnet.optimism.io");
const fallbackProvider = new ethers.JsonRpcProvider("https://optimism-mainnet.public.blastapi.io");

const provider = new ethers.FallbackProvider([primaryProvider, fallbackProvider], 1);

async function getBlockNumber() {
  try {
    const blockNumber = await provider.getBlockNumber();
    console.log("区块号：", blockNumber);
  } catch (error) {
    console.error("获取区块号时出错：", error);
  }
}

getBlockNumber();

这样，如果主端点失败，将自动使用备用端点。

关键要点

• Optimism 可用性 指的是网络及其核心服务的可用性，但 RPC 可用性才是直接影响你的 dApp 的因素。
• 检查官方 Optimism 状态页面 以了解网络级故障，但也要监控你的 RPC 提供商的性能。
• 在选择 RPC 提供商时，不要只看可用性百分比，还要考虑延迟、速率限制、数据一致性和 WebSocket 可靠性。
• 公共 RPC 端点不适合生产环境；使用像 OnFinality 这样的专用提供商以获得更好的可靠性。
• 通过使用多个端点、重试逻辑和缓存来为你的 dApp 构建弹性。

常见问题解答

问：Optimism 当前的可用性是多少？

答：官方状态页面显示 Optimism 组件的当前状态。对于历史可用性，你可以查看第三方聚合器或你自己的监控数据。

问：Optimism 可用性是如何计算的？

答：可用性通常计算为服务在给定时间段内运行的时间百分比。例如，高可用性意味着服务在 30 天内停机时间少于 43 分钟。

问：Optimism 是否提供 SLA？

答：Optimism 网络本身不为其公共 API 提供 SLA。但是，像 OnFinality 这样的 RPC 提供商可能会为专用服务提供 SLA。

问：如果 Optimism 公共 API 宕机，我该怎么办？

答：如果公共 API 宕机，你可以切换到第三方 RPC 提供商。OnFinality 提供可靠的 Optimism RPC 端点；查看我们的 支持的网络 了解详情。

问：如何获取 Optimism 停机警报？

答：你可以使用 UptimeRobot 或 Grafana 等工具设置自己的监控，或订阅 Optimism 或你的 RPC 提供商的状态页面通知。