AWS 部署的 Streamer 在线游戏架构注意事项

Question

我正在开发一款简单的在线游戏，它将在主播和他们的观众之间进行。游戏会话将由流媒体发起，他们创建游戏，然后共享一个链接供所有观众连接。一场比赛将持续约 10 分钟。

我的前端是一个 SPA，它将使用 REST API 与后端通信。

我想在 AWS 上部署它，因为它们具有吸引力的按需计算选项和定价。但是，我想利用我对前端-后端预期交互的先验知识，在保持可扩展性选项的同时，以低成本进行优化。

假设

1. 有时游戏可能由 1000 人（甚至更多）人玩，有时可能是 0 人，而且每分钟都在剧烈波动
2. 后端保存游戏状态
3. 主播和观众交替轮流
4. 观众的决定时间是有限的（比如说 10-15 秒）
5. 在观看者轮到时，每个观看者都可以代表观看者就应采取的行动提交投票
   • 查看器前端将允许用户重复投票并更新他们的投票
   • 查看器前端还将定期向后端询问有关所有其他查看器如何投票的一些统计信息 - 这些统计信息应该大约更新。一秒钟一次，一次全部
6. 每次主播或观众完成他们的回合时，游戏状态都会迭代，并在主播的前端显示一些结果

在单个游戏会话过程中需要保持以下状态：

• 游戏状态 - 包含游戏的当前状态
• 观众投票状态 - 包含所有观众的投票信息
• 观众投票统计 - 包含观众投票统计的快照

架构

我正在尝试找出适合此类应用程序的最佳架构。

本来我打算有一个单节点服务器并将状态保存在内存中，但这不可扩展，而且在不玩游戏时可能会很昂贵。如果我尝试将它部署在弹性 beantalk 上，我相信无法保证游戏会话中的所有玩家总是被路由到同一个服务器。

因此，根据我收集到的信息，最佳方式可能是将所有状态存储在 DynamoDB 中，使用 lambda 函数实现完整的 REST API，然后定期调用 lambda 函数（例如每秒 1 个）来更新观众投票统计数据，并在轮到时更新游戏状态（这个周期性任务也可能在单个 EC2 实例上处理，您是否更喜欢预定的 lambda？）。

所以我的问题是：

1. 这有意义吗？
2. 考虑到我提供的限制，您会选择不同的架构吗？如果是，为什么？
3. 我是否要以开发的简易性（在节点中编写单个 Web 服务器与编写大量 lambda）来换取低成本的部署？

Answer 1

服务器：考虑到成本和规模，可以使用 Api Gateway + Lambda 代替 ECS/ElasticBeanStack 上的节点服务器构建 Rest API。即使您在 ECS 中设置了一个简单的节点服务器，存储状态也必须从服务器卸载到外部数据存储，尽管使用 elastic load balancer sticky sessions 您可以将来自一个游戏/用户的请求转发到同一服务器。

数据存储：对于存储状态和统计数据，考虑到不需要长期存储，我可以看到两个选项。

• Redis：只要并发用户数不会太高，我们可以通过自动缩放进行缩放。优点是低延迟，甚至比 DynamoDb 还要小。但是，如果总用户在短时间内从超低波动到超高而不会产生不必要的成本，那么扩展可能会成为一个问题。 Here 是一个详细的例子。
• DynamoDb：这肯定可以无缝地工作和扩展。您不需要每 1 秒运行一次的作业，您可以使用 Lambda 轻松启用 Dynamo Streams 以更新统计信息。

大多数时候的解决方案是 DynamoDb 和 Redis 的组合。