# EVE 在線架構 > 原文： [http://highscalability.com/blog/2008/10/22/eve-online-architecture.html](http://highscalability.com/blog/2008/10/22/eve-online-architecture.html) *抱歉，這篇文章的內容顯然沒有從舊的 HighScalability 網站過渡，這一切都弄糟了，但仍有一些有用的內容...* [EVE Online](http://www.eve-online.com/) 是“世界上最大的游戲宇宙”，這是 CCP 制作的大型多人在線游戲（ [MMO](http://en.wikipedia.org/wiki/MMO) ）。 對于 MMOG，EVE Online 的體系結構不常見，因為它不會將播放器負載分配給不同的服務器或分片。 而是，同一集群處理整個 EVE Universe。 將此與第二生命網格的[體系結構進行比較很有趣。 他們如何設法擴展規模？](http://highscalability.com/second-life-architecture-grid) ## 信息來源 * [EVE Insider Dev Blog](http://myeve.eve-online.com/devblog.asp) * [EVE 在線常見問題解答](http://www.eve-online.com/faq/faq_07.asp) * [大規模-Eve 演變：Eve Online 的服務器模型](http://www.massively.com/2008/09/28/eve-evolved-eve-onlines-server-model/)及其在 Slashdot 上的[討論](http://games.slashdot.org/games/08/10/02/2137251.shtml) * [EVE 在線論壇](http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229) * [大型多人游戲開發 2](http://www.amazon.com/gp/product/1584503904?ie=UTF8&tag=innoblog-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1584503904) ## 平臺 * [用于服務器和客戶端游戲邏輯的無堆棧 Python](http://www.stackless.com/) 。 它使程序員可以享受基于線程的編程的好處，而不會出現與常規線程相關的性能和復雜性問題。 * SQL 服務器 * 具有 [SSD](http://en.wikipedia.org/wiki/Solid-state_drive) 的刀片服務器，可實現高 IOPS * 計劃將 [Infiniband](http://en.wikipedia.org/wiki/Infiniband) 互連用于低延遲網絡 * 成立于 1997 年 * 約 30 萬活躍用戶 * 多達 40K 并發用戶 * 涉及數百艘船的戰斗 * 每天 2.5 億筆交易 * **代理刀片**-這些是 EVE 集群的面向公眾的部分-它們負責建立玩家連接并在集群的其余部分內建立玩家通信。 * **SOL 刀片**-這些是寧靜的主力軍。 集群分為 90-100 個 SOL 刀片，每個刀片運行 2 個節點。 節點是在一個核心上運行的主要 CPU 密集型 EVE 服務器進程。 有一些 SOL 刀片專用于一個繁忙的太陽能系統，例如 Jita，Motsu 和 Saila。 * **數據庫群集**-這是 EVE Online 的持久層。 運行中的節點與數據庫進行大量交互，當然，與游戲有關的所有事情都駐留在這里。 多虧了固態驅動器，數據庫才能夠滿足 Tranquility 產生的巨大 I / O 負載。 * 借助創新理念，MMO 游戲可以在同一場戰斗中擴展至數百名玩家。 * SSD 實際上將在某種程度上彌合內存與磁盤之間巨大的性能差距。 * 低延遲的 Infiniband 網絡互連將支持更大的集群。 ### 得到教訓 * 關于 EVE Online MMOG 的架構，有許多有趣的事實，例如使用 Stackless Python 和 SSD。 * 查看信息源，以獲取有關 EVE Online 游戲的開發和操作的詳細見解。 * 涉及 1000 多艘戰艦的戰斗 不，不，不超過一千次 如果您想為大多數參與其中的人提供可遠程玩的體驗，那么我們正在將 400 或 500 場戰斗視為絕對最大的戰斗。 以上所有內容均無法播放，并可能導致節點/游戲崩潰。 但是我不反對其他任何數字，總的來說，它們都是運行 Eve-O 宇宙的集群怪物。 我打電話給 BS-我們通常會在 60-100 次船戰中使節點崩潰。 感謝您的反饋。 我已經更新了條目。 他們最近進行了更新，并設法使系統能夠容納一千艘船，當然，這并不意味著可以進行如此大規模的戰斗，而只是意味著我們要說的系統 吉塔，不會崩潰。 但是 400-500 場戰役可能還沒有我們曾經相信的那么遙遠。 他們在 CCP 所做的大量更新，令我感到驚訝的是，定期進行此類戰斗。 當然，我不會參加這些活動，因為我是一個膽小鬼，而我更喜歡將我的 HIC 放在一塊。 安全飛行。 是和不是 我是 Goonswarm 公司的首席執行官，并在大多數星期內與 1000 多名玩家一起參加戰斗。 自從 CCP 啟動“無棧 IO”并在服務器端升級到 64 位體系結構以來，我們注意到服務器產生的延遲有了明顯的改善。 如果我們在某個節點承受壓力之前 24 小時警告 CCP，他們將為我們加強該節點，并且在 99％的時間里戰斗將是可玩的。 您還將注意到，無需等待 10 分鐘即可加載網格，就可以取消 jita 的對接，而幾個月前情況并非如此。 即使是最高端的圖形卡/ CPU 組合也將難以在屏幕上顯示和跟蹤成千上萬的單個對象（船舶，導彈，沉船，太空艙，戰斗機&無人機），因此，如今的大型戰斗通常都依賴于 您的 PC 而不是服務器響應能力。 我可以看到服務器體系結構如何應用于第一人稱游戲，但是設計上的挑戰使正確設置變得異常困難。 這不僅僅是公司從 CCP 購買設計或引擎的問題，對于第一人稱視角的游戲，還需要徹底消除和重新設計。 不幸的是，游戲行業的主要投資者似乎不愿意冒險冒險冒險，但是如果有人管理它，那將是一場噩夢。 [http://www.mustuniversity.com/Schools-Majors/Applied-Arts/Architecture.html“](<a rel=) >在線架構學位 即使是最高端的圖形卡/ CPU 組合也將難以在屏幕上顯示和跟蹤成千上萬的單個對象（船舶，導彈，沉船，太空艙，戰斗機&無人機），因此，如今的大型戰斗通常依賴于 您的 PC 而不是服務器響應能力。 [http://www.carrentaladvice.net/“](<a rel=) >租車 我認為，超過 500 艘船的一切都不過分。 我對當前的限制非常滿意，因為無論如何我都會避免出現大規模的污垢。 戴夫 [http://www.pilkingtonselfcleaningglass.co.uk/where-to-use/glass-doors/index.html](<a rel=) “ >玻璃門 如果我們在某個節點承受壓力之前 24 小時警告 CCP，他們將為我們加強該節點，并且在 99％的時間里戰斗將是可玩的。 [http://www.livescores.com.sg/“](<a rel=) >實時比分 Python 非常慢……它是最慢的語言之一。 它可能比 C ++慢 10 倍。 一些用 python 編寫的高級科學庫實際上是在數學庫的后臺使用 C ++，但我無法想象在這種情況下。 作為一個業余愛好者的開發人員，我仍然不明白為什么 python 可以用于如此大的任務，特別是因為與更傳統的語言相比，編碼（IMO）看起來像地獄。 其次，雖然我沒有完全了解此問題，但我想知道它們如何處理跨節點的持久性... 在我看來，如果不先從數據庫中讀取原始位置，您甚至根本無法進行基本的健全性檢查。 您可以根據位置和上次輸入來假設它們在單個幀中的位置，但是當它們在游戲中越過節點行時，它仍然被寫入服務器機架中某個節點上的持久數據庫中，而突然之間 在他們的新節點上重新同步。 他們甚至可能會反復跳越節點線，從而濫用這種與冷卻時間不同步的方式。 在這種情況下，我假設每個區域都有某種加載屏幕，這可能會解決此問題。 不過，盡管如此，我還是希望有一種方法可以使它更順暢，以便可以將其集成到比單獨的太陽系更為緊密的游戲世界中。.我現在正在研究類似的東西。 如果它平滑地滑行，那么理論上您可以提高節點的分辨率，直到您可以一次處理 2000 個播放器為止，只需橫向擴展即可，而不是每次都像 Jita 那樣使用大型專用服務器，但是跨節點 通信會很瘋狂，但我仍在設法解決這一問題，以避免數據庫上出現 IO 問題