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