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

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

为什么？

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

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

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

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

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

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

以某知名 NFT 交易平台为例，其使用了不可靠的基础设施……

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

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

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

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

在本文中，我们将解释：

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

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

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

(1) 节点可靠性无法孤立建立；可靠性必须伴随节点可扩展性和数据准确性

要打造功能完善的应用，你需要可靠性，同时具备可扩展性和数据准确性。

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

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

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

• 可扩展性：请求量是可预测且受控的，限制了对可扩展性的任何需求风险
• 数据准确性：由于只有一个节点，节点内部不存在数据不一致的可能

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

(3)** **节点被要求做的事情太多

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

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

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

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

(4) 节点需要全职维护

平均而言，每 5 天节点就可能出现以下问题：

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

每个问题都需要花费大量时间来诊断、排查和修复，这意味着投入在前端用户体验上的时间将大幅减少。

(5) 节点的效力取决于能否成功应对时间不可预测的网络升级或硬分叉

网络升级和硬分叉按照协议自身的时间表发生，而非你的时间表。每一次都需要充分准备，一旦出错，可能导致节点崩溃，造成严重影响。

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

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

运行单个节点

这种方式设置更简单，但存在单点故障，既没有异构性也没有冗余性。单个节点的正常运行时间最低可低至 72%，而扩展单个节点也极其低效。

运行带备用的节点

这种方式比单节点创造了稍多的冗余性，但仍然没有异构性（系统缺乏多样性），而且往往一个导致第一个节点宕机的请求，也会连带导致第二个节点宕机。可扩展性问题依然存在，并且你还引入了数据准确性问题——由于大多数系统无法保证每个节点都处于相同的区块高度（甚至同一条链上），这些节点将返回不同的响应。

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

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

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

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

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

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

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

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

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

Alchemy 的 Cortex 引擎结合了自研的、可扩展的分布式系统，这些系统实现了可靠性和可扩展性，同时使我们的 API 能够像单个节点一样运作，从而确保数据准确性。

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

冗余且异构的系统，最大限度减少对节点的数据请求

Web2 基础设施通过将数据存储从服务器中移除，转而建立外部存储中心，来实现可靠性和可扩展性。

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

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

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

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

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

我们来看一个例子：

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

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

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

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

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

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

冗余且异构的系统，用于执行代码

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

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

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

异构节点，针对不同请求进行专门化

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

Alchemy 运行多种类型的节点，包括：

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

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

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

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

异构客户端，减轻错误的影响

最后，Alchemy 运行着 Ethereum 客户端的不同实现版本，包括 geth、Erigon 和 Parity。这实际上使后端维护工作量增加了两倍，但对异构性而言极具价值：这些客户端出现相同错误的概率基本为零。

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

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

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

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

公开的 RPC 提供商基准测试可以帮助评估延迟、成功率和失败请求，并与提供商对其架构的说法相互印证。

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