让我们想象一下，我们是一个SaaS解决方案供应商。 你的客户主要是那些想在你的服务范围内拥有自己的空间的公司，他们的用户可以围绕你的服务一起工作。在这篇文章中，我们将把你的客户称为租户。 该解决方案使用一个关系型数据库。在架构设计过程中，当你已经知道你将选择一个关系型数据库时，你可能会面临在单一数据库或多租户架构之间的选择。
假设有一个要求，应用程序应该允许租户之间共享数据（CRUD），而通过调用REST API或一些队列解决方案来共享，从性能的角度来看是不可接受的。
在这种情况下，单一数据库的解决方案似乎是最合理的，你只需要执行SQL操作。
虽然经过一些妥协，你可能会通过定义一些不应该被判别列隔离的表（在文章的后半部分描述）和应用额外的用于授权的查询，使用共享模式策略的多租户架构达到同样的效果。
然而，我们必须记住，在单一数据库解决方案中隔离租户数据需要大量的额外代码，开发人员必须实现这些代码来保护数据。
这种方法可能会使实施复杂化，而不提共享数据，使开发人员的工作更加困难。
通过选择多租户架构，我们可能会摆脱这个问题。
当然，选择这种方法会带来一些其他的挑战，而这些挑战是我们在使用单一数据库时不会遇到的，而且这些挑战根据所选策略的不同而不同，但这个话题是另一篇文章的内容。
要进行多租户架构，我们必须决定选择哪种策略?
最流行的三种策略是独立数据库、独立模式和共享模式。
在这种情况下，每种策略都有优点和缺点:
- 从隔离的角度来看，独立数据库的策略保证了最高水平。而共享模式策略与其他两种策略相比，水平最低。这就是为什么要确保你的潜在客户同意他的数据将被存储在同一式中的重要原因。至于性能，独立数据库似乎是最好的选择。尽管应用程序将为每个租户管理一个数据库连接池，但对单个数据库的操作将只为一个租户执行。
- 但是，也请记住，通过实施独立模式或共享模式策略，我们可以将其与独立数据库结合起来。例如，通过将一组租户保留在一个单独的/共享的模式和一个租户的单一数据库中，我们已经保证了独立数据库的最高性能和数据隔离水平。这样的方法也需要一些明智的路由策略，但这个话题是另一篇文章的内容。
- 共享模式策略最显著的优势是它需要最少的资源，降低了成本。如果你在选择正确的策略时考虑到其他事情，比如DDL操作的执行、容错，以及其他许多事情，将会有所帮助。但这并不是本文的主题。
演示应用
您可以在Github 页面存储库中找到演示应用程序的代码。我们的演示应用程序是一个 Web 应用程序，用户可以在其中添加帖子。用户存在于域范围内。并且该域被分配给一个租户。域是表示资源特定租户的 URL 的一部分，例如：
/app/polish.dude.eu/home- “polish.dude.eu ”域 的主页
/app/my.doc.com/home- “ my.doc.com”域的主页
详细说明点击标题