可扩展微服务架构中的数据通信

Question

我们正在开展一个项目，以获取有关微服务和自动可扩展架构的一些知识。在这个项目中，我们正在构建一个小型游戏，用户可以在其中驾驶飞机并在线击落其他玩家，托管在 Amazon Web Services 上。一场比赛的持续时间应该在 10 分钟左右，一百万场比赛应该（理论上）能够同时进行，大约一千名玩家应该能够在一场比赛中进行比赛。所以应用程序必须真正具有可扩展性。

我们现在正在架构中遇到困难的部分。我们希望服务器计算玩家的位置。这意味着服务器获取用于重新计算位置的关键输入请求。问题在于，由于应用程序是可扩展的，并且不只有一台服务器在进行所有计算并保存所有数据，因此输入事件可能最终会出现在不同的位置。我们期望不断将所有位置写入数据库并将其读回客户端太慢且可扩展性不够。此外，我们不希望为单个游戏使用专用服务器，因为这可能会削弱计算能力（和金钱）

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

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 与传统数据库相比。