# 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 问题