游戏中的混合服务器技术：深入剖析 Destiny 2的联网模型

Destiny 2，由 Bungie 开发，采用两种联网技术的组合，形成了一种区别于大多数在线射击游戏的混合模型。他们的方案结合了两种传统方法的优势，同时缓解了各自固有的一些缺陷。

本文基于 Bungie 工程师在两场 GDC 演讲中的见解，这些内容我们此前已在本博客中详细报道。Justin Truman，如今是 Bungie 的工作室负责人，在 GDC 2015 的 “Shared World Shooter: Destiny's Networked Mission Architecture” 中，讲解了 Destiny 共享世界背后的联网任务架构（相关报道见：《命运2》的网络架构 - 多人游戏深度解析）。John Chu，如今是 Bungie 中央技术在线部门的首席技术项目经理，在 GDC 2022 的 “Bringing Players Together: Building Cross Play for Destiny 2” 中作了演讲（相关报道见：开发《命运2》的跨平台联机 - 游戏后端深度解析），详细说明了将该架构扩展到七个平台需要做些什么。这两场演讲合在一起，清楚地展示了 Bungie 的混合联网模型是如何被设计、扩展并在长期中加固的。

理解点对点和客户端-服务器模型

要理解 Bungie 的做法，先要了解他们组合的两块基础构件。点对点联网是一种直接通信形式，客户端（玩家）彼此互动，不需要中介。它的主要优势在于延迟更低。不过，正如我们稍后会看到的，它往往会带来安全和隐私方面的担忧。

另一方面，客户端-服务器模型通过一台专门的服务器来托管游戏，提供稳定性和一致性，但由于玩家与服务器之间的地理距离，可能会引入延迟。

Destiny 2独特的混合模型

Bungie 从一开始的目标，正如 Truman 所描述的，是“模糊单人和多人体验之间的界线”，让玩家只需点击“play Destiny”就能遇到其他人，而无需传统的配对大厅。要做到这一点，需要一种传统专用服务器或纯 P2P 方法都无法单独提供的联网模型。

这个方案有三个并行工作的不同层。

• 共享区域（P2P）：第一层是 P2P 层。共享区域内的玩家彼此直接通信，形成 Bungie 所称的点对点“气泡”。这些都是直接的客户端到客户端连接，旨在让移动和即时互动保持高响应，并且让 Bungie 能把这些“气泡”连接起来，使陌生玩家无需大厅或加载界面就能在任务中途自然相遇。

• 物理宿主（专用服务器）：第二层是物理宿主，在 Destiny 2 中它运行在专用服务器上，而不是玩家的机器上。这是对 Destiny 1 最顽固问题之一——主机迁移——的有意修复。当承载物理的玩家离开会话时，游戏会卡顿甚至彻底崩溃。把这项职责转移到专用服务器上，消除了对任何单个玩家连接的依赖，使会话无论谁加入或离开都保持稳定。

• 活动宿主（用于任务状态的专用权威进程）：第三层是活动宿主，一个为任务状态量身打造的轻量化云端进程，Truman 的团队只让它运行任务逻辑严格需要的状态。不是子弹轨迹，不是动画状态，不是世界空间位置。只是一组活动脚本所需的离散事实：小队是否已生成、还剩多少敌人存活、某个目标是否已触发。最终得到的是一个大小约 45MB、以 10Hz 运行的可执行文件，单台 40 核服务器就能同时处理接近 5,000 个实例。正如 Truman 所解释的，这相当于仅靠几百台机器就能支持大约 100 万并发用户。若采用完整模拟的专用服务器方案，则大概需要接近 50 万个无头进程来运行整个游戏。

实现这一点的关键纪律，是 Bungie 所称的 sensors：一种先声明式系统，脚本在引用某些状态之前，必须正式声明自己需要这些状态。

任何内容都不会意外漂到服务器上。如果脚本没有声明某个依赖项，那么该状态就不会在服务器端保留。这样既让活动宿主的占用更小、带宽更可预测，也让架构更加严谨。

从 Destiny 1 过渡到 Destiny 2 时，这三层共同取代了玩家主机化物理模型中那个脆弱的单点。Bungie 最终推出跨平台联机时，John Chu 将所需的底层联网改动形容为引擎中“最大、最吓人、最伤筋动骨的改动”之一，原因正是必须重建这套分层架构，以便跨平台传递一致的状态；这些平台此前都是分开开发并分别优化的。

Destiny 2混合模型的挑战

