深度剖析云计算背后采用的技术

云计算作为一种新型的计算模式，还处于早期发展阶段。众多大小不一、类型各异的提供商提供了各自基于云计算的应用服务。本文通过介绍亚马逊、Google、 IBM这三种典型的云计算实现，为读者剖析在“云计算”背后所采用的具体技术，解析当前云计算的平台建设方法以及应用构建方式。

实例1: Google的云计算平台与应用

Google的云计算技术实际上是针对Google特定的网络应用程序而定制的。针对内部网络数据规模超大的特点，Google提出了一整套基于分布式并行集群方式的基础架构，利用软件的能力来处理集群中经常发生的节点失效问题。
从2003年开始，Google连续几年在计算机系统研究领域的最顶级会议与杂志上发表论文，揭示其内部的分布式数据处理方法，向外界展示其使用的云计算核 心技术。从其近几年发表的论文来看，Google使用的云计算基础架构模式包括四个相互独立又紧密结合在一起的系统。包括Google建立在集群之上的文 件系统Google File System，针对Google应用程序的特点提出的Map/Reduce编程模式，分布式的锁机制Chubby以及Google开发的模型简化的大规模 分布式数据库BigTable。
Google File System 文件系统
为了满足Google迅速增长的数据处理需求，Google设计并实现了Google文件系统（GFS，Google File System）。GFS与过去的分布式文件系统拥有许多相同的目标，例如性能、可伸缩性、可靠性以及可用性。然而，它的设计还受到Google应用负载和 技术环境的影响。主要体现在以下四个方面:
1. 集群中的节点失效是一种常态，而不是一种异常。由于参与运算与处理的节点数目非常庞大，通常会使用上千个节点进行共同计算，因此，每时每刻总会有节点处在失效状态。需要通过软件程序模块，监视系统的动态运行状况，侦测错误，并且将容错以及自动恢复系统集成在系统中。
2. Google系统中的文件大小与通常文件系统中的文件大小概念不一样，文件大小通常以G字节计。另外文件系统中的文件含义与通常文件不同，一个大文件可能包含大量数目的通常意义上的小文件。所以，设计预期和参数，例如I/O操作和块尺寸都要重新考虑。
3. Google文件系统中的文件读写模式和传统的文件系统不同。在Google应用（如搜索）中对大部分文件的修改，不是覆盖原有数据，而是在文件尾追加新 数据。对文件的随机写是几乎不存在的。对于这类巨大文件的访问模式，客户端对数据块缓存失去了意义，追加操作成为性能优化和原子性（把一个事务看做是一个 程序。它要么被完整地执行，要么完全不执行）保证的焦点。
4. 文件系统的某些具体操作不再透明，而且需要应用程序的协助完成，应用程序和文件系统API的协同设计提高了整个系统的灵活性。例如，放松了对GFS一致性 模型的要求，这样不用加重应用程序的负担，就大大简化了文件系统的设计。还引入了原子性的追加操作，这样多个客户端同时进行追加的时候，就不需要额外的同 步操作了。
总之，GFS是为Google应用程序本身而设计的。据称，Google已经部署了许多GFS集群。有的集群拥有超过1000个存储节点，超过300T的硬盘空间，被不同机器上的数百个客户端连续不断地频繁访问着。
下图1给出了Google File System的系统架构，一个GFS集群包含一个主服务器和多个块服务器，被多个客户端访问。文件被分割成固定尺寸的块。在每个块创建的时候，服务器分配 给它一个不变的、全球惟一的64位块句柄对它进行标识。块服务器把块作为linux文件保存在本地硬盘上，并根据指定的块句柄和字节范围来读写块数据。为 了保证可靠性，每个块都会复制到多个块服务器上，缺省保存三个备份。主服务器管理文件系统所有的元数据，包括名字空间、访问控制信息和文件到块的映射信 息，以及块当前所在的位置。GFS客户端代码被嵌入到每个程序里，它实现了Google文件系统 API，帮助应用程序与主服务器和块服务器通信，对数据进行读写。客户端跟主服务器交互进行元数据操作，但是所有的数据操作的通信都是直接和块服务器进行 的。客户端提供的访问接口类似于POSIX接口，但有一定的修改，并不完全兼容POSIX标准。通过服务器端和客户端的联合设计，Google File System能够针对它本身的应用获得最大的性能以及可用性效果。

