我可以构建一个Web应用程序,以便它可以部署到云或专用服务器/ VPS吗?怎么样?

CAD*_*oke 4 architecture cloud message-queue azure cqrs

是否存在足够多的架构,可以将其部署到云服务器或专用(或VPS)服务器,只需极少的更改?显然会有配置更改,但我宁愿让应用程序的其余部分保持一致,保留一个可维护的代码库.

该应用程序将是ASP.NET和/或ASP.MVC.我的开发环境是VS 2010.云可能是,也可能不是,Azure.专用或VPS将是Win Server 2008.可能.

它不是一个面向公众的网站.我想到的Web应用程序将是每个客户端的单独部署.有些客户端规模较小,有些客户希望应用程序在本地Intranet上运行而不是在Web上运行.其他客户可能更喜欢使用云方法来实现黑盒解决方案.应用程序可能会运行几个小时,也可能无限期运行,这取决于客户端和项目.除部署方案外,应用程序或多或少相同.

正如您从标签中看到的那样,我假设基于消息的架构可能是最通用的,但我也常常对这些东西有误.

所有建议和指示欢迎关于一般架构和具体解决方案.

Eug*_*ace 5

是的,这是可能的.Web应用程序istelf(MVC或Webforms)可能保持不变(配置更改).

如果您将Windows Azure视为"云"部署选项,那么要考虑的主要事项是:

网络应用:

  • 会话管理:您将不得不使用Web场友好的方法(例如,不能使用内存服务器端会话状态)
  • 带宽使用:当您部署到云时,延迟高于100%内部部署,您还需要为更多来回发送的比特支付更多费用.建立更节俭的应用程序是一种诱因.
  • 身份验证机制:如果您想提供SSO,您可能需要转向基于声明的方法(使用WIF).这主要是您可以隔离和更改的内容(例如,Windows内部集成安全性,基于云的声明)
  • 使用所有标准提供者(例如,个人资料,成员资格,跟踪等).有Win Azure实现,所以你可以改变它们.

数据:

  • 最简单的可移植性方法是使用SQL Azure,它是SQL Server的一个(大)子集.
  • 如果您使用其他存储系统(例如Windows Azure表等),那么您需要抽象应用程序中的所有数据访问(更难的工作)
  • 除了SQL Azure中没有的一些功能(如SQLCLR,SQL Broker),数据库大小也有限制(当前最大值= 50GB).因此,如果您的客户的数据库超出了这个数量,那么您需要对数据库进行分区(这会增加更多的复杂性,但它是可行的)

管理:

  • 如果您使用标准方法进行日志记录和跟踪(例如Systems.Diagnostics等),那么应用程序将基本保持不变.您的流程必须进行调整(以及您的脚本等)

这里有更多细节.

我不知道你在考虑消息队列是什么,但这也是你可以抽象的东西(例如MSMQ用于内部部署,Windows Azure Queue用于云).您将不得不适应一些语义差异,但它是可行的.