【问题标题】:Migrate Azure Web Site to Azure Cloud Service将 Azure 网站迁移到 Azure 云服务
【发布时间】:2015-06-23 06:48:05
【问题描述】:

我有一个项目,我计划将 Web 应用程序作为 Azure 网站启动,然后如果需要作为扩展策略将其迁移到 Azure 云服务(也称为托管服务)。

这个决定是因为我读到 Azure 网站开发起来更加简单和快速,几乎不需要 Azure 特定的配置或代码。因此,快速而简单地开始是项目的一个很好的起点。

但是,这对您来说是一个好的起点吗? 将 Azure 网站迁移到 Azure 云服务与将普通 ASP.NET 网站迁移到 Azure 云服务一样吗? 您会从一开始就使用 Azure 云服务吗?如果是,为什么?

感谢您的宝贵时间。

【问题讨论】:

  • 希望 Microsoft Azure 网站有一个漂亮的简单表格来解释这些差异。很多重叠。为什么不从 3 个月的网站费用开始?

标签: windows azure cloud cloud-hosting azure-web-app-service


【解决方案1】:

这两种部署模型都有好处,最终取决于您要实现的目标以及应用程序的最终成功。

我在下面概述了每种模型的优缺点,以确保您针对自己的应用目标做出正确的选择。

Windows Azure 网站

您已经正确地确定 Windows Azure 网站是应用程序的一个很好的起点,但是您也可以认为网站确实为许多解决方案提供了足够的可扩展性。