MapReduce分布式编程环境
为了让内部非分布式系统方向背景的员工能够有机会将应用程序建立 在大规模的集群基础之上，Google还设计并实现了一套大规模数据处理的编程规范Map/Reduce系统。这样，非分布式专业的程序编写人员也能够为 大规模的集群编写应用程序而不用去顾虑集群的可靠性、可扩展性等问题。应用程序编写人员只需要将精力放在应用程序本身，而关于集群的处理问题则交由平台来 处理。
Map/Reduce通过“Map（映射）”和“Reduce（化简）”这样两个简单的概念来参加运算，用户只需要提供自己的Map函数以及Reduce函数就可以在集群上进行大规模的分布式数据处理。
据称，Google的文本索引方法，即搜索引擎的核心部分，已经通过Map Reduce的方法进行了改写，获得了更加清晰的程序架构。在Google内部，每天有上千个Map Reduce的应用程序在运行。
分布式大规模数据库管理系统BigTable
构建于上述两项基础之上的第三个云计算平台就是Google关于将数据库系统扩展到分布式平台上的BigTable系统。很多应用程序对于数据的组织还是非 常有规则的。一般来说，数据库对于处理格式化的数据还是非常方便的，但是由于关系数据库很强的一致性要求，很难将其扩展到很大的规模。为了处理 Google内部大量的格式化以及半格式化数据，Google构建了弱一致性要求的大规模数据库系统BigTable。据称，现在有很多Google的应 用程序建立在BigTable之上，例如Search History、Maps、Orkut和RSS阅读器等。
下图2给出了在BigTable模型中的数据模型。数据模型包括行列以及相应的时间戳，所有的数据都存放在表格中的单元里。BigTable的内容按照行来划分，将多个行组成一个小表，保存到某一个服务器节点中。这一个小表就被称为Tablet。
以上是Google内部云计算基础平台的三个主要部分，除了这三个部分之外，Google还建立了分布式程序的调度器，分布式的锁服务等一系列相关的云计算服务平台。
Google的云应用
除了上述的云计算基础设施之外，Google还在其云计算基础设施之上建立了一系列新型网络应用程序。由于借鉴了异步网络数据传输的Web 2.0技术，这些应用程序给予用户全新的界面感受以及更加强大的多用户交互能力。其中典型的Google云计算应用程序就是Google推出的与 Microsoft Office软件进行竞争的Docs网络服务程序。Google Docs是一个基于Web的工具，它有跟Microsoft Office相近的编辑界面，有一套简单易用的文档权限管理，而且它还记录下所有用户对文档所做的修改。Google Docs的这些功能令它非常适用于网上共享与协作编辑文档。Google Docs甚至可以用于监控责任清晰、目标明确的项目进度。当前，Google Docs已经推出了文档编辑、电子表格、幻灯片演示、日程管理等多个功能的编辑模块，能够替代Microsoft Office相应的一部分功能。值得注意的是，通过这种云计算方式形成的应用程序非常适合于多个用户进行共享以及协同编辑，为一个小组的人员进行共同创作 带来很大的方便性。
Google Docs是云计算的一种重要应用，即可以通过浏览器的方式访问远端大规模的存储与计算服务。云计算能够为大规模的新一代网络应用打下良好的基础。
虽然Google可以说是云计算的最大实践者，但是，Google的云计算平台是私有的环境，特别是Google的云计算基础设施还没有开放出来。除了开放 有限的应用程序接口，例如GWT（Google Web Toolkit）以及Google Map API等，Google并没有将云计算的内部基础设施共享给外部的用户使用，上述的所有基础设施都是私有的。
幸运的是，Google公开了其内部集群计算环境的一部分技术，使得全球的技术开发人员能够根据这一部分文档构建开源的大规模数据处理云计算基础设施，其中 最有名的项目即Apache旗下的Hadoop项目。而下面的两个云计算的实现则为外部的开发人员以及中小公司提供了云计算的平台环境，使得开发者能够在 云计算的基础设施之上构建自己的新型网络应用。其中IBM的蓝云计算平台是可供销售的计算平台，用户可以基于这些软硬件产品自己构建云计算平台。亚马逊的 弹性计算云则是托管式的云计算平台，用户可以通过远端的操作界面直接使用。


