AWS部署的流线型在线游戏体系结构考虑

Question

我正在做一个简单的网络游戏，它将在一个彩带和他们的观众之间播放。游戏会话将由彩带发起，他们创建游戏，然后共享一个链接供所有观众连接。一场比赛将持续10分钟。

我的前端是一个SPA，它将使用REST与后端对话。

我想把它部署到AWS，因为他们有吸引力的按需计算选项和定价。但是，我想在维护可伸缩性选项的同时，利用我对前端后端预期交互的先验知识，为低成本进行优化。

假设

1. 有时游戏可能由1000人(甚至更多)玩，有时可能是0，每分钟都有剧烈的波动。
2. 后端保持游戏的状态。
3. 彩带和观众轮流观看。
4. 观众的决定时间是有限的(假设10-15秒)
5. 在观看者转向时，每个观看者都可以就代表观看者应该采取的行动提交一份投票。
   • 查看器前端将允许用户反复投票并更新他们的投票。
   • 查看器前端还会定期询问后端的一些统计数据，说明所有其他观众投票的情况--这些统计数据应该被更新大约。一秒钟一次，一次

6. 每次一个彩带或观众完成他们的回合，游戏状态被迭代，一些结果会显示在彩带的前端

在单个游戏过程中，需要维护以下状态：

• 游戏状态-包含游戏的当前状态。
• 观众投票状态-包含关于所有观众投票的信息。
• 查看者投票统计-包含查看者投票统计信息的快照。

架构

我正试图找出这样一个应用程序的最佳架构。

最初，我计划有一个节点服务器，并将状态保存在内存中，但这是不可伸缩的，如果游戏不玩，也可能会很昂贵。如果我尝试在弹性豆杆上部署这个，我相信没有办法保证游戏会话中的所有玩家都会被路由到同一个服务器上。

因此，从我收集到的信息来看，最佳的方法可能是将所有状态存储在DynamoDB中，使用lambda函数实现完整的REST，然后有一个周期性的lambda函数调用(例如每秒1次)，它将更新查看者的投票统计数据，并在进行转弯时更新游戏状态(这个周期性任务可能也可以在单个EC2实例上处理，您喜欢这样做吗？)

所以我要问你的问题是：

1. 这有道理吗？
2. 考虑到我所提供的限制，您会选择不同的架构吗？如果是的话，为什么？
3. 我是否为了低的部署成本而进行轻松的开发(用节点编写一个单一的web服务器，而不是编写大量的lambda)？

Answer 1

服务器：Rest可以使用Api + Lambda构建，而不是ECS/ElasticBeanStack上的节点服务器，同时考虑到成本和规模。即使在ECS中设置简单的节点服务器，存储状态也必须从服务器卸载到外部数据存储，尽管使用弹性负载平衡器粘性会话，您可以将请求从一个游戏/用户转发到同一台服务器。

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

• Redis:只要并发用户不太高，我们就可以自动缩放。其优点是延迟较低，甚至比DynamoDb还小。但是，如果总用户在短时间内从超低到超高波动，而不产生不必要的成本，那么缩放可能是一个问题。这里是一个详细的例子。
• DynamoDb:这无疑是有效的，并且可以无缝地进行缩放。您不需要每1秒运行一次的作业，您可以轻松地启用带有Lambda的迪纳摩流来更新统计信息。

大多数情况下，解决方案都是DynamoDb和Redis的结合。