各公司服务器架构经典云计算架构包括IaaS、PaaS、SaaS三层服务。

云计算平台架构细分为硬件层、虚拟层、软件平台层、能力层、应用平台以及软件服务层。

云平台的云计算架构虽然分了多个层次，但是每个层次之间都是松耦合关系，在一个具体案例中也不是每个层次的服务都使用到，而且根据具体的应用环境搭建相应的云计算架构。

（1）硬件层和虚拟层对应IaaS层（Infrastructure as a Service）主要提供基本架构的服务，比如提供基本的计算服务、存储服务、网络服务。

计算机服务是提供用户一个计算环境，用户可以在上面开发和运行自己的应用，此环境一般是包含约定CPU、内存和基本存储空间的虚拟机环境，也可以是一台物理服务器，但是对用户是透明的。

存储资源是提供用户一个存储空间，根据用户需求不同可以提供块存储服务，文件存储服务，记录存储服务，对象存储服务。

网络服务是提供用户一个网络方案，可以让用户维护自己的计算环境和存储空间，并可以利用计算环境和存储空间对外提供服务。

（2）软件平台、能力层、应用平台组成PaaS层（Platform as a Service）软件平台层主要提供公共的平台技术，比如统一支撑操作系统，包括使用到的运行平台，对应用屏蔽了运行环境差异，应用只要关心逻辑即可；也包括统一计费、统一配置、统一报表等后台支撑，各种应用利用相应的框架进行开发后，即可做到对外统一界面、统一运维管理、统一报表展示等；也包括分布式缓存、分布式文件系统、分布式数据库等通用技术，上层应用可以根据自己的需要使用相应的API就可以使用到这些通用技术。

能力层主要提供基本业务能力，比如传统电信服务中的短信、彩信、wappush等，互联网服务中的图片、地图、天气预报等，随着IMS兴起，也提供IMS中的彩铃/彩像、IVR等能力。

（3）软件服务层对应SaaS层(Software as a Service )软件服务层主要是对用户提供具体的服务，比如SNS社区、移动U盘、企业移动IM等。

一、Google的Google App EngineGoogle App Engine是一款PaaS服务，它主要提供一个平台让用户在Google强大的基础设施上部署和运行应用程序，同时App Engine会根据应用所承受的负载来对应用所需的资源进行调整，并免去用户对应用和服务器等的维护工作，而且支持Java和Python这两种语言。

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能够针对它本身的应用获得最大的性能以及可用性效果。

Google文件系统（Google File System，GFS）是一个大型的分布式文件系统。

它为Google云计算提供海量存储，并且与Chubby、MapReduce以及Bigtable等技术结合十分紧密，处于所有核心技术的底层。

由于GFS并不是一个开源的系统，我们仅仅能从Google公布的技术文档来获得一点了解，而无法进行深入的研究。

文献[1]是Google公布的关于GFS的最为详尽的技术文档，它从GFS产生的背景、特点、系统框架、性能测试等方面进行了详细的阐述。

当前主流分布式文件系统有RedHat的GFS[3]（Global File System）、IBM的GPFS[4]、Sun的Lustre[5]等。

这些系统通常用于高性能计算或大型数据中心，对硬件设施条件要求较高。

以Lustre文件系统为例，它只对元数据管理器MDS提供容错解决方案，而对于具体的数据存储节点OST来说，则依赖其自身来解决容错的问题。

例如，Lustre推荐OST节点采用RAID技术或SAN存储区域网来容错，但由于Lustre自身不能提供数据存储的容错，一旦OST发生故障就无法恢复，因此对OST的稳定性就提出了相当高的要求，从而大大增加了存储的成本，而且成本会随着规模的扩大线性增长。

正如李开复所说的那样，创新固然重要，但有用的创新更重要。

创新的价值，取决于一项创新在新颖、有用和可行性这三个方面的综合表现。

Google GFS的新颖之处并不在于它采用了多么令人惊讶的技术，而在于它采用廉价的商用机器构建分布式文件系统，同时将GFS的设计与Google应用的特点紧密结合，并简化其实现，使之可行，最终达到创意新颖、有用、可行的完美组合。

GFS使用廉价的商用机器构建分布式文件系统，将容错的任务交由文件系统来完成，利用软件的方法解决系统可靠性问题，这样可以使得存储的成本成倍下降。

由于GFS中服务器数目众多，在GFS中服务器死机是经常发生的事情，甚至都不应当将其视为异常现象，那么如何在频繁的故障中确保数据存储的安全、保证提供不间断的数据存储服务是GFS最核心的问题。

GFS的精彩在于它采用了多种方法，从多个角度，使用不同的容错措施来确保整个系统的可靠性。

2.1.1 系统架构GFS的系统架构如图2-1[1]所示。

GFS将整个系统的节点分为三类角色：Client（客户端）、Master（主服务器）和Chunk Server（数据块服务器）。

Client是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX规范，以库文件的形式提供。

应用程序直接调用这些库函数，并与该库链接在一起。

Master是GFS的管理节点，在逻辑上只有一个，它保存系统的元数据，负责整个文件系统的管理，是GFS 文件系统中的“大脑”。

Chunk Server负责具体的存储工作。

数据以文件的形式存储在Chunk Server上，Chunk Server的个数可以有多个，它的数目直接决定了GFS的规模。

GFS将文件按照固定大小进行分块，默认是64MB，每一块称为一个Chunk（数据块），每个Chunk都有一个对应的索引号（Index）。

图2-1 GFS体系结构客户端在访问GFS时，首先访问Master节点，获取将要与之进行交互的Chunk Server信息，然后直接访问这些Chunk Server完成数据存取。

GFS的这种设计方法实现了控制流和数据流的分离。

Client与Master之间只有控制流，而无数据流，这样就极大地降低了Master的负载，使之不成为系统性能的一个瓶颈。

Client 与Chunk Server之间直接传输数据流，同时由于文件被分成多个Chunk进行分布式存储，Client可以同时访问多个Chunk Server，从而使得整个系统的I/O高度并行，系统整体性能得到提高。

相对于传统的分布式文件系统，GFS针对Google应用的特点从多个方面进行了简化，从而在一定规模下达到成本、可靠性和性能的最佳平衡。

具体来说，它具有以下几个特点。

1．采用中心服务器模式GFS采用中心服务器模式来管理整个文件系统，可以大大简化设计，从而降低实现难度。

Master管理了分布式文件系统中的所有元数据。