《前端工程师_GoogleAppEngine前端技术架构解析》由会员分享，可在线阅读，更多相关《前端工程师_GoogleAppEngine前端技术架构解析（21页珍藏版）》请在金锄头文库上搜索。
1、GoogleAppEngine前端技术架构解析今天看到几篇有关Google App Engine的技术架构文章，一起分享给大家，没看到过的同学赶紧惊喜一下吧，看到过了的同学也假装惊喜一下嘛，呵呵。全部文章有点长，请耐心看下去，相信程序员都是有耐心的，除了我.一、Google的核心技术在切入Google App Engine之前，首先会对Google的核心技术和其整体架构进行分析，以帮助大家之后更好地理解Google App Engine的实现。本篇将主要介绍Google的十个核心技术，而且可以分为四大类： 分布式基础设施：GFS、Chubby 和 Protocol Buffer。 分布式大规模
2、数据处理：MapReduce 和 Sawzall。 分布式数据库技术：BigTable 和数据库 Sharding。 数据中心优化技术：数据中心高温化、12V电池和服务器整合。分布式基础设施GFS由于搜索引擎需要处理海量的数据，所以Google的两位创始人Larry Page和Sergey Brin在创业初期设计一套名为BigFiles的文件系统，而GFS(全称为Google File System)这套分布式文件系统则是BigFiles的延续。首先，介绍它的架构，GFS主要分为两类节点： Master节点：主要存储与数据文件相关的元数据，而不是Chunk(数据块)。元数据包括一个能将64位标
3、签映射到数据块的位置及其组成文件 的表格，数据块副本位置和哪个进程正在读写特定的数据块等。还有Master节点会周期性地接收从每个Chunk节点来的更新(Heart- beat)来让元数据保持最新状态。 Chunk节点：顾名思义，肯定用来存储Chunk，数据文件通过被分割为每个默认大小为64MB的Chunk的方式存储，而且每个Chunk有唯一一个64位标签，并且每个Chunk都会在整个分布式系统被复制多次，默认为3次。下图就是GFS的架构图：图1. GFS的架构图(参片15)接着，在设计上，GFS主要有八个特点： 大文件和大数据块：数据文件的大小普遍在GB级别，而且其每个数据块默认大小为64M
4、B，这样做的好处是减少了元数据的大小，能使Master节点能够非常方便地将元数据放置在存中以提升访问效率。 操作以添加为主：因为文件很少被删减或者覆盖，通常只是进行添加或者读取操作，这样能充分考虑到硬盘线性吞吐量大和随机读写慢的特点。 支持容错：首先，虽然当时为了设计方便，采用了单Master的方案，但是整个系统会保证每个Master都会有其相对应的复制品，以便于在 Master节点出现问题时进行切换。其次，在Chunk层，GFS已经在设计上将节点失败视为常态，所以能非常好地处理Chunk节点失效的问题。 高吞吐量：虽然其单个节点的性能无论是从吞吐量还是延迟都很普通，但因为其支持上千的节点，所
5、以总的数据吞吐量是非常惊人的。 保护数据：首先，文件被分割成固定尺寸的数据块以便于保存，而且每个数据块都会被系统复制三份。 扩展能力强：因为元数据偏小，使得一个Master节点能控制上千个存数据的Chunk节点。 支持压缩：对于那些稍旧的文件，可以通过对它进行压缩，来节省硬盘空间，并且压缩率非常惊人，有时甚至接近90%。 用户空间：虽然在用户空间运行在运行效率方面稍差，但是更便于开发和测试，还有能更好利用Linux的自带的一些POSIX API。现在Google部至少运行着200多个GFS集群，最大的集群有几千台服务器，并且服务于多个Google服务，比如Google搜索。但由于 GFS主要为
6、搜索而设计，所以不是很适合新的一些Google产品，比YouTube、Gmail和更强调大规模索引和实时性的Caffeine搜索引擎 等，所以Google已经在开发下一代GFS，代号为Colossus，并且在设计方面有许多不同，比如：支持分布式Master节点来提升高可用性 并能支撑更多文件，Chunk节点能支持1MB大小的chunk以支撑低延迟应用的需要。Chubby简单的来说，Chubby 属于分布式锁服务，通过 Chubby，一个分布式系统中的上千个client都能够对于某项资源进行加锁或者解锁，常用于BigTable的协作工作，在实现方面是通过 对文件的创建操作来实现加锁，并基于著名科
7、学家Leslie Lamport的Paxos算法。Protocol BufferProtocol Buffer，是Google部使用一种语言中立、平台中立和可扩展的序列化结构化数据的方式，并提供 Java、C+ 和 Python 这三种语言的实现，每一种实现都包含了相应语言的编译器以及库文件，而且它是一种二进制的格式，所以其速度是使用 XML 进行数据交换的10倍左右。它主要用于两个方面：其一是RPC通信，它可用于分布式应用之间或者异构环境下的通信。其二是数据存储方面，因为它自描述，而 且压缩很方便，所以可用于对数据进行持久化，比如存储日志信息，并可被Map Reduce程序处理。与Proto
8、col Buffer比较类似的产品还有Facebook的 Thrift ，而且 Facebook 号称Thrift在速度上还有一定的优势。分布式大规模数据处理MapReduce首先，在Google数据中心会有大规模数据需要处理，比如被网络爬虫(Web Crawler)抓取的大量网页等。由于这些数据很多都是PB级别，导致处理工作不得不尽可能的并行化，而Google为了解决这个问题，引入了 MapReduce这个编程模型，MapReduce是源自函数式语言，主要通过Map(映射)和Reduce(化简)这两个步骤来并行处理大规 模的数据集。Map会先对由很多独立元素组成的逻辑列表中的每一个元素进行指
9、定的操作，且原始列表不会被更改，会创建多个新的列表来保存Map的处理结 果。也就意味着，Map操作是高度并行的。当Map工作完成之后，系统会先对新生成的多个列表进行清理(Shuffle)和排序，之后会这些新创建的列表 进行Reduce操作，也就是对一个列表中的元素根据Key值进行适当的合并。下图为MapReduce的运行机制：图2. MapReduce的运行机制(参19)接下来，将根据上图来举一个MapReduce的例子：比如，通过搜索Spider将海量的Web页面抓取到本地的GFS集群中，然后Index系 统将会对这个GFS集群中多个数据Chunk进行平行的Map处理，生成多个Key为URL
10、，value为html页面的键值对(Key-Value Map)，接着系统会对这些刚生成的键值对进行Shuffle(清理)，之后系统会通过Reduce操作来根据相同的key值(也就是URL)合并这些键 值对。最后，通过MapReduce这么简单的编程模型，不仅能用于处理大规模数据，而且能将很多繁琐的细节隐藏起来，比如自动并行化，负载均衡和机器宕 机处理等，这样将极简化程序员的开发工作。MapReduce可用于包括分布grep，分布排序，web访问日志分析，反向索引构建，文档聚类，机 器学习，基于统计的机器翻译，生成Google的整个搜索的索引等大规模数据处理工作。Yahoo也推出MapRedu
11、ce的开源版本Hadoop，而 且Hadoop在业界也已经被大规模使用。SawzallSawzall可以被认为是构建在MapReduce之上的采用类似Java语法的DSL(Domain-Specific Language)，也可以认为它是分布式的AWK。它主要用于对大规模分布式数据进行筛选和聚合等高级数据处理操作，在实现方面，是通过解释器将其转化 为相对应的MapReduce任务。除了Google的Sawzall之外，yahoo推出了相似的Pig语言，但其语法类似于SQL。分布式数据库技术BigTable由于在Google的数据中心存储PB级以上的非关系型数据时候，比如网页和地理数据等，为了更
12、好地存储和利用这些数据，Google开发了一套数 据库系统，名为BigTable。BigTable不是一个关系型的数据库，它也不支持关联(Join)等高级SQL操作，取而代之的是多级映射的数 据结构，并是一种面向大规模处理、容错性强的自我管理系统，拥有TB级的存和PB级的存储能力，使用结构化的文件来存储数据，并每秒可以处理数百万的读 写操作。什么是多级映射的数据结构呢?就是一个稀疏的，多维的，排序的Map，每个Cell由行关键字，列关键字和时间戳三维定位.Cell的容是一个不 解释的字符串，比如下表存储每个的容与被其他的反向连接的文本。 反向的URL .cnn.www是这行的关键字;conte
13、nts列存储网页容，每个容有一个时间戳，因为有两个反向连接，所以archor的Column Family有两列：anchor:和anchhor:my.look.ca。Column Family这个概念，使得表可以轻松地横向扩展。下面是它具体的数据模型图：图3. BigTable数据模型图(参4)在结构上，首先，BigTable基于GFS分布式文件系统和Chubby分布式锁服务。其次BigTable也分为两部分：其一是Master节 点，用来处理元数据相关的操作并支持负载均衡。其二是tablet节点，主要用于存储数据库的分片tablet，并提供相应的数据访问，同时Tablet 是基于名为SSTa
14、ble的格式，对压缩有很好的支持。图4. BigTable架构图(参15)BigTable正在为Google六十多种产品和项目提供存储和获取结构化数据的支撑平台，其中包括有Google Print、 Orkut、Google Maps、Google Earth和Blogger等，而且Google至少运行着500个BigTable集群。随着Google部服务对需求的不断提高和技术的不断地发展，导致原先的BigTable已经无法满足用户的需求，而Google也正在开发下一代BigTable，名为Spanner(扳手)，它主要有下面这些BigTable所无法支持的特性： 支持多种数据结构，比如tab
15、le，familie，group和coprocessor等。 基于分层目录和行的细粒度的复制和权限管理。 支持跨数据中心的强一致性和弱一致性控制。 基于Paxos算法的强一致性副本同步，并支持分布式事务。 提供许多自动化操作。 强大的扩展能力，能支持百万台服务器级别的集群。 用户可以自定义诸如延迟和复制次数等重要参数以适应不同的需求。数据库ShardingSharding就是分片的意思，虽然非关系型数据库比如BigTable在Google的世界中占有非常重要的地位，但是面对传统OLTP应用， 比如广告系统，Google还是采用传统的关系型数据库技术，也就是MySQL，同时由于Google所需要面对流量非常巨大，所以Google在数据库 层采用了分片(Sharding)的水平扩展(Scale Out)解决方案，分片是在传统垂直扩展(Scale Up)的分区模式上的一种提升，主要通过时间，围和面向服务等方式来将一个大型的数据库分成多片，并且这些数据片可以跨越多个数据库和服务器来实现水平 扩展。Google整套数据库分片技术主要有下面这些优点： 扩展性强：在Google生产环境中，已经有支持上千台服务器的MySQL分片集群。 吞吐量惊人：通过巨大的MySQL分片集群能满足巨量的查询请求。 全球备份：不仅在一个数据中心还是在全球的围，Google都会对MySQL的分片数据进行备份，
