amazon-web-services - AWS 部署的 Streamer 在线游戏架构注意事项

Question

我正在开发一个简单的在线游戏，它将在主播和他们的观众之间播放。游戏 session 将由主播发起，他们创建游戏，然后共享一个链接供所有观众连接。一场比赛将持续约 10 分钟。
我的前端是一个 SPA，它将使用 REST API 与后端对话。
由于其有吸引力的按需计算选项和定价，我想将其部署在 AWS 上。但是，我想使用我对前端-后端预期交互的先验知识，以低成本进行优化，同时保持可扩展性选项。
假设

有时游戏可能有1000s(甚至更多)人玩，有时可能是0，每分钟都在剧烈波动

后端保存游戏状态

主播和观众轮流交替

观众的决定时间是有限的(比如说10-15秒)

轮到观众时，每个观众都可以就应该代表观众采取什么行动进行投票

查看器前端将允许用户重复投票并更新他们的投票

查看器前端还会定期向后端询问有关所有其他查看器如何投票的统计数据 - 这些统计数据应该大约更新。一秒一次，一次全部

每次主播或观众轮到他们时，都会迭代游戏状态，并在主播的前端显示一些结果

在单个游戏 session 过程中需要保持以下状态:

游戏状态 - 包含游戏的当前状态

观众投票状态 - 包含所有观众的投票信息

观众投票统计 - 包含观众投票统计的快照

建筑学
我试图找出这种应用程序的最佳架构可能是什么。
最初我计划有一个单节点服务器并将状态保存在内存中，但这不可扩展，而且在不玩游戏时也可能很昂贵。如果我尝试在弹性 beantalk 上部署它，我相信没有办法保证游戏 session 中的所有玩家总是被路由到同一个服务器。
因此，从我收集到的信息来看，最佳方式可能是将所有状态存储在 DynamoDB 中，使用 lambda 函数实现完整的 REST API，然后定期调用 lambda 函数(例如每秒 1 次)来更新观众投票统计数据并在轮到时更新游戏状态(这个周期性任务也可能在单个 EC2 实例上处理，您是否更喜欢计划的 lambda？)。
所以我对你的问题是:

这有意义吗？

鉴于我提供的限制，您会选择不同的架构吗？如果是为什么？

我是否为了低成本部署而牺牲了开发的便利性(在节点中编写单一的 Web 服务器与编写大量的 lambda 表达式)？

Answer 1

服务器 :考虑到成本和规模，Rest API 可以使用 Api Gateway + Lambda 而不是 ECS/ElasticBeanStack 上的节点服务器来构建。即使您在 ECS 中设置了一个简单的节点服务器，存储状态也必须从服务器卸载到外部数据存储，尽管使用 elastic load balancer sticky sessions您可以将来自一个游戏/用户的请求转发到同一服务器。
数据存储:对于存储状态和统计信息，考虑到不需要长期存储，我可以看到两个选项。

Redis:只要并发用户不会太高，我们可以通过自动扩展来扩展。优势是低延迟，甚至比 DynamoDb 还要短。但是，如果总用户数在短时间内从超低到超高波动，而不会产生不必要的成本，那么扩展可能会成为一个问题。 Here是一个详细的例子。

DynamoDb:这肯定可以无缝地工作和扩展。您不需要每 1 秒运行一次的作业，您可以轻松启用 Dynamo Streams使用 Lambda 更新统计信息。

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