我目前正在为我的新项目设计架构。这具有 ASP.Net MVC Web 客户端和用于第三方集成的 WCF Web 服务作为前端。
目前，这个应用程序将由我们在数据中心租用的机架空间上托管，但将来我们可能会将其移至 Microsoft Azure。
我是否必须在我的体系结构中针对 Azure 进行具体规划？或者我当前的具有 IIS、MSMQ、SQL Server、Velocity 等的架构可以在 Azure 中正常工作而不会出现太多问题？由于缺乏可用的时间，我一直忽略 Azure，但需要确保我获得适合未来需要的架构。
我需要注意什么？
感谢和问候，
阿杰
这取决于您考虑迁移到 Azure 的认真程度以及多久。如果你是，那么我会说是的。
不幸的是，能够在任何地方运行一次的想法有点像白日梦。如果平台限制了您的架构选择，那么抽象一切的概念就行不通了——几乎每个平台都这样做。例如，即使您可以选择数据持久性技术，您也几乎肯定会在某个时候遇到阻抗失配问题，这会影响您的设计。
因此，在 Azure 的情况下，您需要考虑许多问题。
首先，在这个阶段没有 MSMQ 或 Velocity。Azure 有它自己的队列组件，它具有更多的被动模型（轮询消息、无路由等），因此您可以使用它，但它不像 MSMQ 那样具有事务性，您需要确保所有消息都是幂等的。我相信分布式缓存正在以它的方式出现，但它还没有（而且可能不是 Velocity）。
其次，您可以选择Azure 的表存储或SQL Azure 数据库为您的表格般的持久性。您选择哪一个可能取决于您扩展痛点的位置。最简单的选择是走 SQL 路线，但 DB 大小存在某些限制，您将无法使用 SQL Server 周围的许多服务，例如作业代理、依赖项（用于缓存回调）、等等，如果您遇到 SQL Server 无法扩展的问题，那么在云中运行可能不会有太大帮助，因为它仍然是一个 RDBMS。如果你想要一个更具可扩展性的解决方案，那么 Azure 表存储就是你的选择——但它是非关系型的，你需要修改你的体系结构以适应它支持的更有限的事务范围——以及它的固有限制。 REST-HTTP 架构的查询机制和延迟。思考碱，不是酸。
第三，您需要以不同的方式考虑文件存储。由于您的每个实例都在 VM 中运行，因此当 VM 关闭时，任何本地存储都会消失，因此为了实现长期持久性，您需要使用Azure Blob 存储并在设计应用时牢记这一点。
第四，您可以选择两种类型的角色 - Web 角色，运行 IIS（您目前无法控制，就调整 IIS 参数而言）和工作角色，它们更像 Windows 服务。并且您的角色没有相互了解的机制 - 因此从 web 到工作人员的通信通过队列或表/blob 存储发生。所以你也需要记住这一点。
总而言之，如果您想迁移到 Azure，则需要做出许多设计决策 - 该平台本质上限制了您可以使用的技术，因此限制了您可以使用的设计选项。如果您在设计时考虑到了 Azure，那么您最终会得到一个更具固有可扩展性的系统，但在此过程中需要做出某些决定——有些可能会破坏交易。
[编辑：我应该补充一点，这个答案更多地是为了考虑将你的整个应用程序移动到 Azure。当然，这不是唯一的选择——您可能只想将某些组件移动到云中并将其余组件保留在本地，例如使用Azure .NET 服务总线之类的东西进行交互]
我会说不。
为您当前的平台设计，并仅在您实际使用 Azure 时进行修改。你很有可能不需要它，所以不要浪费你的时间。
无论如何，您的应用程序的体面设计应该会从底层架构中产生相当多的抽象，因此如果或当您切换平台时，默认情况下应该本地化更改。
我对 Azure 平台的当前产品了解不多，但我想说的是，总的来说，我会根据您现在的要求进行设计。猜测需求在未来会如何变化是非常困难的，并且会影响整个项目的成功。