如何在零停機下遷移 RPC 供應商

最後更新：2026年7月14日1 分鐘閱讀

團隊會拖延更換 RPC 供應商，因為感覺上像是要重建整個系統。但實際上多半只需要幾個小時的設定。每家主要供應商都採用相同的 JSON-RPC 標準，所以你的應用程式今天送出的請求，明天換到新供應商時仍然適用。遷移 RPC 供應商是端點的替換，不是重寫。

剩下的工作都在替換本身之外：找出所有端點 URL 藏身的地方、盤點那些無法直接搬過去的特定供應商呼叫、以及依序切換流量而不讓使用者察覺。

什麼是「即插即用」的端點相容性？

即插即用的端點相容性，是指兩個 RPC 供應商對於標準 JSON-RPC 方法能接受相同的請求，並回傳相同的回應。應用程式只要改變呼叫的端點 URL，就能切換供應商。方法名稱、參數、回應格式都維持不變，所以標準介面完全不需要修改程式碼。

這種相容性來自協定本身，而不是供應商之間的協議。eth_call、eth_getLogs、eth_sendRawTransaction，以及 eth_*、net_*、web3_* 系列的其他方法，都是由 Ethereum JSON-RPC 規範所定義，任何正經的供應商都會按照規範實作。串流也是一樣的道理。透過 WebSocket 的 eth_subscribe，在我們的訂閱端點上傳送的 newHeads、logs 和 newPendingTransactions 串流，和其他主要供應商上的是一樣的。

以下是我們的端點格式，與大多數其他供應商採用的格式對照：

text

Copied

Alchemy:         https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY
Other providers: https://your-endpoint-name.provider.example/YOUR_AUTH_TOKEN/

兩者都是路徑中帶有密鑰的 URL。如果你的端點存在環境變數裡，遷移標準流量就只是改變這個變數的值。這也是為什麼「保留一個備援 RPC 端點」這項標準的可靠性建議，同時也是遷移保險。你為了提升可用性而加入的備援機制，正是你用來切換的機制。

標準 JSON-RPC 呼叫在新供應商上不需修改即可執行。真正需要處理的地方，是你的應用程式依賴特定供應商功能之處，而找出這些地方正是盤點要做的事。

遷移前應該盤點什麼？

供應商遷移中大多數意外都是切換之後才被發現，但每一個其實都能在切換前找出來。對一般規模的程式碼庫來說，盤點大約花一兩個小時。

找出所有端點參照。 端點 URL 累積的地方比任何人記得的都多。搜尋環境變數檔、Hardhat 和 Foundry 設定、Docker 映像檔、CI pipeline，以及前端建置檔案中，目前供應商的網域和任何寫死的 URL。漏掉的那一個，通常藏在某個好幾個月沒人打開過的排程工作或 CI pipeline 裡。

盤點供應商前綴方法。 大多數供應商都會提供帶有廠商前綴的便利方法（我們的是 alchemy_），這些方法無法跨平台搬移。Token 查詢對應到 Data API 的等效方法，例如 alchemy_getTokenBalances，轉帳紀錄則對應到 alchemy_getAssetTransfers。等效方法是存在的，但回應格式不同，所以每一個都要當成小規模的程式碼修改來處理，而不是單純找換字串。

檢查你的驗證方式。 URL 路徑中的金鑰可以直接搬移。如果你用 x-token header 或 JWT 來驗證，這些控制項就需要在新供應商上重新建立。在我們這邊，網域和 IP 白名單設定在 Alchemy 儀表板中，只需要幾分鐘就能完成。

