深入 Cortex:打造低於 50ms、99.995% 正常運行時間基礎設施背後的工程

可靠的區塊鏈連線是不可妥協的條件。Cortex 是驅動 Alchemy 平台的智慧區塊鏈引擎，涵蓋 RPC APIs、data APIs、rollups，以及支撐整個開發者平台其餘部分的基礎設施。

它是從第一性原理出發建構而成，經過數兆次請求與超過七年資料的訓練，目標只有一個：提供在任何規模下都能可靠運作的基礎設施。

結果是平均回應時間低於 50 毫秒、99.995% 的正常運行時間，以及可擴展至數千萬使用者的吞吐量，且無需在你這端進行遷移、更換工具或變更設定。

如需跨供應商的公開比較數據，可參考 Alchemy 的 RPC 效能基準測試，其中涵蓋延遲、成功率與失敗請求。

這篇文章將深入探討 Cortex 背後的工程決策：橫跨延遲、吞吐量與可靠性各層面的系統性工作，正是這些數字得以實現的原因。

Cortex 如何降低延遲？

利用 kubernetes affinity 進行 Pod 協同定位

當你的應用程式發出請求時，該請求會在得到回應之前經過內部的多個服務。每次從一台伺服器轉移到另一台，都會產生延遲成本。

Pod 協同定位是指將通訊最頻繁的服務放在同一台實體機器上。Kubernetes 支援 affinity 規則來實現這一點，讓對延遲敏感的工作負載一起運作，而不是分散在不同機器或機架上。

結果就是：請求保持在本地處理，減少了網路跳點，也縮短了回應時間。

Istio 的位置感知路由

即使在同一個資料中心內，服務也會分散在不同節點與機架上。Istio 是負責管理內部服務通訊方式的網路層。

透過位置感知路由，Istio 能得知每個服務實例的實際位置，並在可行時將流量導向最近的可用實例。如果處理請求的服務正好運作在同一個節點上，流量就會留在當地，而不會跨越網路傳到較遠的實例。

這能減少不必要的網路跳點，而且不需要對應用程式程式碼做任何變更。

微核心代理架構

隨著基礎設施複雜度提升，緊密耦合的系統會變得難以安全變更。更新其中一個元件，可能會為整個堆疊帶來風險。

微核心方法讓核心保持精簡與穩定，只負責關鍵路徑。其餘部分，包括日誌記錄、速率限制、身分驗證與路由邏輯，則以疊加其上的模組化元件實作。

我們的代理層位於接收請求與後端系統之間。由於它採用微核心模型建構，各個模組可以獨立更新與部署，而不會影響核心請求路徑。這讓迭代速度更快，同時降低了出現回歸問題的風險。

直連資料中心路由

對於企業級工作負載，透過公開網際網路傳輸流量會帶來變數：不一致的延遲、封包遺失，以及會依你無法控制的條件而變動的壅塞路徑。

直連資料中心路由則避免了這些問題，透過私有的最佳化網路路徑，將企業流量直接傳送至我們的基礎設施。這消除了共用公開路由所帶來的不可預測性，並在每一跳都提供更穩定的低延遲表現。

Cortex 如何擴展規模？

數千台全球部署的裸機伺服器

大多數雲端基礎設施運作在虛擬機器上。虛擬化很有彈性，但也帶來額外開銷，因為 CPU、記憶體頻寬與 I/O 都與同一主機上的其他工作負載共用。

裸機是指直接在實體硬體上運作，中間沒有 hypervisor。每一份資源都專屬於你的請求。這消除了共用環境中的效能變異性，讓 Cortex 在高負載下依然維持穩定的吞吐量。

Java Virtual Threads

處理大量並行請求會對伺服器的執行緒模型造成壓力。傳統作業系統層級的執行緒相當消耗記憶體，而且隨著並行程度提高，管理情境切換的成本也會隨之增加。

Java Virtual Threads 於 Java 21 中推出，是由 JVM（而非作業系統）管理的輕量級執行緒。建立與切換這些執行緒的成本遠低於傳統執行緒，讓單一機器能夠處理更多並行任務，而不會產生通常會限制吞吐量的記憶體與 CPU 開銷。

實務上，這代表能更有效率地運用現有硬體，並擁有更大的餘裕來吸收流量高峰而不影響效能。

