Azure 提供了用于运行应用程序的不一样执行模型。每种模型提供一组不一样服务,而你选择哪一种模型彻底取决于你要作什么。本文介绍三种模型,描述它们的技术并提供相关用例。前端
开发人员、IT 操做人员和其余人可使用 Azure 虚拟机在云中建立和使用虚拟机。提供所谓的 Infrastructure as a Service (IaaS),这是一项可普遍使用的技术。图 1 显示其基本组件。web
图 1:Azure 虚拟机可提供"基础结构即服务"技术。数据库
如图所示,可使用 Azure 管理门户或基于 REST 的 Azure 服务管理 API 建立虚拟机。能够从包括 Internet Explorer、Mozilla 和 Chrome 在内的任何经常使用浏览器访问管理门户。对于 REST API,Microsoft 为 Windows、Linux 和 Macintosh 系统提供了客户端脚本工具。其余软件也可随意使用此接口。编程
不管你如何访问此平台,建立新 VM 都须要为 VM 的映像选择一个虚拟硬盘 (VHD)。这些 VHD 将存储在 Azure blob 中。windows
有两种选项可供您开始操做浏览器
库中以及 VMDepot 上的 VHD 包含全新的 Microsoft 和 Linux 操做系统映像,以及包含安装在其上的 Microsoft 和其余第三方产品的映像。选项一直都在增加。示例包含如下产品的各个版本和配置:服务器
除了 VHD 之外,你还要指定你的新 VM 的大小。Azure 库 中列出了每一个大小的完整统计信息。网络
最后,选择你的新 VM 应在其中运行的 Azure 数据中心(不管是在美国、欧洲仍是亚洲)。app
一旦 VM 开始运行,你将根据其运行按小时付费,并在删除该 VM 时中止付费。你支付的数额不取决于你的 VM 的使用率,它仅取决于时钟时间。闲置了一小时的 VM 与负载很重的 VM 的费用相同。框架
每一个运行的 VM 都有一个关联的 OS disk,该磁盘保存在 Blob 中。当你使用库 VHD 建立 VM 时,该 VHD 将会复制到你的 VM 的 OS 磁盘中。您对于运行的 VM 的操做系统所作的任何更改都存储在这里。例如,若是你安装可修改 Windows 注册表的应用程序,该更改将存储在你的 VM 的 OS 磁盘中。在你下次从该 OS 磁盘建立 VM 时,VM 将继续在你离开它时的相同状态下运行。对于存储在库中的 VHD,Microsoft 将在须要时应用更新,例如操做系统修补程序。可是,对于你本身的 OS 磁盘中的 VHD,你要对应用这些更新负责(尽管 Windows 更新在默认状况下处于打开状态)。
还能够修改运行的 VM,而后使用 sysprep 工具进行捕获。Sysprep 可删除特定内容(例如计算机名称),所以 VHD 映像可用于建立带有相同常规配置的其余 VM。这些映像与你上载的映像一块儿存储在管理门户中,所以它们能够用做其余 VM 的起点。
虚拟机还监视托管您建立的每台 VM 的硬件。若是运行 VM 的物理服务器发生故障,则平台会注意到此状况并在另外一台计算机上启动相同的 VM。假设你有合适的许可,你能够从你的 OS 磁盘中复制已更改的 VHD,而后在其余任何位置(例如你本身的本地数据中心或其余云提供程序中)运行它。
除了其 OS 磁盘之外,你的 VM 还有一个或多个数据磁盘。尽管其中每一个磁盘看起来都像是你的 VM 的已装载磁盘驱动器,但实际上每一个磁盘的内容都存储在 Blob 中。对数据磁盘所作的每次写入都将永久存储在基础 blob 中。与全部 Blob 同样,Azure 同时在单个数据中心内和多个数据中心上复制它们以防止出现故障。
可使用管理门户、PowerShell 以及其余脚本工具,或者直接经过 REST API 来管理运行的 VM。(事实上,你经过管理门户执行的任何操做均可以经过此 API 以编程方式完成。)Microsoft 合做伙伴(如 RightScale 和 ScaleXtreme)也提供依赖 REST API 的管理服务。
能够普遍使用 Azure 虚拟机。Microsoft 面向的主要方案包括:
虽然这些不是惟一的可能状况,但它们确实为你如何使用 Azure 虚拟机提供了很好的示例。
当你使用 Azure 虚拟机建立新 VM 时,能够选择独立运行它,或使它成为一块儿在 cloud service中运行的一组 VM 的一部分。(尽管名称相似,但请不要和表示 Azure PaaS 技术名称的"云服务"混淆;这是两个不一样的概念)。每一个独立 VM 都有它本身的公用 IP 地址,而同一云服务中的全部 VM 均可经过一个公用 IP 地址进行访问。图 2 显示了这种状况。
图 2:每一个独立 VM 都有它本身的公用 IP 地址,而在云服务中分红一组的 VM 可经过一个公用 IP 地址来公开。
例如,若是你已建立一个虚拟机来建立并测试一个简单的应用程序,则你可能会使用独立 VM。可是,若是你要建立一个多层应用程序,其中包含一个 Web 前端、一个数据库或许还有一个中间层,则你极可能如图 2 所示的那样将多个 VM 链接到一个云服务。
将 VM 在云服务中分组还使您可使用其余选项。Azure 为同一云服务中的 VM 提供负载平衡,使用户请求分散在 VM 上。以这种方式链接的 VM 还能够经过 Azure 数据中心内的本地网络直接相互通讯。
同一个云服务中的 VM 还能够分组为一个或多个 availability sets。要理解为什么这很重要,可考虑一个运行多个前端 VM 的 Web 应用程序。若是全部这些 VM 都部署在同一台物理计算机上甚至在计算机的同一机架中,单个硬件故障就可能致使它们全都不可访问。可是,若是这些 VM 分组为一个可用性集,Azure 就会跨数据中心部署它们,所以任何一个单点故障都不会波及到其余 VM。
若要更好地理解 Azure 虚拟机的工做原理,有必要给出几个较为具体的场景。例如,假设你要建立一个在 Azure 上运行的可靠且可缩放的 Web 应用程序。一种方法是在一个或多个 Azure VM 中运行该应用程序的逻辑,而后使用 SQL Server 进行数据管理。图 3 显示了这种状况。
图 3:在 Azure 虚拟机中运行的应用程序可使用 SQL Server 进行存储。
在此示例中,两种 VM 都是从库中的标准 VHD 建立的。该应用程序的逻辑在 Windows Server 2008 R2 上运行,所以开发人员今后 VHD 建立三个 VM,而后在每一个 VM 上安装其应用程序。因为全部这些 VM 都在同一云服务中,所以他能够配置硬件负载平衡来分散请求。开发人员还从库中包含 SQL Server 2012 的 VHD 建立两个 VM。在这两个 VM 运行后,他在每一个实例中配置 SQL Server,以使用具备自动故障转移功能的数据库镜像。这不是必需的,由于应用程序能够只使用单个 SQL Server 实例,可是采用此方法能够提升可靠性。
假设某个组织想建立一个 SharePoint 服务器场,但并不但愿在本身的数据中心中运行该服务器场。缘由多是本地数据中心缺少资源,或者建立该场的业务部门不但愿与其内部 IT 组打交道。在此类状况下,在 Azure 虚拟机上运行 SharePoint 颇有意义。图 4 显示了这种状况。
图 4:Azure 虚拟机容许在云中运行 SharePoint 场。
SharePoint 场有几个组件,每一个组件在从不一样 VHD 建立的 Azure VM 中运行。须要如下项目:
尽管图中未显示,但此 SharePoint 场可能使用 Azure 虚拟网络链接到本地网络。这使 VM 以及它们所包含的应用程序对于使用该网络的人们而言像是位于本地。
如这些示例所示,你可使用 Azure 虚拟机在云中建立和运行新的应用程序,或以其余方式运行现有应用程序。不管你选择哪一个选项,该技术的目标都是相同的:为公有云计算提供一个通用基础。
人们经过多种不一样方式使用 Web 技术。公司可能须要迁移或设置可处理每周数以百万次的单击的现有网站,该网站部署在全球若干数据中心中。一个网站设计机构能够与一组开发人员合做构建一个可应对数以千计用户的自定义 Web 应用程序。公司开发人员可能须要设置应用程序,以便针对来自其公司 Active Directory 的经身份验证的用户在云中跟踪费用报表。IT 顾问可使用经常使用的开放源应用程序为小型企业设置内容管理系统。 可使用 Azure 虚拟机完成全部这些操做。可是建立和管理原始 VM 须要一些技巧和花一点功夫。若是你须要实现一个网站或 Web 应用程序,这里有一个更容易(也更便宜)的解决方案,这种方法一般称为"平台即服务"(PaaS)。如图 5 所示,Azure 可为此提供网站。
图 5:Azure 网站支持经过各类技术构建的静态网站、经常使用 Web 应用程序和自定义 Web 应用程序。
Azure 网站在 Azure 云服务的基础上构建,用于建立为运行 Web 应用程序而优化的"平台即服务"解决方案。如图所示,网站将在一组可能包含由多个用户建立的多个网站的单个虚拟机,以及属于单个用户的标准 VM 上运行。VM 是经过 Azure 网站管理的资源池的一部分,所以容许得到高可靠性和容错能力。 入门都很轻松。借助 Azure 网站,用户能够从一系列应用程序、框架和模板中进行选择并在几秒内建立一个网站。而后,他们可使用最喜欢的开发工具(WebMatrix、Visual Studio、任何其余编辑器)和源控件选项来设置持续集成,并做为一个团队进行开发。依赖于 MySQL 数据库的应用程序可使用 ClearDB(Microsoft 合做伙伴)为 Azure 提供的 MySQL 服务。 开发人员可使用网站建立可伸缩的大型 Web 应用程序。该技术支持使用 ASP.NET、PHP、Node.js 和 Python 建立应用程序。例如,应用程序可使用易贴的会话,而现有 Web 应用程序能够不作任何更改移动到此云平台。在网站上构建的应用程序可随意使用 Azure 的其余方面,例如 Service Bus、SQL 数据库 和 Blob 存储。你还能够在不一样 VM 中运行一个应用程序的多个副本,而网站会自动在各 VM 中对请求进行负载平衡。由于新网站实例是在已存在的 VM 中建立的,所以能够很是快速地启动新的应用程序实例;这明显快于等待建立新的 VM。 如 图 5 所示,你能够经过多种方式将代码和其余 Web 内容发布到网站中。您可使用 FTP、FTPS 或 Microsoft 的 WebDeploy 技术。网站还支持从源控件系统发布代码,例如 Git、GitHub、CodePlex、BitBucket、Dropbox、Mercurial、Team Foundation Server 和基于云的 Team Foundation Service。
Azure 虚拟机提供 IaaS,而 Azure 网站提供 Web 宿主。第三个计算选项"云服务"提供 Platform as a Service (PaaS)。这种技术旨在支持可扩展、可靠且运做便宜的应用程序。它还可使开发人员没必要担忧管理他们所使用的平台,而将全副精力用在本身的应用程序上。图 6 解释了此概念。
图 6:Azure 云服务提供"平台即服务"功能。
和其余 Azure 计算选项同样,云服务也依赖于 VM。该技术提供了两个略有不一样的 VM 选项: web roles实例运行包含 IIS 的 Windows Server 变体,而 worker roles实例运行不含 IIS 的同一 Windows Server 变体。云服务应用程序依赖于这两个选项的某种组合。
例如,一个简单的应用程序可能只使用一个 Web 角色,而一个稍复杂的应用程序可能使用一个 Web 角色来处理来自用户的传入请求,而后将那些请求建立的工做传递给辅助角色进行处理。(此通讯可能使用 Service Bus 或 Azure 队列。)
如图所示,一个应用程序中的全部 VM 都在同一云服务中运行,如以前对 Azure 虚拟机所述的那样。所以,用户经过单个公用 IP 地址访问应用程序,而请求会自动在应用程序的 VM 上实现负载平衡。与使用 Azure 虚拟机建立的云服务同样,该平台将采用一种可以避免单点硬件故障的方式在云服务应用程序中部署 VM。
即便应用程序在虚拟机中运行,理解云服务提供的是 PaaS 而非 IaaS 也很重要。如下办法有助于理解这一点:使用 IaaS(如 Azure 虚拟机),首先要建立和配置你的应用程序将运行的环境,而后将应用程序部署到此环境中。你要负责该环境的大部分管理工做,如在每一个 VM 中部署操做系统的新修补版本。相反,在 PaaS 中,这样的环境彷佛早已存在。您只需部署您的应用程序。已为你处理它所运行的平台的管理工做,包括部署操做系统的新版本。
使用云服务,你无需建立虚拟机。相反,你提供一个配置文件,告知 Azure 每一个 VM 须要多少个角色实例(如三个 Web 角色实例和两个辅助角色实例),平台将为你建立它们。虽然你仍然要选择这些 VM 应该是什么大小(选项与 Azure VM 的相同),可是你无需亲自显式建立它们。若是你的应用程序须要处理更大的负载,则能够要求增长 VM,Azure 将建立这些实例。若是负载下降,则能够关闭这些实例并中止为它们付费。
一般经过两个步骤就能使云服务应用程序可供用户使用。首先,开发人员将应用程序上载到该平台的暂存区域。当开发人员准备好使应用程序上线后,他会使用 Azure 管理门户请求将其投入生产。暂存与生产之间的这种切换无需停机就可完成,这使运行的应用程序可在不打扰其用户的状况下升级到新版本。
云服务还提供监视功能。和 Azure 虚拟机同样,它将检测到发生故障的物理服务器,并在新的计算机上从新启动原先在该服务器上运行的 VM。云服务不只检测硬件故障,还检测发生故障的 VM 和应用程序。与虚拟机不一样,它在每一个 Web 角色和辅助角色中都存在有代理,所以它可以在发生故障时启动新的 VM 和应用程序实例。
云服务的 PaaS 特性还具备其余含义。其中一个最重要的含义是,应编写基于此技术构建的应用程序以在任何 Web 角色或辅助角色实例出现故障时正确运行。要实现这一目标,云服务应用程序不该该在它本身的 VM 的文件系统中维持状态。与使用 Azure 虚拟机建立的 VM 不一样,对云服务 VM 所作的写入不是持久的;这与虚拟机数据磁盘彻底不一样。相反,云服务应用程序应将全部状态明确写入 SQL 数据库、blob、表或其余某种外部存储中。以这种方式构建应用程序会使它们更易于扩展、抵抗故障的能力更强,这是云服务的两个重要目标。
全部三个 Azure 执行模型都能在云中构建可扩展且可靠的应用程序。既然在本质上是相似的,你应该使用哪一种模型呢?答案取决于你想要作什么。
虚拟机提供最通用的解决方案。若是你须要可能的最大控制权,或者须要泛型 VM 以用于开发和测试等目的,这是最好的选择。虚拟机也是在云中运行现成本地应用程序的最佳选择,如上述的 SharePoint 示例所示。同时,由于你使用这一技术建立的 VM 看起来正像是你的本地 VM,因此这也多是灾难恢复的最佳选择。固然,能力越强责任也就越大,IaaS 会要求你承担一些管理工做。
当你要建立一个简单的网站时,网站即是合适的选择。当你想要基于现有应用程序(如 Joomla、WordPress 或 Drupal)建立网站时更是如此。若是建立一个管理任务很少的 Web 应用程序(甚至可扩展性很强的 Web 应用程序),或将现有 IIS Web 应用程序移到公有云中,网站模型也是一个不错的选择。它还提供快速部署功能。你的应用程序的一个新实例几乎能够当即开始运行,而经过虚拟机或云服务部署新的 VM 可能须要几分钟。
云服务是 Azure 提供的初始执行模型,它是一个显式 PaaS 方法。虽然 PaaS 与 Web 宿主之间的界限并不分明,但云服务在一些重要方面与网站不一样,其中包括:
由于云服务是 PaaS,因此它还提供了一些超越 Azure 虚拟机的优点。它会为你完成更多管理任务(如部署操做系统更新),所以你的操做成本极可能低于使用 Azure 虚拟机的 IaaS 方法的成本。
全部这三种 Azure 执行模型都各有优缺点。作出最佳选择须要了解这些内容,明白你要完成的任务,而后从中选出最合适的模型。
有时,单凭一种执行模型可能还不够。在这样的状况下,组合使用模型较为合适。例如,假设你要构建一个应用程序,既想利用云服务 Web 角色的管理优点,又须要使用标准 SQL Server 提升兼容性或性能。在此状况下,最佳选择是组合使用执行模型,如 图 7 所示。
图 7:单个应用程序可使用多个执行模型。
如图所示,云服务 VM 在不一样于虚拟机 VM 的单独云服务中运行。尽管如此,两者仍可高效通讯,因此经过此方法构建一个应用有时是最佳选择。
因为云平台须要支持多种不一样方案,因此 Azure 提供了不一样的执行模型。想要高效使用此平台的任何用户(若是你已阅读至此,可能也包括你)都须要了解每种执行模型。