基于Windows Azure的云计算应用设计

本文从云计算应用的特点出发，分析了在云计算环境下应用程序开发设计的一些变化。根据这些新的特点，本文提出一个“自我感知应用”（Self- Sensing Application）的新概念。接着文章从架构设计的角度阐述了Windows Azure平台的构建方式和架构特点，然后结合Windows Azure平台的一些功能特点，讲述几个在云计算环境下典型的应用架构设计方式，期望抛砖引玉。最后，文章展望了应用程序未来的发展趋势。云计算环境下的应用特点

多年来应用程序开发者和架构师们都在努力设计一种既能够在功能上满足当前业务需求，另外又能够在用户需求发生变化或者能够在可预见的将来适应环境变化的应用。尤其是在互联网领域，架构师都在努力让自己设计的应用具有比较强的扩展能力，能够跟得上用户不断增长或者出现突发请求的一些情况。在传统的 Web应用设计中，我们在架构上一般采用基于多层架构的设计，在Web层中大量使用了负载均衡等技术。一般我们的处理方式都是在应用程序设计好之后，在应用部署的过程中事先把环境配置好，应用程序在运行过程配置都是不发生变化的。但是，随着云计算时代的到来，我们面对一些新的挑战，相应的应用程序设计方式随之发生了一些变化。我们首先从云计算的技术特点开始讨论应用的变化。

从技术角度看云计算的特点

毫无疑问，云计算是目前信息产业中讨论得最多的话题。虽然大家对于云计算还没有一致定义，但是对于云计算的一些特点，相关的服务模型等内容日渐趋于统一。在讨论云计算应用架构特点之前，我们先从技术的角度来讨论一下云计算本身的一些特点。

按需服务

云计算是一个把信息技术作为服务（IT as a Service）提供的一种方式。这种服务的概念都是从消费方（用户）角度出发，而不是从服务提供方出发考虑问题，因此，一个基本特点是云计算要求按需服务，即用户可以根据需求即时得到服务。从这个角度讲，云计算就像我们公共服务中的自来水、电和煤气一样，集中供应并按需服务和计费。

资源池

云计算的一个好处是提高资源的利用率，而这个一般需要通过共享的方式来达到这个目的。这里可以类比一下我们日常吃饭中的自助餐和桌餐的差别。如果需要共享就需要先把资源集中到一个公共的资源池中。在云计算当中，根据这个资源池中资源的类别，我们把云计算的服务模型分为三种，即所谓的SPI 模型，如下表所示：

高可扩展性

云计算平台的资源池相对于单个用户的需求而言是比较大的，因此考虑到会有大量不同用户共用一个资源池，他们之间的资源使用模式一般存在一定的互补性，所以对于某个用户的需求而言，云计算具有很高的扩展性。另外，云计算平台在做架构设计的时候，都会考虑到如何让用户可以平滑扩展他们的资源需求，比如计算资源，存储资源等。

弹性服务

弹性服务指的是云计算的资源分配可以根据应用访问具体情况进行动态地调整。也正是因为如此，云计算对于非恒定需求的应用，比如需求波动很大、阶段性需求等，具有非常好的应用效果。在云计算的环境中，资源的扩展方式可以分为两大类，一种是事先可以预测的，比如一些季节性的需求。另一种是完全基于某种规则实时动态调整的。无论是哪一种，都要求云计算平台提供弹性的服务。

自服务和自动化

对于自服务和自动化概念本身都比较好理解，但是我把这两个放在一起是因为它们之间的内在联系。自服务是云计算中降低服务成本，提高服务便捷性的一种途径，因此它是一个服务的提供方式。但是，对于云计算服务提供方来说，自服务就要求尽量简化用户操作，降低用户使用服务的难度，提升服务响应速度，而这个只能通过后台自动化的方式才能实现。因此从这个意义上来讲，自服务是目的，而自动化则是手段。

服务可度量

