Windows Azure 基本概念浅析

Windows Azure 基本概念浅析
2011年04月14日
　　Windows Azure Platform不断在变化，所以它的概念什么的也不断在变动。考虑到将来童鞋们要用到这些东西，所以我基于MSDN2010年11月22日的文档以及The Windows Azure Programing Model 1.0整理了这篇文章。 Windows Azure 和Windows Azure 平台不是一个东西，平台指的是微软在其全球几个数据中心搭建的云服务平台，平台里包括了Windows Azure 操作系统和一些列的各种服务，比如SQL Azure等等。
　　正如所有云计算服务一样Windows Azure 平台简化了维护技术设施和软件的工作，同时基于按需使用的原则提供了弹性的支付方案，这样一来不仅保障了基础设施的高可用性和可伸缩性，同时也保证了相比自己购买服务器和基础设施所需的覆盖长期需求的成本。
　　Windows Azure操作系统作为Windows Azure平台的开发、运行时以及控制环境。 它内置了负载均衡以及资源的自动管理。
　　目前，要进行Windows Azure的编程工作需要使用到以下服务和工具： Windows Azure提供了一套基于整个英特网级别，建立在多个分布于全球不同地区的数据中心的主机环境，用户可以使用这个环境来执行托管的代码。
　　关于计算服务中的几个概念的关系如下：
　　Windows Azure Compute Service
　　--Deployment -- Role -- Role --Depolyment -- Role
　　注意的是，这个Deployment Azure是不管的，每个Deployment是用VS编译出来的包，其中有几个role部署上去就用几个role
　　目前， Windows Azure 的roles有三种： Web Role ：专门为Web程序配置的环境，支持IIS7和ASP.NET，它实际运行于IIS7.0之上。通常，把它用来处理外部的HTTP请求，这里还支持WCF、PHP和Java等技术
　　Worker Role： 适用于通用的程序，它可能作为Web Role的后台处理程序
　　Virtual Machine Role（VM Role）提供一个用户自定义的镜像来把现有的Windows Server 程序迁移到Windows azure 环境
　　一个Services可以混合使用多种role。
　　Role可能需要和运行时环境有所交互，这样就必须使用Windows Azure Managed API 。 Windows Azure Storage Servies 提供了一种在云端存储持久化数据的功能。 其主要包括以下几种基础的服务： Blob服务， 用来存储文本和二进制数据
　　Queue 服务，用来存储服务局通信用的可靠的持久化消息
　　Table 服务，用来存储可以被查询的结构化数据
　　Windows Azure SDK提供了REST API和托管的API以用来访问存储服务。它们支持任何形式的通过HTTP/s访问 管理门户是用来管理用户的Windows Azure 服务的部署和监控的工具。
　　在管理门户里面，我们会看到一些概念： Deployment Health， 表示部署的项目的状态
　　Affinity Groups， 它允许用户基于地理区域组织托管的服务和存储以优化性能
　　Management Certificates， 用来允许客户端访问用户的订阅的资源
　　Reporting， 允许用户签入基于云端的SQL Azure 数据库报告服务
　　Service Bus Access，访问 AppFabric 服务门户
　　Virtual Network， 访问 Windows Azure Microsoft Connect 服务
　　Windows Azure虽然有VM Role，但是，它更多的是希望做到PaaS（平台即服务）层次的抽象，因此它没有完全复制旧的面向Windows Server的编程模型，而是建立了一套新的模型以期在以下三点有所提升： 管理能力：作为一个PaaS应用，平台本身负责处理掉大量的管理型事务，如系统的升级、更新、打补丁等，这样一来，让用户可以不必自己去管理程序运行的环境--这是一种非常棒的省去麻烦的做法。
　　可用性：避免在升级、打补丁、硬件错误或者其他原因引起的服务下线。Azure通过云平台提供的冗余措施来避免这些问题，所以Azure的编程模型本身即是以保证服务可以持续运行而设计的。
　　可伸缩：Azure提供的是整个互联网级别的可伸缩性。同时也允许更加弹性化的资源使用。
　　想要充分利用Windows Azure平台所提供的这些好处，面向Azure开发的云端程序必须要遵守以下三条规则： 一个Windows Azure程序包括一个或多个Roles（可以混合多种role）
　　一个Windows Azure程序中的每个Roles都运行于多个Instances
　　一个Windows Azure程序在任何一个role instance出错的时候都可以正确工作
　　只有完全遵守着3条规则而开发的程序才可以让你的程序完全享受到云计算带来的好处。
　　正如前文所说的，Azure中的Role包括三种，Web Role, Worker Role和VM Role，
　　
　　举例来说，一个程序可以使用Web Role来处理来自用户的HTTP请求然后把请求传递给Work Role来处理。这样一种方式使得整个程序具备了良好的伸缩性。
　　对于任何一个Windows Azure程序来说，对于它的每一个role都应该至少运行两个隔离的实例。每个实例都运行于它自己的VM之上。
　　下图是上面那张图的实际运行的实例的情况，可以看到，程序的每一个role都运行了多个实例，并且在不同的VM之上。开发者应该告诉Windows Azure它需要给每个Role运行多少个实例。每个Role的特定实例都运行着一模一样的代码，所以这些实例都是可以互相替换的，这样一来，Azure就可以自动的处理负载均衡和容错等问题了。但是需要注意的一点是，Azure不保证对于同一个用户的请求都能被同一个实例处理。
　　
　　对于上面这个程序，当它的任何一个Role的实例挂了之后，系统还能保证正常工作（除非全部Instance都挂掉，当然，这个概率比一个挂掉的概率小得多）
　　
　　接下来，涉及到稍微技术细节一点的东西，让我们来看看Windows Azure编程模型的细节
　　Windows Azure 运行在大型的数据中心中，而每一个程序的不同实例都会被部署到不同的服务器上，Fabric Controller管理数据中心里的计算机。我们部署一个云端程序的时候实际上是上传我们的服务配置文件和程序包。配置文件告诉fabric controller使用不同的主机来运行role的实例。而一旦部署成功，fabric controller会继续监控这些程序的运行，当其中某个实例挂掉了，它会启动一个新的实例。
　　
　　正因为有了Fabric controller，Azure才能够有如此良好的管理能力，它自动对程序和底层的系统环境进行维护和更新。这样一来，整个系统具备了良好的抵抗硬件错误带来的停机时间，
　　事实上，在服务器硬件的选取上，Fabric controller不是随机的，它把一个role的不同实例配置到不同的fault domain（故障域，包括了一系列的硬件，如计算机，交换机等等--显然，它们是处于一个故障点中的)中，因此，硬件的错误不会波及到整个程序的运行。
　　而在软件上，当程序的一个实例挂了，fabric controller会重启程序或者重启程序运行的VM。那么，Azure又是如何做到让程序无停机的升级的呢？类似上面的fault domain，在Azure里，role的不同实例位于不同的update domain（更新域，和fault domain 不同）。当程序的新版部署了以后，fabric controller将关闭一个更新域的实力，升级之，然后启动它。之后才对其他更新域的实例挨个处理。这样就实现了所谓的不下线升级。
　　从伸缩性上看，Azure不仅允许用户指定某个role要运行多少个实例，同时也允许那些负载变化比较大的程序通过Web门户或者自己开发的程序来实时调整实例的数量。
　　技术带来的这些好处看起来如此的美妙，不过，要谨记的是，Windows Azure是按每个运行的实例来收费的，所以要是用户为了节约成本而仅使用一个instance的话那他就违背了编程模型的三大原则，这样，也就无法享受到上面说的好处了。 Windows Azure编程模型所带来的不只是前面说的那三个原则，从程序的角度看，我们还必须看到的是，这个模型给我们的开发环境带来了一些新的问题，我们可以将之主要归纳为以下3个方面： 首先，从操作系统的角度来看，传统的服务器系统是由运维团队来管理的，而在Azure里面，则是由Fabric Controller来控制，虽然用程序控制自动化程度高，但是我们也会遇到一些问题，比如如何让程序运行在管理员模式下，此外更加严重的问题是，instance所允许的物理服务器总是在不同的机器上，所以程序写入本地系统的信息肯定是无法保证可靠性的。虽然现在Work Role和Web Role可以运行在管理员模式下，但是，上面的问题还是没有解决的。这也就引出了第二个问题：既然程序写入本地系统的信息是没有保障的，我们编程的时候就必须知道它是非持久性的，而且为了不同的实例都能访问到数据所以数据应该被存储于role instances之外。
　　同样的，存储也必须要有冗余，也必须能够处理大量的数据。对于超大型的数据，传统的关系型系统不是最好的选择，所以也就有了前文提到的ｂｌｏｂｓ这样的数据结构。
　　
　　在这个图例里，程序使用了两个Blob和一个Table，但是Azure storage在底层为每个实例都维护了一个数据镜像，同样也是跨物理系统的，跨故障域的，这样即使有某些镜像挂掉了，还是可以用的。不过必须注意的是，Windows Azure的这个机制使得这些数据每次只能被一个实例操作（读写）
　　最后我们再来看看instances间的交互，这可是一个复杂的问题（想想进程同步问题）。。 通常我们设计程序的时候都会分层（逻辑上的分layer或者物理上的分tier）或者分模块，这些部分通常都需要相互交互的，然而，在Azure中，这样的交互和传统程序略有不同。还记得前面提到的特定的一个role的每个实例都是等价可替换的吗？这意味着一个Web role传了一个请求给Worker Role，但是它不应该去管具体worker role的哪个实例来处理这个请求的，甚至，web role都不应该依赖于比如IP地址这样的依实例而变的星系来进行通信。我们需要一个更加通用的机制。
　　在Azure平台上，我们的程序可以使用最通用的Windows azure queues来进行通信，它的原理如下图：
　　
　　这个例子里，一个Web role的某个instance获得了一个请求1）这个instance创建了一条包含这个请求所需的工作的信息，并把它写入Windows Azure queue（记得最上面提到的基本的3中数据结构之一，所以queue和blob一样基于相同的原理--每个实例copy一份） 2），接下来，Worker role从queue中读取消息，注意的是它并不管是那个web role写入的。在处理完工作后从queue中删除这条消息，没错，你看到的确实是Dequeue后处理完工作再删除，这和我们理解的普通队列有所不同，举例来说，在Microsoft Message Queuing技术里，一个程序可读取队列里的消息是一条原子操作，如果读取消息的程序出错，那么，这个读事务就会还原，也就是原来的消息会重现，这样就保证了MSMQ队列里的每一条消息都能按照发送的顺序被正确的提交。但是Windows Azure又有些不同，它不支持事务读操作，所以它无法保证精确的按需递交，在Azure里，一个消息可以被读并处理多次。加入某个worker role的实例读了消息，并且处理完工作了，但是在还没删除之前就挂掉了，那么这条被读取的消息在超时之后就会自动重现。Azure这样的设计机制据说是在速度和可伸缩性和上面提到的那种可靠性上的取舍--选择了速度。
　　当然，除了队列之外，Azure还可以通过API来让某个实例发现其他的特定的实例，然后直接发送请求给对方。