4

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

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

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

正如您从标签中看到的那样,我假设基于消息的架构可能是最通用的,但我也习惯于在这些东西上犯错。

欢迎所有关于一般架构和特定解决方案的建议和指示。

4

1 回答 1

5

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

如果您正在考虑将 Windows Azure 作为“云”部署选项,那么需要考虑的主要事项是:

网络应用:

  • 会话管理:您必须使用网络农场友好的方法(例如,不能使用内存服务器端会话状态)
  • 带宽使用:当您部署到云端时,本地延迟高于 100%,您还需要为来回发送的更多位支付更多费用。构建更节俭的应用程序有 $ 激励措施。
  • 身份验证机制:如果您想提供 SSO,您可能需要转向基于声明的方法(使用 WIF)。这在很大程度上是您可以隔离和更改的(例如 Windows 本地集成安全性、基于云的声明)
  • 使用所有标准提供者(例如个人资料、成员资格、跟踪等)。有所有的 Win Azure 实现,所以你可以改变它们。

数据:

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

管理:

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

更多详细信息可在此处获得。

我不知道您试图考虑消息队列的用途,但您也可以将其抽象化(例如,用于本地的 MSMQ,用于云的 Windows Azure 队列)。您将不得不适应一些语义差异,但这是可行的。

于 2010-06-16T03:30:08.487 回答