管理学中有一句名言：没有考核，就没有管理。云计算作为服务提供的方式，需要对服务进行度量。一般服务提供方和用户之间需要有一个服务水平协议（SLA）。这样对于私有云来说，可以根据服务情况进行内部费用核算。而对于公有云来说，服务可度量就是计费的前提，然后根据实际使用量来进行计费。

云计算应用的特点

从前面的描述我们可以看到云计算给应用程序带来的一些挑战，那就是应用程序如何在云计算环境下充分利用云计算平台的一些特点来更好的满足用户需求。云计算应用要能够利用云计算环境中可动态扩展的资源，构建一个具有弹性的高可用应用程序。下面我们分别讨论一下云计算环境下的应用特点和要求。

自动化要求

自动化是人类的梦想，而计算机对自动化领域的发展有着巨大的影响，它极大的提高了工作和生产效率。在云计算环境下，自动化要求实际上是对计算工作本身的一个自动化改变。云计算的自动化可以赋予用户对平台基础架构的资源配置任务进行全面统筹的能力，并实现对资源的动态分配以提高管理效率、减少人为错误并加快用户对资源请求的响应速度。应用程序在设计的时候要能充分利用云计算环境的自动化特性，从而使得应用程序可以在很少或没有人工干预的情况下，自动适应需求的变化。

分布式计算

大部分云计算平台都是用廉价和标准的计算机硬件构成，然后通过云计算软件的方式在计算能力、可靠性等方面来达到传统的大型计算机的水准。也就是说在云计算环境下，资源池通常是通过分布式软硬件方式来实现。因此云计算应用程序的运行往往涉及到多个计算资源。无论是计算还是存储需求，应用程序一般都会涉及到多个节点，这样在设计的时候要考虑并行设计的思想或采用分布计算的方式。比如，有些云计算应用可以根据计算的要求，采用类似 MapReduce的编程模型。

松耦合

无论是功能上还是性能上云计算对应用的灵活性提出了更高的要求。这就要求应用程序在设计的时候要考虑松耦合的架构。耦合度与灵活性一般是相反的，也即耦合度越高灵活性越低，而耦合度越低灵活性越高。因此，在做云计算应用架构设计的时候，一般要追求松耦合的设计。比如，在做Web应用设计的时候，对于用户状态的保持就需要尽量采用无状态的方式来设计，这样应用程序的水平扩展能力比较好。

数据存储方式

在传统的应用设计中，我们一般采用关系型数据库来存储数据。但是在云计算环境下，尤其是对于互联网应用，存在两个需要面对的问题。一是云计算环境下的数据量都比较大，传统的关系型数据库面临数据扩展能力的挑战。另一个是许多应用对于数据存储的要求更多体现在非结构化数据或者是半结构化数据的存储上面。因此，大多数云计算平台都会提供针对非结构化和半结构化的数据存储方式。这样应用程序的架构需要针对新的数据存储方式作出调整。

上面描述的一些应用特点对我们开发和设计应用程序会带来许多影响。一个是应用程序在设计的过程中不仅仅需要考虑操作系统平台或中间件级别的编程接口，还要针对其运行的云平台的接口来对应用程序进行设计。另外一个比较大的影响是有一些工作量从平台产品转移到了应用程序的开发设计人员。比如说，在采用半结构化数据存储的时候，开发设计人员需要处理数据的一致性问题。还有，在云计算平台上如果想要得到比较好的性能，开发设计人员往往还需要对数据的分区进行特别设计，或需要采用一些并行设计的算法等。

具有自我感知能力的应用

传统的基础架构或系统平台中的资源都不能动态配置，因此应用程序在设计的时候主要考虑自身的业务逻辑的实现。应用程序本身的监控和管理都是通过其他系统管理软件如System Center，Tivoli等来实现。有一些管理得比较好应用程序，可以通过这些系统管理软件实现部分资源动态调整。但是，这些传统的应用程序本身对底层平台的运行情况是没有任何感知的。随着云计算的出现，应用程序本身的自动化逐渐成为可能。我把这些具有运行环境感知功能的应用程序称之为“自我感知应用”（Self-Sensing Application）。

