我正在使用 docker 构建一个具有微服务结构的游戏。
我开始构建服务的方式是为每个服务提供一个 mongoDB 实例，因此为 mongoDB 实例提供 OneToOne 服务，
Resources ---> resourcesDB (mongoDB instance 1)
Chat ---> chatDB (mongoDB instance 2)
Buildings ---> buildingsDB (mongoDB instance 3)
Battle ---> battleDB (mongoDB instance 4)
...
这在开始时真的很有意义，因为例如这些服务没有任何共同点，也不需要与同一个 mongo 实例建立连接，当它们确实有一些共同点（构建 <-> 资源）时，它们只需发送一个调用到所需的服务并处理其余的（更新他的数据库）。
但我开始认为这不是正确的方法，因为有几件事：
1 - 例如，resourcesDB 只有 2 个集合，
Logs ---> logging every resources change (building built, war lost etc.)
Resources ---> 1 document per user holding how much he have.
这意味着这个数据库不会保存任何巨大的数据（日志将在一段时间后被删除），所以为这两个集合设置一个实例看起来像是一个巨大的过度杀戮，即使这个实例没有自己的服务器并且会共享服务器与服务。
2 - 维护和做备份将需要一些额外的工作，我不确定在我的情况下是否需要。
每个服务都会经常更新他的数据库，资源每秒都在计算以查看每个用户有多少，所以它会'users amount'每秒更新数据库，除了其他请求，比如建造建筑物（减少资源）和其他更新，聊天服务将在每条私人消息或聊天消息中更新数据库，战斗服务将在每场战斗中每秒更新部队地点和统计数据以及更多内容。
我正在考虑将该结构用于下一个：
可能只有 1 个带有独立数据库的数据库实例，因此每个服务都将连接到一个独立的数据库，但我读到维护数据库的备份和扩展仍然很麻烦。
有 1 个数据库，其中包含所有集合，每个集合都将由不同的服务访问，并且永远不会被 2 访问，所以我不必担心 2 个服务更改同一个集合。
保持原样，并使用许多 mongoDB 实例
关于上述方法的几个问题：
我应该选择什么？拥有 1 个数据库听起来不错，因为它将为我节省大量资源并使我的生活更轻松，但是将服务与许多数据库分开对我来说是合理的逻辑，因为一项服务不需要查看集合或能够访问一个集合与他的工作无关。
我不确定 mongoDB 如何处理与同一个实例或同一个数据库的许多连接，正如您所见，即使我的用户数量很少，它也可能在一秒钟内收到很多调用。
我阅读了有关 mongo Sharding 的信息，据我了解它发生在每个数据库而不是实例级别，这就是为什么我正在考虑 1 数据库选项，因为它在我的情况下非常有用，对吗？