依照新的計費模型重新估算流量成本。 這是盤點項目中會影響帳單而不是程式碼的一項。許多供應商是以固定的每秒請求數來計費。我們則是以運算單位計費，像 eth_blockNumber 這種輕量呼叫的成本比 eth_getLogs 這種重量呼叫低，而吞吐量是在滾動時間窗內的運算單位速率，而不是固定的請求數上限。這種差異影響是雙向的：以日誌為主的索引工作負載，消耗的額度會比請求數字所顯示的快，而輕量輪詢工作負載消耗的則會較少。大多數團隊會在切換前，用自己流量最高峰的一小時去對照我們的定價，而不是用每月總量去猜測。

檢查 trace 和 debug 方法的方案限制。 debug_ 和 trace_ 方法在大多數供應商上都依方案限制。在 Alchemy 上，這些方法在按用量付費方案和企業方案上可用，但免費方案不行，所以如果你在免費端點上跑概念驗證，要預期 trace 呼叫在那裡會失敗，儘管其他一切都能正常運作。

以上這些項目都不會阻擋遷移，但加總起來會決定遷移的範圍。對大多數應用程式而言，盤點結束時會得到一份環境變數的簡短清單、一兩個方法對應，以及一個定價估算。

如何做到零停機切換？

零停機模式和團隊用於資料庫遷移的模式相同：新舊並行執行，分階段搬移流量，並在新路徑贏得信任之前，保持舊路徑暢通。

客戶端函式庫讓並行階段幾乎零成本。viem 的 fallback transport 接受一份有序的端點清單，一個失敗就往清單下一個移動：

typescriptCopied
import { createPublicClient, fallback, http } from "viem";
import { mainnet } from "viem/chains";
const client = createPublicClient({
chain: mainnet,
transport: fallback([
  http("https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"),
  http("https://your-endpoint-name.provider.example/YOUR_AUTH_TOKEN/"),
]),
});

把新供應商放在第一位、舊供應商放在第二位，每個請求都會先試新端點，失敗再退回原本就能用的那個。切換期間最壞的情況，就是你現在的設定。ethers.js 在 FallbackProvider 中提供相同的模式，還有一個法定人數（quorum）選項，會查詢多個供應商，並在它們達成一致時才接受結果，讓你在客戶端內部就能做到跨供應商的一致性檢查。

流量搬移的順序比搬移速度更重要，原則是：先讀後寫。讀取是無狀態的，也容易驗證，所以應該及早把讀取流量導向新端點，並比對回傳結果。在兩個供應商上都執行你最重的查詢，例如針對你合約最繁忙區塊範圍的 eth_getLogs，以及針對核心合約的 eth_call，然後比較回應結果。交易送出要最後搬移，等讀取都驗證無誤之後才進行，因為讀取失敗頂多重試，寫入失敗就是一張客服工單。

WebSocket 訂閱需要多一個步驟。訂閱綁定在建立它的連線上，所以不會自動容錯切換，而是會中斷，你必須重新建立。計畫在新端點上重新訂閱，並用 eth_getLogs 查詢重新連線期間經過的區塊，補上缺口，確保不漏掉任何事件。我們的 WebSocket 最佳實務也建議把訂閱範圍盡量縮小，這樣重新訂閱和補資料的成本都會更低。

並行執行期間有兩件事值得放上儀表板。第一是區塊高度落後。兩個健康的供應商在任何時刻都可能停在稍微不同的鏈頭位置，所以應該針對新端點持續落後舊端點的情況發出警示，而不是針對瞬間的差異。第二是錯誤格式。速率限制的回應在不同供應商間並不相同。以 HTTP 來說，我們回傳帶有 Retry-After header 的 429；以 WebSocket 來說，同樣的限制會以沒有 header 的 JSON-RPC 429 錯誤呈現。在讓新端點承載正式流量之前，先在你使用的兩種傳輸方式上測試你的重試邏輯。

大多數團隊會讓並行階段跑一兩天的正式流量，再把新端點設為預設。舊端點繼續設定為備援，直到其計費週期結束。整個過程中，回退隨時只要一個設定變更就能完成，這就是零停機在實務上的意義。事情仍然可能出錯，只是不需要影響到你的使用者。