我正在设计用于多租户SAAS模型的Web应用程序，由于某些规定，我们决定为每个租户建立一个数据库，并且正在考虑为中间件提供微服务。但是我有点困惑，微服务架构谈论“每个微服务都有自己的数据库”。这是我的问题
我可以想到一个将我的数据库表模仿为DTO的层，并且每个微服务都通过该层与数据库进行通信，如果我在这里错了，请纠正我。
那么设计每个租户一个数据库的中间件应该是正确的方法 或者，如果有更好的方法，请随时分享。
下面是我们开始的高级设计 here
答案 0 :(得分：0)
我们的应用程序是SaaS和具有微服务架构的多租户。我们确实确实为每个服务使用1个数据库，尽管在某些情况下，实际上每个租户只是一个单独的架构，而不是一个单独的实例。
“每个服务的数据库”中的关键概念与避免在服务之间共享表/文档有关，而与实际实现方式无关。如果两个服务都访问同一个表，那么这将成为服务之间紧密耦合以及常见的故障点-微服务旨在避免两种情况。
每个服务的数据库意味着不要在多个服务之间共享持久性，这取决于您如何实现。
多租户是另一个挑战，有多种解决方法。在我们的情况下（法规不支配我们的体系结构），我们设计了TenantId作为主键的一部分的可感知租户的表结构。每个了解租户的服务都实现了这种分离，我们的授权服务有助于使用户保持在其分配的租户的边界之内。
如果您需要比键/值分隔更多的分隔，我希望利用模式作为隔离数据和安全性的好工具：
在任何一种情况下，您可能都希望在选择的数据库中编写一些工具来帮助管理不断增长的模式集合，但是除非您最终要拥有成千上万的租户，否则应该会让您失望得多道路。
最后一点是，您将严重依赖某种类型的集成总线，以使多个独立的数据存储保持同步。我极力鼓励您将其余的时间花在设计上，因为这些事件已成为系统的命脉。例如，在我们的多租户设置中，创建新的租户会触摸我们其他服务的80％（通过广播消息），以便这些服务可以与新的租户进行交互。有一些集成事件需要快速发生，其他一些事件可能会花费一些时间，但是管理所有这些活动部分是一个挑战。
答案 1 :(得分：0)
您应该在这里区分两件事：
数据库分片 分片是一种与水平分区有关的数据库体系结构模式，在该模式中，您可以根据某些逻辑键拆分数据库。在您的情况下，您的逻辑密钥是您的Tenant（tenantId或tenantCode）。分片可让您将数据从一个数据库拆分到多个物理数据库。理想情况下，每个逻辑分片可以有一个数据库。在您的情况下，这意味着您最好在每个租户中都具有数据库。请记住，您不必将其分开那么远。如果您的数据不够大，不值得将每个租户数据放入单独的数据库，则从2个数据库开始，然后将租户的一半放入一个物理数据库，另一半放入另一个物理数据库。然后，您可以通过在数据库中保存某个租户所在数据库中的某些配置或另一个表来在应用程序层上协调此操作。随着数据的增长，您可以迁移和/或创建其他物理数据库或物理碎片。
每个微服务的数据库 每个微服务都有自己的数据库是微服务体系结构的基本规则之一。造成这种情况的原因有很多，
您可以详细了解here。当然，它有一些缺点，但请记住，这是微服务体系结构中的关键规则之一。
您的问题
如果我将共享数据库用于微服务，则违反了概念/目的 微服务设计，它们都应该被隔离，并且任何 更改应仅限于该微服务。
如果您可以尝试避免为多个微服务共享数据库。如果最终这样做，则应该考虑您的建筑设计。有时强行使用一个数据库可以指示一些微服务应该合并为一个，因为它们之间的耦合很大，因此使用它们的开销变得非常复杂。
如果我使用的每个微服务都有自己的数据库，那么几乎 每个租户不可能有一个数据库，否则每个 微服务最终拥有n个数据库。
我不太同意这是不可能的。是的，这很难管理，但是如果您决定使用微服务，并且需要数据库分片，则需要处理额外的复杂性。确保每个微服务拥有一个数据库，然后为每个微服务拥有n个数据库可能非常具有挑战性。 作为解决方案，我建议如下：
将tenant（tenantId或tenantCode）作为一列包含在数据库的每个表中。这样，如果您决定需要分拆该表，模式中的表集或属于某个微服务的整个数据库，则以后可以轻松迁移。就像上面关于数据库分片的部分所述，您可以从一个物理分片（一个物理数据库）开始，但已经定义了逻辑分片（在这种情况下，使用每个表中的租户信息）。
仅在您需要的微服务中将数据物理地分离到不同的碎片中。假设您有2种微服务：产品库存微服务和客户微服务。假设您的产品库存微服务数据库中有3亿种产品，而只有50万个客户。您不需要在微服务客户中为每个租户建立数据库，而在产品库存微服务中具有3亿条记录的租户，这对于提高性能非常有用。 就像我上面说的，从1或2个物理数据库开始，随着时间的流逝，数据会随着时间的增长而增加和迁移，因此您需要它。这样，至少在不需要时，您将节省服务器开发和维护的一些开销。
