[翻译图书] Moving Applications to the Cloud on the Microsoft Windows Azure Platform - 2

第一章 介绍Windows Azure平台

Microsoft® Windows® Azure™ 技术平台提供了一个点播的, 基于云的计算方式, 这里的云指的是存在于一个或多个数据中心里互相连接着的计算机资源. 当前, Windows Azure平台在美国, 欧洲, 也亚洲都有数据中心. 研发人员可以使用云来部署和运行应用程序以及存储数据. On-premises的应用程序也可以使用基于云的资源. 比如说, 存在于On-premises的一台服务器上的一个应用程序, 一个运行在桌面电脑上的胖客户端, 或者是运行在移动设备上的客户端, 他们都可以访问在云中存储的数据.

 

Windows Azure平台通过虚拟化抽象了硬件资源. 每个部署在Windows Azure中的应用程序都运行在一台或多台虚拟机上. 这些被部署了的应用程序表现的就像它们各自存在于专门的实体计算机上一样, 但他们可能却与存在于同台物理机里的其他众多虚拟机共享着诸如硬盘空间, 网络IO, CPU内核等资源. 物理硬件上面的抽象层的一个关键好处是可移植性和可扩展性. 将服务虚拟化可以允许他在任何数目的物理实体机中间移动. 通过结合虚拟技术, 商品硬件, 多租户, 和聚合需求, 微软达成了规模经济. 这些生成了更高的数据中心的利用率, 即硬件的按金分配, 接下来就是为你省钱了.

 

虚拟化还允许你既有垂直的可扩展性, 也有水平的可扩展性. 垂直可扩展性意味着, 随着需求的增长, 你可以增加每个虚拟机的资源的数量, 比如说CPU内核或内存. 水平的可扩展性意味着你可以添加更多的已有服务的虚拟机的拷贝. 所有的这些实例都是在网络层次做了负载均衡的, 所以到来的请求会在这些虚拟机之间进行分配.

在本文写作之际, Windows Azure平台包括三个主要的组件:

Windows Azure

Windows Azure plat-form AppFabric

SQL Azure

 

Windows Azure提供了如下的能力:

基于Windows的应用程序计算环境

结构化, 非结构化数据存储, 还有异步的信息传递

Windows Azure platform AppFabric 提供了两项服务:

Service Bus, 帮助你连接在on-premises 或公有云中的服务, 忽略网络拓扑逻辑的细节.

访问控制服务, 使用security token为基于Representational State Transfer (REST)的web service管理认证和授权.

SQL Azure本质上就是云中的SQL Server.

平台还包括各种管理服务, 能允许你控制所有的这些资源, 基于web的用户界面也可以, 编程方法来控制也可以的. 在多数情况下, 可以用REST-based 的API来定义你的服务如何工作. 多数的可以通过web portal完成的管理任务也可以通过API完成. 最后, 微软提供了完整的一套工具和SDK, 能够允许你在本地的模拟环境下开发, 测试你的应用程序. 这个本地的测试环境叫做"development fabric". 多数的工具都被集成到了Visual Studio中. 另外, 还有第三方的管理工具可以使用.

                                        

The Windows Azure Platform

----------------------------------------

在Windows Azure中, 整个计算环境会可靠地处理请求和存储数据. 一个内部的子系统, 叫做"Windows  Azure  Fabric  Controller  (FC)"的, 管理所有的计算和存储资源, 部署新的服务, 监管所部署的服务的健康状态. 当一个服务挂掉的时候, FC会创建必要的资源, 重新部署这个服务. 另一个Windows Azure平台的组件就是SQL Azure. SQL Azure是一个云中的关系数据库. 本质上说, SQL Azure是一个微软SQL的一个巨大的子集. 尽管SQL Azure是Windows Azure存储服务的一个补充, 实际上他们是不同的.

 

在本书还在写作的过程中, Windows Azure platform App Fabric提供了两个服务: Service Bus和Access Control Services.

Service Bus允许你连接到应用程序和服务, 不管这些服务在哪里.  比如说, 你能够连接在企业防火墙之内的on-premises的application到运行在云中的service. 它实现了普通的消息和沟通模式, 比如event, one-way message, publish, subscribe, remote procedure call (RPC)风格的信息交换, 还有为streamed data服务的tunnel.

Access Control服务允许你为基于REST的服务管理identity. 他实现了一个token-issuing service, 这服务也提供了token转换的能力. Windows Azure platform AppFabric在这份指导中并没有讨论. 更多信息, 可以参考本章后面的reference. 记住, Windows Azure platform AppFabric 和Windows Azure Fabric Controller是不同的.

 

除了这些组件, Windows Azure平台还提供了对service的诊断服务, 比如对应用程序健康状况的监控.

在Windows Azure中所有的存储和管理子系统都使用基于REST的接口. 他们不依赖任何的.NET Framework或Windows操作系统. 任何能发行HTTP或HTTPS请求的技术都可以访问Windows Azure的