預測性擴展邏輯

標準的自動擴展會監控 CPU 使用率之類的門檻值，並在超過該門檻後才增加容量。這讓它在設計上就是被動的：需求先上升，基礎設施才隨後跟上。

我們的擴展邏輯會同時監控多項訊號，包括 CPU、記憶體、磁碟 I/O 與流量模式，再利用歷史資料來在高峰發生前預先判斷。容量會在需求之前而非之後就先配置好，藉此縮小流量增加與基礎設施吸收能力之間的落差。

AI 管理的節點叢集

我們的節點叢集由全自動化的代理系統管理，負責處理升級、測試與監控。更新會即時偵測並套用，且管道中內建了自動化測試，因此絕不會錯過強制性的網路升級與硬分叉。

這提升了正常運行時間，並在關鍵鏈上事件發生時消除了人為延遲的風險。

為什麼這些系統會相互加乘？

這些並非各自獨立的優化措施。Pod 協同定位降低了延遲，位置感知路由進一步降低了延遲。微核心架構讓我們得以在不引入不穩定性的情況下同時改善兩者。裸機硬體則為 Java Virtual Threads 提供了高效運作所需的資源。預測性擴展則確保容量能在需要之前就已備妥。

每一層都經過設計，目的是讓上層運作得更快、更具韌性。這正是「從第一性原理重新思考基礎設施」的意義所在，也是 Cortex 的立基之處。

這一切都在幕後運作。你這端不需要任何遷移、新工具，也不需要進行任何設定。我們持續打造基礎設施，讓你能持續打造自己的產品。

立即開始建置，或聯絡業務團隊洽詢客製化方案、整合問題等事宜。

常見問題

什麼是 Alchemy Cortex？

Cortex 是驅動 Alchemy 開發者平台的智慧區塊鏈引擎，涵蓋 RPC APIs、data APIs、rollups 與基礎設施。它從第一性原理出發建構，並經過數兆次請求與超過七年資料的訓練，以提供低於 50 毫秒的回應時間、99.995% 的正常運行時間，以及無需遷移或變更設定即可擴展的吞吐量。

Cortex 如何達成低於 50 毫秒的回應時間？

Cortex 利用 Kubernetes affinity 進行 Pod 協同定位，將頻繁通訊的服務放在同一台實體機器上；透過 Istio 的位置感知路由將流量導向最近的服務實例；採用微核心代理架構維持穩定的核心效能；並針對企業流量使用直連資料中心路由，透過私有網路傳輸。

Cortex 的微核心代理架構是什麼？

微核心方法讓負責處理請求的核心系統保持精簡與穩定，而日誌記錄、速率限制、身分驗證與路由邏輯則以模組化元件實作，這些元件可以獨立更新，不會影響關鍵路徑，也不會為整個堆疊帶來風險。

Cortex 在擴展規模方面有何不同之處？

Cortex 採用預測性擴展邏輯，同時監控包括 CPU、記憶體、磁碟 I/O 與流量模式在內的多項訊號，再利用歷史資料在需求高峰出現前預先配置容量，而不是等超過門檻後才做出反應。

為什麼 Cortex 使用裸機伺服器而非虛擬機器？

裸機伺服器直接在實體硬體上運作，中間沒有 hypervisor，每一份資源都專屬於請求使用，消除了共用虛擬化環境中的效能變異性與開銷，在高負載下依然能提供穩定的吞吐量。

什麼是 Java Virtual Threads，Cortex 為何使用它？

Java Virtual Threads 是由 JVM（而非作業系統）管理的輕量級執行緒，其建立與情境切換成本遠低於傳統執行緒，讓單一機器能夠處理更多並行任務，而不會產生通常會限制吞吐量的記憶體與 CPU 開銷。

Cortex 如何管理區塊鏈節點升級？

Cortex 採用全自動化的代理系統，即時處理升級、測試與監控，管道中內建自動化測試，因此絕不會錯過強制性的網路升級與硬分叉，藉此提升正常運行時間並消除人為延遲的風險。

使用 Cortex 是否需要進行遷移或設定？

不需要。你這端不需要任何遷移、新工具或設定，Cortex 在幕後運作，自動帶來基礎設施上的改進，讓你能持續打造自己的產品。