--- title: "Node RPC vs. Dedicated Clusters:為你的工作負載選擇合適的基礎設施" description: "了解 Alchemy 的兩種基礎設施模型如何運作、各自適用的情境，以及如何為你的團隊做出選擇。" --- # Node RPC vs. Dedicated Clusters:為你的工作負載選擇合適的基礎設施多數鏈上工作負載在多租戶基礎架構上都能運作良好。但隨著團隊規模擴大，一些問題便會浮現：我們需要專屬節點嗎？是否該隔離特定工作負載？實際的取捨是什麼？本指南將說明 Alchemy 的兩種基礎架構模式——[Node RPC](/rpc-api)（我們的共享基礎架構方案）與 [Dedicated Clusters](/dedicated-clusters)——各自如何運作、分別適用於哪些情境，以及你的團隊該如何思考這項決策。 ## Node RPC：多數工作負載的預設選擇 Node RPC 是 Alchemy 的正式環境級多租戶基礎架構，針對彈性擴展與操作簡便性進行了優化。其背後是 [Cortex](/blog/cortex)，這套引擎每年支撐了超過 1 兆美元的交易量，服務對象包括 [Robinhood](https://www.alchemy.com/dapps/robinhood)、Stripe、[Coinbase](https://www.alchemy.com/dapps/coinbase)、Circle、Chainlink 及 Polymarket。在 Node RPC 上，擴展幾乎是即時的。流量高峰會由節點叢集自動吸收。跨多個區域內建容錯移轉機制。計費方式以用量為基礎，成本會隨實際流量而非預先配置的容量調整。若想查看目前各供應商的共享 RPC 效能表現，可參考 Alchemy 的 [RPC provider benchmarks](https://www.alchemy.com/benchmarks)。 ## Dedicated Clusters：無窮的客製化，全代管服務 Dedicated Clusters 提供屬於你自己的節點基礎架構——由 Alchemy 提供、營運及維護，但依你的確切需求進行配置。與單節點的專屬方案不同，每個 cluster 會為每條鏈配置一組具備冗餘性的節點群，運行於 [Cortex](/blog/the-tech-behind-cortex) 之上，與 Node RPC 使用相同的引擎。你將在單租戶環境中獲得相同的 API 與可靠性保證。每個 cluster 皆設計為零停機運作。每個區域、每條鏈至少配置兩個以上的節點，可實現滾動式維護且不中斷服務。區塊層級的一致性確保每個節點回傳相同的鏈狀態視圖，消除因讀取過期或衝突資料而產生的錯誤。即時 Grafana 儀表板則讓你完整掌握節點健康狀況、請求模式與效能表現。隨著流量成長，我們會同步擴展你的 cluster——我們的自動化快照與部署能力，能以業界最快速度讓新容量上線。若遇到超出合約容量的突發流量高峰，你可以選擇啟用自動回退至 Alchemy 共享節點群，不會有請求遺失，也無需人工介入。每個 cluster 都會依你的確切需求進行配置： - **自訂 tracer 與二進位檔**直接部署於你的節點上，讓模擬、追蹤與索引作業更快速、更具成本效益 - **單租戶隔離**——符合 [SOC 2 Type II 合規標準](/blog/inside-alchemy-enterprise-grade-security-infrastructure)，你的環境中不會有其他客戶的流量、程式碼或資料 - **區域部署**，讓你能就近部署在自身系統堆疊、鏈基礎架構或使用者附近，降低延遲 - **自訂硬體配置**，依你的流量特性調整以達到最佳效能 - **固定月費**——不按請求計費，沒有意外費用 ## 何時該選擇 Dedicated Clusters Node RPC 已能妥善處理絕大多數工作負載。Dedicated Clusters 則是為那些有特定需求、無法透過多租戶基礎架構滿足的團隊所設計。以下是四種常見情境。 **自訂 tracer 或二進位檔。** 依賴非標準節點軟體的工作負載——例如自訂 EVM tracer、客戶端或二進位檔——需要能夠將自訂程式碼推送至節點的能力。Dedicated Clusters 原生支援此需求，因此非常適合依賴自訂 tracer 進行索引與事件處理的安全性與鑑識團隊。 **法規或內部隔離要求。** 某些合規框架與內部安全政策要求環境中不得有其他客戶的流量、程式碼或資料。Dedicated Clusters 提供單租戶隔離，配備審計就緒的控管機制與 SOC 2 Type II 合規認證——這是受監管金融機構的標準要求。 **區域部署需求。** Node RPC 已在廣泛的區域範圍內提供低延遲覆蓋。但若你的工作負載需要部署在該範圍之外的特定地理位置——例如與你的系統堆疊、定序器（sequencer）或驗證者（validator）位於同一區域——Dedicated Clusters 可部署在你所需的確切區域。這對於交易公司、DeFi 協定及高頻交易營運等每一毫秒都至關重要的場景尤其重要。 **以容量計費更有效率的高流量工作負載。** 對於極高吞吐量、多鏈的工作負載而言，以配置容量計算的固定月費，可能比按請求計費更具可預測性。若以上需求都不適用於你，Node RPC 同樣能提供業界頂尖的效能與可靠性，且無需額外的設定作業。 ## 為什麼不自行架設節點？我們合作過的許多團隊都曾考慮過——或目前正在管理——自己的節點基礎架構。這類經驗往往會走上一條熟悉的路徑：先是在招募人才、工具建置與監控系統上投入大量資源，接著是持續不斷的營運負擔，包括客戶端升級、網路變更，以及涵蓋每一條支援鏈的待命輪值。若想更深入了解這項取捨，可參考我們關於[自行架設節點的優缺點](/overviews/running-your-own-node)的概覽文章。這種風險會隨時間累積。一次錯過的升級會導致節點落後，請求開始失敗，面向客戶的交易隨之中斷——使用者無法完成交易、挫折感累積，每一分鐘的停機都意味著營收與信任的流失。此外，原本可用於產品開發的工程資源，反而被耗費在無助於業務差異化的基礎架構維護上。這正是 Dedicated Clusters 所要解決的問題。Alchemy 從部署、升級、監控到事故應變，全程一手包辦。 ## 混合式做法需要為特定工作負載使用 Dedicated Clusters 的團隊，通常並非所有工作負載都需要如此。最常見的正式環境架構是混合式的：對需要單租戶控管的鏈或工作負載使用 Dedicated Clusters，其餘則使用 Node RPC。兩者之間的遷移相當直接。兩種方案都使用相同的 Alchemy API——將工作負載導向 Dedicated 就如同將請求指向不同的端點 URL 一樣簡單，無需修改程式碼，也無需重新架構。這種做法讓團隊能在關鍵之處掌握單租戶控管能力，同時對其餘流量保留 Node RPC 的彈性與成本效益。 ## 比較 ## 如何做決定這項決策可歸結為四個問題。你的工作負載是否需要自訂 tracer 或二進位檔？你是否有法規或政策上的要求，需要單租戶隔離？你是否需要部署在 Node RPC 目前尚未覆蓋的區域？以容量計費對你的流量規模而言是否更具成本效益？若其中任一問題的答案是肯定的，那麼值得評估 Dedicated Clusters 或混合式架構。若所有問題的答案都是否定的，Node RPC 便是合適的選擇。無論哪種情況，後續的路徑都保有彈性。團隊可以先從 Node RPC 開始，日後再將特定工作負載遷移至 Dedicated，而不會影響現有的基礎架構。 ## 常見問題 ### 什麼是 Alchemy Node RPC？ Node RPC 是 Alchemy 的多租戶基礎架構，由 Cortex 提供支援。它針對彈性擴展與操作簡便性進行了優化：擴展近乎即時，內建跨多區域的容錯移轉機制，且計費方式以用量為基礎。 ### 什麼是 Alchemy Dedicated Clusters？ Dedicated Clusters 讓你擁有屬於自己的節點基礎架構，由 Alchemy 全程代管，並依你的確切需求進行配置。它們運行於單租戶環境中，支援自訂 tracer、區域部署、自訂硬體以及固定月費計價。 ### Node RPC 與 Dedicated Clusters 的主要差異是什麼？ Node RPC 是共享基礎架構，採用依用量計費方式，適用於多數工作負載。Dedicated Clusters 則提供單租戶隔離與自訂配置，適合有特定合規、效能或客製化控管需求的團隊。 ### 什麼時候該選擇 Dedicated Clusters 而非 Node RPC？若你需要自訂 tracer 或二進位檔、有法規或內部隔離要求、需要部署在特定區域，或運行高流量工作負載且以容量計費更具效率，Dedicated Clusters 便是合適的選擇。 ### 我可以同時使用 Node RPC 與 Dedicated Clusters 嗎？可以。常見的正式環境架構是混合式的：對需要單租戶控管的工作負載使用 Dedicated Clusters，其餘則使用 Node RPC。遷移作業就跟變更端點 URL 一樣簡單，無需修改程式碼。 ### Dedicated Clusters 會比 Node RPC 更難維護嗎？不會。兩者皆由 Alchemy 全程代管。部署、升級、監控與事故應變都由我們全程處理，你這端完全無需進行任何維護作業。 ### Node RPC 與 Dedicated Clusters 支援的 API 相同嗎？是的。兩者皆運行於相同的 Alchemy API 之上，因此在兩者之間遷移工作負載無需修改程式碼或重新架構。 ### 為什麼不自行架設節點，而要使用 Alchemy？自行架設節點意味著必須在招募人才、工具建置上投入大量資源，並承擔持續的營運負擔：客戶端升級、網路變更，以及涵蓋每一條支援鏈的待命輪值。Alchemy 為你處理這一切，讓你的工程團隊得以專注於產品開發，而非基礎架構維護。 ## 開始使用超過 70% 的頂尖鏈上應用程式運行於 Alchemy 之上。若你正在評估基礎架構選項——無論是整合供應商、取代自建系統，或是為未來擴展規模做準備——歡迎[聯絡我們的團隊](/contact-sales-dedicated-clusters)，為你的工作負載找到合適的配置方案。