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