优点

  • 10 个免费网站预览期间 [Free for 12 months]
  • 轻松部署(使用 Git、TFS、Web 部署或 FTP)
  • Quick Scalability(您可以移动到自己的专用集群 [aka reserved 标准])
  • 简单开发(支持经典 ASP、ASP.NETNode.js、Python 和PHP
  • 持久化环境(大多数人都习惯了)

缺点

  • 自定义域不支持 SSL
  • 预览中(目前没有 SLA)

Windows Azure 云服务

云服务(以前称为托管服务)绝对是 Web 应用程序未来的愿景。它在构建时考虑了弹性,通过扩展以满足需求,并在流量变慢时回拨容量,从而使应用程序的成本保持在可承受的范围内。

优点

  • 加强对应用程序成本的控制(如果架构正确)
  • 灵活性(您可以完全控制环境)
    • SSL 支持
    • 语言不可知
    • Web 服务器不可知(尽管 IIS 默认可用)
  • 自动管理服务器

缺点

  • 应仔细考虑架构
  • 部署时间较慢(开发周期变慢)

便携性需要考虑的事项

以上项目可能已经为您提供了足够的计划应用程序的近期未来,并且您很可能希望在未来考虑云服务(从长远来看,它更适合许多应用程序场景)。

以下是有助于在网站之间移植到云服务的事项列表:

  1. 开始思考无状态

    Windows Azure 网站很好,因为它是一个持久环境,这意味着您可以将会话状态和资产等内容存储到磁盘。

    虽然这是一个很好的功能,但如果您的最终目标是云服务,那么最好开始规划无状态应用程序。以下是您可以做的一些事情来开始思考无状态:

    • 不要依赖会话状态
      • 如果您需要,请制定策略以使其可扩展(缓存服务、SQL 或存储)
    • 使用存储服务
      • 静态 HTML、css、javascript 和图像等资产最好放在 Storage 中
        • 避免在您的网站上增加额外的带宽(可能会保持更长时间的共享以降低成本)
        • 可以启用 CDN,为国际市场提供更好的体验
        • 将应用程序迁移到云服务时更容易更新 Web 资产
      • 存储用户内容
        • 如果您的应用程序已经存储到存储服务中,那么在将来迁移到云服务时,代码修改将减少。
  2. 轻松发现数据中的模式

    云服务的好处是它使您能够通过仅扩展需要扩展的内容来降低成本。开始识别规模单位的过程,即如何对数据库或存储中的表进行分区。

【讨论】:

【解决方案2】:

我阅读了所有帖子,所有帖子都非常有帮助。 除了所有帖子,我在 msdn 上找到了一条信息:Windows Azure Websites, Cloud Services, and VMs: When to use which?

使用 Windows Azure 网站,您可以:

  • 在 Windows Azure 上构建高度可扩展的网站。
  • 快速轻松地将站点部署到高度可扩展的云环境中,让您可以从小处着手并根据需要进行扩展。
  • 使用您选择的语言和开源应用程序,然后使用 FTP、Git 或 TFS 进行部署,并轻松集成 SQL 数据库、缓存、CDN 和存储等 Windows Azure 服务。

借助云服务,您可以:

  • 在 Windows Azure 上构建或扩展您的企业应用程序。
  • 使用丰富的 PaaS 环境创建高度可用、可扩展的应用程序和服务。支持高级多层场景、自动化部署和弹性扩展。为世界各地的客户提供出色的 SaaS 解决方案。

msdn 上也有总结选项:

以及比较msdn上的一些特性网站和云服务:

【讨论】:

    【解决方案3】:

    Azure 是拥有您的应用程序的好地方,但在开始迁移之前您需要了解一些注意事项。

    • Azure 网站和托管服务的部署非常简单。和 Visual Studio 你生成包并简单地上传它。然后你 有一个开发环境来检查它。如果你没问题,换 IPS。如果不适合您,请再次升级。

    • 您的实例有一些可能令人讨厌的属性。为了 例如,您无法确定自己的 IP。然后,如果您的应用程序有效 对于某些使用 IP 限制的提供商,您需要弄清楚 如何继续。

    • 更多注意事项。您的“服务器”可以随时重新映像。 如果您将某些内容存储在本地磁盘上,该文件可能随时消失。

    • 如果您至少有 2 个或更多实例 每个网站。也许您的应用程序还没有为此做好准备。第一步 将是managing the sessions with the appFabric。是真的 很简单,只需更改您的网络配置。小心因为这 会话状态与“旧状态”不完全一样。你不能存储 不可序列化的对象(应该很容易适应)或非常大的对象(超过 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 SitesCloud Services 的特定问题以及出于扩展原因从一个迁移到另一个的好处有关。
    • 关于Azure中的会话管理检查using table storage for session state management,我觉得也是一个很好的解决方案。
    • 表存储更便宜,内存缓存更快。
    【解决方案4】:

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

    Azure 网站不能成为 Azure 虚拟网络的一部分。要访问本地资源,必须配置 Azure 服务总线中继等机制。

    【讨论】:

      【解决方案5】:

      我们的网站在某些主机上运行在 PHP 上,并在某个时候决定将其移至 Azure(这是我们服务的主要部分)。我们从 Azure 网站开始,这从开发的角度来看非常棒(主要是与 git 集成)。但经过大约一周的测试(当我们决定实际移动生产网站时)我们发现目前

      1. 自定义域没有 SSL
      2. 自定义域仅适用于保留实例(无共享基础架构)
      3. SLA

      所以我们转移到了托管服务。我们的主要问题是缺乏简单部署的能力(需要构建包并上传网站的整个包),并找到解决方案是使用dropbox - 作为角色的启动任务,我们正在安装dropbox服务机器,它从保管箱中获取所有网站,而保管箱又具有SVN签出文件夹,因此站点更新变得非常容易。

      【讨论】:

      • 呜呜!看起来很危险,但如果可行 :) 我对这个解决方案印象深刻。
      猜你喜欢
      • 2015-12-04
      • 1970-01-01
      • 2019-07-30
      • 2012-12-22
      • 1970-01-01
      • 1970-01-01
      • 2014-06-16
      • 2018-07-18
      • 1970-01-01
      相关资源
      最近更新 更多