---
title: "打造應用程式可靠性：Web3 成功的關鍵"
description: "節點可靠性對您的 Web3 應用程式至關重要。了解 Alchemy 的基礎設施如何在您擴展規模時確保可靠性。"
---

# 打造應用程式可靠性：Web3 成功的關鍵

許多團隊的 web3 應用程式注定失敗。

為什麼？

因為應用程式完全依賴節點，而節點極難維護。以下是部分原因：

1. 節點可靠性無法憑空建立；可靠性必須同時兼顧節點的可擴充性與資料準確性
1. 節點的設計初衷並非全規模的正式環境解決方案
1. 節點被期望要做的事情太多
1. 節點需要全職維護
1. 節點的效能取決於能否成功應對時間難以預測的網路升級或硬分叉

這些複雜因素讓節點難以管理與維護。

但有兩個架構面向能大幅提升節點可靠性，**也就是使用者在需要時能成功與你的應用程式互動的能力**：

- **異質性（Heterogeneity）**：多樣且互補的系統，能夠處理不同類型的請求
- **冗餘性（Redundancy）**：備援系統，讓其中一個系統故障時，其他系統仍能運作

在 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\)** **節點被期望要做的事情太多
節點被期望能做無數件事，例如執行點對點軟體、作為可擴充的資料庫、執行任意程式碼等等。

而節點對於自己該做或不該做什麼，並沒有任何「立場」。

綜合起來，這造成了兩個主要後果：

- **可擴充性**；隨著請求量增加而擴充規模時，你需要啟動新的節點；而每個新節點都必須具備完整的那一長串功能，造成沉重的低效與成本（同樣地，即使是最便宜的方案，運行一個節點每月也要花費 1,000 美元）。
- **邊緣案例**；由於節點缺乏基本的保護機制，單一查詢就可能讓整個節點癱瘓。

<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 引擎採用一種稱為「次級基礎設施（secondary infrastructure）」的進階架構，來複製節點的資料。

<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 的交易（Transactions）資料
- 使用者 2 要求取得區塊 85 的日誌（Logs）資料
- 使用者 3 要求取得區塊 92 的區塊（Blocks）資料

<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（歸檔）：** 比完整節點更進一步。完整節點會清除不再需要用來驗證的條目，而歸檔節點則會保留一切（額外多出數 TB 的資料）。這些詳盡資料在更有效率地查詢資訊時非常好用，在少數應用情境中也很方便，但在大多數情況下都嫌過度。
- **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 引擎會為節點建立「快照（snapshot）」，這樣建立新節點時，系統就能從最近的「檢查點（checkpoint）」開始，大幅縮短同步過程所需的時間。

<EbookCta
  eyebrow="免費指南"
  title="自建 vs. 採購：區塊鏈基礎設施"
  description="在你雇用基礎設施團隊之前，先讀這篇：自建團隊在處理第一個正式請求之前，每年就可能花費 850K 至 1M 美元以上。查看完整的成本分析。"
  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)有助於評估延遲、成功率與失敗請求，並可與供應商對其架構的說法相互對照。

你的應用程式能否成功，取決於這個選擇。讓我們知道我們能如何幫上忙！