我必须在设计应用程序架构时考虑Azure吗？

Question

我目前正在为我的新项目设计架构。这有ASP.Net MVC客户端和web服务作为前端的第三方集成。

目前，此应用程序将由我们在数据中心的租赁机架空间上托管，但未来我们可能会将其移动到Microsoft Azure。

我必须在我的架构中为Azure做特定的规划吗？或者我目前的架构，有IIS，MSMQ，SQL Server，Velocity等，可以在Azure中工作而不会有太多问题？由于缺乏可用的时间，我一直对Azure一无所知，但需要确保我的架构正确，以满足未来的需求。

我需要注意的东西是什么？

感谢和问候，

阿贾伊

Answer 1

这取决于你有多认真地考虑迁移到Azure，以及多快。如果你是，那么我会说是。

不幸的是，能够写一次就能在任何地方运行的想法有点白日做梦。如果平台限制了您的架构选择，那么抽象一切的概念就不起作用了--几乎每个平台都是这样做的。例如，即使您可以选择数据持久化技术，您也几乎肯定会在某些时候遇到阻抗不匹配问题，这将影响您的设计。

因此，在Azure的案例中，您需要考虑许多问题。

首先，在这个阶段没有MSMQ或Velocity。Azure有它自己的queueing component，它有更多的被动模型(消息轮询，无路由等)，所以你可以使用它，但它不像MSMQ那样是事务性的，你需要确保所有消息都是幂等的。我相信分布式缓存已经上路了，但它还没有实现(也可能不是Velocity)。

其次，您可以为您的表式持久性选择Azure's Table Storage或SQL Azure Database。你选择哪一个可能取决于你扩展的痛点在哪里。最简单的选择是使用SQL，但数据库大小有一定的限制，您将无法使用SQL Server周围的许多服务，如作业代理、依赖项(用于缓存回调)等。如果您遇到SQL Server无法扩展的问题，那么在云中运行不太可能有太大帮助，因为它仍然是一个RDBMS。如果你想要一个更具扩展性的解决方案，那么Azure Table Storage就是你的选择--但它是非关系型的，你需要修改你的架构，以适应它支持的更有限的事务范围--以及它的查询机制和REST-HTTP架构的延迟的固有限制。想想BASE，而不是ACID。

第三，您需要以不同的方式考虑文件存储。因为您的每个实例都在VM中运行，所以当VM关闭时，任何本地存储都会消失，因此为了长期持久化，您需要使用Azure Blob Storage并在设计应用程序时牢记这一点。

第四，您可以选择两种类型的角色- web角色，运行IIS (就调整IIS参数而言，您目前无法对其进行控制)和worker角色，它们更像是windows服务。而且你们的角色之间没有相互感知的机制--所以从web到worker的通信是通过队列或者表/blob存储来实现的。所以你也需要记住这一点。

总而言之，如果你想迁移到Azure，就需要做出很多设计决定--平台本身的性质限制了你可以使用的技术，因此你可以选择什么样的设计。如果你在设计时考虑到了Azure，那么你最终会得到一个更具可伸缩性的系统，但在此过程中需要做出某些决定--其中一些可能会破坏交易。

[编辑:我应该补充说，这个答案更多的是针对将整个应用程序迁移到Azure的考虑。当然，这并不是唯一的选择-您可能只想将某些组件迁移到云中，而将其余组件保留在本地，例如使用Azure .NET Service Bus之类的东西进行交互。]

Answer 2

我会说不是。

针对您当前的平台进行设计，并仅当您实际要使用Azure时才针对Azure进行修改。你很有可能不需要它，所以不要浪费你的时间。

无论如何，你的应用程序的良好设计应该会从底层架构中产生相当多的抽象，所以如果或当你切换平台时，默认情况下更改应该是本地化的。

Answer 3

我对Azure平台的当前产品了解不多，但我想说的是，总的来说，我会根据您现在的需求进行设计。猜测需求在未来可能如何变化是非常困难的，并且可能会影响整个项目的成功。