本指南通过使用 Amazon GameLift 进行低延迟的全球游戏服务器托管和匹配，帮助游戏开发人员开始多人游戏开发。它支持客户端使用 Unity、Unreal 和 Godot 游戏引擎，并提供与 Amazon GameLift 的示例集成，用于多种游戏服务器实现选项，包括 C++、Go、Unity 和 Unreal。 本指南还实施了将游戏后端与 Amazon GameLift 集成的最佳实践，此外还通过近乎实时的游戏服务器日志、进程级游戏服务器指标和后端 API 的分布式跟踪实现了 Amazon CloudWatch 的可观测性。
架构图
[架构图描述]
第 1 步
游戏客户端通过调用 Amazon DynamoDB 端点来测量与 AWS 区域之间的 TCP 延迟。
第 2 步
游戏客户端使用 AWS 游戏开发工具包向 Amazon API Gateway 发出经过身份验证的 POST 请求，请求正文中包含延迟数据。
第 3 步
API Gateway 使用自定义身份组件公有密钥验证客户端 JSON Web 令牌。
第 4 步
API Gateway 调用请求配对 AWS Lambda 函数，该函数向 Amazon GameLift FlexMatch 发送包含延迟数据的 StartMatchmaking 请求。
第 5 步
Amazon GameLift FlexMatch 将玩家与其他玩家进行配对，并在出现新匹配时调用 Amazon GameLift 队列请求置放。它还可以为现有比赛填补玩家。
第 6 步
Amazon GameLift 队列根据玩家的延迟，在其中一个 Amazon GameLift 实例集站点中找到一个置放点。
第 7 步
置放完成并开始会话后，Amazon GameLift FlexMatch 会将 MatchmakingSucceeded 事件发送到 Amazon Simple Notification Service（Amazon SNS）主题。它还会发送所有中间事件，例如 MatchmakingSearching。
第 8 步
Amazon SNS 调用流程匹配 Lambda 函数，该函数将所有匹配状态更改更新到 DynamoDB 表。
第 9 步
游戏客户端使用包含匹配工单 ID 的 GET 请求来轮询匹配状态。
第 10 步
Lambda get-match-status 函数从 DynamoDB 获取最新的匹配信息，并将其发送回游戏客户端。配对完成后，它还将 IP、端口和玩家会话 ID 发送给客户端。
第 11 步
游戏客户端通过 TCP（在实时游戏中通常是 UDP）连接到游戏会话，并发送经游戏服务器验证的玩家会话 ID。
第 12 步
这些实例使用 CloudWatch 座席向 Amazon CloudWatch 发送日志和指标。
第 1 步
游戏客户端通过调用 Amazon DynamoDB 端点来测量与 AWS 区域之间的 TCP 延迟。
第 2 步
游戏客户端使用 AWS 游戏开发工具包向 Amazon API Gateway 发出经过身份验证的 POST 请求，请求正文中包含延迟数据。
第 3 步
API Gateway 使用自定义身份组件公有密钥验证客户端 JSON Web 令牌。
第 4 步
API Gateway 调用请求配对 AWS Lambda 函数，该函数向 Amazon GameLift FlexMatch 发送包含延迟数据的 StartMatchmaking 请求。
第 5 步
Amazon GameLift FlexMatch 将玩家与其他玩家进行配对，并在出现新匹配时调用 Amazon GameLift 队列请求置放。它还可以为现有比赛填补玩家。
第 6 步
Amazon GameLift 队列根据玩家的延迟，在其中一个 Amazon GameLift 实例集站点中找到一个置放点。
第 7 步
置放完成并开始会话后，Amazon GameLift FlexMatch 会将 MatchmakingSucceeded 事件发送到 Amazon Simple Notification Service（Amazon SNS）主题。它还会发送所有中间事件，例如 MatchmakingSearching。
第 8 步
Amazon SNS 调用流程匹配 Lambda 函数，该函数将所有匹配状态更改更新到 DynamoDB 表。
第 9 步
游戏客户端使用包含匹配工单 ID 的 GET 请求来轮询匹配状态。
第 10 步
Lambda get-match-status 函数从 DynamoDB 获取最新的匹配信息，并将其发送回游戏客户端。配对完成后，它还将 IP、端口和玩家会话 ID 发送给客户端。
第 11 步
游戏客户端通过 TCP（在实时游戏中通常是 UDP）连接到游戏会话，并发送经游戏服务器验证的玩家会话 ID。
第 12 步
这些实例使用 CloudWatch 座席向 Amazon CloudWatch 发送日志和指标。
Well-Architected 支柱
当您在云中构建系统时，AWS Well-Architected Framework 可以帮助您了解所做决策的利弊。框架的六大支柱使您能够学习设计和操作可靠、安全、高效、经济高效且可持续的系统的架构最佳实践。使用 AWS 管理控制台中免费提供的 AWS Well-Architected Tool，您可以通过回答每个支柱的一组问题，根据这些最佳实践来检查您的工作负载。
上面的架构图是按照 Well-Architected 最佳实践创建的解决方案示例。要做到完全的良好架构，您应该遵循尽可能多的 Well-Architected 最佳实践。
-
卓越运营阅读《卓越运营》白皮书
Amazon GameLift 可在全球范围内管理游戏服务器实例集，并在每个位置提供高可用性配置，让您可以配置游戏服务器实例集的扩展和运行方式。API Gateway、Lambda 和 DynamoDB 等无服务器服务可通过代您管理底层基础设施来减少运营工作量，让您可以专注于代码和配置。通过使用 CloudWatch 监控本指南的所有组件（包括指标和日志），您可以近乎实时地调查瓶颈或错误。
-
安全性阅读《安全性》白皮书
API Gateway 支持使用游戏客户端提供的 JSON Web 令牌和自定义身份组件提供的公有密钥对验证用户身份的请求进行身份验证。身份验证有助于确保玩家访问后端 Lambda 函数数据时身份属实。
-
可靠性阅读《可靠性》白皮书
Amazon GameLift 通过在多个可用区（AZ）托管游戏服务器实例，在所有区域提供高可用性。它还将自动替换任何失败的游戏服务器进程或实例。
匹配工单的 DynamoDB 表可以随着玩家负载的增加自动水平扩缩。DynamoDB 还托管在该区域的多个可用区中。匹配工单被视为是临时性的（并且会在 3 小时后自动删除），因此您无需在表中进行备份。
对于任何可用性问题的通知，除了 API Gateway 和 Lambda 层上的任何错误外，我们建议对来自 Amazon GameLift 游戏服务器的相应指标实施 CloudWatch 警报。
-
性能效率阅读《性能效率》白皮书
Amazon GameLift 可以实现客户端与服务器的直接通信，以优化近乎实时的性能。使用该架构图，开发人员可以使用 Amazon GameLift 在多个区域托管游戏服务器，从而减少游戏客户端和服务器之间的延迟。DynamoDB 会存储匹配结果，让您能够以个位数毫秒级的响应时间大规模检索这些结果。
-
成本优化阅读《成本优化》白皮书
DynamoDB 生存时间（TTL）特征于 3 小时后从您的表中删除项目，并且不会消耗任何写入吞吐量。如此，您便有足够的时间在需要时获得项目，同时又最大限度地减少了不必要存储的总体成本。
Amazon GameLift 让您可以组合使用 Amazon Elastic Compute Cloud（Amazon EC2）按需实例和竞价型实例。在同一个 Amazon GameLift 队列之后配置按需实例集和竞价型实例集有助于通过 Amazon GameLift 的内置竞价型优化算法降低成本，该算法在竞价型可用时优先选择竞价型。
-
可持续性阅读《可持续性》白皮书
Amazon GameLift 要求每个区域至少有一个实例，以提供适当的响应时间并启动服务扩展，但在流量较低时可以将位置扩展到 1，在开发和测试环境中可以扩展到 0。
此外，后端使用的无服务器服务（包括 DynamoDB、Lambda 和 API Gateway）可以根据需求进行扩展以匹配所需容量，从而减少了本指南的计算占用空间。
免责声明
示例代码；软件库；命令行工具；概念验证；模板；或其他相关技术（包括由我方人员提供的任何前述项）作为 AWS 内容按照《AWS 客户协议》或您与 AWS 之间的相关书面协议（以适用者为准）向您提供。您不应将这些 AWS 内容用在您的生产账户中，或用于生产或其他关键数据。您负责根据特定质量控制规程和标准测试、保护和优化 AWS 内容，例如示例代码，以使其适合生产级应用。部署 AWS 内容可能会因创建或使用 AWS 可收费资源（例如，运行 Amazon EC2 实例或使用 Amazon S3 存储）而产生 AWS 费用。
本指南中提及第三方服务或组织并不意味着 Amazon 或 AWS 与第三方之间存在认可、赞助或从属关系。AWS 的指导是一个技术起点，您可以在部署架构时自定义与第三方服务的集成。