持久化
了解如何在以下平台上管理具有 24/7 始终在线部署的持久世界 私有舰队.
许多类型（MMO、沙盒、社交游戏）利用持久世界让玩家：
结识并与新朋友社交；培育有机的玩家社区，
探索一个由玩家放置的用户生成内容所填充的鲜活开放世界，
参与与大型团队或整个公会进行、持续数小时的史诗团本战斗。
探索以下策略以 提供尽可能出色的玩家体验、控制成本，并消除因故障或回滚导致的玩家沮丧情绪。通过将易于游戏开发者使用的边缘计算优势引入，增强传统的服务器模型。
或者，请参见 部署 编排以利用分数 vCPU 定价。
✔️ 准备工作
要实现持久、不中断的 24/7 始终在线部署：
指定
"max_duration": -1以防止在 24 小时后自动终止，
一旦就绪，部署会被分配一个 URL（ 私有机群部署 API 用于启动 待命（standby）服务器， team_size 持久化.
在虚拟机（Performance）或裸金属（Overdrive）规格之间进行选择。
🔑 服务器所有权
以边缘计算为切入点，探索现代与传统所有权模型的优缺点。
工作室托管
服务器托管传统上由工作室管理，托管成本由游戏收入覆盖。
👍 优点
透明的产品定价——托管成本由玩家的许可/订阅覆盖，
在客户端、服务与扩缩松耦合的前提下具备强大的客户端/服务器兼容性，
由于服务器为闭源性质，因此更能抵御作弊与逆向工程。
👎 缺点
为了确保服务器完整性与稳定性，对社区模组的支持会受到限制。
社区服务器
让你的玩家自行托管并资助他们的服务器，消除对第三方租赁服务的需求。让收入流经你的工作室，而不是交给对终端用户体验质量缺乏洞察的第三方。
👍 优点
通过经策展的模组清单增强模组支持， 应用与版本,
由于与社区更紧密协作，改进玩家反馈循环，
由于玩家承担托管成本，从而降低财务风险。
👎 缺点
工作室的运营工作更多——审核玩家请求并收款，
由于模组版本数量增加，客户端/服务器兼容性较弱，
由于代码库分布式且存在逆向工程的可能性，更容易受到作弊影响。
🥛 容量与扩缩
学习高级技术，以优化服务器可用性、托管成本与服务质量。
容量
部署在 之后不追踪或管理活跃玩家连接 部署 ，以赋予你对任意设计的绝对控制权与自由度。
实施容量管理以确保你的服务器：
最大化成本节省—— 基准测试 并高效利用服务器资源，
提供流畅的游戏体验——防止过多并发玩家导致服务器过载，
防止因崩溃引发的差评——捕获并处理意外异常。
为确保高效的服务器容量管理：
在以下情况下释放玩家名额，如果 匹配到游戏服务器的玩家 在几秒内未连接，
频繁地从客户端向服务器发送最小心跳消息以跟踪活动，
若数秒内未检测到活动，则断开客户端并释放玩家名额，
防止将玩家加入已满且没有可用名额的服务器。
参见 服务器浏览器 使用我们的托管服务进行自动化容量处理。
已保留的部署资源数量在运行时无法更改。 通过使用调整后的新服务器实例进行横向扩展 应用程序版本 需要更多的 CPU 或内存资源。
向上扩容
扩容持久服务器不需要“拍脑袋估算” 区域流量或服务器成本。为 私有舰队 以下时段预留 低谷 的容量，并在意外峰值时自动溢出到云端。
启用 在您的应用版本中启用缓存 以在几秒钟内部署服务器。
实施服务器扩缩策略以：
在谨慎防范滥用的同时实现大规模托管，
尽量减少空闲待命服务器造成的浪费成本，
通过快速响应玩家需求增长来避免长时间排队。
集成要点
扩缩授权会分配正在运行的服务器，或启动新服务器以服务玩家。
服务器实时通知扩缩授权有关服务器启动/停止与玩家连接变更。
扩缩授权会删除（过期）无响应（崩溃）服务器的陈旧记录。
客户端直接与服务器连接并建立游戏会话，随后进入游戏流程。
我们强烈建议基于连接数进行扩缩，而不是基于物理负载 （CPU 与 RAM），因为物理负载的瞬时波动可能导致不可预测的可用性。
已保留的部署资源数量在运行时无法更改。 通过使用调整后的新服务器实例进行横向扩展 应用程序版本 需要更多的 CPU 或内存资源。
向下缩容
高效的缩容策略是优化成本的关键，但 关闭服务器 如果不谨慎，可能会负面影响玩家体验。 在发布前考虑这些因素并测试变更：
你对玩家活动/断连的检测是否可靠？
输入的缺失是否能可靠地指示玩家不活跃？玩家常用机器人、宏等技术伪造活动并保持连接以避免排队时间。
活跃玩家经常执行、且难以伪造的行为是否存在？
在 持久化 服务器上，使用机器人或宏是问题还是特性？
关闭服务器是否容易且快速地可逆（能迅速恢复扩容）？
你能否通过加载场景、小游戏、大厅或其他方式来掩盖服务器加载？
玩家是否绑定到特定的服务器实例，还是可以轻松迁移？
连接到不同服务器会如何影响玩家的账号、购买历史、社交体验、进度、物品栏及其他游戏玩法要素？
审查你的 持久化 并确保关键数据不丢失。
实施自动化方法或玩家工具来恢复关键数据。
提供人工支持，并就故障与问题与社区沟通。
🔎 可发现性
为寻找接受新玩家的活跃服务器，实施一种或多种发现方法：
在有足够玩家加入时启动新游戏 匹配器.
向现有对局中 添加玩家以通过回填替换离开的玩家.
允许玩家浏览服务器并从列表中选择，具备 服务器浏览器.
💭 配置与状态
集成服务以定义初始服务器需求，并管理玩家与服务器状态。
配置管理
配置是指 部署期间传递给服务器的初始数据：
例如客户端/服务器版本兼容性数据，
第三方集成参数、密钥与机密。
状态管理
状态指的是描述 一系列先前玩家行为与服务器事件结果的数据：
玩家连接、玩家控制的状态变更（例如， Pawn（棋子/角色）),
执行频繁的状态备份以防止数据丢失 以应对意外的客户端或服务器问题：
使用第三方服务进行实时异步备份，例如 Heroic Labs 的 Nakama，,
在客户端/服务器启动或关闭时，将反序列化后的状态文件保存到 云对象存储，.
游戏对象通常指定一个控制它们的所有者，可以是服务器或玩家。
服务器拥有的对象
服务器拥有的对象只能由服务器操控。已连接的玩家对服务器拥有的对象仅有受限的读取权限。服务器拥有的对象通常不会与其他服务器共享。
服务器拥有的对象可以 在意外服务器崩溃时由替换服务器加载。使用 部署 ID 在首次启动时标识你的新存档文件，并用于存储服务器拥有对象的状态。
玩家拥有的对象
玩家拥有的对象既可由玩家操控，也可由服务器操控。将持久对象的所有权分配给玩家，可在后续更易迁移到其他服务器。
在玩家设备或游戏后端备份玩家拥有对象的状态， 以覆盖不同游玩会话之间。
恢复目标
在出现问题时，某些类别的数据对丢失更为敏感，例如：
账号、订阅、购买与小额交易数据—— 关键,
进度、成就、排行榜与物品栏数据—— 重要,
反作弊、审核、性能与错误追踪数据—— 重要,
玩家行为、社交、聊天数据—— 低重要性.
从独立的交易历史来源实现恢复购买 以获得最佳体验。
我们强烈建议你的团队讨论以下内容：
你的游戏客户端与服务器所处理的数据类别，
每个类别对你的业务与玩家的重要性与敏感度，
恢复点目标（RPO）——在造成严重损害前可接受的数据丢失量，
恢复时间目标（RTO）——在造成严重损害前可接受的停机时长。
服务器意外崩溃会导致您的服务器自动重启。 服务器状态可能会丢失.
信号给你的主进程，允许短暂的终止期限。一旦到期，会发送
长时间运行的持久服务器带来了新的可观测性挑战，尤其是在监控、日志与缺陷追踪中的异常检测。
我们 强烈建议为服务器重启实施告警 以提升对问题的可见性。
我们的 端点存储 日志集成 只会传输日志 在 部署之后，添加自定义日志与缺陷追踪（例如 Sentry）以排查部分故障与缺陷。
考虑为具有可预测流量模式的游戏预留 私有舰队 待命容量。
最后更新于
这有帮助吗？