持久化

在……上管理具有 24/7 全天在线部署的持久世界 私有舰队.

许多游戏类型（MMO、沙盒、社交游戏）利用持久世界让玩家：

• 结识并与新朋友社交；培养自然形成的玩家社区，

• 探索一个充满玩家放置的用户生成内容的鲜活开放世界，

• 与大型团队或整个公会一起参与持续数小时的史诗级团本战斗。

探索以下策略，以 提供尽可能好的玩家体验，控制成本，并消除因宕机或回滚而带来的玩家挫败感.

或者，请参见 部署 云编排以利用按比例的 vCPU 定价。

✔️ 准备

要启用持久、不中断的 24/7 全天在线部署：

1. 创建新的应用版本（或更新现有版本）。

   • 在控制台中——选择“persistent（持久）”，而不是指定最大时长。

   • 使用 API——指定 “max_duration”: -1 在你的应用版本请求中。

2. 在控制台中创建一个私有舰队并安排主机。

   1. 创建舰队是免费的，请先这样做以预览位置和详情。

   2. 选择虚拟机（Performance）或裸金属（Overdrive）规格。

   3. 在安排主机之前，系统会提示你确认最终价格。

3. 使用……部署新服务器 服务器浏览器 或自定义集成。

   1. 服务器浏览器会根据配置的……启动服务器 扩缩容策略.

   2. 自定义集成应 使用私有舰队 API 启动服务器.

测试你的服务器扩缩容和 终止流程 以验证你的成本控制的可靠性。部署停止后，存储在内存中的服务器状态将会丢失，参见 持久化.

如果你需要帮助， 请通过 Discord 联系我们。关于实时游戏支持，请查看我们的 工单系统.

🔑 服务器所有权

边缘计算环境下现代与传统所有权模型的优缺点。

工作室托管

服务器通常由工作室管理，并从游戏收入中收回托管成本。

👍 优点

• 不向玩家额外收费——托管成本从工作室收入中收回。

• 客户端/服务器/服务之间松耦合，具有很强的兼容性。

• 由于游戏是闭源代码，因此更能抵御作弊和滥用。

👎 缺点

• 对社区 Mod 支持有限，以确保服务器完整性和公平性。

社区服务器

让玩家在 Edgegap 上资助自己的服务器，并释放原本会流向缺乏用户体验洞察的第三方托管服务的托管收入。

👍 优点

• 通过精选的 Mod 和版本增强 Mod 支持。

• 通过与社区直接合作，迭代式改进你的游戏。

• 通过提升游戏寿命和自助模式来建立社区信任。

👎 缺点

• Mod 支持和兼容性需要开发投入。

• 需要更多运营工作来管理社区和支付系统。

• 由于暴露游戏内部机制，逆向工程风险增加。

🥛 容量与扩缩容

学习优化服务器成本和服务质量的高级技术。

自动扩缩容参考架构

手动启动你的部署，复制 URL 和端口在实时游戏中行不通。

使用以下任一方式，自动化热门游戏流程，以管理会话并按需扩展：

匹配:

• 更短的回合

• 按需对局

• 技能评级和/或 自定义规则

服务器浏览器:

• 持久模式或回合制

• 社交区域枢纽

• 自动分配和/或 自定义搜索

自定义后端：

• 迁移实时游戏

• 使用 v2 API 部署

• 监控 Webhooks

容量

部署不会跟踪或管理活跃玩家连接 在你……之后 部署 以便让你拥有绝对控制权和自由来实现任何设计。

实施容量管理，以确保你的服务器：

• 控制托管成本 - 基准测试 并优化每位玩家的服务器资源使用，

• 提供一致的体验 ——将每台服务器的 CCU 保持在安全范围内。

参见 服务器浏览器 ，通过我们的托管服务实现自动化容量处理。

提示：如果你选择开发自定义会话和容量编排器。

• 流程必须防止与并发预留争夺容量。

• 向你的编排器频繁发送心跳，以同步服务器状态。

• 快速从发现流程中移除过期、崩溃或已停止的服务器。

• 如果玩家未在分配时间内连接，则使容量预留超时。

• 检测到玩家不活跃时，断开客户端并释放容量。

已保留的部署资源数量在运行时无法更改。 通过使用调整后的新服务器实例水平扩展 应用程序版本 需要更多 CPU 或内存资源。

扩容

智能扩缩容策略 防止玩家排队等待并尽量降低空闲服务器成本.

我们建议围绕并发玩家而不是机器负载来扩展资源 （CPU 和 RAM），因为负载波动可能导致可用性不可预测。