Bungie 自己的工程师曾把他们的联网拓扑形容为“异常复杂”。玩家面对的后果也确实如此。

IP 暴露是 P2P 的结构性后果，而不是漏洞。 在任何点对点架构中，客户端都会直接通信，这意味着你遇到的每个玩家都能看到你的 IP 地址。在 Destiny 2 中，这包括 PvE 和 PvP 里的每个玩家。正如 Chris “Battle(non)sense” 在他 2017 年对 PC Gamer 的分析中指出的，PC 版依然带着一组清晰的权衡，而这些是专用服务器游戏根本不必面对的：

“游戏会把你的 IP 地址直接告诉你遇到的每个人，第三方工具的叠加层无法工作，游戏捕获工具的功能在某些情况下会受限，命中判定的响应速度会因玩家而异，而且有些玩家会遇到所需上行带宽不足的问题，而这在专用服务器上很少发生。”

对于正在考虑混合模型的工作室来说，IP 暴露值得被视为一项一级设计约束。在没有位于玩家之间的中继层时，P2P 与 IP 隐私在根本上是不相容的。

安全性也会因此叠加变得更复杂。当客户端在 P2P 环境中处理命中判定这类敏感任务时，游戏就更难防止被利用。多人开发中常见的原则是“永远不要信任客户端”。在混合模型里，这一原则就更难被干净地执行。

网络代码：缝隙显露之处

注：以下信息基于 Chris “Battle(non)sense” 为 PC Gamer 在 2017 年进行的网络测试；某些细节可能已随着后续后端更新而改变。

在专用服务器游戏中，你的命中判定延迟只取决于一个变量：你到服务器的 ping 值。它始终一致、可预测，并且不受房间里其他任何人的影响。

P2P 则完全取消了这种保证。正如 Chris 所说，“玩家互联网连接的质量，以及他们之间的距离，会直接影响命中判定的响应感觉。” 一个以 15Hz 发送更新而不是预期 30-40Hz 的玩家，会明显拉长你和他之间的延迟，不管你自己的连接多么稳。某个玩家糟糕的上行链路会拖累所有与其连接的人的体验。而使用住宅网络且上传能力有限的玩家数量，往往比多数开发者预想的要多。

专用服务器会在中心层面吸收这种波动。P2P 则把它分散到比赛中的每一段同伴关系里。

同样的原因也让带宽随着玩家数量增加而扩展不良。在一小时的 4v4 Crucible 中，Chris 测得单个客户端发送了 152.3MB、接收了 128.3MB。在 P2P 拓扑中，增加玩家会让各个方向的流量成倍增长。这个数学结果很可能影响了 Bungie 将 Crucible 上限设为 4v4，而不是 5v5 或 6v6 的决定。围绕混合模型进行设计的工作室，应该尽早做自己的带宽预测，尤其是在更大的玩家规模下。

最后，tick 频率在这里也有自己的细微差别。Destiny 2 以 30Hz 采样战斗伤害（流传为传言的 10Hz 指的是 Activity Host，它以更低频率处理计分和弹药生成）。在 PC 上，当帧率超过 40fps 时，客户端可将更新发送到最高 40Hz；这意味着渲染性能与网络更新频率直接耦合，而这在专用服务器架构中没有对应的机制。

Private Fleet：大规模混合编排

对于在 Destiny 2 这种规模下运行基础设施的工作室来说，服务器编排就成了一项核心工程关注点。

Edgegap 的 Private Fleet 是一种基于容器的编排解决方案，它可以管理持久化服务器以优化成本，然后再通过即时部署以及覆盖全球 615+ 地点的全球服务器部署自动扩展到云端。就近托管会把玩家放到最近可用的服务器上，从而将延迟平均降低最多58%，而无需工作室自行构建和管理这些基础设施。

结论

《命运2》采用的混合联网模型展示了将服务器架构融合在一起的可能性以及真实成本。它证明了把 P2P 的灵活性与专用服务器的权威性结合起来，能够在大规模下提供无缝的共享世界体验，但这要求精细的工程设计来解决随之而来的安全、延迟和一致性挑战。上面链接的两场 GDC 演讲对 Bungie 在实践中如何解决这些问题讲得更深入，值得与本文一并阅读。

—

本文基于 Justin Truman 在 GDC 2015 的演讲、John Chu 在 GDC 2022 的演讲，以及 Chris “Battle(non)sense” 于 2017 年 11 月由 PC Gamer 发布的网络分析。原始内容的所有权利归各自所有者所有。