实例2: 亚马逊的弹性计算云

亚马逊是互联网上最大的在线零售商，但是同时也为独立开发人员以及开发商提供云计算服务平台。亚马逊将他们的云计算平台称为弹性计算云（Elastic Compute Cloud，EC2），它是最早提供远程云计算平台服务的公司。
开放的服务
与 Google提供的云计算服务不同，Google仅为自己在互联网上的应用提供云计算平台，独立开发商或者开发人员无法在这个平台上工作，因此只能转而通 过开源的Hadoop软件支持来开发云计算应用。亚马逊的弹性计算云服务也和IBM的云计算服务平台不一样，亚马逊不销售物理的云计算服务平台，没有类似 于“蓝云”一样的计算平台。亚马逊将自己的弹性计算云建立在公司内部的大规模集群计算的平台之上，而用户可以通过弹性计算云的网络界面去操作在云计算平台 上运行的各个实例（Instance），而付费方式则由用户的使用状况决定，即用户仅需要为自己所使用的计算平台实例付费，运行结束后计费也随之结束。
弹性计算云从沿革上来看，并不是亚马逊公司推出的第一项这种服务，它由名为亚马逊网络服务的现有平台发展而来。早在2006年3月，亚马逊就发布了简单存储 服务（Simple Storage Service，S3），这种存储服务按照每个月类似租金的形式进行服务付费，同时用户还需要为相应的网络流量进行付费。亚马逊网络服务平台使用REST （Representational State Transfer）和简单对象访问协议（SOAP）等标准接口，用户可以通过这些接口访问到相应的存储服务。
2007 年7月，亚马逊公司推出了简单队列服务（Simple Queue Service，SQS），这项服务使托管主机可以存储计算机之间发送的消息。通过这一项服务，应用程序编写人员可以在分布式程序之间进行数据传递，而无 须考虑消息丢失的问题。通过这种服务方式，即使消息的接收方还没有模块启动也没有关系。服务内部会缓存相应的消息，而一旦有消息接收组件被启动运行，则队 列服务将消息提交给相应的运行模块进行处理。同样的，用户必须为这种消息传递服务进行付费使用，计费的规则与存储计费规则类似，依据消息的个数以及消息传 递的大小进行收费。
在亚马逊提供上述服务的时候，并没有从头开始开发相应的网络服务组件，而是对公司已有的平台进行优化和改造，一方面满足了本身网络零售购物应用程序的需求，另一方面也供外部开发人员使用。
在开放了上述的服务接口之后，亚马逊公司进一步在此基础上开发了EC2系统，并且开放给外部开发人员使用。
灵活的工作模式
亚马逊的云计算模式沿袭了简单易用的传统，并且建立在亚马逊公司现有的云计算基础平 台之上。弹性计算云用户使用客户端通过SOAP over HTTPS协议来实现与亚马逊弹性计算云内部的实例进行交互。使用HTTPS协议的原因是为了保证远端连接的安全性，避免用户数据在传输的过程中造成泄 露。因此，从使用模式上来说，弹性计算云平台为用户或者开发人员提供了一个虚拟的集群环境，使得用户的应用具有充分的灵活性，同时也减轻了云计算平台拥有 者（亚马逊公司）的管理负担。
而弹性计算云中的实例是一些真正在运行中的虚拟机服务器，每一个实例代表一 个运行中的虚拟机。对于提供给某一个用户的虚拟机，该用户具有完整的访问权限，包括针对此虚拟机的管理员用户权限。虚拟服务器的收费也是根据虚拟机的能力 进行计算的，因此，实际上用户租用的是虚拟的计算能力，简化了计费方式。在弹性计算云中，提供了三种不同能力的虚拟机实例，具有不同的收费价格。例如，其 中默认的也是最小的运行实例是1.7GB的内存，1个EC2的计算单元（1虚拟的计算核以相关的计算单元），160GB的虚拟机内部存储容量，是一个32 位的计算平台，收费标准为每个小时10美分。在当前的蓝计算平台中，还有两种性能更加强劲的虚拟机实例可供使用，当然价格也更加昂贵一点。
由于用户在部署网络程序的时候，一般会使用超过一个运行实例，需要很多个实例共同工作。弹性计算云的内部也架设了实例之间的内部网络，使得用户的应用程序在 不同的实例之间可以通信。在弹性计算云中的每一个计算实例都具有一个内部的IP地址，用户程序可以使用内部IP地址进行数据通信，以获得数据通信的最好性 能。每一个实例也具有外部的地址，用户可以将分配给自己的弹性IP地址分配给自己的运行实例，使得建立在弹性计算云上的服务系统能够为外部提供服务。当 然，亚马逊公司也对网络上的服务流量计费，计费规则也按照内部传输以及外部传输进行分开。
总而言之，亚马逊通过提供弹性计算云，减少了小规模软件开发人员对于集群系统的维护，并且收费方式相对简单明了，用户使用多少资源，只需要为这一部分资源付费即可。这种 付费方式与传统的主机托管模式不同。传统的主机托管模式让用户将主机放入到托管公司，用户一般需要根据最大或者计划的容量进行付费，而不是根据使用情况进 行付费，而且，可能还需要保证服务的可靠性、可用性等，付出的费用更多，而很多时候，服务并没有进行满额资源使用。而根据亚马逊的模式，用户只需要为实际 使用情况付费即可。
在用户使用模式上，亚马逊的弹性计算云要求用户要创建基于亚马逊规格的服务器映像（名 为亚马逊机器映像即亚马逊 Machine Image, AMI）。弹性计算云的目标是服务器映像能够拥有用户想要的任何一种操作系统、应用程序、配置、登录和安全机制，但是当前情况下，它只支持Linux内 核。通过创建自己的AMI，或者使用亚马逊预先为用户提供的AMI，用户在完成这一步骤后将AMI上传到弹性计算云平台，然后调用亚马逊的应用编程接口 （API），对AMI进行使用与管理。AMI实际上就是虚拟机的映像，用户可以使用它们来完成任何工作，例如运行数据库服务器，构建快速网络下载的平台， 提供外部搜索服务甚至可以出租自己具有特色的AMI而获得收益。用户所拥有的多个AMI可以通过通信而彼此合作，就像当前的集群计算服务平台一样。
在弹性计算云的将来发展过程中，亚马逊也规划了如何在云计算平台之上帮助用户开发Web 2.0的应用程序。亚马逊认为除了它所依赖的网络零售业务之外，云计算也是亚马逊公司的核心价值所在。可以预见，在将来的发展过程中，亚马逊必然会在弹性 计算云的平台上添加更多的网络服务组件模块，为用户构建云计算应用提供方便。