扩缩容不需要对区域流量或服务器成本进行“猜测估算”。安排 私有舰队 容量用于 低潮 并在意外流量高峰期间自动溢出到云端。

启用 在您的应用版本中启用缓存 在几秒内部署服务器。

缩容

不谨慎地关闭服务器可能会对玩家体验产生负面影响。 在发布前，请考虑以下因素并测试更改：

你对玩家不活跃/断线的检测是否可靠？

• 玩家输入缺失是否可靠？玩家经常使用机器人和宏来伪装活跃并避免被踢出，导致重新连接时需要排队等待。

• 是否还有其他更难伪造的活跃指标？

• 是否有游戏设计上的替代方案来减轻使用机器人带来的影响/动机？

你能否轻松快速地重启服务器，而无需大规模回滚？

• 你的服务器可能需要一些时间来重启并恢复状态。状态恢复是否会给你的游戏后端带来额外的数据传输或服务成本？

• 你能否通过小游戏/大厅来隐藏服务器加载过程，以保持玩家参与度？

玩家是否绑定到特定服务器实例，还是可以轻松迁移？

• 连接到不同服务器会如何影响玩家的账号、购买历史、社交体验、进度、库存以及整体留存？

• 审查你的 持久化 并确保关键数据不会丢失。

• 如果出现停机，透明度和社区管理会非常有帮助。

💭 配置与状态

定义服务器种子参数，并可靠地管理玩家/服务器状态。

配置管理

配置或种子是指 部署期间传递给服务器的初始数据：

• 按环境注入的变量:

  • 例如客户端/服务器版本兼容性数据，

• 服务器位置, 服务器端口 以及 其他服务器信息,

• 匹配信息 或 自定义部署变量,

• 第三方集成参数、密钥和机密。

配置是不可变的。 在服务器启动期间读取，运行时不做修改。

状态管理

状态指的是运行时数据， 是之前玩家操作和服务器事件的结果：

• 玩家连接、玩家控制的状态变化（例如 Pawn),

• 场景/关卡中包含的属性变化（例如 Actor, 游戏对象),

• 与……相关的变化 游戏模式, 游戏状态，或 游戏场景 信息。

状态数据变化频繁。 同步每秒发生多次（tick 频率）。

频繁的状态备份有助于防止数据丢失 以防出现意外崩溃/问题：

• 通过第三方游戏后端 API 进行异步更新，例如 Heroic Labs 的 Nakama,

• 通过周期性服务器心跳将序列化状态文件传输到 云对象存储.

有状态组件通常有明确的指定所有者，可能是服务器或玩家。

服务器拥有的对象

服务器拥有的对象只能由服务器操作。已连接玩家对服务器拥有的对象只有有限的读取权限。

服务器拥有的对象可以 由替代服务器恢复（状态迁移）。它们通常不会在并发运行的服务器之间共享（需服务器网格化）。

玩家拥有的对象

玩家拥有的对象可以由玩家和服务器共同操作。将持久世界对象的所有权分配给玩家，可以使存储和状态迁移更容易。

在玩家设备或游戏后端上备份玩家拥有的对象 在会话之间。加密玩家状态和/或上传状态校验和，以检测未经授权的修改。

恢复目标

某些数据类别可能对数据丢失和恢复时间更敏感。

我们强烈建议你们团队讨论以下内容：

• 你的游戏客户端、服务器和游戏后端中处理的数据类别。

• 每个类别的数据丢失对玩家和业务的影响。

• 恢复点目标（RPO）——造成严重损害前可接受的数据丢失量。

• 恢复时间目标（RTO）——系统需要多快恢复。

请查看下面我们简化的恢复目标评估示例：

数据类别	RPO	RTO
账号、订阅和购买	🔥 5 分钟	🔥 30 分钟
进度、库存和技能评级	🔥 5 分钟	🔥60 分钟
审核、性能和错误跟踪	⚠️ 30 分钟	⚠️ 8 小时
社交功能、聊天历史、行为分析	⏬ 24 小时	⏬ 72 小时

为最关键的类别提前准备灾难恢复手册。

服务器崩溃处理取决于您的 进程重启策略. 服务器状态可能会丢失.

👀 可观测性

长时间运行的持久服务器带来了新的可观测性挑战，尤其是在监控、日志和缺陷跟踪中检测异常。我们 强烈建议为服务器重启设置告警 以获得可追溯性并对正常运行时间进行额外监督。

连接你的 端点存储 以保存部署日志，否则它们将被删除！

添加自定义日志和缺陷跟踪（Sentry, Bugsnag）以排查部分故障。