自我感知应用的出现是应用程序发展的一种趋势，是自动化在应用程序运行过程中的一种体现。在做传统应用程序设计的时候，我们把主要的精力都放在功能性的需求方面，但是对于一些非功能性的需求往往采用手工配置的方式来实现。云计算平台的出现使得计算平台的资源具有可编程的特性，因此我们在应用程序的架构设计中可以通过基础架构平台的一些接口来感知应用程序的实际运行情况，并可以结合访问情况对应用程序的运行资源进行动态调整，以实现完善的自动化程序运行。

云计算平台具有可编程的资源分配，因此我们还可以设定自动化的部署过程，也就是让应用程序的可以自动化的完成应用程序的部署，升级等工作。自动化部署也是应用程序动态扩展的一个前提。这样当需要更多计算实例来处理更多的用户请求的时候，新的计算实例可以动态的生成出来并自动启用。

自我感知应用是应用程序朝着成为具有独立、自治单元的方式发展的一种体现。应用架构师在做设计的时候，面对的是底层抽象的、几乎无限的计算资源，而不是传统意义上的物理资源。从另外一个角度看这种设计方式也是应用程序与底层计算平台松耦合的一种体现，从而使得应用程序不绑定具体物理硬件。云计算平台从底层提供几乎无限的计算、存储和网络资源，其上的应用程序就像一个个具有人工智能的独立单元，他们在完成自身业务工作之外，还能够具有自我管理和自我修复的功能。

Windows Azure的架构设计Windows Azure的概况

Windows Azure平台目前包含Windows Azure，SQL Azure和Windows Azure Platform AppFabric三大部分，而其中Windows Azure是平台最为核心的组成部分，它被称为云计算操作系统，也是本文讨论的重点。不过这个操作系统目前只运行在微软的数据中心当中，微软是通过销售云计算服务作为她的业务模式。

查看原图（大图）

图1：Windows Azure平台

实际上为了便于理解，我们也可以把Windows Azure看成是数据中心的操作系统。当然，这里我们称之为操作系统实际上是一种类比，因为Windows Azure不是传统意义上的操作系统。但是它履行了资源管理的职责，只不过它管理的资源更为宏观，数据中心中的所有服务器、存储、交换机和负载均衡器等都接受它的管理。因为未来的数据中心会越来越像一台超级计算机，因此Windows Azure也会越来越像一个超级操作系统。Windows Azure的设计团队中就有许多微软技术重量级人物，其中包括Dave Cutler，他被称为是Windows NT和VMS之父。

Windows Azure为开发者提供了托管的、可扩展的、按需应用的计算和存储资源，还为开发者提供了云平台管理和动态分配资源的控制手段。Windows Azure是一个开放的平台，支持微软和非微软的语言和环境。开发人员在构建Windows Azure应用程序和服务时，不仅可以使用熟悉的Microsoft Visual Studio，Eclipse等开发工具，同时Windows Azure还支持各种流行的标准与协议，包括SOAP、REST、XML、和HTTPS等。

Windows Azure的组成和架构

从云计算SPI模型来看，Windows Azure主要处于平台即服务的层次。按照微软目前公开的发展计划，其将在年内提供基础设施即服务层次的一些服务，比如VM Role。Windows Azure作为基础平台的调度和管理软件，它是构建高效、可靠、可动态扩展应用的重要平台。主要由四大部分组成：

计算服务

存储服务

管理服务

开发环境

查看原图（大图）

图2：Windows Azure的组成

上述四个组成部分中只有开发环境是安装在用户的计算机上的，用于用户开发和测试Windows Azure的应用程序，其余三部分都是Windows Azure服务平台的一部分而安装在微软数据中心。

