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