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