Windows Azure Fabric控制器被比作是Windows Azure的大脑，它负责平台中各种资源的统一管理和调配。而Windows Azure Fabric则由其管理的大量IT设备组成。开发人员通过Windows Azure开发工具（比如Visual Studio 2010和相应的SDK）开发的应用程序一般分为两大部分。一部分是应用程序代码，也称服务代码，另一部分是应用的配置文件也称服务模型。每个应用包括两个配置文件：服务定义文件和服务配置文件。这两个配置文件中会包含应用程序在Windows Azure上运行和发布的一些信息，如认证信息、服务端口、服务角色、需要的实例数和自定义变量等。当用户通过开发者门户把应用程序上传到Windows Azure平台的时候，其中的配置文件则由Windows Azure Fabric控制器来读取，然后由其根据配置文件中指定的方式进行服务部署。

Windows Azure的计算资源目前是通过成为Web Role和Work Role的方式来分配的。为了便于理解，我们可以认为Web Role和Worker Role是两种不同的虚拟机模版。其中Web Role是为了方便运行Web应用程序而设计的，而Work Role是为了其他应用类型，比如批处理而设计的。一种比较常见的架构设计方式是使用Web Role来处理展示逻辑，而通过Worker Role来进行业务逻辑处理。Web Role负责客户端的HTTP请求，为了支持应用的扩展，Web Role上的应用一般会设计为无状态的，从而使得系统可以方便的增加Web Role实例数量，提高应用的并发处理能力。

图3：Web Role与Work Role的分工

当应用程序部署完后，Windows Azure Fabric控制器便开始监控应用的状态，以保证应用程序的正常运行。为了使控制器能够实时获取应用和运行实例的状态，所有Role实例，也即虚拟机实例中都预先安装了代理程序，Fabric控制器就是通过这些代理来实时获取相应的状态信息。当检测到实例故障的时候，Fabric控制器就会启动新的包含同样服务的实例并添加到服务组中去。按照微软的计划，Windows Azure将在今年晚些时候提供另外一种称为VM Role的计算服务，它将让用户对底层计算平台有更多的控制权，可以通过远程桌面服务（RDS）方式连接过去。其主要目的是要已有的Windows应用程序可以相对平滑地迁移到Windows Azure上去。

Windows Azure 提供的存储不是一个关系型数据系统，并且它的查询语言也不是SQL，它主要被设计用来支持建于Windows Azure上的应用，它提供更简单容易扩展的存储。当然，对于在Windows Azure之外的应用程序也可以通过标准的REST API来访问和使用这个存储服务。Windows Azure主要提供了三种数据存储方式以满足应用程序的不同需求，这三种存储方式分别为Blob、Table和Queue。Windows Azure为了提升兼容性而提供的Drive其底层实现实际上就是Blob的一种。所有这三种存储服务都可以通过标准的REST API来访问。

图4：使用REST API访问存储服务

Windows Azure提供的存储服务具有以下特点：

可以存放大量数据

大范围分布的

可以无限扩展的

所有数据都会复制多份

可以选择数据存储地点

Blob非常便于存储二进制数据，比如JPEG图片或MP3文档等多媒体数据。Blob适用于部分应用，但它存储的数据缺乏结构化，为了让应用能够以更易获取的方式来使用数据，Windows Azure 存储服务提供了Table。它最大的不同之处是提供半结构化数据的存储，并且是一种可扩展存储，它通过多个节点对分布式数据进行扩展和收缩，这比使用一个标准的关系型数据库更为有效。与Blob和Table都是用于长期存储数据不同，Queue的主要功能是提供一种Web Role实例和Worker Role 实例之间通信的方式。而Drive的主要作用是为Windows Azure应用程序提供一个NTFS文件卷，这样应用程序可以通过NTFS API来访问存储的数据。提供这种Drive存储方式使得迁移已有应用程序到Windows Azure的过程变得更为平滑。无论数据以Blob、Table、Queue或Drive任何方式存储，Windows Azure存储服务都会将所有数据复制三次，如果有一份拷贝出现问题，存储服务能自动恢复出一份新的拷贝，保证应用能够准确及时读取原始数据信息。

Windows Azure应用程序的自我感知

