我有这样一个概念：将游戏引擎重写为可伸缩的微服务集合。
这是目前的概念证明，但主要原则在于每个玩家都有一个单独的容器来控制和管理他们的会话/连接，因此容器将根据连接用户的数量进行上下扩展。
每个播放器容器将与多个其他微服务对话以收集数据并执行操作，这些服务将是2或3的静态副本。
有一个微型服务，我在脑海中，我觉得是有点瓶颈，我目前正在寻找方法，使更多的'可扩展性'和'健壮'。
这个有问题的微服务是gamemap服务。将会有多个游戏Map服务（每个uniqe或示例游戏Map至少有一个服务）。每个贴图将包含n个单元格，每个单元格可以包含具有不同类型/状态的对象（例如，其他playerobjects、itemobjects）
我想能够有一个副本，至少2为每个游戏Map立即翻转，如果一个是由于某种原因失败和关闭。。对于用户来说，在失败和故障转移游戏Map之间实现无缝过渡非常重要。为了实现这一点，我需要在他们之间共享一致/最新的状态。
需要能够在两个复制副本之间实现负载平衡，这是一个不错的选择，但不是必需的。
到目前为止，我提出的一个可能的解决方案是hazelcast。这将允许我在可伸缩内存数据网格中保持每个map单元的状态（同样是为了健壮性和可伸缩性）。
我预计，在一个游戏Map中，每秒钟可能会有多达100次的状态变化，我担心的是，这可能太慢，导致用户之间的巨大延迟。
有人根据这两个场景或者更重要的是hazelcast的用例得到任何提示、建议或反馈吗？
p、 如果有帮助或者有人感兴趣的话，我可以在某个时候上传我的游戏引擎非常粗糙的连接/架构图作为微服务。