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