本系列是基于公然资料对Google App Engine是如何使成为事实的这个话题举行深度切磋。而且在切入Google App Engine之前，首先会对Google的焦点技术和其整体架构举行阐发，以帮助大家之后更好地舆解Google App Engine的使成为事实。
本篇将主要介绍Google的十个焦点技术，而且可以分为四大类： 漫衍式基础举措措施：GFS，Chubby和Protocol Buffer。
漫衍式大规模数值处置惩罚：MapReduce和Sawzall。
漫衍式数值库技术：BigTable和数值库Sharding。
数值中心优化技术：数值中心高温化，12V电池和办事器整合。
GFS 由于搜刮引擎需要处置惩罚海量的数值，以是Google的两位首创人Larry Page和Sergey Brin在创业开始的一段时间设计一套名为“BigFiles”的文件系统，而GFS（全称为“Google File System”）这套漫衍式文件系统则是“BigFiles”的延续。
首先，介绍它的架构，GFS主要分为两类节点： Master节点：主要储存与数值文件相干的元数值，而不是Chunk（数值块）。元数值包括1个能将64位标签映射到数值块的位置及其构成文件的表格，数值块副本位置和哪1个进程项正在读写特定的数值块等。另有Master节点会周期性地接收从每个Chunk节点来的更新（”Heart-beat”）来让元数值保持最新状况。
Chunk节点：顾名思义，必定用来储存Chunk，数值文件通过被分割为每个默认巨细为64MB的Chunk的方式储存，而且每个Chunk有唯一1个64位标签，并且每个Chunk城市在整个漫衍式系统被复制屡次，默认为3次。
下图就是GFS的架构图：
图1. GFS的架构图（参片[15]）
接着，在设计上，GFS主要有八个独特之处： 大文件和大数值块：数值文件的巨细普遍在GB级别，而且其每个数值块默认巨细为64MB，如许做的利益是削减了元数值的巨细，能使Master节点可以容或很是方便地将元数值放置在内存中以提升访问效率。
操作以新增为主：因为文件很少被删减或者笼罩，通常只是举行新增或者读取操作，如许能充分思量到硬盘线性吞吐量大和RAND读写慢的独特之处。
撑持容错：首先，虽则其时为了设计方便，采用了单Master的方案，但是整个系统会包管每个Master城市有其相对于应的复制品，以便于在Master节点呈现问题时举行切换。其次，在Chunk层，GFS已经在设计上将节点败绩视为常态，以是能很是好地处置惩罚Chunk节点无效的问题。
高吞吐量：虽则其单个节点的机能无论是从吞吐量照旧推迟都很平凡，但因为其撑持上千的节点，以是总的数值吞吐量长短常惊人的。
掩护数值：首先，文件被分割成固定尺寸的数值块以便于生存，而且每个数值块城市被系统复制三份。
扩大能力强：因为元数值偏小，使得1个Master节点能节制上千个存数值的Chunk节点。
撑持压缩：对那一些稍旧的文件，可以通过对它举行压缩，来节流硬盘空间，并且压缩率很是惊人，有时候甚或接近90。
用户空间：虽则在用户空间运行在运行效率方面稍差，但是更便于研发和试验，另有能更好利用Linux的自带的一些POSIX API。
此刻Google内部至少运行着200多个GFS集群，最大的集群有几千台办事器，并且办事于多个Google办事，比如Google搜刮。但由于GFS主要为搜刮而设计，以是不是很合适新的一些Google产物，比YouTube、Gmail和更夸大大规模引得和及时性的Caffeine搜刮引擎等，以是Google已经在研发下一代GFS，代号为“Colossus”，并且在设计方面有很多差别，比如：撑持漫衍式Master节点来提升高可用性并能支撑更多文件，chunk节点能撑持1MB巨细的chunk以支撑低推迟应用的需要。
Chubby
简单的来说，Chubby属于漫衍式锁办事，通过Chubby，1个漫衍式系统中的上千个client均可以容或对某项资源举行“加锁”或者“解锁”，常用于BigTable的协作工作，在使成为事实方面是通过对文件的创立操作来使成为事实“加锁”，并基于著名科学家Leslie Lamport的Paxos算法。
Protocol Buffer
Protocol Buffer，是Google内部施用一种语言中立，平台中立和可扩大的序列化结构化数值的方式，并提供java、c 和python这三种语言的使成为事实，每一种使成为事实都包罗了响应语言的编译器和库文件，而且它是一种二进制的格式，以是其速率是施用xml举行数值交换的10倍摆布。它主要用于两个方面：其一是RPC通讯，它可用于漫衍式应用之偶尔者异构环境下的通讯。其二是数值储存方面，因为它自描写，而且压缩很方便，以是可用于对数值举行持久化，比如储存日志信息，并可被Map Reduce程序处置惩罚。与Protocol Buffer比较类似的产物另有Facebook的Thrift，而且Facebook号称Thrift在速率上另有一定的优势。
MapReduce 首先，在Google数值中心会有大规模数值需要处置惩罚，比如被网络爬虫（Web Crawler）抓取的大量网页等。由于这些个数值很多都是PB级别，导致处置惩罚工作不得不尽有可能的并行化，而Google为相识决这个问题，引入了MapReduce这个编程模子，MapReduce是源自函数式语言，主要通过"Map（映射）"和"Reduce（化简）"这两个步骤来并行处置惩罚大规模的数值集。Map会先对由很多独立元素构成的逻辑列表中的每个元素举行指定的操作，且原始列表不会被更改，会创立多个新的列表来生存Map的处置惩罚成果。也就意味着，Map操作是高度并行的。当Map工作完成之后，系统会先对新生成的多个列表举行清理（Shuffle）和排序，之后会这些个新创立的列表举行Reduce操作，也就是对1个列表中的元素按照Key值举行适当的归并。
下图为MapReduce的运行机制：
图2. MapReduce的运行机制（参[19]）
接下来，将按照上图来举1个MapReduce的例子：比如，通过搜刮Spider将海量的Web页面抓取到本地的GFS集群中，然后Index系统将会对这个GFS集群中多个数值Chunk举行平行的Map处置惩罚，生成多个Key为URL，value为html页面的键值对（Key-Value Map），接着系统会对这些个刚生成的键值对举行Shuffle（清理），之后系统融会贯通过Reduce操作来按照不异的key值（也就是URL）归并这些个键值对。
最后，通过MapReduce恁地简单的编程模子，不仅能用于处置惩罚大规模数值，而且能将很多繁琐的细节隐蔽起来，比如自动并行化，负载均衡和机器宕机处置惩罚等，如许将泼天地简化程序员的研发工作。MapReduce可用于包括“漫衍grep，漫衍排序，web访问日志阐发，反向引得构建，文档聚类，机器进修，基于统计的机器翻译，生成Google的整个搜刮的引得“等大规模数值处置惩罚工作。Yahoo也推出MapReduce的开源版本Hadoop，而且Hadoop在业界也已经被大规模施用。 Sawzall Sawzall可以被认为是构建在MapReduce之上的采用类似Java语法的DSL（Domain-Specific Language），也可以认为它是漫衍式的AWK。它主要用于对大规模漫衍式数值举行用筛子选和聚合等高级数值处置惩罚操作，在使成为事实方面，是通过诠释器将其转化为相对于应的MapReduce任务。除开Google的Sawzall以外，yahoo推出了相似的Pig语言，但其语法类似于SQL。
BigTable 由于在Google的数值中心储存PB级以上的非关系型数值时辰，比如网页和地舆数值等，为了更好地储存和利用这些个数值，Google研发了一套数值库系统，名为“BigTable”。BigTable不是1个关系型的数值库，它也不撑持联系关系（join）等高级SQL操作，取而代之的是多级映射的数值结构，并是一种面向大规模处置惩罚、容错性强的自我管理系统，领有TB级的内存和PB级的储存能力，施用结构化的文件来储存数值，并每秒可以处置惩罚数一百万的读写操作。
啥子是多级映射的数值结构呢？就是1个稀疏的，多维的，排序的Map，每个Cell由行关键字，列关键字和时间戳三维定位．Cell的内部实质意义是1个不诠释的字符串，比如下表储存每个网站的内部实质意义与被其他网站的反向毗连的文本。 反向的URL com.cnn.www是这行的关键字；contents列储存网页内部实质意义，每个内部实质意义有1个时间戳，因为有两个反向毗连，以是archor的Column Family有两列：anchor: cnnsi.com和anchhor:my.look.ca。Column Family这个概念，使得表可以轻松地横向扩大。底下是它具体的数值模子图：
图3. BigTable数值模子图（参[4]）
在结构上，首先，BigTable基于GFS漫衍式文件系统和Chubby漫衍式锁办事。其次BigTable也分为两部分：其一是Master节点，用来处置惩罚元数值相干的操作并撑持负载均衡。其二是tablet节点，主要用于储存数值库的分片tablet，并提供响应的数值访问，同时tablet是基于名为SSTable的格式，对压缩有很好的撑持。
图4. BigTable架构图（参[15]）
BigTable正在为Google六十多种产物和项目提供储存和获取结构化数值的支撑平台，其中包括有Google Print， Orkut，Google Maps，Google Earth和Blogger等，而且Google至少运行着500个BigTable集群。
跟着Google内部办事对需求的不停提高和技术的不停地成长，导致原先的BigTable已经没有办法满足用户的需求，而Google也正在研发下一代BigTable，名为“Spanner（扳手）”，它主要有个底下这些个BigTable所没有办法撑持的特性： 撑持多种数值结构，比如table，familie，group和coprocessor等。
基于分层目录和行的细粒度的复制和职权范围管理。
撑持跨数值中心的强一致性和弱一致性节制。
基于Paxos算法的强一致性副本同步，并撑持漫衍式事务。
提供很多自动化操作。
壮大的扩大能力，能撑持一百万台办事器级另外集群。
用户可以自界说诸如推迟和复制回数等重要参量以顺应差别的需求。
数值库Sharding
Sharding就是分片的意思，虽则非关系型数值库比如BigTable在Google的世界中占有很是重要的官位地方，但是面临传统OLTP应用，比如广告系统，Google照旧采用传统的关系型数值库技术，也就是MySQL，同时由于Google所需要面临流量很是伟大，以是Google在数值库层采用了分片（Sharding）的程度扩大（Scale Out）处理完成方案，分片是在传统垂直扩大（Scale Up）的分区模式上的一种提升，主要通过时间，规模和面向办事等方式来将1个大型的数值库分成多片，并且这些个数值片可以跨越多个数值库和办事器来使成为事实程度扩大。
Google整套数值库分片技术主要有个底下这些个长处： 扩大性强：在Google出产环境中，已经有撑持上千台办事器的MySQL分片集群。
吞吐量惊人：通过伟大的MySQL分片集群能满足巨量的查询哀求。
全球备份：不仅在1个数值中心照旧在全球的规模，Google城市对MySQL的分片数值举行备份，如许不仅能掩护数值，而且方便扩大。
在使成为事实方面，主要可分为两块：其一是在MySQL InnoDB基础上新增了数值库分片的技术。其二是在ORM层的Hibernate的基础上也新增了相干的分片技术，并撑持虚拟分片（Virtual Shard）来便于研发和管理。同时Google也已经将这两方面的代码提交给相干组织。 数值中心高温化
大中型数值中心的PUE（Power Usage Effectiveness）普遍在2摆布，也就是在办事器等计算设备上耗1度电，在空调等辅助设备上也要耗损一度电。对一些很是超卓的数值中心，最多也就能达到1.7，但是Google通过一些有效的设计使部分数值中心到达了业界率先的1.2，在这些个设计傍边，其中最有特色的莫过于数值中心高温化，也就是让数值中心内的计算设备运行在偏高的温度下，Google的能量物质方面的总监Erik Teetzel在谈到这点的时辰说：“平凡的数值中心在70华氏度（21摄氏度）底下工作，而我们则保举80华氏度（27摄氏度）“。但是在提高数值中心的温度方面会有两个常见的限制条件：其一是办事器设备的崩溃点，其二是精确的温度节制。如果做好这两点，数值中心就可以容或在高温下工作，因为假定数值中心的管理员能对数值中心的温度举行正负1/2度的调节，这将使办事器设备能在崩溃点5度之内工作，而不是常见的20度之内，如许既经济，又安全。另有，业界传言Intel为Google提供抗高温设计的定制芯片，但云计算界的顶级专业人士James Hamilton认为不太有可能，因为虽则处置惩罚器也很是恐惧热能，但是与内存和硬盘比拟照旧强很多，以是处置惩罚器在抗高温设计中其实不是1个焦点因素。同时他也很是撑持使数值中心高温化这个想法，而且期望将来数值中心甚或能运行在40摄氏度下，如许不仅能节流空调方面的成本，而且对环境也很有帮助。 12V电池 由于传统的UPS在资源方面比较浪费，以是Google在这方面另辟蹊径，采用了给每台办事器配1个专用的12V电池的作法来替换了常用的UPS，如果主电源系统呈现妨碍，将由该电池负责对办事器供电。虽则大型UPS可以达到92到95的效率，但是比起内置电池的99.99长短常捉襟见肘的，而且由于能 量守恒的缘故原由，导致那么未被UPS充分利用的电力会被转化成热能，这将导致用于空调的能耗响应地攀升，从而走入1个恶性循环。同时在电源方面也有类似的“神来之笔”，平凡的办事器电源会同时提供5V和12V的直流电。但是Google设计的办事器电源只输出12V直流电，须要的转换在主板上举行，虽则这类设计会使主板的成本增长1美圆到2美圆，但是它不仅能使电源能在接近其峰值容积的情况下运行，而且在铜线上传送电流时效率更高。 办事器整合
谈到虚拟化的刺客锏时，熬头个让人想到必定是办事器整合，而且普遍能使成为事实1:8的整合率来降低各方面的成本。有趣儿的是，Google在硬件方面也引入类似办事器整合的想法，它的作法是在1个机箱巨细的空间内放置两台办事器，这些个做的利益有很多，首先，减小了占地平面或物体表面的大。其次，通过让两台办事器同享诸如电源等设备，来降低设备和能量物质等方面的投入。
本篇结束，下篇将料想一下Google整体架构。