实例3:IBM蓝云计算平台

IBM在2007年11月15日推出了蓝云计算平台，为客户带来即买即用的云计算平台。它包括一系列的云计算产品，使得计算不仅仅局限在本地机器或远程服务器农场（即服务器集群），通过架构一个分布式、可全球访问的资源结构，使得数据中心在类似于互联网的环境下运行计算。
通过IBM的技术白皮书，我们可以一窥蓝云计算平台的内部构造。“蓝云”建立在IBM大规模计算领域的专业技术基础上，基于由IBM软件、系统技术和服务支 持的开放标准和开源软件。简单地说，“蓝云”基于IBM Almaden研究中心（Almaden Research Center）的云基础架构，包括Xen和PowerVM虚拟化、Linux操作系统映像以及Hadoop文件系统与并行构建。“蓝云”由IBM Tivoli软件支持，通过管理服务器来确保基于需求的最佳性能。这包括通过能够跨越多服务器实时分配资源的软件，为客户带来一种无缝体验，加速性能并确 保在最苛刻环境下的稳定性。IBM新近发布的“蓝云（Blue Cloud）”计划，能够帮助用户进行云计算环境的搭建。它通过将Tivoli、DB2、WebSphere与硬件产品（目前是x86刀片服务器）集成，能够为企业架设一个分布式、可全球访问的资源结构。根据IBM的计划，首款支持Power和x86处理器刀片服务器系统的“蓝云”产品将于2008年正式 推出，并且计划随后推出基于System z“大型主机”的云环境，以及基于高密度机架集群的云环境。
在IBM的云计算白皮书上，我们可以看到如下的蓝云计算平台配置情况。
下图4演示了蓝云计算的高层架构。可以看到，蓝云计算平台由一个数据中心: IBM Tivoli部署管理软件（Tivoli Provisioning Manager）、IBM Tivoli监控软件（IBM Tivoli Monitoring）、IBM WebSphere应用服务器、IBM DB2数据库以及一些虚拟化的组件共同组成。图中的架构主要描述了云计算的后台架构，并没有涉及到前台的用户界面。
蓝云的硬件平台并没有什么特殊的地方，但是蓝云使用的软件平台相较于以前的分布式平台具有不同的地方，主要体现在对与虚拟机的使用以及对于大规模数据处理软 件Apache Hadoop的部署。Hadoop是网络开发人员根据Google公司公开的资料开发出来的类似于Google File System的Hadoop File System以及相应的Map/Reduce编程规范。现在也正在进一步开发类似于Google的Chubby系统以及相应的分布式数据库管理系统 BigTable。由于Hadoop是开源的，因此可以被用户单位直接修改，以适合应用的特殊需求。IBM的蓝云产品则直接将Hadoop软件集成到自己 本身的云计算平台之上。
“蓝云”中的虚拟化
从蓝云的结构上我们还可以看出，在每一个节点上运行的软件栈与传统的软件栈一个很大的不同在于蓝云内部使用了虚拟化技术。虚拟化的方式在云计算中可以在两个 级别上实现。一个级别是在硬件级别上实现虚拟化。硬件级别的虚拟化可以使用IBM p系列的服务器，获得硬件的逻辑分区LPAR。逻辑分区的CPU资源能够通过IBM Enterprise Workload Manager来管理。通过这样的方式加上在实际使用过程中的资源分配策略，能够使得相应的资源合理地分配到各个逻辑分区。P系列系统的逻辑分区最小粒度 是1/10颗中央处理器（CPU）。
虚拟化的另外一个级别可以通过软件来获得，在蓝云计算平台中使用了Xen虚拟化软件。Xen也是一个开源的虚拟化软件，能够在现有的Linux基础之上运行另外一个操作系统，并通过虚拟机的方式灵活地进行软件部署和操作。
通过虚拟机的方式进行云计算资源的管理具有特殊的好处。由于虚拟机是一类特殊的软件，能够完全模拟硬件的执行，因此能够在上面运行操作系统，进而能够保留一 整套运行环境语义。这样，可以将整个执行环境通过打包的方式传输到其他物理节点上，这样就能够使得执行环境与物理环境隔离，方便整个应用程序模块的部署。 总体上来说，通过将虚拟化的技术应用到云计算的平台，可以获得一些良好的特性。
1. 云计算的管理平台能够动态地将计算平台定位到所需要的物理平台上，而无需停止运行在虚拟机平台上的应用程序，这比采用虚拟化技术之前的进程迁移方法更加灵活。
2. 能够更加有效率地使用主机资源，将多个负载不是很重的虚拟机计算节点合并到同一个物理节点上，从而能够关闭空闲的物理节点，达到节约电能的目的。
3. 通过虚拟机在不同物理节点上的动态迁移，能够获得与应用无关的负载平衡性能。由于虚拟机包含了整个虚拟化的操作系统以及应用程序环境，因此在进行迁移的时候带着整个运行环境，达到了与应用无关的目的。
4. 在部署上也更加灵活，即可以将虚拟机直接部署到物理计算平台当中。
总而言之，通过虚拟化的方式，云计算平台能够达到极其灵活的特性，而如果不使用虚拟化的方式则会有很多的局限。


