---
title: "打造应用可靠性：web3 成功的关键"
description: "节点可靠性对你的 web3 应用至关重要。了解 Alchemy 的基础设施如何在你扩展规模时确保可靠性。"
---

# 打造应用可靠性：web3 成功的关键

许多团队的 web3 应用注定失败。

为什么？

因为应用完全依赖节点，而节点极难维护。原因包括：

1. 节点可靠性无法孤立建立；可靠性必须伴随节点可扩展性和数据准确性
1. 节点并非为全规模生产环境设计
1. 节点被要求做的事情太多
1. 节点需要全职维护
1. 节点的效力取决于能否成功应对时间不可预测的网络升级或硬分叉

这些复杂因素使节点难以管理和维护。

但有两个架构维度能显著提升节点可靠性，**即用户在需要时能否成功与你的应用交互**：

- **异构性**：多样且互补的系统，能够处理不同类型的请求
- **冗余性**：备用系统，当一个系统宕机时，其他系统仍能保持运行

在 web3 中，缺乏可靠性可能带来严重后果。

以某知名 [NFT 交易平台](https://www.alchemy.com/dapps/best/nft-marketplaces)为例，其使用了不可靠的基础设施……

他们的平台不稳定，造成了：

- 沉重的工程负担
- 用户体验下降
- 单季度停机时间超过 190 小时

影响是什么？**损失了 600 万美元的收入。**

不要让这种情况发生在你身上。

**在本文中，我们将解释：**

1. 为什么维持节点可靠性具有挑战性
1. 常见的节点基础设施模式及其失败原因
1. Alchemy 如何应对可靠性挑战，并构建规模化的可靠性

## 为什么维持节点可靠性具有挑战性

在 web3 中，有**五个**主要原因使可靠性特别难以维持：

### \(1\) 节点可靠性无法孤立建立；可靠性必须伴随节点可扩展性和数据准确性
要打造功能完善的应用，你需要可靠性，同时具备可扩展性和数据准确性。

- **可扩展性**：当应用流量扩大 10 倍、100 倍、1000 倍甚至更多时，仍能持续与区块链交互的能力。
- **数据准确性**：应用向每一个用户返回正确且一致的数据的状态。

### **\(2\) 节点并非为全规模生产环境设计**‍

节点最初的设计目的是供个人在小规模场景下运行。虽然成本不低（每月 1000 美元），但对于这种有限的使用场景，它们可以创造足够的可靠性，并维持：

- **可扩展性**：请求量是可预测且受控的，限制了对可扩展性的任何需求风险
- **数据准确性**：由于只有一个节点，[节点内部不存在数据不一致的可能](https://alchemy.com/blog/data-accuracy)

然而，开发环境并非生产环境，生产环境需要截然不同的工具。

<ExternalVideo
  url="https://vimeo.com/775874944"
  provider="vimeo"
  providerUid="775874944"
/>

### \(3\)** **节点被要求做的事情太多
节点被要求做无穷多的事情，例如运行点对点软件、充当可扩展数据库、执行任意代码等等。

节点对于自己该做什么、不该做什么也没有任何“立场”。

综合起来，这带来两个主要后果：

- **可扩展性**：随着请求量增长进行扩容时，你需要启动新节点；而每个新节点都必须包含那一长串功能，造成繁琐的低效和成本（同样，即使是最便宜的方案，运行一个节点每月也要花费 1000 美元）。
- **边界情况**：由于节点缺乏基本防护，一个查询就可能单独导致节点崩溃。

<ExternalVideo
  url="https://vimeo.com/775874968"
  provider="vimeo"
  providerUid="775874968"
/>

### \(4\) 节点需要全职维护
平均而言，每 5 天节点就可能出现以下问题：

- 内存泄漏
- 数据存储问题
- CPU 占满
- 对等连接不稳定
- 内部数据库损坏
- 交易广播问题
- 错误与回归
- 每 6 个“稳定版本”中就有 1 个存在问题

每个问题都需要花费大量时间来诊断、排查和修复，这意味着[投入在前端用户体验上的时间将大幅减少](https://www.alchemy.com/case-study/zerion)。

<CalloutBlock>

“与 Alchemy 合作帮助我们节省了相当于三名全职工程师的人力——否则他们将不得不一直埋头处理基础设施维护工作。” - Evgeny Yurtaev，Zerion 首席执行官兼联合创始人，[Zerion](https://www.alchemy.com/dapps/zerion)

</CalloutBlock>

<ExternalVideo
  url="https://vimeo.com/775874996"
  provider="vimeo"
  providerUid="775874996"
/>

### \(5\) 节点的效力取决于能否成功应对时间不可预测的网络升级或硬分叉
网络升级和硬分叉按照协议自身的时间表发生，而非你的时间表。每一次都需要充分准备，一旦出错，可能导致节点崩溃，造成严重影响。

<CalloutBlock>

“在与 Alchemy 集成之前，我们自行运行区块链基础设施。这种方式几乎不可能在没有问题的情况下维护和扩展。任何行业范围内的更新都要花费我们数小时来实施，让所有人都头疼不已。” - Evgeny Yurtaev，Zerion 首席执行官兼联合创始人

</CalloutBlock>

## 常见的基础设施架构模式及其失败原因

运行可靠的节点基础设施本质上具有挑战性，而许多常见的 web3 架构在建立可靠性方面效果不佳：

### 运行单个节点
这种方式[设置更简单，但存在单点故障](https://www.alchemy.com/overviews/running-your-own-node)，既没有异构性也没有冗余性。单个节点的正常运行时间最低可低至 72%，而扩展单个节点也极其低效。

### 运行带备用的节点
这种方式[比单节点创造了稍多的冗余性](https://www.alchemy.com/overviews/alternative-rpc-endpoint)，但仍然没有异构性（系统缺乏多样性），而且往往一个导致第一个节点宕机的请求，也会连带导致第二个节点宕机。可扩展性问题依然存在，并且你还引入了[**数据准确性**](https://alchemy.com/blog/data-accuracy)问题——由于大多数系统无法保证每个节点都处于相同的区块高度（甚至同一条链上），这些节点将返回不同的响应。

### ‍**在一组节点集群间做负载均衡**

这种模式创造了更多冗余性，但仍然没有异构性。数据准确性和可扩展性问题依然存在（一连串重试就会导致整个节点集群瘫痪）。

<ExternalVideo
  url="https://vimeo.com/775875017"
  provider="vimeo"
  providerUid="775875017"
/>

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "", dataType: "object" },
      { key: "2", width: 200, title: "Reliability", dataType: "object" },
      { key: "3", width: 200, title: "Scalability", dataType: "object" },
      { key: "4", width: 200, title: "Data accuracy", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p><strong>Running one node</strong><br/>Heterogeneity<br/>Redundancy</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Lacks heterogeneity and redundancy</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Cumbersome to spin up new nodes</p>", tooltip: "", icon: "" },
        "4": { title: "<p>Yes! Has data accuracy</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p><strong>Running one node with a backup</strong><br/>Heterogeneity<br/>Redundancy</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Lacks heterogeneity and redundancy</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Cumbersome to spin up new nodes</p>", tooltip: "", icon: "" },
        "4": { title: "<p>No data accuracy</p>", tooltip: "", icon: "" },
        id: 1,
      },
      {
        "1": { title: "<p><strong>Load balancing across a fleet of nodes</strong><br/>Heterogeneity<br/>Redundancy</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Lacks heterogeneity and redundancy</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Cumbersome to spin up new nodes</p>", tooltip: "", icon: "" },
        "4": { title: "<p>No data accuracy</p>", tooltip: "", icon: "" },
        id: 2,
      },
    ],
  }}
/>

### 节点常常宕机，而且修复起来**非常、非常麻烦。**

如果还不够清楚的话：许多用于连接区块链的“解决方案”并未充分提供异构性或冗余性，因此最终都会失败。失败会带来严重的后果。

<CalloutBlock>

“在使用 Alchemy 之前，我们一直深陷于管理后端基础设施的泥潭，白白消耗了大量开发资源——而其他开发者平台提供的解决方案广度也不够。与节点相关的问题几乎占据了我们所有的值班事故。” - Brad Bayliss，Enjin 首席技术经理

</CalloutBlock>

节点可能需要数天或数周的恢复时间才能重新正常运行。这些问题代价高昂、难以解决，需要整个团队埋头苦干。

2019 年，BlockCypher 曾试图应对 Ethereum 的 Constantinople 硬分叉。他们遇到了数据缺失的错误，却无法诊断出根本原因。他们因此经历了**超过一个月的停机**，最终不得不基本上从头重建。

不要让这种情况发生在你身上 ;\)

你的 web3 基础设施越具备异构性和冗余性，它就越可靠。

## Alchemy 如何构建规模化的可靠性

<CalloutBlock>

“毫无疑问，Alchemy 是唯一一家提供了全面工具集的提供商，让我们能够在每天进行数千次调用的同时，实现无缝扩展和不间断的可靠性。” - Kyle Gusdorf，Decentral Games 软件工程师

</CalloutBlock>

[Alchemy 的 Cortex 引擎结合了自研的、可扩展的分布式系统](https://alchemy.com/overviews/blockchain-node-providers)，这些系统实现了可靠性和可扩展性，同时使我们的 API 能够像单个节点一样运作，从而确保数据准确性。

### Cortex 通过可扩展且多样化的系统同时实现冗余性和异构性

<ExternalVideo
  url="https://vimeo.com/775877885"
  provider="vimeo"
  providerUid="775877885"
/>

### 冗余且异构的系统，最大限度减少对节点的数据请求  
Web2 基础设施通过将数据存储从服务器中移除，转而建立外部存储中心，来实现可靠性和可扩展性。

然而，由于节点架构的独特性质，将数据存储从节点中移除基本上是不可能的。

为了实现可靠性和可扩展性，Alchemy 的 Cortex 引擎使用了一种先进的架构——称为二级基础设施——来复制节点的数据。

<ImageBlock
  src="https://media.alchemy.com/1704726829-supernode-secondary-infrastructure.jpg"
  alt="Cortex 二级基础设施复制节点数据的示意图"
  width={1920}
  height={1080}
  caption="Cortex 的二级基础设施"
/>

Cortex 的协调层 Vox Nodi 持续运行系统检查，确保二级基础设施拥有最新数据，因此任何数据请求（例如区块号、交易日志、交易回执）都将是准确的。

通过将请求优先路由至二级基础设施，节点得到保护，其“工作负载”也随之降低。

<ImageBlock
  src="https://media.alchemy.com/1704726923-routing-requests-to-secondary-infrastructure.jpg"
  alt="将请求路由到二级基础设施"
  width={1920}
  height={1080}
  caption="将请求路由到二级基础设施"
/>

大多数请求都可以由二级基础设施处理，只有边界情况才会被路由至节点。

我们来看一个例子：

用户想要获取不同数据类型和区块的信息：

- 用户 1 请求截至区块 82 的交易数据
- 用户 2 请求从区块 85 开始的日志数据
- 用户 3 请求从区块 92 开始的区块数据

<ImageBlock
  src="https://media.alchemy.com/1704727109-secondary-infrastructure-example.jpg"
  alt="二级基础设施处理请求、节点处理边缘情况的示意图"
  width={1920}
  height={1080}
  caption="二级基础设施示例"
/>

用户 1 的请求可以由二级基础设施系统处理。（重要的是，如果这样的请求直接打到节点上，节点会崩溃，而二级基础设施系统则可以无缝处理这种负载。）

用户 2 的请求同样可以由二级基础设施处理。

用户 3 的请求无法通过二级基础设施处理，因为该系统尚未获得区块 92 的最新区块数据。用户 3 的请求现在将由节点处理。

在这个例子中，用户 1、2、3 的体验完全一致。无论请求是由二级基础设施响应，还是直接由节点响应，停机时间都没有差别。但通过优先将请求路由至二级基础设施系统，节点得到了保护，其“工作负载”也随之降低。

<CalloutBlock>

“Alchemy 让我们不再需要使用二级 / 备用基础设施。Alchemy 从不宕机，其正常运行时间极其稳定。他们的平台对我们来说运作得非常完美。” - Johnny Rhea，Element.Fi 联合创始人兼首席技术官

</CalloutBlock>

### 冗余且异构的系统，用于执行代码
由于 Ethereum Virtual Machine \(EVM\) 是图灵完备的，你可以要求节点执行代码。由于节点无法自我调控，任意请求随时都有可能拖垮整个节点集群。

为了防止这种情况，Alchemy 对我们系统曾经响应过的所有请求进行去重并存储。

这意味着只有真正全新的请求才会在节点上运行，而绝大多数请求都可以由这些存储系统来执行。

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Node Type", dataType: "object" },
      { key: "2", width: 200, title: "Data Coverage", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>Geth Archive Node</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Since genesis</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p>Geth Full (Fast) Node</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Most recent 2,000 blocks</p>", tooltip: "", icon: "" },
        id: 1,
      },
    ],
  }}