设备. 典型地, 在Windows Azure中运行的应用程序会有多个实例. 这些事例的每一个都运行在有Windows Azure创建和管理的Windows Virtual Machine中. 目前, 你不能像使用Virtual PC或Virtual Server一样的方式来访问这些虚拟机. Windows Azure替你控制了.

要开始了解Windows Azure platform, 请访问http://www.windowsazure.com.

 

Windows Azure Compute

-------------------------------------------

在Windows Azure中运行的应用程序被称为"hosted service". 典型地, 一个hosted service包含不同的计算资源, 他们一起处理信息, 和彼此通信并和外部世界交互. Windows Azure里的Hosted service是有角色的, 目前有两种角色可用: Worker Role和Web Role.

 

Work role是通用的代码宿主. 它们频繁地被用于处理长久运行的任务, 还有非交互的任务. 但实际上, 你可以让它寄存任何种类的工作. Work Role已经通用到甚至可以寄存整个应用程序平台, 比如Microsoft IIS服务, 或者Apache Tomcat. Windows Azure初始化和长时间运行work role, 就像运行Windows Service 一样.

 

默认地, 你可以认为web role是拥有IIS的特殊的worker role. 所以, 他们能够寄存web applications和web services. 图标1描述了Web Role 和Worker role.





 

典型地, 一个Web Role实例接受到访端口80或443的http或https请求. 这些公开端口被叫做"public endpoints". 所有的public endpoint都是在网络层面自动被负载均衡的. Work role和web role二者都既可以向外发出TCP连接, 也可以为进来的连接打开endpoints.  除了负载均衡的public endpoint之外, 实例间还可以打开内部的endpoints. 这些internal endpoints既不是负载均衡的, 对Internet也不可见. 作为替代, internal endpoints能够被用来进行实例间和角色(role)间的同步通讯.

 

同时运行着web role和worker role的虚拟机实例还运行着一个Windows Azure agent(代理人). 这个"代理人"暴露了一个API允许该实例跟 Windows Azure FC互动. 比如说, 一个实例可以使用"代理人"来遍历该虚拟机实例所有公共的和内部的endpoints, 而这些endpoints可能是该虚拟机正在使用的, 或是用来发现运行时配置的.

 

部署的应用程序的web role可以通过ASP.NET, Windows Communication Foundation (WCF), 或任何能与IIS协同工作的技术来实现. 比如说, 你可以弄一个寄存在Windows Azure中的PHP应用程序, 因为IIS通过Fast CGI支持这它. Fast CGI是一个规定了如何与web server中的应用程序的接口的协议. 大多数的web role应用程序都是针对"请求-响应"模式的负载而优化过的, 这里请求与响应之间的时间间隔在理想情况下是非常短的.

 

对Web Role的一项关键的衡量指标就是"session management", 即会话管理. 在标准的ASP.NET应用程序中, 是由某些方法存储会话状态(session state)的. 比如说, 在线商店会保存一个购物车. 与web服务器场相似, 在每台服务器实例的内存中存储会话状态(session state)对于基于web role的站点来说是个让人挠头的问题. 因为不能保证用户每次发出请求后都会被重定向到相同的web role实例上. 取而代之的是, 你会在web role实例之外的地方去维护会话状态(session state)的信息, 比如说Windows Azure Storage, 或是SQL Azure, 或是你发回给客户端的cookie, 或是在隐藏的表单元素中.

在Windows Azure中最常见的应用程序模式是让web role接受到来的请求, 然后用Windows Azure的queue来传递这些请求给worker role去处理. Worker Role定期地去queue里读取信息, 来查看是否有工作要做. 如果有的话, 它就开始执行任务. 典型地, Web Role会从persistent storage中接受完成了的工作, 比如说一个blob, 或是一个table. Figure 2 展示了这个典型的设计模式.

 





 

这是种简单并且常见的Web role与worker role之间的互动方式, 但是也还有许多其他可能的互动方式的. 比如说, 你可以使用WCF来连接Web role和worker role.

在Web 和worker role上运行的"代理人"的另一项功能是通过FC来维护系统的心脏跳动. FC会监视VM们和物理机们的健康状况.如果应用程序由于在代码中出现了错误而变得没有响应, 或者实例底层的硬件出现了当掉的情况, FC会采取任何恰当的措施来进行恢复.  如果应用程序崩溃了, FC可能会简单地重启失败的实例. 在物理层硬件错误这种极端情况下, FC会尝试迁移受影响的实例到数据中心的另一台物理机上. 任何时候FC都会尝试保持尽可能多的你指定了的众多实例的运行.目前还没有自动衡量(auto-scaling )能力. 你要对Windows Azure中的计算资源的实例的数量负责, 要么通过Web Portal对数量进行控制, 要么就通过management API来进行控制.