我目前正在为我的新项目设计架构。它具有 ASP.Net MVC Web 客户端和 WCF Web 服务，用于作为前端进行第三方集成。
目前，该应用程序将由我们托管在数据中心租用的机架空间上，但将来我们可能会将其迁移到 Microsoft Azure。
我是否必须在我的架构中对 Azure 进行具体规划？或者我当前的架构(包含 IIS、MSMQ、SQL Server、Velocity 等)可以在 Azure 中运行而不会出现太多问题吗？由于缺乏可用时间，我一直忽略 Azure，但需要确保我获得适合 future 需要的架构。
我需要注意哪些事项？
感谢和问候，
阿杰
最佳答案
这取决于您考虑迁移到 Azure 的认真程度以及多久。如果你是，那么我会说是的。
不幸的是，能够在任何地方编写一次运行的想法有点痴人说梦。如果平台限制了您的架构选择，那么抽象一切的概念就行不通——而且几乎每个平台都如此。例如，即使您可以选择数据持久性技术，您也几乎肯定会在某些时候遇到阻抗不匹配问题，从而影响您的设计。
因此，就 Azure 而言，您需要考虑许多问题。
首先，现阶段没有 MSMQ 或 Velocity。 Azure有它自己的queueing component它具有更多的被动模型(轮询消息、无路由等)，因此您也许可以使用它，但它不像 MSMQ 那样具有事务性，并且您需要确保所有消息都是幂等的。我相信分布式缓存正在发展中，但它还没有实现(而且可能不是 Velocity)。
其次，您可以选择Azure's Table Storage或SQL Azure Database为了你餐 table 般的坚持。您选择哪一种可能取决于您所解决的痛点所在。最简单的选择是采用 SQL 路线，但数据库大小存在某些限制，并且您将无法使用 SQL Server 周围的许多服务，例如作业代理、依赖项(用于缓存回调)、如果您遇到 SQL Server 无法扩展的问题，那么在云中运行可能不会有太大帮助，因为它仍然是一个 RDBMS。如果您想要一个更具可扩展性的解决方案，那么 Azure 表存储就是您的选择 - 但它是非关系型的，您需要修改架构以适应它支持的更有限的事务范围 - 以及其固有的局限性REST-HTTP 架构的查询机制和延迟。想想BASE ，不是 ACID。
第三，您需要以不同的方式考虑文件存储。由于每个实例都在虚拟机中运行，因此当虚拟机关闭时，所有本地存储都会消失，因此为了实现长期持久性，您需要使用 Azure Blob Storage并在设计您的应用程序时牢记这一点。
第四，您可以选择两种类型的角色 - Web 角色、运行 IIS(您目前无法控制，在调整 IIS 参数方面)和辅助角色，它们更像 Windows 服务。并且没有机制让您的角色相互了解 - 因此从网络到工作人员的通信是通过队列或表/blob 存储进行的。因此，您也需要牢记这一点。
总而言之，如果您想迁移到 Azure，则需要做出许多设计决策 - 该平台本质上限制了您可以使用的技术，因此限制了您可以使用的设计选项。如果您在设计时考虑到了 Azure，那么您最终将得到一个本质上更具可扩展性的系统，但在此过程中需要做出某些决定 - 其中一些可能会破坏交易。
[编辑:我应该补充一点，这个答案更多是为了考虑将整个应用程序迁移到 Azure。当然，这不是唯一的选择 - 您可能只想将某些组件移动到云端，并将其余组件保留在本地，使用类似 Azure .NET Service Bus 的内容进行交互。例如]
关于architecture - 我是否必须在设计应用程序架构时考虑到 Azure？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1281853/