数据库（Mongo）卷持久性Docker Swarm

Question

我们正在实施一个3节点的Swarm集群，用于部署微服务应用程序。此应用程序中的所有微服务都使用它们自己的数据库容器（每个服务模式的数据库），并使用事件总线在微服务之间共享数据。示例：

  ms_1:
    image: AnImage
    depends_on:
      - ms_2-mongo
    networks:
      - traefik_public_ntw
      - ms_1_mongo_ntw
  #### Microservice ####
  ms_1-mongo:
    image: mongo:3.6.19-xenial
    networks:
      - ms_1_mongo_ntw
    volumes:
      ms_1-mongo:/data/db
  #### Microservice ####
  ms_2:
    image: AnImage
    depends_on:
      - ms_2-mongo
    networks:
      - traefik_public_ntw
      - ms_2_mongo_ntw
  #### Microservice ####
  ms_2-mongo:
    image: mongo:3.6.19-xenial
    networks:
      - ms_2_mongo_ntw
    volumes:
      ms_2-mongo:/data/db

到目前为止，一切正常，但是我对Docker Swarm的行为以及如何避免卷问题（数据持久性）有一些疑问。

节点失败

如果某个节点发生故障，则Docker Swarm将检测到所需状态与实际状态不同，并将通过在其他可用节点上重新安排缺少的容器来自动进行协调。

在Mongo服务的情况下，这将导致问题，因为在另一个节点上缺少该卷，因此新任务中的数据将不可用。一种可能的解决方案是将mongo卷存储在NFS存储中（与集群中的所有节点共享）。在这种情况下，如果该节点发生故障，则该任务将在其他节点上重新安排，并且该任务将找到该卷。

问题： 将卷放在NFS存储上是否是一个好主意，特别是在性能方面？

某些微服务的性能

我们的某些微服务将不得不管理大量的读写操作（IoT遥测数据）。将来可能会导致某些性能问题。我们正在考虑为此特定的微服务部署分片群集。我们将实现将组成集群的几种服务，而不是一种mongo服务（因为在这种情况下，我们当然不能使用副本功能）。在这种情况下，我们可以避免使用NFS共享，但是我们必须将服务任务自己“粘”在一个节点上（不要让大量的任务散布，而是基本上由我们自己完成）。

另一个想法是为应用程序的所有微服务构建一个共享集群（例如上述）。微服务仍将拥有自己的数据库，但是，我们没有为每个微服务部署mongo服务，而是为所有微服务应用（所有微服务都使用Mongo作为存储）只有一个集群，而微服务（Web应用）将使用集群作为存储。

此用例的最佳策略是什么？有人遇到过这个问题吗？