/>

<ImageBlock
  src="https://media.alchemy.com/1704727753-mudit-gupta-tweet.png"
  alt="Mudit Gupta 关于负载均衡的推文"
  width={846}
  height={242}
  caption="Mudit Gupta 关于负载均衡的推文"
/>

### 异构节点，针对不同请求进行专门化
除了二级基础设施系统之外，Alchemy 还通过不同的节点类型增加异构性。在极少数二级基础设施无法响应请求的情况下，系统会默认切换到可扩展性最强的节点。

Alchemy [运行多种类型的节点](https://www.alchemy.com/overviews/what-is-an-ethereum-node)，包括：

- **轻节点（Light）：**仅下载区块头，即在网络上进行交易所需的最少数据。轻节点可以高效地与网络交互，节省数兆字节的带宽和数吉字节的存储空间，但局限在于它们无法访问完整数据。
- **全节点（Full）**：拥有验证网络上区块正确性所需的一切，并可以与任何[智能合约](https://www.alchemy.com/docs/how-to-deploy-a-smart-contract-to-the-sepolia-testnet)交互，还可以部署自己的合约。全节点需要大量的计算和带宽资源。
- **归档节点（Archive）：**比全节点更进一步。全节点会修剪掉不再需要用于验证的条目，而归档节点则保留一切（额外的数据量达数太字节）。这些细节非常适合更高效地查询信息，对少数应用很有用，但在大多数情况下是多余的。
- **调试节点（Debug）：**调试节点比归档节点更进一步，存储的信息量在所有节点类型中最多，让你能够极其详细地逐步跟踪[智能合约](https://www.alchemy.com/overviews/solidity-smart-contract)的执行过程。

<ImageBlock
  src="https://media.alchemy.com/1704727971-alchemy-runs-multiple-types-of-nodes.jpg"
  alt="Alchemy 运行多种类型的节点"
  width={1920}
  height={1080}
  caption="Alchemy 运行多种类型的节点"
/>

不同节点类型各具特性，擅长处理不同的任务，因此如果某一个节点无法回应请求，其他节点很可能仍然健康，并且更适合响应该请求。

例如，如果有请求要获取最新数据（可能尚未记录在二级基础设施中），该请求可以被路由到快速节点，而归档节点则会被“保护”起来，因为在归档节点的数据中筛选查找的成本要高得多。

为了更方便地按需启动新节点，Cortex 引擎会对节点进行“快照”，这样在创建新节点时，系统可以从最近的“检查点”开始，从而大幅缩短同步过程。

<EbookCta
  eyebrow="免费指南"
  title="自建还是购买：区块链基础设施"
  description="在组建基础设施团队之前，先看看这个：自建基础设施在服务第一个生产请求之前，每年成本就可能高达 85 万至 100 万美元以上。查看完整成本分析。"
  ctaLabel="下载指南"
  ctaHref="/resources/build-vs-buy"
  coverImage={{
    src: "https://media.alchemy.com/ebooks/cta-build-vs-buy.png",
    alt: "Build vs. Buy ebook cover",
  }}
/>

### 异构客户端，减轻错误的影响
最后，Alchemy 运行着 Ethereum 客户端的不同实现版本，包括 [geth](https://www.alchemy.com/overviews/what-is-a-geth-node-and-how-to-run-one)、Erigon 和 Parity。这实际上使后端维护工作量增加了两倍，但对异构性而言极具价值：这些客户端出现相同错误的概率基本为零。

## 通过**冗余性与异构性**建立可靠性

在 Alchemy，我们已投入数十万小时打造 Cortex——一套从零开始构建、兼具异构性和冗余性的复杂系统，大幅提升了我们的容错能力，确保我们能够可靠地响应任何区块链请求。

<ImageBlock
  src="https://media.alchemy.com/1704728098-use-alchemy-rpc.png"
  alt="为你的 NFT 使用 Alchemy RPC"
  width={856}
  height={190}
  caption="为你的 NFT 使用 Alchemy RPC"
/>

<CalloutBlock>

“基础设施既可靠又可扩展，这样我们才能在客户最需要我们的时候保持在线——这对 Collab.Land 来说至关重要。在这方面，Alchemy 是行业标杆。” - Raymond Feng，Collab.Land 首席技术官

</CalloutBlock>

<ImageBlock
  src="https://media.alchemy.com/1704728160-use-alchemy-rpc-for-your-dapps.png"
  alt="为你的应用使用 Alchemy RPC"
  width={846}
  height={214}
  caption="为你的应用使用 Alchemy RPC"
/>

我们花了数年时间构建起这套让可靠性成为可能的复杂、相互依存的系统。构建以控制可靠性极具挑战性，但利用可靠的基础设施对你应用的成功至关重要。

在你探索基础设施选项时，最先应该向提供商提出的问题之一是：**“你的基础设施具备多高的异构性和冗余性？你能向我展示什么证据来证明你们系统的可靠性？”**

公开的 [RPC 提供商基准测试](https://www.alchemy.com/benchmarks)可以帮助评估延迟、成功率和失败请求，并与提供商对其架构的说法相互印证。

你的应用能否成功，取决于这个选择。欢迎告诉我们能为你提供什么帮助！