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