eve_news_en_1920x1080.jpg


介紹新技術平台 : Quasar



原文鏈接: https://www.eveonline.com/news/view/introducing-quasar

2021年 9月 14日, 這日代表 EVE 一個時代的結束, 亦代表 EVE 技術往前邁進的起點。隨着 新 NPE 內容的推出, 技能規劃 的引入, EVE Online 以全新的方式走向未來。

上一次修改網絡層架構已追溯到 2011年, CCP 引入自己的 IOCP - 輸入輸出完成端口 : CarbonIO, 這亦是後來臭名昭著 time dilation 時間膨脹的基礎。然後開展了「Project Sanguine」以處理 CarbonIO 接手後的其他問題。EVE 中的每一項改善最終都是沿於與 Python 全局解釋器鎖 (GIL) 的仔細調整。簡單地說, Python 架構一次只能做一件事。EVE 採用 Stackless Python, 通過 StacklessIO 和 CarbonIO 實現 IOCP, 以及圍繞時間膨脹的合作設計, 以保持新伊甸活着的錯覺。但 GIL 是不是需要爲所有內容服務呢? CCP 該如何利用現今硬件工業以爆炸式堆疊核心數量, 而不再是追求更高的核心時脈的升級趨勢呢?

CCP 已經有許多與 Project Sanguine 相關的實驗, 最爲人熟悉的就是 EVE : Aether Wars。目標不是從根本上改變 EVE Online 的通信模型, 而是改變模擬模型。相比之下, Project Sanguine 的目標是處理 EVE 伺服器日常中枯燥的部分。如果新伊甸不必處理那些對現場模擬相關的其他事情, 那麼在模擬近 9,000 名玩家同場作戰就可以更快。因此, Project Sanguine 就是要實現兩個目標:避免不必要的 GIL 溝通, 爲更重要的內容預留處理空間。

2016 年底, Project Sanguine 以 ESI 和 EVE Portal 第一次迭代出現在新伊甸宇宙中。通過這些項目, EVE Online 的服務器架構中建立了一個新的溝通模式:消息總線。利用這新的匯總方式, 重新發現了與 GIL 相關的瓶頸, 亦更清楚地了解了它們當中的處理步驟:message routing (消息路由), serialization (序列化) 和 transmission (傳輸)。如果一艘船在 1,000 艘船之間發射了一發激光, 那就有 1,000 條消息需要立即發送給整個戰場。伺服器必須將該消息副本尋址到 1,000 個目的地 (消息路由), 將該數據轉換為傳輸格式 (序列化), 然後通過線路發送數據(傳輸)。在大多數情況, CarbonIO 都能運作良好, 但速度始終受到 GIL 所限。CarbonIO 已經為 EVE Online 良好地服務了很長一段時間, 但自 2011 年以來,互聯網本身亦發生了很大變化。

隨着新生態系統的改變, 要持續利用這架構就需要一個更標準化的協議。隨著整合 gRPC 技術, 伺服器可以以 protocol buffers (gRPC 的編寫標準), 一次處理消息路由及序列化的操作。當然最後仍然需要使用 GIL 來調度數據以進行傳輸, 但是之前兩步已在另外的處理線路上處理好。這代表所有傳輸、序列化和消息路由都發生在 GIL 之外。速度只受到其間的內存複製速度所限。

有了這先進的處理架構, 那實際上體現在那呢? 隨着 ESI 的引入, 如 Kubernetes 的雲端處理系統;以及需要更簡單的處理語言, 如 Go 的引入。這些技術一點一點積累到目前的生態系統中,CCP 亦開始以這些工具構建更多項目, 讓新伊甸以更現代化的形式呈現 :

第一項是 Activity Tracker (生涯/成就系統)。它跟跡着你 EVE 的軌跡。另一個衍生項目, Opportunities (機遇) 則試圖預測玩家的發展並突出新伊甸中有趣的部分。這架構亦被利用於 Abyssal Proving Grounds leaderboards (深淵競技場排行榜)。開發團隊利用這新消息傳遞架構進行了大量工作, 爲新伊甸建構更多生態系統。

在 Skill Plans (技能規劃) 項目以前, 每一個項目都是以 CarbonIO 向 Tranquility 挖掘數據。但 技能規劃則不一樣, 它不僅通過能 gRPC 進行通信,而且亦不接觸 Tranquility 或其數據庫。

爲甚麼繞過 Tranquility 及其數據庫如此重要? 要真正理解這一點, 必須談論當遇到錯誤時所發生的事。CCP使用了多種技術和工具查看分析新伊甸的數據, 其中 Honeycomb.io 被用來追踨技能規劃項目正式推出時的運作情況。

大體上可以看出性能還可以, 而且很大的改進空間:

而然在第二天, 有一只猴子開始開始騷擾伺服器中的倉鼠:

你沒看錯, 這發現了一個錯誤引致了發送一個信息需要 50萬微秒, 則8分20秒。當中細節在此就不詳細論述了。以下是此錯誤狀態的重點:TQ 伺服器還在運作, 數千名玩家還在線上, 而且亦沒有影響到他們,(您可以看到大部分消息數值仍然圖表最底部)。這是因為 CCP 根本不與傳統意義上的 Tranquility 伺服器進行交流。沒有經 CarbonIO 到傳統代理, 然後轉到服務器節點, 然後再轉到數據庫。相反, Tranquility 專注於更重要的事情, 而 EVE 桌面客戶端正在通過 gRPC 與新的生態系統進行通信, 亦即是技能規劃服務使用自己的數據庫。

就如上月, CCP 再一次測試不進行每日維護。其中一個新通信系統的優點是, 它不需要停機維護。亦不需要 TQ 重啟來更新其內容。亦無需將補丁部署到服務器或桌面客戶端。這亦是 Project Sanguine 成為 EVE 的新技術平台 Quasar 的一里程碑。現在是時候給這項目一個名稱了, 這樣日後就能更易理解和引用, 同時讓玩家更深入地了解 EVE 的技術進步最近發生了甚麼, 以及它們如何與遊戲一起進步邁進蓬勃發展的第三個十年。恰巧的是, 目前 EVE 季度主題名字是 Gateway, 也預示著 gRPC 網關的直接使用。



那之後呢?

CCP 正致力於更新各舊服務, 當中有兩大願景 : 以 Quasar 平台建立更多基礎功能, 不僅限於技能規劃; 和規範古老的系統, 為日後更快的迭代鋪平道路。

這對玩家們意味著什麼? CCP 能在更多不同媒介上提供更多更強大的服務。

  • 最后更改: 2021/10/06 04:21
  • user15