差别

这里会显示出您选择的修订版和当前版本之间的差别。

--- zh:dev_blog_and_patchnote:introducing_quasar [2021/10/06 03:51] – user1529
+++ zh:dev_blog_and_patchnote:introducing_quasar [2021/10/06 04:21] (当前版本) – user15
@@ 行 14: / 行 14: @@
 年 9月 14日, 這日代表 EVE 一個時代的結束, 亦代表 EVE 技術往前邁進的起點。隨着[[improved_new_player_experience | 新 NPE]] 內容的推出, [[updates_to_skill_training | 技能規劃]] 的引入, EVE Online 以全新的方式走向未來。
-上一次修改網絡層架構已追溯到 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 該如何利用現今硬件工業以爆炸式堆疊核心數量, 而不再是追求更高的核心時脈的升級趨勢呢?
+上一次修改網絡層架構已追溯到 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 伺服器日常中枯燥的部分。如果新伊甸不必處理那些對現場模擬相關的其他事情, 那麼在模擬[[two_guinness_world_records_titles_broken|近 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 溝通, 爲更重要的內容預留處理空間。
 年底, 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 年以來，互聯網本身亦發生了很大變化。
@@ 行 24: / 行 24: @@
 {{https://images.contentful.com/7lhcm73ukv5p/2qUtR4Gaxi3tcX54Qk1rX9/20020463bd360d14f21828c840e8f0d0/Picture1.png}}
-有了這先進的處理架構, 那實際上體現在那呢? 隨着 ESI 的引入, 和如 [[https://zh.wikipedia.org/wiki/Kubernetes|Kubernetes]] 的雲端處理系統, 以及需要更簡單的處理語言, 如 [[https://golang.org/|Go]] 的引入。這些技術一點一點積累到目前的生態系統中，CCP 亦開始以這些工具構建更多項目, 讓新伊甸以更現代化的形式呈現 :
+有了這先進的處理架構, 那實際上體現在那呢? 隨着 ESI 的引入, 如 [[https://zh.wikipedia.org/wiki/Kubernetes|Kubernetes]] 的雲端處理系統；以及需要更簡單的處理語言, 如 [[https://golang.org/|Go]] 的引入。這些技術一點一點積累到目前的生態系統中，CCP 亦開始以這些工具構建更多項目, 讓新伊甸以更現代化的形式呈現 :
 {{https://images.contentful.com/7lhcm73ukv5p/7ewb7Pq017sQzNbSOb5Qnx/aa87b30e9e43a78f8c6fdd6109ed2c31/Picture4.png}}
@@ 行 48: / 行 48: @@
 {{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 與新的生態系統進行通信, 亦即是技能規劃服務使用自己的數據庫。
 {{https://images.contentful.com/7lhcm73ukv5p/6dtEIV0AkbP3I6l1FhABMM/004f56990d9327b80a98cce6a1847cbf/Picture10.png}}