Azure云计算之Windows Azure

      Windows Azure是一个集应用程序开发，服务托管，服务管理为一体的云计算操作系统。它为开发人员提供了构建在微软数据中心之上的随需应变的计算和存储平台来托管可升级，高可靠性的web应用。它使开发人员可以使用极少的on-premises 资源来开发大规模，分布式的应用程序并快速部署使用而不用关心IT基础架构。
       Windows Azure顾名思义就是云端的Windows，传统的Windows操作系统平台给我提供了计算和存储服务，同样Windows Azure也为我们的云程序提供了计算存储的平台。

这是Windows Azure的组件图。从图中我们可以看出Windows Azure构建在位于微软数据中心的大量服务器集群上。Windows Azure Fabric将这大量的计算存储能力编织成一个整体，在Fabric之上提供计算和存储两大服务。

      计算服务允许开发人员使用.net，非托管语言，java，php等多种语言来开发应用程序。在Windows Azure中，一个应用程序通常有多个实例。每个实例都跑在一个独立的虚拟机上。这些虚拟机由平台的Hypervisor统一管理，开发人员不能够显式地控制这些虚拟机的开关，也不能上传自己的虚拟机镜像。开发人员只能告诉Windows Azure他使用Web role还是Worker role来创建应用程序，每个应用程序需要有几个实例。web role通过IIS 7来接受来自Internet的Http或Https请求。Web role可以用ASP.NET，WCF或者其他支持IIS的技术来开发。从图上我们可以看到Windows Azure的内建负载平衡机制可以自动将请求发送到同一个Web role的不同实例上去处理。当然，并不是所有的程序都是基于web的，所以Windows Azure提供了Worker role。Worker role和Web role很类似，但是没有IIS。不过Worker role还是可以接受来自Internet的请求，甚至在里面跑一个Apache server。但是一般不推荐这样做，因为从名字可以看出Worker role有点像我们windows平台下的工作线程，所以他最好还是用来处理cup密集型的工作。Worker role实例可以通过多种方式来和Web role交互。一种方式是使用Windows Azure存储队列（Storage queues），Web role作为生产者来往队列里面塞入任务，Worker role作为消费者从队列里面取出任务进行处理。Windows Azure存储队列在下面我们会讲到。另一种交互的方法就是使用WCF或其他技术来使Web role和Worker role建立直接的连接来通讯。

     
      下面来看存储服务。就像我们先前说的一样，微软的云计算平台是一组云计算服务的集合，这些服务都可以独立使用或协同工作。存储服务也不例外，云端的程序和on-premises的程序都可以通过相同的RESTful的方式来访问Azure存储服务。存储服务主要提供了三种形式的存储：Blobs，Tables和Queues。Blob存储是最简单，一个存储账户可以有一个或多个容器，每个容器可以存有一个或多个blobs。每个Blob可以存储最高可达1T大小的二进制文件，当然为了传输更为高效，大的blob文件会被切成块来传输，这样当传输中断后，续传过程只需要从最后传输失败的块开始重传。
      在很多情况下Blob存储过于非结构化，所以Azure存储提供了Table形式的存储。这里的Table和我们传统数据库里面的Table是不同的。这里的Table没有schema，每个Table都是一组entity的集合，一个entity又是一组property的集合，property又包含了Name，Type和Value。
Properties可以是int，string，bool，datetime等多种类型。Table也不可以通过SQL来存取，只能通过ADO.NET的Data Service或LINQ（.NET Language-Integrated Query）。一张表同样可以存储上亿跳数以而达到TB级别的大小，Azure存储会将数据分区后存储在不同的服务器上。

      Queue我们前面已经介绍过，它的用途主要不是数据存储，而是提供Web role和Worker role一种异步通信的方法。不过这里我们需要注意的是Windows Azure Storage queues和MSMQ或者通常我们数据结构中所说的队列并不具有相同的语义。它并不保证先入先出，也不保证每条消息只会被出队列一次。使用Queue的程序必须显式地调用删除方法来删除已经处理完的消息。也许你会觉得这样的设计很奇怪，但是从希望每条消息至少被正确地处理一次的角度来看，这样的设计就非常合理了。假设有一个Worker role从队列中取出一条消息，然后处理了一半就非正常关闭了，它就没有机会从queue中删除这条消息，这时候Azure queues会等待一个超时周期后重新将这条消息加入队列中，当下一个Worker role来取消息的时候，这条没有被正常处理的消息就会被再次处理。这样程序的可靠性就提高了。

 

    下面我们看Windows Azure的基础：The fabric。 Windows Azure Fabric 通过fabric controller把大量的服务器组织起来共同来提供稳定可靠的服务。Fabric controller管理着整个data center中的所有资源，包括服务器，交换机，负载均衡等。它可以通过每台服务器上安装的fabric agent来了解每一个Windows Azure应用程序运行的情况。这样的设计使得fabric controller可以获取足够的信息来智能地来处理很多事情。例如用户部署了一个应用程序，fabric controller就可以通过程序的配置文件来知道这个应用需要几个Web role和Worker role，然后可以启动相应数量的虚拟机并监控它们。当一个虚拟机机非正常退出后它有可以迅速再启动一个，始终保持用户需要的数量。

     单单是这样其实还是不够的如果一个程序需要2个Web role的实例，fabric controller简单地将它们分配到同一台交换机下面的服务器上，那么一旦交换机出现问题，整个程序就停止服务了。这也就违背了云计算所标榜的high availability。为了解决这样的问题，fabric controller将位于数据中心一个区域的一组机器包括交换机划分成一个fault domain，然后把Web role的实例放到不同的fault domain中去。这样独立的硬件故障就不会导致整个应用停止服务。

     单单是这样还不够。只要是软件就不可避免地会需要不断升级。Windows Azure的目标是要提供真正可靠的程序，所以停止服务来升级应用程序是需要避免的。所以fabric controller还将服务器划分出了不同的update domain。应用程序的实例会被部署到不同的update domain上。如图所示的4个实例中，fabric controller会先关闭第一个update domain中的两个实例然后升级程序，完成后启动新的程序再关闭第二个update domain中的两个实例进行升级。这样Windows Azure应用程序就可以7乘24小时不间断地提供服务了。

 

 

----注：本文原创，转载请标明出处。图片来自微软官方文档。