对于一个自我感知应用而言，一方面它要能够感知底层运行平台的一些环境信息，另一方面它还需要一种机制能够把自身运行要求转递给底层运行环境。我们知道Windows Azure上应用程序由代码和基于XML的配置文件两部分组成。应用程序可以通过配置文件把自身运行要求传递给Windows Azure，确切的讲是提交给Fabric控制器。但是，应用程序如何才能感知环境的一些变化呢？加入配置文件更新之后应用程序如何才能得到通知并作出响应呢？这里就要用到Windows Azure提供的服务运行时编程接口（Service Runtime API）。

Windows Azure的服务运行时编程接口最常用的使用方式就是帮助应用程序了解应用服务和应用所在的Role实例的信息，包括：

它能够让应用程序访问在服务配置文件和服务定义文件中的最新服务配置信息。当配置文件的信息被更新的时候，服务运行时编程接口能够保证返回最新的配置信息。

它能够应用得到最新的服务拓扑结构，比如哪些Role实例在运行，每种Role类型有多少实例等。

由于Worker Role中的代码运行周期有点类似于有限状态自动机的处理方式，服务运行时编程接口能够帮助应用得到Worker Role实例的生命周期信息。

服务运行时编程接口可以通过两种方式使用。对于.NET托管代码，Windows Azure的SDK中包含一个名为Microsoft.WindowsAzure.ServiceRuntime.dll，当用Visual Studio新生成一个云服务项目时它会被自动引用。而对于本地代码，可以通过使用SDK中的头文件和库文件就可以用C来调用这个编程接口了。

服务运行时编程接口是应用程序本身用来得到自身及其运行环境信息用的，但是如果应用程序之外，比如说一个管理工具要得到指定应用程序的信息，那么一般需要利用另外一个称为服务管理的编程接口（Service Management API）。这两个编程接口在功能有重合的地方，它们之间的最大区别在于服务运行时编程接口在Windows Azure中运行，而服务管理的编程接口一般在Windows Azure之外运行，它更多的用在那些针对Windows Azure的管理工具开发当中。

常见的云计算应用设计方式软件+服务的方式

当微软在2005年底提出软件+服务的概念的时候，许多人都认为这只是一个市场宣传口号。但是，在过去几年我们发现有越来越多的应用通过软件+服务的模式取得成功。从应用架构角度来看，软件+服务的方式结合了云服务和设备端两方面的优势。从传统的应用如杀毒软件，Live Messenger/QQ到帮助苹果取得成功的iTunes，应用商店等，都是结合了终端软件和云计算服务的各自特点。

图5：软件+服务的方式

软件+服务对于架构师的意义在于在设计应用架构的时候，可以打开思路，充分利用云和端的各自优势。由于Windows Azure提供的服务如计算、存储都是可以独立使用，所以对于像一个做在线远程教学的应用，在设计的时候就可以考虑自己构建运行应用程序的网站，但是把课件视频等大数据量存放到Windows Azure的存储服务上，大大降低项目对存储设备的投资，从而降低项目的进入门槛。

运行在各种端设备上的应用程序可以直接与构建在Windows Azure平台上的服务进行交互，但是对于一些需要透过防火墙才能与互联网上的云计算服务进行集成的企业应用来说，需要一个Internet Service Bus（ISB）来进行应用集成。Windows Azure AppFabric就提供了ISB的功能，让企业内部应用可以不受防火墙和NAT等限制进行服务集成。

我们在通过软件+服务的方式进行应用架构设计的时候，由于是基于互联网的分布式计算，因此要特别考虑到网络延时对应用的设计和架构的影响。我们可以采用不同的方式来降低分布式方式带来的影响。比如尽量采用粗粒度的调用方式，降低软件与云服务的交互次数。另外，在架构设计的时候，尽量让动态数据与计算工作靠近，让静态数据与使用用户距离更近。Windows Azure的存储服务在创建账号的时候，用户可以选择数据存储的数据中心位置。除此之外，Windows Azure还提供了CDN服务，从而使得应用数据可以尽可能靠近访问用户。

