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

Question

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

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

附加信息：

1. 我将从Azure SQL单一数据库开始

2. 我将使用实体框架核心

问题：

1. 如果我的应用程序超过500个用户怎么办？有什么选择可以有效地扩展规模？（当您达到弹性池的限制时）

2. 该选项与EF Core迁移的适应程度如何？

3. 关于以后如何开始和解决此问题的其他建议？

Answer 1

回答上下文

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

想象一个租户连接，系统根据目录是哪个租户从目录中获取要连接的数据库（我们称其为租户的上下文）。该应用程序会将连接字符串移交给该应用程序的其余部分以供使用。

现在，这是解决方案的妙处：该连接字符串可以（实际上）指向任何地方。它可以指向池中的数据库，也可以指向托管实例。它甚至可以指向已在Internet上提供的本地数据库。所有这些都是因为应用程序无法确定数据的位置，因此它仅获取连接字符串即可正常工作。

1.如果我的应用程序超过500个用户怎么办？有什么选择可以有效地扩展规模？（当您达到弹性池的限制时）

假设用户是租户，那么什么也不会发生。在应用程序可访问的任何位置（例如在新池中）创建新数据库。而且由于租户的连接字符串可以指向任何地方，所以完全可以。

2.该选项与EF Core迁移的适应程度如何？

与其他任何数据库模型一样，该选项也非常适合EF Core迁移：数据库更新必须以体面和托管的方式进行。例如，这可以通过运行迁移或运行更新脚本来完成。问题的实质仍然存在：您需要更新多个数据库。为此，制定适当的迁移计划是明智的。

有几种方法可以缓解可能的问题，或至少限制东西破裂的可能性。一种方法是仅创建仅添加到当前模型的迁移。另一个方法是通过在服务总线之间建立一个异步通信层来将数据库模型与应用程序分离。

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

3.关于以后如何开始和解决此问题的其他建议？

至于我担心：如果你知道这是未来，作用于它现在。尽早实施多租户是最容易的。走得越远，难度就越大，因为您可能要在应用程序中开始硬编码（不是真正的，而是某种）连接，一旦要添加多租户就需要将其断开。

结论

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

获得更多技术知识：例如，您可以实现一个TenantContext在登录时标识租户并在登录时获取随附的连接字符串（存储，服务总线，数据库等）的工具。然后，在应用程序的其余部分，从中获取连接字符串，TenantContext并使用这些字符串获取特定于租户的数据。

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

编辑：
作为，因为下面的评论的添加：有是注册的方式DbContext预先在DI系统的实例。您可以实现ConnectionStringResolver注入到上下文中的类似a的东西。一旦您实际需要 DbContext，就知道租户上下文。构造DbContext，使用ConnectionStringResolver来找到租户的正确连接字符串。