随着微服务的扩展，管理数据存储并发性

Question

我仍然在努力寻找微服务的方法。我有一个基本的问题。

在企业场景中，微服务可能必须写入持久数据存储--可以是关系数据库，也可以是某种NoSQL。在大多数情况下，持久数据存储是企业级的，而是单个实体(当然是复制和备份的)。

现在，让我们考虑将单个微服务部署到私有/公共云环境的情况，该环境具有自己的持久数据存储(比如企业级RDBMS)。当我扩展我的微服务时，将会有多个微服务实例试图从同一数据存储中进行读/写。可以对传统的数据存储进行调优，以处理大约50-200个并发连接。当我的微服务必须扩展到更远的时候，我该如何处理这种情况？

这种情况下的最佳实践是什么？有什么可以使用的模式吗？

Answer 1

理想情况下，每个微服务实例都是自包含的，因此每个实例可以独立于其他实例进行扩展，同时还可以封装其状态，以便其他实例只能通过定义良好的API访问它。因此，您不仅需要弄清楚如何扩展您的微服务用来存储状态的数据库，而且如果您真的想要抓住这个体系结构模式，您还需要解决这个封装问题。

你有没有考虑过Service Fabric来解决这个问题？服务结构具有stateful services的概念，其中数据实际存储在每个微服务实例中。该平台自动为HA处理复制和磁盘持久化，还内置了数据分区，以便跨机器分发。这个想法基本上是抛弃中央数据库，而是将您的计算和数据放在一个微服务实例中。现在，您的服务是自包含的，突然之间，解决方案很好地适应了这种体系结构模式，因为现在每个微服务实例都可以独立扩展和升级，并且您可以将数据完全封装在服务中。当然，权衡的是您没有获得成熟的RDBMS的特性集，但如果您正在考虑NoSQL商店，这不应该是一个大问题。

我一直认为，在无共享微服务体系结构中，像数据库这样的中央存储在某种程度上是反模式。完全公开:我在Service Fabric上工作，所以我的观点可能有点偏颇！