“蓝云”中的存储结构
蓝云计算平台中的存储体系结 构对于云计算来说也是非常重要的，无论是操作系统，服务程序还是用户应用程序的数据都保存在存储体系中。云计算并不排斥任何一种有用的存储体系结构，而是 需要跟应用程序的需求结合起来获得最好的性能提升。总体上来说，云计算的存储体系结构包含类似于Google File System的集群文件系统以及基于块设备方式的存储区域网络SAN两种方式。
在设计云计算平台的存储体 系结构的时候，不仅仅是需要考虑存储的容量。实际上随着硬盘容量的不断扩充以及硬盘价格的不断下降，使用当前的磁盘技术，可以很容易通过使用多个磁盘的方 式获得很大的磁盘容量。相较于磁盘的容量，在云计算平台的存储中，磁盘数据的读写速度是一个更重要的问题。单个磁盘的速度很有可能限制应用程序对于数据的 访问，因此在实际使用的过程中，需要将数据分布到多个磁盘之上，并且通过对于多个磁盘的同时读写以达到提高速度的目的。在云计算平台中，数据如何放置是一 个非常重要的问题，在实际使用的过程中，需要将数据分配到多个节点的多个磁盘当中。而能够达到这一目的的存储技术趋势当前有两种方式，一种是使用类似于 Google File System的集群文件系统，另外一种是基于块设备的存储区域网络SAN系统。
Google 文件系统我们在前面已经做过一定的描述。在IBM的蓝云计算平台中使用的是它的开源实现Hadoop HDFS （Hadoop Distributed File System）。这种使用方式将磁盘附着于节点的内部，并且为外部提供一个共享的分布式文件系统空间，并且在文件系统级别做冗余以提高可靠性。在合适的分布式数据处理模式下，这种方式能够提高总体的数据处理效率。Google文件系统的这种架构与SAN系统有很大的不同。
SAN系统也是云计算平台的另外一种存储体系结构选择，在蓝云平台上也有一定的体现，IBM也提供SAN的平台能够接入到蓝云计算平台中。图5就是一个SAN系统的结构示意图。
从图5中可以看到，SAN系统是在存储端构建存储的网络，将多个存储设备构成一个存储区域网络。前端的主机可以通过网络的方式访问后端的存储设备。而且，由 于提供了块设备的访问方式，与前端操作系统无关。在SAN连接方式上，可以有多种选择。一种选择是使用光纤网络，能够操作快速的光纤磁盘，适合于对性能与 可靠性要求比较高的场所。另外一种选择是使用以太网，采取iSCSI协议，能够运行在普通的局域网环境下，从而降低了成本。由于存储区域网络中的磁盘设备 并没有与某一台主机绑定在一起，而是采用了非常灵活的结构，因此对于主机来说可以访问多个磁盘设备，从而能够获得性能的提升。在存储区域网络中，使用虚拟 化的引擎来进行逻辑设备到物理设备的映射，管理前端主机到后端数据的读写。因此虚拟化引擎是存储区域网络中非常重要的管理模块。
SAN 系统与分布式文件系统例如Google File System并不是相互对立的系统，而是在构建集群系统的时候可供选择的两种方案。其中，在选择SAN系统的时候，为了应用程序的读写，还需要为应用程序 提供上层的语义接口，此时就需要在SAN之上构建文件系统。而Google File System正好是一个分布式的文件系统，因此能够建立在SAN系统之上。总体来说，SAN与分布式文件系统都可以提供类似的功能，例如对于出错的处理 等。至于如何使用还是需要由建立在云计算平台之上的应用程序来决定。
与Google不同的是，IBM并没 有基于云计算提供外部可访问的网络应用程序。这主要是由于IBM并不是一个网络公司，而是一个IT的服务公司。当然，IBM内部以及IBM未来为客户提供 的软件服务会基于云计算的架构。（注: 本文受国家973计划资助，资助号: 2007CB310900以及国家自然科学基金资助，资助号90718040）

云计算中心