每个租户具有微服务和数据库的SAAS应用程序

Question

我正在为多租户SAAS模型设计web应用程序，由于一些规定，我们决定每个租户有一个数据库，我们正在考虑为我们的中间件提供微服务。但我有点困惑，微服务架构谈论的是“每个微服务都有自己的数据库”。下面是我的问题

1. 如果我将共享数据库用于微服务，这违反了微服务设计的概念/目的，即它们都应该被隔离，任何更改都应该限于该微服务

我可以想到一个层，它模仿我的数据库表作为DTO，每个微服务都通过这个层与数据库通信，如果我错了，请纠正我。

那么，设计每个租户一个数据库的中间件的正确方法应该是什么呢？如果有更好的方法，请随意分享。

下面是我们从这里开始的高级设计

Answer 1

我们的应用程序是SaaS和具有微服务体系结构的多租户。我们确实为每个服务使用一个数据库，尽管在某些情况下，它实际上只是每个租户的一个单独模式，而不是一个单独的实例。

“每个服务的数据库”中的关键概念都与避免在服务之间共享表/文档有关，而与如何实现这一点关系不大。如果两个服务都是紧密耦合的，那么两个服务之间的紧密耦合就如同两个表之间的紧密耦合一样。

每个服务的数据库意味着不在多个服务之间共享持久性，如何实现这一点取决于您。

多租户是另一个挑战，有多种方法可以应对。在我们的情况下（法规没有规定我们的体系结构），我们设计了租户感知表结构，将TenantId作为主键的一部分。每个租户感知服务都实现了这种分离，我们的授权服务有助于将用户限制在其指定租户的范围内。

如果您需要比键/值分离更多的分离，我希望利用模式作为隔离数据和安全性的一个很好的工具：

• 比如说，每个实例（每个租户）可以有一个SQL，每个实例（每个租户）可以有一个数据库模式

在任何一种情况下，您都可能希望在您选择的数据库中编写一些工具来帮助管理您不断增长的模式集合，但是除非您最终会有成千上万的租户，否则这应该会让您走得很远。

要说明的最后一点是，您将非常依赖某种集成总线来保持您的多个独立数据存储同步。我强烈建议您在设计上花费尽可能多的时间，就像您在设计剩余的持久性一样，因为这些事件将成为系统的生命线。例如，在我们的多租户设置中，创建一个新租户会触及我们80%的其他服务（通过广播消息），以便这些服务准备好与新租户交互。有些集成事件需要快速发生，有些需要慢慢来，但是管理所有这些移动部分是一个挑战。

Answer 2

你应该在这里区分两件事：

>

每个微服务的数据库每个微服务都有自己的数据库，这是微服务体系结构中的基本规则之一。原因有很多，其中一些是：

• 缩放
• 隔离
• 为不同的微服务使用不同的数据库技术（如果需要）
• 开发团队分离

你可以在这里读到更多关于它的信息。当然它有一些缺点，但是请记住这是微服务架构中的关键规则之一。

你的问题

如果我将共享数据库用于微服务，这违反了微服务设计的概念/目的，即它们都应该被隔离，任何更改都应该限于该微服务。

如果您可以尝试避免多个微服务共享数据库。如果你最终做到这一点，你应该考虑一下你的建筑设计。有时，强制一个数据库表明，一些微服务应该合并为一个，因为它们之间的耦合非常大，因此使用它们的开销变得非常复杂。

如果我使用每个微服务都有自己的数据库，那么几乎不可能每个租户都有一个数据库，否则每个微服务最终都会有n个数据库。

我并不认为这是不可能的。是的，这很难管理，但如果您决定使用微服务，并且需要数据库切分，那么您需要处理额外的复杂性。当然，每个微服务有一个数据库，然后每个微服务有n个数据库可能非常具有挑战性。作为解决方案，我建议如下：

>

只在需要的微服务中将数据物理地分离到不同的碎片。假设你有两个微服务：产品库存微服务和客户微服务。假设你的产品库存中有3亿个产品，微服务数据库只有50万个客户。在customers micro服务中，您不需要为每个租户建立数据库，但在product inventory micro服务中，您需要拥有3亿条记录，这在性能方面非常有用。正如我上面所说的，从一个或两个物理数据库开始，随着时间的推移，您的数据会增加，并且您需要它。这样，您将在服务器的开发和维护中节省一些开销，至少在您不需要的时候是这样。