本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

GAMEREL03-BP02 实现游戏功能的松散耦合以处理故障，同时将对玩家体验的影响降至最低

解耦组件是指设计服务器组件以使其能够尽可能独立运行的概念。游戏的某些方面很难分离，因为数据需要尽可能保持最新状态，才能为玩家提供良好的游戏体验。但是，许多组件和游戏任务可以解耦。例如，排行榜和统计服务对游戏体验并不重要，对这些服务的读取和写入可以在游戏中异步执行。

在未建立这种最佳实践的情况下暴露的风险等级：高

实施指导

对游戏中检测到问题时可以自动禁用或由管理员禁用的功能进行正常降级，并配置依赖于该功能的上游服务，以便能够正常处理故障。例如，如果游戏客户端中未正确加载特定的玩家数据，则应考虑这些数据对游戏体验是否至关重要。如果不是，请将游戏客户端配置为在不中断玩家体验的情况下正常处理此故障，并选择稍后在玩家重新访问屏幕时重试获取这些数据。

使用超时、重试和退避等逻辑来处理错误和故障。超时可防止系统不合理地长时间挂起。重试可以为瞬态和随机错误提供高可用性。

定义可以松散耦合到关键组件的非关键组件。松散耦合使系统更具弹性，因为一个组件的故障不会级联到其他组件。当游戏功能不需要与游戏服务器或后端建立状态连接时，您应该实现无状态协议以动态扩展并从暂时故障中恢复。开发非关键组件，使用 API 将其与无状态协议松散耦合。 HTTP/JSON 将来自游戏客户端的网络调用实现异步和非阻塞，以最大限度地减少性能缓慢的游戏功能或其他依赖服务对玩家的影响。

要通过松散耦合进一步提高弹性，请在可异步处理的组件之间使用队列、流媒体或基于主题的系统等消息服务。此模型适用于不需要立即响应的交互，或者确认请求已注册就足够了。该解决方案涉及一个生成事件的组件和另一个消耗事件的组件。这两个组件不会通过直接的点对点交互进行整合，而是通过中间层（例如持久存储层或队列层）进行整合。这还有助于在处理失败时保留消息，从而提高系统的可靠性。

研究并选择适当的消息传送机制，因为各种消息传递服务具有不同的特征，例如排序和交付机制。将操作设计为等导数，以便所选的消息系统至少传送一次消息。举个例子，以一个典型的游戏用例为例，在该用例中，你的游戏需要跟踪玩家的游戏时间、统计数据或其他相关数据，这可能会在玩家并发高峰时段产生高写入吞吐量的用例。

要实现可靠的架构，请考虑用例是否需要玩家认为的写后读一致性。通常，诸如此类的场景适用于异步处理，可通过实现写入队列模式来实现，在该模式中，请求被提取到可扩展且耐用的消息队列（如 Amazon SQS）中，并可使用消费者服务（例如 Lambda 函数）批量插入到您的后端数据库中。这种方法比多个分布式组件（包括玩家的游戏客户端、您的后端 Web 和应用程序服务器以及内部数据库系统）之间的同步通信更可靠。它还可以降低成本，因为不需要扩展后端数据库来满足峰值写入吞吐量，因为写入队列中的使用者处理可以根据需要减慢这种摄取速度。

实施步骤

资源