我仍在努力找到解决微服务的方法。我有一个基本问题。
在企业场景中，微服务可能必须写入持久数据存储，无论是RDBMS还是某种NoSQL。在大多数情况下，持久数据存储是企业级的，但它是一个单独的实体（当然是复制和备份的）。
现在，让我们考虑一个部署到私有/公共云环境的单个微服务拥有自己的持久数据存储（比如企业级RDBMS）的情况。当我扩展我的微服务时，会有多个微服务实例试图从同一数据存储中读/写。传统的数据存储可能可以调整为处理50-200个并发连接。当我的微服务必须扩展到远远超出这个范围时，我该如何处理这种情况？
在这种情况下，最佳做法是什么？有什么可以使用的模式吗？
理想情况下，每个微服务实例都是自包含的，这样每个实例都可以独立于其他实例进行扩展，同时封装其状态，以便其他实例只能通过定义良好的API访问它。因此，您不仅需要弄清楚如何扩展微服务用于存储状态的数据库，如果您真的想确定这种架构模式，还需要解决封装问题。
您是否查看了Service Fabric来解决此问题？Service Fabric有一个有状态服务的概念，其中数据实际上存储在每个微服务实例中。该平台为HA自动处理复制和磁盘持久性，还内置了用于跨机器分发的数据分区。这个想法基本上是放弃中央数据库，而是将您的计算和数据放在一个微服务实例中。现在，您的服务是自包含的，突然间，解决方案很好地适应了这种架构模式，因为现在每个微服务实例都可以独立扩展和升级，并且您可以在服务中完全封装数据。当然，代价是你没有得到一个成熟的RDBMS的功能集，但如果你无论如何都在考虑NoSQL存储，那应该不是什么大不了的事。
我一直认为，像数据库这样的中央存储在某种程度上是无共享微服务架构中的反模式。不过要充分披露：我在Service Fabric工作，所以我的观点可能有点偏见！