采用SOA设计方式

云计算平台能够从资源使用的角度保证应用程序的灵活性。但是要让应用的构建和功能上保持灵活性，我们需要采用面向服务的方式来构建我们的应用，也就是说在云计算的环境下我们同样需要SOA的思想来设计我们的应用。我们一般认为服务就是通过某种标准的接口来访问应用的功能和数据。如果我们事先构建了一个服务池，那么就可以通过某种服务编排的方式来创建一个新的服务或一个新的组合应用。这种构建方式可以给应用的架构带来很大的灵活性。

在云计算的环境下，我们可以融合软件+服务和SOA的设计思想，从问题本身需求出发设计和组合应用的服务，可以利用不同平台上的服务而不在局限于企业内部。在设计服务的时候，一个重要的设计目标就是让服务变成平台或者位置无关。新的服务或应用可以组合在企业内部的应用服务以及部署在像Windows Azure云平台上的应用服务，如下图所示：

图6：SOA设计方式

松耦合的架构设计

在云计算环境下，应用程序的运行环境等变得不像传统环境那样可控。对于大规模分布的应用而言，要充分考虑到底层环境的单个节点出问题的可能性。为了保证应用程序的可靠运行，一般会采用松耦合的架构设计，并在架构设计的时候考虑系统如何快速从错误中恢复过来，比如状态的保持，自动化数据备份和恢复等。另外，松耦合架构设计不但可以增强系统的整体健壮性，还能增加系统的可扩展性。

一种的常见的设计方式就是采用异步消息机制来实现松耦合的架构设计。通过异步消息机制可以使得应用各个模块之间通过事先定义好的接口进行异步通信，相互之间就像一个不透明的黑盒子。比如对于Web应用程序，我们可以通过这种方式把Web服务器、应用服务器和数据库服务器之间进行隔离。在云计算环境中，这种异步机制对于应用程序的水平扩展显得更为重要。这也就是为什么无论是亚马逊的AWS还是微软的Windows Azure都会提供基于消息队列的通信机制。下面是一个典型的基于Windows Azure的应用架构。

图7：典型的基于Windows Azure的应用架构

在上面的架构中，我们可以看到Web Role实例与Worker Role实例不再一一绑定，而是通过Windows Azure的存储队列进行通信。因此，Web Role的实例数和Worker Role的实例数可以根据业务具体情况进行分配。这种通过消息队列的方式同时也很好的解决了数据的并发处理，并使整个系统具有良好的扩展性。而且，某个实例暂时停止工作都不会对整个系统造成大的影响，从而增强了应用程序的可用性。

总结

云计算无疑已受到大家极大的关注，但是它还是一个相对较新的概念，相关的技术正处于快速发展的过程中。我们已经可以看到云计算对IT行业的硬件模型，应用模型和用户体验等方面带来了革命性的影响。从应用模型的角度来看，云计算平台的出现使得开发人员可以快速的构建高可用的，可以几乎无限扩展的应用。Windows Azure平台为广大开发人员提供了一个开发、设计和运行应用的云计算环境。随着云计算相关技术的进一步发展，我们也将在Windows Azure上看到越来越多的新特性，从而使我们能够进一步简化在其上开发自我感知应用的工作，另外非功能性的一些要求也将更多通过配置文件而不是代码来实现。

人们对于信息技术需求的发展始终没有改变，那就是追求可靠，便捷，易用的信息应用。当我们把一个冰箱连接到电源插座的时候，我们从来不会去考虑这个电力是从哪个发电站来的，我们也不需要成为一个电力专家来使用这个冰箱。云计算的出现让信息技术往这个方向更进了一步。我们认为应用程序将逐渐演变成具有自我感知能力的应用，成为一个能够根据平台环境和用户请求进行自我调整和自我修复的自治单元。也许不远的将来，整个互联网就像一台巨大的计算机，其上提供无限的计算资源和服务，人们使用其上的应用程序就像我们现在使用自来水，电力那样方便，自然。