将Azure网站迁移到Azure云服务

13

我有一个项目,计划使用Azure Web Site作为Web应用程序的起点,如果需要扩展策略,则将其迁移到Azure Cloud Service(也称为Hosted Service)。

这是因为我读到Azure Web Sites更简单、快速地开发,几乎不需要进行Azure特定的配置或编码。因此,快速和简单的起点对于项目来说是个好开始。

但是,这对你来说是一个好的起点吗?将Azure Web Site迁移到Azure Cloud Service是否与将普通的ASP.NET网站迁移到Azure Cloud Service相同?您会从一开始就使用Azure Cloud Service吗?如果是,为什么?

谢谢您花费宝贵的时间。


1
希望微软Azure网站有一个漂亮简单的表格来解释它们之间的区别。有很多重叠的地方。为什么不从3个免费月的网站开始呢? - paparazzo
5个回答

34

这两种部署模式都有其优势,最终取决于你想实现什么,以及你的应用程序是否成功。

以下我概述了每种模型的优缺点,以确保您为应用程序的目标做出正确的选择。

Windows Azure Web Sites

您已经正确地确定Windows Azure Web Sites是一个很好的应用程序起点,但您还可以考虑Web Sites是否为许多解决方案提供足够的可扩展性。

优点

  • 预览期间提供10个免费网站[免费12个月]
  • 易于部署(使用Git、TFS、Web Deploy或FTP)
  • 快速扩展性(您可以移动到自己的专用集群[也称为保留标准])
  • 简单开发(支持经典ASP、ASP.NETNode.js、Python和PHP
  • 持久环境(大多数人都习惯了这种方式)

缺点

  • 自定义域名不支持SSL
  • 处于预览阶段(目前没有SLA)

Windows Azure Cloud Services

云服务(以前称为托管服务)绝对是Web应用程序未来的愿景。它专注于构建弹性,以保持应用程序的可负担性,通过根据需求进行扩展,并在流量减缓时降低容量。

优点

  • 更好地控制应用程序成本(如果架构正确)
  • 灵活性(您对环境拥有完全控制权)
    • SSL支持
    • 语言无关
    • Web服务器无关(尽管默认情况下提供IIS)
  • 自动管理服务器

缺点

  • 需要仔细考虑架构
  • 部署时间较长(减慢开发周期)

可移植性的考虑事项

以上内容可能已经足够让您规划应用程序的即时未来,您很有可能会在将来考虑云服务(从长远来看,它更适合许多应用场景)。

以下是一些有助于 Web 站点向云服务迁移的事项:

  1. 开始思考无状态应用

    Windows Azure Web Sites 是一个持久环境,这意味着您可以将诸如会话状态和资产存储到磁盘中。

    虽然这是一个很好的功能,但是如果您的最终目标是要进入云服务,则最好开始计划面向无状态应用。以下是一些开始思考无状态的方法:

    • 不要依赖 Session State
      • 如果需要,制定一个策略使其可扩展(缓存服务、SQL 或存储)
    • 使用存储服务
      • 将静态 HTML、CSS、JavaScript 和图像等资产放置在存储中更好
      • 可避免 Web 站点上的额外带宽(潜在地更长时间共享以降低成本)
      • 可以启用 CDN,在国际市场提供更好的体验
      • 在应用程序迁移到云服务时更容易更新 Web 资产
    • 存储用户内容
      • 如果您的应用程序已经存储到存储服务,则移动到云服务时未来只需要进行一次代码修改。
  2. 使数据模式易于发现

    云服务的好处在于它使您能够通过仅缩放所需的部分来降低成本。开始识别您的规模单元的过程,即如何将数据库或存储中的表进行分区。


这正是我真正寻求的答案。感谢您指出每种方法的优缺点以及在从一种方法转换到另一种方法时需要考虑的因素,这正是我所问的。谢谢! - kzfabi
我发布了一篇新的博客文章,描述了如何识别您的应用程序是在Web Sites还是Cloud Services中运行 - cory-fowler

3
我阅读了所有的帖子,它们都非常有用。除了这些帖子,我在msdn上发现了一个信息:Windows Azure Websites, Cloud Services, and VMs: When to use which? 使用Windows Azure Websites,您可以: - 在Windows Azure上建立高度可扩展的网站。 - 快速轻松地将站点部署到高度可扩展的云环境中,使您可以小规模启动并根据需要进行扩展。 - 使用您选择的语言和开源应用程序,然后通过FTP、Git或TFS进行部署,并轻松集成Windows Azure服务,如SQL数据库、缓存、CDN和存储。
使用Cloud Services,您可以: - 在Windows Azure上构建或扩展企业应用程序。 - 使用丰富的PaaS环境创建高可用性、可扩展的应用程序和服务。支持高级多层次场景、自动化部署和弹性扩展。向世界各地的客户提供出色的SaaS解决方案。
此外,msdn还总结了Web Sites、Cloud Services和Virtual Machines的选项: Summarizes the options about Web Sites,Cloud Services  and Virtual Machines 比较一些在msdn上的Web Sites和Cloud Services特性: Comparing features of Web Sites and Cloud Services

2
Azure是一个很好的应用程序托管平台,但在开始迁移之前,有一些需要注意的事项。
Azure网站和托管服务非常容易部署。使用Visual Studio生成包并上传即可。然后你有一个开发环境来检查它。如果没问题,交换IP地址。如果不行,再次升级。
你的实例具有某些可能会让人感到烦恼的属性。例如,你无法确定自己的IP地址。那么如果你的应用程序使用IP限制的某个提供程序,则需要想出如何操作。
还有更多需要考虑的因素。你的“服务器”可以随时重置。如果你将某些内容存储在本地磁盘上,那个文件随时都可能消失。
如果每个网站至少有2个实例或更多,则Azure效果非常好。也许你的应用程序还没有为此做好准备。第一步将是使用appFabric管理会话。这很容易,在你的web config中只需进行一些更改。要小心,因为此会话状态与“旧会话状态”不完全相同。你不能存储非序列化对象(应该很容易适应),或者大型对象(超过8MB)。
如果你要从零开始开发,我建议你从Azure开始。原因很简单:启动成本非常低,直到应用程序有很多访问量之前,你都不需要支付很多钱。设置SQLAzure和存储帐户也非常便宜。一旦你准备好了所有内容,添加更多实例或升级很容易。
例如:假设你有一个想法,想向一些可能的投资者展示。
首先设置一个小型SQLAzure数据库(1GB),每月9.99美元。
然后构建一个网站并放置2个额外的小实例,每月18.72美元。
假设你需要100 GB的空间(图片、备份等),每月12.50美元。
这时,你已经准备好开始创业,每月不到50美元的费用。
如果你的网站受欢迎,访问量开始增加,你可以将实例更换为小型实例(使用额外的小型实例作为生产环境真的很危险,因为没有CPU保留)。然后将额外的小型成本(18.71美元)提高到57.60美元。也许你需要更多的SQL Azure空间?等等...
价格从这里计算:http://www.windowsazure.com/en-us/pricing/calculator/?scenario=web
这里有几个小建议,当然还有更多。我的建议是开通一个试用账户并进行尝试。
最后的建议是:不要仅仅通过购买更多资源来解决问题,有时需要重构和优化代码。如果每次遇到问题都只是增加资源,你可能会面临巨额费用和混乱的代码。
希望对你有所帮助!

嗨@Jordi,你说的都是正确的,但不是我问的问题。我已经了解了Azure的基础知识。我问的是与[Azure Web Sites](http://www.windowsazure.com/en-us/home/scenarios/web-sites/)和[Cloud Services](http://www.windowsazure.com/en-us/home/scenarios/cloud-services/)相关的特定问题以及从一个迁移到另一个以实现扩展的好处。 - kzfabi
关于Azure中的会话管理,请查看使用表存储进行会话状态管理,我认为这也是一个非常好的解决方案。 - kzfabi
3
表格存储更便宜,内存缓存更快。 - Jordi

1

Windows Azure云服务相对于Web站点的另一个优势是,云服务可以添加到Azure虚拟网络中。这可以使其访问本地资源,如数据库。因此,如果您的要求需要Azure提供的可扩展性,但由于安全限制需要将数据保留在本地,则云服务是更好的选择。

Azure Web站点无法成为Azure虚拟网络的一部分。要访问本地资源,必须配置诸如Azure Service Bus Relay之类的机制。


0
我们的网站一直在某些托管上运行PHP,后来决定将其迁移到Azure(我们的主要服务所在地)。我们从Azure Web Sites开始,从开发角度来看非常好(主要是与git的集成)。但是在测试了大约一周后(当我们决定实际迁移生产网站时),我们发现目前存在以下问题:
  1. 自定义域名没有SSL
  2. 自定义域名仅适用于保留实例(没有共享基础架构)
  3. SLA
因此,我们转向托管服务。对我们来说,主要问题是缺乏简单部署的能力(需要构建网站的整个包并上传),而找到的解决方案是使用Dropbox-作为角色的启动任务,我们正在安装机器上的Dropbox服务,它会从Dropbox获取所有网站,而Dropbox则有SVN检出文件夹,因此网站更新变得非常容易。

哇!看起来很危险,但如果可行 :) 我真的对那个解决方案印象深刻。 - Jordi

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接