--- title: "我們如何打造低延遲 RPC 基礎設施" description: "RPC 延遲是系統性問題，並非單一瓶頸。以下說明 Alchemy 如何在邊緣節點、路由、擴展、節點維運與測量等各環節降低延遲。" --- # 我們如何打造低延遲 RPC 基礎設施 錢包載入使用者餘額。交易應用程式在換幣前估算 gas。索引器在一次性作業中回填數個月的歷史資料。以上每一個動作都是一次 RPC 呼叫，而每一毫秒的延遲都會被螢幕前等待的真實使用者感受到。 RPC 延遲不是由單一原因造成，因此也無法靠單一手段解決。它來自請求路徑開銷、可避免的內部網路傳輸、路由效率不佳、突發流量高峰、鏈與節點的維運延遲、特定工作負載的瓶頸，以及測量不完整。只修好其中一項而忽略其他，只是把瓶頸移到別處。因此我們把延遲當作一個系統性問題來處理，投入我們所能掌控的每一層，並將 99.99% 的正常運行時間與平均 50 毫秒以下的回應時間，作為我們所支援的 100 多條鏈的基準線。 ## 我們做了什麼 Alchemy Edge Proxy', tooltip: "", icon: "", }, benefit: { title: "Faster response at the tail, up to 7.5x", tooltip: "", icon: "", }, id: 0, }, { cause: { title: "Avoidable internal network travel", tooltip: "", icon: "", }, built: { title: 'Closer service placement within the cluster', tooltip: "", icon: "", }, benefit: { title: "Less time lost inside our infrastructure", tooltip: "", icon: "", }, id: 1, }, { cause: { title: "Inefficient routing", tooltip: "", icon: "" }, built: { title: 'Contextual smart routing', tooltip: "", icon: "", }, benefit: { title: "Shorter infrastructure paths, up to 2.5x faster queries", tooltip: "", icon: "", }, id: 2, }, { cause: { title: "Traffic spikes", tooltip: "", icon: "" }, built: { title: 'Predictive scaling', tooltip: "", icon: "", }, benefit: { title: "Capacity ready before the surge (Usual: 30K RPS)", tooltip: "", icon: "", }, id: 3, }, { cause: { title: "Predictable throughput under load", tooltip: "", icon: "" }, built: { title: 'Purpose-built, elastic throughput', tooltip: "", icon: "", }, benefit: { title: "Stable performance when volume climbs", tooltip: "", icon: "", }, id: 4, }, { cause: { title: "Chain and node operational lag", tooltip: "", icon: "", }, built: { title: 'AI-managed node fleet', tooltip: "", icon: "", }, benefit: { title: "Upgrades detected, tested, and rolled out with less delay", tooltip: "", icon: "", }, id: 5, }, { cause: { title: "Workload-specific bottlenecks", tooltip: "", icon: "", }, built: { title: 'Product-specific optimization', tooltip: "", icon: "", }, benefit: { title: "Full product flows (World: 44% faster to mine) and heavy queries (Solflare: up to 20x faster archive) stay fast", tooltip: "", icon: "", }, id: 6, }, { cause: { title: "Incomplete measurement", tooltip: "", icon: "" }, built: { title: 'Benchmark methodology', tooltip: "", icon: "", }, benefit: { title: "Latency measured with success rate and failed requests", tooltip: "", icon: "", }, id: 7, }, ], }} /> ## Alchemy Edge Proxy 降低請求路徑開銷 邊緣層是門戶：是請求接觸到的第一個由 Alchemy 掌控的進入點。在請求抵達任何節點之前，它會先經過連線建立、TLS 協商、身份驗證與路由邏輯。每一步都會增加若干毫秒，而這些毫秒在尾部——也就是最慢的那批請求，使用者真正感受得到的那批——累積得最多。 Alchemy Edge Proxy 是我們為了把這些開銷從請求路徑中剝除而建置的層。透過在門戶而非堆疊更深處處理連線重用、身份驗證與路由決策，它削減了每個請求都要負擔的固定成本。結果是尾部 RPC 速度最高提升 7.5 倍。更深入的說明請參見 [Alchemy Edge Proxy](/blog/alchemy-edge-proxy)。 在底層，邊緣層運行在微核心代理架構之上，這是 [Cortex](/cortex) 的一部分：一個小型、穩定的核心掌管關鍵請求路徑，而身份驗證、速率限制、路由等模組則可獨立更新。由於邊緣層是我們端到端掌控的關鍵基礎設施層之一，我們可以持續改進它，不必等待任何其他人的網路。 ## 在我們的基礎設施內部：更近的部署位置、更聰明的路由、穩定的吞吐量 當請求進入我們的基礎設施後，距離與硬體依然會消耗時間。如果處理一次呼叫的各個服務彼此相距較遠，請求就會在任何實際工作展開之前，先花上數毫秒在它們之間傳輸。而當流量攀升時，共用的硬體會帶來那種表現為延遲不一致的變異性。 這正是 [Cortex](/cortex)（Alchemy 的智慧區塊鏈引擎）發揮主要作用之處。Cortex 是支撐我們低延遲數字的核心基礎設施投資，其中幾項具體機制在這裡特別關鍵： - 搭配 Kubernetes 親和性的 Pod 共置，讓彼此通訊最頻繁的服務留在同一台機器上，使請求維持在本地而不必跨機架跳轉。 - Istio 的地區感知路由會把內部流量導向最近的可用服務實例，在真正有幫助的情況下縮短基礎設施路徑。 - 數千台全球部署的裸機伺服器直接運行在專屬硬體上，沒有虛擬化開銷，讓吞吐量在高負載下依然保持穩定。 - Java 虛擬執行緒讓單一機器能處理遠多於傳統執行緒的並行請求，且不需承擔傳統執行緒的記憶體與 CPU 成本，這正是吸收流量高峰而不讓延遲攀升的關鍵。 這些機制共同削減了使用者從不會去想、但總是能感受到的傳輸時間，並在流量上升時維持穩定的效能。 ## 預測性擴展在高峰前備妥容量 鏈上流量的增長不會客氣地循序漸進。一次上線、一次鑄造、或一個市場事件，都可能在數秒內讓負載倍增，而在高峰過後才到位的容量，就是來得太晚的容量。 我們的預測性擴展邏輯會在需求出現之前預先備妥容量，而不是事後才反應，它持續觀察 CPU、記憶體、磁碟 I/O 與流量模式等訊號，在高峰到來前先行佈建。Usual 就是最好的證明：他們的峰值達到每秒 30,000 個請求，第一小時內處理了 3,800 萬個請求，並在 36 小時內突破 10 億個請求，而延遲在這波高峰下並未崩潰。 > "Alchemy 能夠提供近乎完美的可用性，在每秒處理巨量請求的情況下（我們的峰值是每秒 3 萬個請求，而且仍有餘裕），完全沒有任何卡頓或停機。而且這一切都是在很短的通知時間內做到的！" > > Adli Takkal-Bataille，[Usual](/case-studies/scaling-to-30000-requests-per-second) ## AI 管理的節點群組自動化讓節點維運保持最新 區塊鏈本身也在你腳下不斷變化。客戶端會發布更新，網路會排定硬分叉，而一個運行過時軟體的節點，就是一個給出緩慢或錯誤答案的節點。若靠人工處理，恰恰會在最需要精準的時刻引入延遲與風險。 我們的節點群組由一套完全自動化的代理系統管理，負責處理升級、測試與監控。更新會即時被偵測並套用，流程中內建自動化測試，因此強制性的網路升級與硬分叉絕不會被遺漏。若要在我們運行的每一條鏈上以人工方式完成這件事，根本不可能保持最新——這正是我們將其自動化的原因，也是為何我們能在 100 多條鏈上維持同樣低延遲標準，而非只照顧少數幾條。這套自動化機制是 [Cortex](/cortex) 的一部分，而 Cortex 正是驅動 Alchemy 平台的智慧區塊鏈引擎：[RPC APIs](/rpc-api)、資料 API、rollup，以及整個開發者技術堆疊的其餘部分。 ## 針對特定產品的優化改善完整的使用者流程 延遲不只關乎單一次呼叫。真實的產品會把多次呼叫串連在一起，而整個流程的速度取決於其中最慢的一環。使用者真正感受到的是整條路徑，而不是任何單一方法。 由 Tools for Humanity 打造、運行在 World Chain 上的 World，挖礦時間縮短了 44%，從 5.5 秒降到 3.1 秒；而 `alchemy_requestGasAndPaymasterAndData` 的 gas 估算延遲降低了 74%，從約 380 毫秒降到 100 毫秒。 > "在尋找基礎設施供應商時，我們最看重的是企業級的規模與支援。在我們所需的每一項產品上，Alchemy 都是毫無爭議的領先者——唯一合理的選擇。" > > Steven，[Tools For Humanity](/case-studies/world-onchain-performance) ## Solana 歸檔基礎設施降低重度查詢延遲 歷史與歸檔查詢本身就是難題。拉取大範圍的過去狀態是很重的工作，而在 Solana 這種高吞吐量的鏈上，若沒有為此打造的基礎設施，這類查詢可能會爬得很慢。我們在自訂的多區域 HBase 架構上，打造了 Solana 上最快的歸檔方法，這也是我們 Solana 平台的一部分。 Solflare 正是運行這類工作負載的案例，他們看到歸檔查詢速度最高提升 20 倍，大型歷史查詢的回應時間降到 200 毫秒以下，錢包回填工作在一分鐘內完成。 > "Alchemy 的 Archival RPC 跟上了 Solflare 的吞吐量，同時維持穩定在 <200 毫秒的回應時間。" > > Dusan K.，[Solflare](/case-studies/solflare) ## 基準測試方法同時衡量速度與可靠性 如果不誠實面對每個請求實際發生的情況，速度數字就毫無意義。一個隱藏了失敗或遺失呼叫的漂亮平均值，並不是快，而是誤導。 我們的基準測試方法在衡量延遲的同時，也衡量成功率與失敗請求，讓數字能反映真實工作負載會經歷的情況。這是我們對自己設下的標準，也邀請你用同樣的標準來檢視我們。你可以查閱完整的[基準測試方法](/blog/how-we-benchmark-rpc-performance)。 ## 目標：讓基礎設施快到讓人感覺不到它的存在 最好的基礎設施，就是沒有人會注意到的那種。當延遲夠低、可靠性夠高時，錢包就是會載入，換幣就是會確認，回填就是會完成。這套技術堆疊中沒有任何一層能單獨解決延遲問題，但它們加在一起，就構成了這樣的體驗。 親自查看這些數字。到 [Alchemy 基準測試頁面](/benchmarks)比較各家供應商，並閱讀我們[如何衡量 RPC 效能](/blog/how-we-benchmark-rpc-performance)的詳細方法，讓你不只是看結果，也能評判這套方法本身。當你準備好在此基礎上進行開發時，[免費開始使用](https://dashboard.alchemy.com/signup/)。 ## 常見問題 **是什麼造成 RPC 延遲？** RPC 延遲來自幾個各自獨立的來源：進入點的請求路徑開銷、內部服務之間可避免的傳輸、路由效率不佳、流量高峰、鏈與節點的維運延遲、特定工作負載的瓶頸，以及測量不完整。由於這些成因彼此獨立，沒有單一的修復能消除全部問題。 **單一項優化能解決 RPC 延遲嗎？** 不能。只修好一個成因，只是把瓶頸轉移到下一個成因上。要可靠地降低延遲，需要投入請求路徑的每一層，從邊緣層一路到節點基礎設施，以及效能的測量方式。 **在 RPC 基礎設施中，什麼是邊緣層？** 邊緣層是請求抵達的第一個由供應商掌控的進入點，是 RPC 流量的門戶。在此處而非堆疊更深處處理連線建立、身份驗證與路由，能消除每個請求原本都要負擔的固定開銷。 **Alchemy 如何誠實地衡量 RPC 延遲？** Alchemy 會把延遲與成功率、失敗請求一併衡量，而不是把它當作孤立的平均值。這樣可以防止看似快速的數字掩蓋了遺失或失敗的呼叫，讓結果真正反映實際生產工作負載會經歷的情況。 **預測性擴展如何應對流量高峰？** 預測性擴展會在需求出現之前預先備妥容量，而不是等高峰開始後才反應。這正是讓 Usual 能夠在 36 小時內維持每秒 30,000 個請求、累計超過 10 億個請求，而延遲在高峰期間不會惡化的原因。 **為什麼 Solana 歸檔查詢效能是一個獨立的問題？** 歸檔查詢需要拉取大範圍的歷史狀態，這本身就是很重的工作，而 Solana 的高吞吐量又讓這些範圍變得更大。專為此打造的歸檔基礎設施，正是讓這類查詢保持快速的關鍵，就像 Solflare 的歸檔查詢速度最高提升 20 倍所展現的那樣。