随着微服务规模扩展管理数据存储并发 [英] Managing data-store concurrency as microservices scale

问题描述

我仍在尝试围绕微服务寻求解决方案.我有一个基本问题.

I am still trying to find my way around micro-services. I have a fundamental question.

在企业场景中，微服务可能必须写入永久数据存储-无论是RDBMS还是某种NoSQL.在大多数情况下，持久性数据存储是企业级的，但是只有一个实体(当然可以复制和备份).

In an enterprise scenario, micro-services would probably have to write to a persistent data-store - be it a RDBMS or some kind of NoSQL. In most cases the persistent data-store is enterprise grade, but a single entity (ofcourse replicated and backed up).

现在，让我们考虑将单个微服务部署到具有自己的持久数据存储(例如企业级RDBMS)的私有/公共云环境中的情况.当我扩展微服务时，将有多个微服务实例尝试从同一数据存储读取/写入.传统的数据存储可能可以调整为处理约50-200个并发连接.当我的微服务必须扩展到远远超出此范围时，我该如何处理?

Now, let's consider the case of a single micro-service deployed to private/public cloud environment having it's own persistent data-store (say enterprise grade RDBMS). As I scale my micro-service, there will be multiple instances of the micro-service trying to read/write from the same data-store. A traditional data-store can probably be tuned to handle ~50-200 concurrent connections. How do I handle a situation when my microservices has to be scaled much beyond that?

在这种情况下的最佳做法是什么?可以使用任何模式吗?

What are the best practices in such a scenario? Any patterns that can be used?

推荐答案

理想情况下，每个微服务实例都是独立的，因此每个实例可以独立于其他实例扩展，同时也封装了其状态，以便其他实例只能通过井井有条地访问它.定义的API.因此，不仅需要弄清楚如何扩展微服务用于存储状态的数据库，还需要解决这个封装问题，如果您真的想钉牢这种架构模式.

Ideally each microservice instance is self-contained so that each instance can scale independently of others while also encapsulating its state so that others can only access it through a well-defined API. So not only do you need to figure out how to scale your database(s) that your microservices use to store state, you also have this encapsulation problem to solve if you really want to nail this architectural pattern.

您是否查看过服务结构解决这个吗? Service Fabric具有状态服务的概念状态服务数据实际存储在每个微服务实例内部的位置.该平台可自动为HA处理复制和磁盘持久性，并且内置了数据分区，可在计算机之间分发.这个想法基本上是放弃中央数据库，而不是将您的计算和数据放在微服务实例中.现在您的服务是独立的，解决方案突然很适合此架构模式，因为现在每个微服务实例都可以横向扩展和独立升级，并且您已将数据完全封装在服务中.当然，要权衡的是您没有获得成熟的RDBMS的功能集，但是如果您考虑无论如何要使用NoSQL存储，那都不是什么大问题.

Have you looked at Service Fabric to solve this? Service Fabric has a concept of stateful services where data is actually stored inside each microservice instance. The platform handles replication and disk persistence automatically for HA and also has data partitioning built-in for distribution across machines. The idea is basically to ditch the central database, instead co-locating your compute and data within a microservice instance. Now your services are self-contained and suddenly the solution fits this architectural pattern nicely, because now each microservice instance can be scaled out and upgraded independently and you have full encapsulation of your data inside the service. The trade-off of course is that you don't get the feature set of a full-blown RDBMS, but if you're considering NoSQL stores anyway that shouldn't be a huge deal.

我一直认为，像数据库这样的中央存储在无共享微服务体系结构中有点反模式.不过，请充分披露:我在Service Fabric上工作，所以我的观点可能有点偏颇！

My thought on this has always been that a central store like a database is somewhat of an anti-pattern in a shared-nothing microservices architecture. Full disclosure though: I work on Service Fabric so my opinion may be a little biased!

这篇关于随着微服务规模扩展管理数据存储并发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！