假设我想使用ASP.NET Core创建一个多租户SaaS应用程序，并且我想使用类似于以下示例的Azure SQL弹性池：Microsoft Docs
每个池的最大数据库数为500：Azure Pricing
其他信息：
我将从Azure SQL单一数据库开始
我将使用Entity Framework Core
问题：
如果我的应用程序超过500个用户怎么办？有哪些选择 有效地扩展？ （当您达到弹性池的限制时）
该选项与EF Core迁移的适应程度如何？
关于以后如何开始和解决此问题的其他建议？
答案 0 :(得分：5)
答案上下文
在回答您的特定问题之前，让我添加一些有关所看到的解决方案的上下文。伴随多租户的是租户管理。而且，就像您链接到的文档中一样，可能会有某种目录包含所有特定于租户的信息。这些信息之一（很可能是）是指向租户特定数据库的连接字符串。
想象一个租户连接，系统根据目录是哪个租户从目录中获取要连接的数据库（我们称其为租户的上下文）。该应用程序会将连接字符串移交给该应用程序的其余部分以供使用。
现在这是解决方案的妙处：连接字符串可以（实际上）指向任何地方。它可以指向池中的数据库，也可以指向托管实例。它甚至可以指向已在Internet上提供的本地数据库。所有这些都是因为应用程序无法确定数据的位置，因此它仅获取连接字符串即可正常工作。
1。如果我的应用程序超过500个用户怎么办？有什么选择可以有效地扩展规模？ （当您达到弹性池的限制时）
假设用户是指租户：什么也不会发生。在应用程序可访问的任何位置（例如在新池中）创建新数据库。而且由于租户的连接字符串可以指向任何地方，所以完全可以。
2。该选项与EF Core迁移的适应程度如何？
该选项与EF Core迁移一样，也与其他任何数据库模型一样，都适用：数据库更新需要以体面且受管理的方式执行。例如，这可以通过运行迁移或运行更新脚本来完成。问题的实质仍然存在：您需要更新多个数据库。为此，制定适当的迁移计划是明智的。
有几种方法可以减轻可能出现的问题，或者至少限制东西破裂的可能性。一种方法是仅创建仅添加到当前模型的迁移。另一个方法是通过在服务总线之间建立一个异步通信层来将数据库模型与应用程序分离。
这是一个定义非常复杂的策略，并且高度依赖于各种因素，例如正在构建的应用程序的类型，数据库更新的频率以及数据库方案的复杂性。
3。还有其他关于以后如何开始和解决此问题的建议吗？
就我而言：如果您知道这将要发生，请立即采取行动。尽早实施多租户是最容易的。走的越远，难度就越大，因为您可能会开始对应用程序中的连接进行硬编码（不是真正的，而是某种连接），而一旦要添加多租户，就需要取消连接。
结论
如果我正确地解释了您的问题，您就会知道多租户将成为您应用程序的“物”。这意味着您需要从头开始解决它。但是您不必从一开始就拥有完整的完整多租户……您只需为此做好准备。
获取更多技术信息：例如，您可以实现一个TenantContext，以便在登录时标识租户并在登录时获取随附的连接字符串（存储，服务总线，数据库等）。然后，在应用程序的其余部分中，从TenantContext获取连接字符串，并使用它们来获取特定于租户的数据。
首先，例如在开发期间，上下文可以非常简单，并且仅返回一个租户的信息。但是由于您引入了去耦，因此该应用程序的其余部分已经为多租户做好了准备。一旦真正需要它，您要做的就是实现TenantContext。
编辑：
另外，由于以下注释： 是一种预先在DI系统中注册DbContext实例的方法。您可以实现插入到上下文中的ConnectionStringResolver之类的东西。当您实际上确实需要一个DbContext时，租户上下文也会被知道。使用ConnectionStringResolver为租户找到正确的连接字符串，从而构造DbContext。