我有一个 ASP.NET MVC 2 Azure 应用程序，我正在尝试从单租户切换到多租户。我已经在 Stack Overflow 上查看了许多博客、帖子和问题，但我仍在努力思考适合这个特定应用程序的细节。
目前，应用程序将一些信息存储在 SQL Azure 数据库中，以及一些其他信息存储在 Azure 存储帐户中。我正在考虑编写租户配置代码来简单地为新租户创建一个新数据库，以及一个新的 Azure 存储帐户。这让我想到了以下问题：
我将如何在本地测试这种方法？据我所知，本地 Azure 存储模拟器只有 1 个存储帐户。我不确定我是否能够在本地创建其他人。我将如何在本地进行测试？或者有可能吗？
【问题讨论】：
标签： azure multi-tenant
多租户需要考虑很多方面，其中之一是数据架构。您还有计费、性能、安全性等。
关于数据架构，我们先来探索一下SQL存储。您可以使用以下选项：添加您的代码将用于过滤记录的 CustomerID（或其他标识符），为不同的客户使用不同的模式容器（每个客户都有自己的专用模式拥有的所有数据库对象的副本）在数据库中）、线性分片（每个客户都有自己的数据库）和联合（SQL Azure 的一项功能，它根据性能和可伸缩性需求提供渐进式分片）。所有这些选项都是有效的，但对性能、可扩展性、安全性、维护（例如备份）、成本以及数据库设计有不同的影响。根据您提供的信息，我无法告诉您选择哪一个；如果您已经有代码库，则某些模型比其他模型更容易实现。一般来说，线性分片是最简单的模型并提供强大的客户隔离，但可能是最昂贵的。基于模式的分离并不太难，但需要很好地处理安全要求，并且可能会引入跨客户的性能问题，因为这种方法不是无共享的（对于同一数据库上的客户）。最后，Federations 需要使用客户识别器并且有一些限制；然而，这项技术让您可以更好地控制性能分布和长期可扩展性（因为与线性分片一样，Federation 使用无共享架构）。
关于存储帐户，每个客户使用不同的存储帐户绝对是可行的方法。如果不使用单独的存储帐户，您将面临的主要问题是性能限制，例如每秒可以使用单个存储帐户执行的最大事务数。但是，正如您所指出的，在本地进行测试可能是个问题。但是请考虑这一点：本地模拟器不提供与 Azure 存储帐户 100% 的对等（模拟器不支持某些功能）。所以我只会使用本地模拟器进行初始开发和故障排除。任何严肃的测试，包括多租户测试，都应该使用真实的存储帐户来完成。这是您可以完全测试应用程序的唯一方法。
【讨论】：
您应该考虑不创建单独的数据库，而是在单个 SQL 数据库中创建不同的对象命名空间。每个租户都可以拥有自己的一组表。
根据您使用存储的方式，您可以为每个客户端创建单独的存储容器或消息队列。
鉴于这些限制，您应该能够使用存储模拟器和本地 SQL 实例进行本地测试。
如果您需要进一步解释，请告诉我。
【讨论】：