每个微服务的单个DB真的意味着每个微服务的单个DB服务器吗？
它被认为是最好的方法，微服务数据库对它是私有的，而没有共享的方法，是最好的。
最近我遇到了一个基于云的系统，它使用postgres、mongodb和遵循每个服务DB，只要每个服务运行自己的存储引擎集群，该集群只承载一个数据库。
例如，服务A和服务B使用弹性搜索(ES)，各有3个索引。它们有自己的ES集群，其中托管了3个索引。使用mongodb或postgres的其他服务也是如此，其中1-2集合托管在单个mongo集群上，或7-8表由一个postgres集群管理。
我对他们遵循设计的方式感到困惑。据我理解，单独的数据库并不意味着单独的数据库引擎实例。任何现代数据库引擎都可以很容易地托管多个数据库。服务拥有数据库，但不拥有DB引擎实例。这不仅造成了维护的噩梦，而且每个数据库引擎的利用率都严重不足。我的理解是正确的还是我有错误的理解？
回答 2
Stack Overflow用户
发布于 2022-07-20 13:12:12
每个服务中的单个数据库中的值是允许服务独立于其他服务进行扩展。让这些服务共享这样的基础设施会使这种情况有所妥协，但会以一种非常琐碎的方式出现。
这样想一想，如果其中一个服务的负载是100倍，那么提供它自己的实例并与其他服务分别扩展它的难度有多大。只要集合/数据库不相互交谈，这是非常简单的。
会有一种诱惑力，让这些数据库在后端互相交谈。在一个实例中拥有多个数据库/集合意味着特别是报告要容易得多。从报告的角度来抵制做这件简单事情的冲动，对保持这种分离将有很大帮助。
共享数据库引擎不是问题，只要您有纪律不要将数据库连接在一起。
Stack Overflow用户
发布于 2022-07-21 06:44:48
第一个问题是，什么是真正的服务，应该有一个单独的逻辑模式；实际上，一个服务的多个方面应该首先共享一个模式。
一旦您决定了某件事(比如“微服务”)，就需要它自己独立的逻辑模式--第二组要考虑的是成本、效率和管理复杂性以及实际需要的规模等操作问题。这些关注应该指导您是设置单独的还是共享的引擎，而不是担心开发人员。
您可以使用其他机制来处理开发人员连接事物的问题。它们仍然可以连接到分离数据库并直接从它们获取数据，而不是通过APIs等等，因此您应该要么信任您的开发人员，进行代码评审，提供不同的连接和角色，以防止连接到一个模式，在任何情况下，等等，这是治理问题，不应该与一个操作的。
https://stackoverflow.com/questions/73050859
复制相似问题
腾讯云开发者
