可伸缩微服务体系结构中的数据通信

Question

我们正在致力于一个项目，以获得一些关于微服务和自动可伸缩架构的知识。在这个项目中，我们正在构建一个小游戏，用户可以在亚马逊网络服务上在线驾驶飞机并击落其他玩家。一场比赛的持续时间应该是10分钟左右，一百万场比赛(理论上)应该能够同时进行，大约1000名玩家应该能够在一场比赛中发挥作用。因此，应用程序必须真正具有可伸缩性。

我们现在在架构中遇到了一个困难的部分。我们希望服务器计算球员的位置。这意味着服务器会收到用于重新计算位置的键输入请求。问题是，由于应用程序是可伸缩的，并且不只有一台服务器执行所有计算并保存所有数据，因此输入事件可能会在不同的位置结束。我们期望不断地将所有位置写入数据库，并将其读回客户端，这太慢了，也不够可伸缩。此外，我们不想为单一游戏专用服务器，因为这可能只是腰部的计算能力(和金钱)

我们已经搜索了其他游戏架构的不同实现，比如消息传递，但都无济于事，我们找不到任何适合的方法。我们想知道是否有任何类型的模式可以使这种实现工作？我们真正需要的是对一些可能的模式有一个方向感。

Answer 1

试用ElasticCache http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/WhatIs.html

这使得在节点之间共享位置变得很容易，他们讨论将其用于分数表，但也可以将其用于位置数据

将ElasticCache与自动扩展http://docs.aws.amazon.com/autoscaling/latest/userguide/WhatIsAutoScaling.html相结合，您应该能够根据需要扩展环境

Answer 2

您的示例听起来像是Apache Kafka这样的流媒体平台的主要用例。它本身是一个可伸缩的集群，充当一个大的事件队列(您的游戏输入)，这些事件被存储并提供给流消费者(所有游戏服务器)。这具有非常高的性能，并且应该能够以低延迟每秒处理数百万个输入。

您还应该确保将您的游戏世界划分为更广泛的“区域”，以确保并不是每台服务器都需要所有其他服务器的数据。我敢肯定，在任何时候，任何玩家的屏幕上都没有其他玩家。

查看Kafka examples

与传统的数据库相比较，提出了一种新的performance measurements。