两侧同时换到之前的修订记录 前一修订版 后一修订版 | 前一修订版 后一修订版两侧同时换到之后的修订记录 |
zh:dev_blog_and_patchnote:introducing_quasar [2021/10/06 02:43] – user1529 | zh:dev_blog_and_patchnote:introducing_quasar [2021/10/06 03:05] – user1529 |
---|
<jumbotron> | <jumbotron> |
{{ https://images.ctfassets.net/7lhcm73ukv5p/kNlaK1AZFGTuu0aJscdij/31af215a5a4f46ba5ea1c5ac66a9bf9b/EVE_News_EN_1920x1080.jpg.jpg }} | {{ https://images.ctfassets.net/7lhcm73ukv5p/46XW9ifTdqYZOB7kylkqrr/37421a84f9ca688b71f89a3bac135bfb/EVE_News_EN_1920x1080.jpg}} |
| |
-------- | -------- |
| |
====== ====== | ====== 介紹新技術平台 : Quasar ====== |
| |
----- | ----- |
</jumbotron> | </jumbotron> |
| |
2021年 9月 14日, 這日代表 EVE 一個時代的結束, 亦代表 EVE 技術往前邁進的起點。隨着[[updates_to_skill_training | 新 NPE]] 新 NPE 內容的推出, 技能規劃的引入, EVE Online 以全新的方式走向未來。 | 2021年 9月 14日, 這日代表 EVE 一個時代的結束, 亦代表 EVE 技術往前邁進的起點。隨着[[improved_new_player_experience | 新 NPE]] 內容的推出, [[updates_to_skill_training | 技能規劃]] 的引入, EVE Online 以全新的方式走向未來。 |
| |
上一次修改網絡層架構已追溯到 2011年, CCP 引入自己的 IOCP - 輸入輸出完成端口 : CarbonIO, 這亦是後來臭名昭著 time dilation 時間膨脹的基礎。然後開展了 "Project Sanguine" 以處理 CarbonIO 接手後的其他問題。EVE 中的每一項改善最終尋底都是來自於與 Python 的全局解釋器鎖 (GIL) 的仔細調整。簡單地說, Python 架構一次只能做一件事。EVE 採用 Stackless Python, 通過 StacklessIO 和 CarbonIO 實現 IOCP, 以及圍繞時間膨脹的合作設計, 以保持新伊甸活着的錯覺。但 GIL 是不是需要爲所有內容服務呢? CCP 該如何利用現今硬件工業以爆炸式堆疊核心數量, 而不再是追求更高的核心時脈的升級趨勢呢? | 上一次修改網絡層架構已追溯到 2011年, CCP 引入自己的 [[https://zh.wikipedia.org/wiki/IOCP|IOCP - 輸入輸出完成端口]] : CarbonIO, 這亦是後來臭名昭著 time dilation 時間膨脹的基礎。然後開展了 "Project Sanguine" 以處理 CarbonIO 接手後的其他問題。EVE 中的每一項改善最終尋底都是來自於與 Python 的[[https://zh.wikipedia.org/wiki/%E5%85%A8%E5%B1%80%E8%A7%A3%E9%87%8A%E5%99%A8%E9%94%81|全局解釋器鎖 (GIL)]] 的仔細調整。簡單地說, Python 架構一次只能做一件事。EVE 採用 [[https://zh.wikipedia.org/wiki/Stackless_Python|Stackless Python]], 通過 StacklessIO 和 CarbonIO 實現 IOCP, 以及圍繞時間膨脹的合作設計, 以保持新伊甸活着的錯覺。但 GIL 是不是需要爲所有內容服務呢? CCP 該如何利用現今硬件工業以爆炸式堆疊核心數量, 而不再是追求更高的核心時脈的升級趨勢呢? |
| |
CCP 已經有許多與 Project Sanguine 相關的實驗, 最爲人熟悉的就是 EVE : Aether Wars。目標不是從根本上改變 EVE Online 的通信模型, 而是改變模擬模型。Project Sanguine 的目標是處理 EVE 伺服器日常中枯燥的部分。如果新伊甸不必處理那些對現場模擬相關的其他事情, 那麼在模擬近 9,000 名玩家同場作戰就可以更快。因此, Project Sanguine 就是要實現兩個目標:避免不必要的 GIL 溝通, 爲更重要的內容預留處理空間。 | CCP 已經有許多與 Project Sanguine 相關的實驗, 最爲人熟悉的就是 EVE : Aether Wars。目標不是從根本上改變 EVE Online 的通信模型, 而是改變模擬模型。相反久下, Project Sanguine 的目標是處理 EVE 伺服器日常中枯燥的部分。如果新伊甸不必處理那些對現場模擬相關的其他事情, 那麼在模擬[[two_guinness_world_records_titles_broken|近 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 年以來,互聯網本身亦發生了很大變化。 | 2016 年底, Project Sanguine 以 ESI 和 EVE Portal 第一次迭代出現在新伊甸宇宙中。通過這些項目, EVE Online 的服務器架構中建立了一個新的溝通模式:[[https://baike.baidu.hk/item/MOM/6530865|消息總線]]。利用這新的匯總方式, 重新發現了與 GIL 相關的瓶頸, 亦更清楚地了解了它們當中的處理步驟:message routing (消息路由), serialization (序列化) 和 transmission (傳輸)。如果一艘船在 1,000 艘船之間發射了一發激光, 那就有 1,000 條消息需要立即發送給整個戰場。伺服器必須將該消息副本尋址到 1,000 個目的地 (消息路由), 將該數據轉換為傳輸格式 (序列化), 然後通過線路發送數據(傳輸)。在大多數情況, CarbonIO 都能運作良好, 但速度始終受到 GIL 所限。CarbonIO 已經為 EVE Online 良好地服務了很長一段時間, 但自 2011 年以來,互聯網本身亦發生了很大變化。 |
| |
隨着新生態系統的改變, 要持續利用這架構就需要一個更標準化的協議。隨著整合 gRPC 技術, 伺服器可以以 protocol buffers (gRPC 的編寫標準), 一次處理消息路由及序列化的操作。當然最後仍然需要使用 GIL 來調度數據以進行傳輸, 但是之前兩步已在另外的處理線路上處理好。這代表所有傳輸、序列化和消息路由都發生在 GIL 之外。速度只受到其間的內存複製速度所限。 | 隨着新生態系統的改變, 要持續利用這架構就需要一個更標準化的協議。隨著整合 [[https://zh.wikipedia.org/wiki/GRPC|gRPC]] 技術, 伺服器可以以 [[https://zh.wikipedia.org/wiki/Protocol_Buffers|protocol buffers]] (gRPC 的編寫標準), 一次處理消息路由及序列化的操作。當然最後仍然需要使用 GIL 來調度數據以進行傳輸, 但是之前兩步已在另外的處理線路上處理好。這代表所有傳輸、序列化和消息路由都發生在 GIL 之外。速度只受到其間的內存複製速度所限。 |
| |
{{https://images.contentful.com/7lhcm73ukv5p/2qUtR4Gaxi3tcX54Qk1rX9/20020463bd360d14f21828c840e8f0d0/Picture1.png}} | {{https://images.contentful.com/7lhcm73ukv5p/2qUtR4Gaxi3tcX54Qk1rX9/20020463bd360d14f21828c840e8f0d0/Picture1.png}} |
| |
有了這先進的處理架構, 那實際上體現在那呢? 隨着 ESI 的引入, 和如 Kubernetes 的雲端處理系統, 以及需要更簡單的處理語言, 如 Go 的引入。這些技術一點一點積累到目前的生態系統中,CCP 亦開始以這些工具構建更多項目, 讓新伊甸以更現代化的形式呈現 : | 有了這先進的處理架構, 那實際上體現在那呢? 隨着 ESI 的引入, 和如 [[https://zh.wikipedia.org/wiki/Kubernetes|Kubernetes]] 的雲端處理系統, 以及需要更簡單的處理語言, 如 [[https://golang.org/|Go]] 的引入。這些技術一點一點積累到目前的生態系統中,CCP 亦開始以這些工具構建更多項目, 讓新伊甸以更現代化的形式呈現 : |
| |
{{https://images.contentful.com/7lhcm73ukv5p/7ewb7Pq017sQzNbSOb5Qnx/aa87b30e9e43a78f8c6fdd6109ed2c31/Picture4.png}} | {{https://images.contentful.com/7lhcm73ukv5p/7ewb7Pq017sQzNbSOb5Qnx/aa87b30e9e43a78f8c6fdd6109ed2c31/Picture4.png}} |
而然在第二天, 有一只猴子開始開始騷擾伺服器中的倉鼠: | 而然在第二天, 有一只猴子開始開始騷擾伺服器中的倉鼠: |
| |
{[https://images.contentful.com/7lhcm73ukv5p/6k8aye5ZSJ58SHpJxZwTub/8dd8d35f3d1425185a74ca85a231d0e1/Picture9.png}} | {{https://images.contentful.com/7lhcm73ukv5p/6k8aye5ZSJ58SHpJxZwTub/8dd8d35f3d1425185a74ca85a231d0e1/Picture9.png}} |
| |
你沒看錯, 這發現了一個錯誤引致了發送一個信息需要 50萬微秒, 則8分20秒。當中細節在此就不詳細論述了。以下是此錯誤狀態的重點:TQ 伺服器還在運作, 數千名玩家還在線上, 而且亦沒有影響到他們,(您可以看到大部分消息數值仍然圖表最底部)。這是因為 CCP 根本不與傳統意義上的 Tranquility 伺服器進行交流。沒有經 CarbonIO 到傳統代理, 然後轉到服務器節點, 然後再轉到數據庫。相反, Tranquility 專注於更重要的事情, 而 EVE 桌面客戶端正在通過 gRPC 與新的生態系統進行通信, 亦即是技能計劃服務使用自己的數據庫。 | 你沒看錯, 這發現了一個錯誤引致了發送一個信息需要 50萬微秒, 則8分20秒。當中細節在此就不詳細論述了。以下是此錯誤狀態的重點:TQ 伺服器還在運作, 數千名玩家還在線上, 而且亦沒有影響到他們,(您可以看到大部分消息數值仍然圖表最底部)。這是因為 CCP 根本不與傳統意義上的 Tranquility 伺服器進行交流。沒有經 CarbonIO 到傳統代理, 然後轉到服務器節點, 然後再轉到數據庫。相反, Tranquility 專注於更重要的事情, 而 EVE 桌面客戶端正在通過 gRPC 與新的生態系統進行通信, 亦即是技能計劃服務使用自己的數據庫。 |