Azure SQL多弹性池（多租户SaaS）

假设我想使用ASP.NET Core创建一个多租户SaaS应用程序，并且我想使用类似以下示例的Azure SQL弹性池：

每个池的最大数据库数为500：

其他信息：

我将从Azure SQL单数据库开始

我将使用实体框架核心

问题：

如果我的应用程序超过500个用户会发生什么？有什么选择 有效地扩展它？（当您达到弹性池的极限时）

该选项在多大程度上适合EF Core迁移

关于以后如何开始和处理这个问题，还有其他建议吗

---

回答上下文

在回答您的具体问题之前，让我为我看到的解决方案添加一些上下文。多租户带来了租户管理。而且，就像您链接到的文档中一样，可能会有某种目录包含所有特定于租户的信息。其中一条信息可能是（很可能是）到租户特定数据库的连接字符串

假设一个租户连接，系统从目录中获取要连接的数据库，基于它是哪个租户（让我们称之为租户的上下文）。应用程序将把连接字符串交给应用程序的其余部分使用

现在，解决方案的妙处在于：连接字符串可以（实际上）指向任何地方。它可以指向池中的数据库，也可以指向托管实例。它甚至可以指向通过互联网提供的内部数据库。所有这些都是因为应用程序不知道数据在哪里，所以它只获得一个连接字符串并开始工作

1。如果我的应用程序超过500个用户会发生什么？有哪些选项可以有效地扩展此功能？（当您达到弹性池的极限时）

假设用户指的是租户：什么都不会发生。在应用程序可访问的任何位置创建新数据库，例如在新池中。既然租户的连接字符串可以指向任何地方，那就完全可以了

2。该选项在多大程度上适合EF Core迁移？

与任何其他数据库模型一样，该选项也适用于EF Core迁移：对数据库的更新需要以一种体面且受管理的方式执行。例如，这可以通过运行迁移或更新脚本来完成。事实是：您需要更新多个数据库。为了实现这一目标，制定一个体面的移民计划是明智的

有几种方法可以缓解可能出现的问题，或者至少限制材料断裂的可能性。一种是只创建只添加到当前模型中的迁移。另一种方法是通过在数据库模型和应用程序之间设置一个异步通信层（如服务总线），将数据库模型与应用程序分离

这是一个非常复杂的定义策略，并且高度依赖于您正在构建的应用程序的类型、数据库更新的频率以及数据库方案的复杂性等因素

3。关于以后如何开始和处理此问题，还有其他建议吗？

就我而言：如果你知道这件事即将发生，现在就行动吧。在早期实现多租户是最容易的。这条路越远，就越困难，因为您可能在应用程序中开始硬编码（不是真的，而是某种）连接，一旦您想要添加多租户，就需要将这些连接解耦

结论

如果我正确地解释了您的问题，您就知道多租户将成为您的应用程序的“一件事”。这意味着您需要从一开始就解决它。但您不必从一开始就拥有完全成熟的多租户。。。你只需要做好准备

更专业一点：例如，您可以实现一个

TenantContext

，它在登录时标识租户，并在登录时获取附带的连接字符串（存储、服务总线、数据库等）。然后，在应用程序的其余部分，从

TenantContext

获取连接字符串，并使用这些字符串获取特定于租户的数据

首先，例如在开发过程中，上下文可以非常简单，只返回一个租户的信息。但是由于您引入了解耦，应用程序的其余部分已经为多租户做好了准备。一旦真正需要它，您所需要做的就是实现

TenantContext

编辑：

---

由于下面的注释，作为补充：有一种方法可以预先在DI系统中注册

DbContext

实例。您可以实现类似于

ConnectionStringResolver

的东西，它被注入到上下文中。一旦您实际需要一个DbContext，承租人上下文也是已知的。DbContext是使用

ConnectionStringResolver

为租户找到正确的连接字符串来构造的

您是否对每个租户都有单独的db有严格要求？我的意思是，这可能会非常昂贵。我仍在检查其他可能性，但我想知道这种针对db/tenant的方法在Azure弹性池中如何工作。这是一些可靠的建议。只是想知道，就像阅读你的观点一样。。我对如何在DI系统中处理DBContext感到非常好奇。如果通过从某处获取动态连接字符串来创建它们，则无法事先在DI系统中注册dbContext实例。@jpgrassi请查看更新后的答案。是的，我真的实现过几次；它有效；）啊，我在想这样的事情。很酷，谢谢分享！