（总结）Google服务器架构图解简析
http://www.ha97.com/4128.html
[TOC]
PS：Google，无疑是互联网时代最闪亮的明星。截止到今天为止，Google美国主站在Alexa排名已经连续3年第一，Alexa Top100中，各国的Google分站竟然霸占了超过20多个名额，不得不令人感叹Google的强大。不论何时，不论何地，也不论你搜索多么冷门的词汇，只要你的电脑连接互联网，只要你轻轻点击“google搜索”，那么这一切相关内容google都会在1秒钟之内全部搞定，这甚至比你查询“我的文档”都要快捷。这也就是为什么Google创业12年，市值超过2000亿美元的原因。
有人可能认为Google拥有几台“蓝色基因”那样的超级计算机来处理各种数据和搜索，事实是怎样的呢？下面我们就将详细解析神奇Google的神奇架构。
硬件
截止到2010年，Google大约有100万台服务器，有超过500个计算机集群，处理不同地域的不同任务。可惜服务器的详细配置和最新集群的具体情况，在多个文献库里面都查询不到，我个人理解，这可能属于商业机密。大概也是因为机密的缘故，强大的Google计算机集群并没有递交Top500计算机的申请，多年来我们在Top500中都看不到Google的影子。(进入Top500需要提交并且公开自己计算机系统的详细配置)不过根据文献资料，可以肯定的是，这100万台服务器都不是什么昂贵的服务器，而是非常普通的PC级别服务器，其中的服务器硬盘在两年前还普遍是IDE接口、并且采用PC级主板而非昂贵的服务器专用主板。Google的集群也全部是自己搭建的，没有采用Myricom 的 Myrinet 或者Giganet 的 cLAN 等先进昂贵的集群连接技术，Google各个数据中心和服务器间不同的耦合程度都随需而定自行连接。
那么Google的存储呢？Google存储着海量的资讯，近千亿个网页、数百亿张图片。早在2004年，Google的存储容量就已经达到了5PB。可能很多读者一开始都认为Google采用了诸如EMC Symmetrix系列磁盘阵列来保存大量的资讯，但是Google的实际做法又一次让我们大跌眼镜——Google没有使用任何磁盘阵列，哪怕是低端的磁盘阵列也没用。Google的方法是将集群中的每一台PC级服务器，配备两个普通IDE硬盘来存储。不过Google倒也不是都是什么设备都落后，至少这些硬盘的转速都很高，而且每台服务器的内存也还算比较大。最大的电脑DIY消费者是谁？恐怕Google又登上了这个DIY宝座。Google的绝大部分服务器甚至也不是采购什么大品牌，而是购买各种廉价零件而后自行装配的。有趣的是，Google非常不满意现存的各种PC电源的功耗，甚至还自行设计了Google专用服务器电源。
很快，我们就有了疑问。这样的一个以PC级别服务器搭建起来的系统，怎么能承受巨大的工作负载呢？怎么能保证高可用性呢？的确，这些低端的服务器经常出现故障——硬盘坏道、系统宕机这类的事故其实每天都在100万台服务器中发生。而Google的方法是设立镜像站。以Google主站为例，2003年就在美国硅谷和弗吉尼亚设立了多个镜像站。这些镜像站其实不是传统的镜像站。真正的镜像站是双机热备，当一台服务器宕机时，另一台服务器接管相关任务。而Google的镜像站其实真正的职责是DNS负载均衡，所以有的Google镜像站本身还有自己的镜像站。这里举例说明Google镜像站的作用：一个访问，DNS正常解析到A处，但当A处负载过大时，DNS服务就将域名解析到B处，这样既达到了冗余，也缩减了投资。由于不是双机热备，某一时间，镜像站的内容可能略有不同，不过对于精确度要求不那么高的普通检索而言，并不是问题。
平台：GFS/MapReduce/ BigTable/Linux
GFS/MapReduce/ BigTable/这三个平台，是Google最引以为傲的平台，全部架构在Linux之上。
GFS（Google File System）
首先我们来看一看GFS（Google File System）Google文件系统。我们知道，一般的数据中心检索时候需要用到数据库系统。但是Google的情况很特殊——Google拥有全球上百亿个Web文档，如果用常规数据库系统检索，那么检索速度就可想而知了。因此，当Crawlers采集到许多新的Web后，Google将很多的Web都汇集到一个文件里进行存储管理，而且Google将Web文件压缩成Chunk块，进一步减少占用空间(64MB一个chunk)。最后，Google只检索压缩后的部分。而GFS(Google File System）正是在这样的检索技术上构建的文件系统，GFS包括了GFS Master服务器和Chunk服务器。如下图所示，系统的流程从GFS客户端开始：GFS客户端以chunk偏移量制作目录索引并且发送请求——GFS Master收到请求通过chunk映射表映射反馈客户端——客户端有了chunk handle和chunk 位置，并将文件名和chunk的目录索引缓存，向chunk服务器发送请求——chunk服务器回复请求传输chunk数据。
如果读者您读着有点迷糊，这很正常，因为只有少数搜索引擎企业才采用这样的技术。简单来说是这样：
Google运用GFS大大简化了检索的难度。
MapReduce
除了GFS，MapReduce对Google也是功不可没。Google拥有不少于100万台服务器，看起来每台服务器的职能都非常明确，但是其中却有重要的协同问题有待解决：如何并发计算，如何分布数据，如何处理失败，如何负载均衡？我们可以预见，无数的代码将被用在协同问题上，而且很可能效率低下。这时候，MapReduce就派上用场了。MapReduce是Google开发的C++编程工具，用于大规模数据集的并行运算。MapReduce主要功能是提供了一个简单强大的接口，可以将计算自动的并发和分布执行。这样一来，就可以通过普通PC的集群，实现高性能。MapReduce主要从两方面提升了系统：首先是失效的计算机问题。如果某一台计算机失效了，或者是I/O出现了问题——这在Google以廉价服务器组建的集群中极为常见，MapReduce的解决方法是用多个计算机同时计算一个任务，一旦一台计算机有了结果，其它计算机就停止该任务，而进入下一任务。另外，在MapReduce之间传输的数据都是经过压缩的，节省了很多带宽资源。
BigTable
BigTable，这是一个用来处理大数据量的系统，适合处理半结构化的数据。
Google心经：
Google总是尝试用最少的钱，做最多的事情。不要小看那些便宜、不牢靠的PC级服务器，一台服务器也许确实不牢靠，但是100万台的服务器集成却成为了全球最完善、最稳定的系统之一。在采购服务器方面，Google也从未一次性大量购买，都是有了需求再选购。另一个能够体现Google精打细算的方面是Google尽量压缩所有能够压缩的文件。
包括软件和硬件，Google的设计构想都很前卫，Google尝试过许多还在实验室里的萌芽技术，如上文所说，很多都取得了巨大成功。Google早先的目标是 0.5 秒钟做出搜索结果，但实际上目前的平均时间已经缩减到了 0.25 秒。而且，Google从来没有停止研究的脚步，现在还在测试OpenSoalris，观察OpenSoalris是否能够替代Linux。
Google的行为非常踏实。不参加Top500评选，文献里也鲜有相关资料。可见Google不吹嘘、也没有过度宣传，只是勤勤恳恳的更新程序、优化集群。今天，Google收录了绝大多数人类语言的网页，并且在多数国家都建立了Google分站，收录的网页也是与日俱增，全球影响力更是不言而喻。
向Google的架构学习，向Google的成就致敬。
Google是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的基础架构来支撑它们的产品。
平台
Linux
大量语言：Python，Java，C++
状态
- 在2006年大约有450,000台廉价服务器，这个数量到2010年增加到了1,000,000台。
- 在2005年Google索引了80亿Web页面，现在没有人知道具体数目，近千亿并不断增长中。
- 目前在Google有超过500个GFS集群。一个集群可以有1000或者甚至5000台机器。成千上万的机器从运行着100PB以上字节存储的GFS集群获取数据，集群总的读写吞吐量可以达到每秒40万亿字节
- 目前在Google有6000个MapReduce程序，而且每个月都写成百个新程序
- BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择
堆栈
Google形象化它们的基础组织为三类
产品：搜索，广告，email，地图，视频，聊天，博客
分布式系统基础组织：GFS，MapReduce和BigTable
计算平台：一群不同的数据中心里的机器
确保公司里的人们部署起来开销很小，花费更多的钱在避免丢失日志数据的硬件上，其他类型的数据则花费较少
可信赖的存储机制GFS(Google File System)
- 可信赖的伸缩性存储是任何程序的核心需求。GFS就是Google的核心存储平台
- Google File System – 大型分布式结构化日志文件系统，Google在里面扔了大量的数据
- 为什么构建GFS而不是利用已有的东西？因为可以自己控制一切并且这个平台与别的不一样，Google需要：
- 跨数据中心的高可靠性
- 成千上万的网络节点的伸缩性
- 大读写带宽的需求
- 支持大块的数据，可能为上千兆字节
- 高效的跨节点操作分发来减少瓶颈
Master和Chunk服务器
Master服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器交流来在文件上做元数据操作并且找到包含用户需要数据的那些Chunk服务器
Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创建冗余来避免服务器崩溃。一旦被Master服务器指明，客户端程序就会直接从Chunk服务器读取文件
一个上线的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群
关键点在于有足够的基础组织来让人们对自己的程序有所选择，GFS可以调整来适应个别程序的需求
使用MapReduce来处理数据
现在你已经有了一个很好的存储系统，你该怎样处理如此多的数据呢？比如你有许多TB的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大，这就是MapReduce出现的原因
MapReduce是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值对来生成一个中间的键/值对，还有一个reduce方法来合并所有关联到同样的中间键的中间值。许多真实世界的任务都可以使用这种模型来表现。以这种风格来写的程序会自动并行的在一个大量机器的集群里运行。运行时系统照顾输入数据划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这允许程序员没有多少并行和分布式系统的经验就可以很容易使用一个大型分布式系统资源
为什么使用MapReduce？
- 跨越大量机器分割任务的好方式
- 处理机器失败
- 可以与不同类型的程序工作，例如搜索和广告。几乎任何程序都有map和reduce类型的操作。你可以预先计算有用的数据、查询字数统计、对TB的数据排序等等
MapReduce系统有三种不同类型的服务器
- Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态
- Map服务器接收用户输入并在其基础上处理map操作。结果写入中间文件
- Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操作
例如，你想在所有Web页面里的字数。你将存储在GFS里的所有页面抛入MapReduce。这将在成千上万台机器上同时进行并且所有的调整、工作调度、失败处理和数据传输将自动完成
步骤类似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS
在MapReduce里一个map操作将一些数据映射到另一个中，产生一个键值对，在我们的例子里就是字和字数
Shuffling操作聚集键类型
Reduction操作计算所有键值对的综合并产生最终的结果
Google索引操作管道有大约20个不同的map和reduction。
程序可以非常小，如20到50行代码
一个问题是掉队者。掉队者是一个比其他程序慢的计算，它阻塞了其他程序。掉队者可能因为缓慢的IO或者临时的CPU不能使用而发生。解决方案是运行多个同样的计算并且当一个完成后杀死所有其他的
数据在Map和Reduce服务器之间传输时被压缩了。这可以节省带宽和I/O。
在BigTable里存储结构化数据
BigTable是一个大伸缩性、错误容忍、自管理的系统，它包含千千兆的内存和1000000000000000的存储。它可以每秒钟处理百万的读写
BigTable是一个构建于GFS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询，它提供查询机制来通过键访问结构化数据。GFS存储存储不透明的数据而许多程序需求有结构化数据，商业数据库不能达到这种级别的伸缩性并且不能在成千上万台机器上工作。
通过控制它们自己的低级存储系统Google得到更多的控制权来改进它们的系统。例如，如果它们想让跨数据中心的操作更简单这个特性，它们可以内建它，系统运行时机器可以自由的增删而整个系统保持工作。
每个数据条目存储在一个格子里，它可以通过一个行key和列key或者时间戳来访问，每一行存储在一个或多个tablet中。一个tablet是一个64KB块的数据序列并且格式为SSTable
BigTable有三种类型的服务器：
Master服务器分配tablet服务器，它跟踪tablet在哪里并且如果需要则重新分配任务
Tablet服务器为tablet处理读写请求。当tablet超过大小限制(通常是100MB-200MB)时它们拆开tablet。当一个Tablet服务器失败时，则100个Tablet服务器各自挑选一个新的tablet然后系统恢复。
Lock服务器形成一个分布式锁服务。像打开一个tablet来写、Master调整和访问控制检查等都需要互斥
一个locality组可以用来在物理上将相关的数据存储在一起来得到更好的locality选择，tablet尽可能的缓存在RAM里
硬件
当你有很多机器时你怎样组织它们来使得使用和花费有效？使用非常廉价的硬件
A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.
Linux，in-house rack design，PC主板，低端存储
Price per wattage on performance basis isn’t getting better. Have huge power and cooling issues
使用一些collocation和Google自己的数据中心
其他
迅速更改而不是等待QA
库是构建程序的卓越方式
一些程序作为服务提供
一个基础组织处理程序的版本，这样它们可以发布而不用害怕会破坏什么东西
Google将来的方向
- 支持地理位置分布的集群
- 为所有数据创建一个单独的全局名字空间。当前的数据由集群分离
- 更多和更好的自动化数据迁移和计算
- 解决当使用网络划分来做广阔区域的备份时的一致性问题(例如保持服务即使一个集群离线维护或由于一些损耗问题)
学到的东西
基础组织是有竞争性的优势。特别是对Google而言。Google可以很快很廉价的推出新服务，并且伸缩性其他人很难达到。许多公司采取完全不同的方式。许多公司认为基础组织开销太大。Google认为自己是一个系统工程公司，这是一个新的看待软件构建的方式
跨越多个数据中心仍然是一个未解决的问题。大部分网站都是一个或者最多两个数据中心。我们不得不承认怎样在一些数据中心之间完整的分布网站是很需要技巧的
如果你自己没有时间从零开始重新构建所有这些基础组织你可以看看Hadoop。Hadoop是这里很多同样的主意的一个开源实现
平台的一个优点是初级开发人员可以在平台的基础上快速并且放心的创建健全的程序。如果每个项目都需要发明同样的分布式基础组织的轮子，那么你将陷入困境，因为知道怎样完成这项工作的人相对较少
协同工作不一直是掷骰子。通过让系统中的所有部分一起工作则一个部分的改进将帮助所有的部分。改进文件系统则每个人从中受益而且是透明的。如果每个项目使用不同的文件系统则在整个堆栈中享受不到持续增加的改进
构建自管理系统让你没必要让系统关机。这允许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级
创建可进化的基础组织，并行的执行消耗时间的操作并采取较好的方案
不要忽略学院。学院有许多没有转变为产品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.
考虑压缩。当你有许多CPU而IO有限时压缩是一个好的选择。
Google 三剑客
Google主要以GFS、MapReduce、BigTable这三大平台来支撑其庞大的业务系统，我称他们为Google三剑客，网上也有说是Google的三架马车。
一、GFS（Google File System）
这是Google独特的一个面向大规模数据密集型应用的、可伸缩的分布式文件系统，由于这个文件系统是通过软件调度来实现的，所以Google可以把GFS部署在很多廉价的PC机上，来达到用昂贵服务器一样的效果。
下面是一张Google GFS的架构图：
从上图我们可看到Google的GFS主要由一个master和很多chunkserver组成，master主要是负责维护系统中的名字空间、访问控制信息、从文件到块的映射以及块的当前位置等元素据，并通过心跳信号与chunkserver通信，搜集并保存chunkserver的状态信息。chunkserver主要是用来存储数据块，google把每个数据块的大小设计成64M，至于为什么这么大后面会提到，每个chunk是由master分配的chunk-handle来标识的，为了提高系统的可靠性，每个chunk会被复制3个副本放到不同的chunkserver中。
当然这样的单master设计也会带来单点故障问题和性能瓶颈问题，Google是通过减少client与master的交互来解决的，client均是直接与chunkserver通信，master仅仅提供查询数据块所在的chunkserver以及详细位置。下面是在GFS上查询的一般流程：
1、client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引（chunk index）。
2、给master发送一个包含文件名和块索引的请求。
3、master回应对应的chunk handle和副本的位置（多个副本）。
4、client以文件名和块索引为键缓存这些信息。（handle和副本的位置）。
5、Client 向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了chunk handle（chunkserver以chunk handle标识chunk）和块内的一个字节区间。
6、除非缓存的信息不再有效（cache for a limited time）或文件被重新打开，否则以后对同一个块的读操作不再需要client和master间的交互。
不过我还是有疑问，google可以通过减少client与master通信来解决性能瓶颈问题，但单点问题呢，一台master挂掉岂不是完蛋了，总感觉不太放心，可能是我了解不够透彻，不知道哪位朋友能解释一下，谢谢：）
二、MapReduce，Google的分布式并行计算系统
如果上面的GFS解决了Google的海量数据的存储，那这个MapReduce则是解决了如何从这些海量数据中快速计算并获取指定数据的问题。我们知道，Google的每一次搜索都在零点零几秒，能在这么短时间里环游世界一周，这里MapReduce有很大的功劳。
Map即映射，Reduce即规约，由master服务器把map和reduce任务分发到各自worker服务器中运行计算，最后把结果规约合并后返回给用户。这个过程可以由下图来说明。
按照自己的理解，简单对上图加点说明：
1、首先把用户请求的数据文件切割成多份，每一份（即每一个split）被拷贝在集群中不同机器上，然后由集群启动程序中的多份拷贝。
2、master把map和reduce任务交给相对空闲的worker处理，并阻塞等待处理结果。
3、处理map任务的worker接到任务后，把以key/value形式的输入数据传递给map函数进行处理，并将处理结果也以key/value的形式输出，并保存在内存中。
4、上一步内存中的结果是要进行reduce的，于是这些map worker就把这些数据的位置返回给master，这样master知道数据位置就可以继续分配reduce任务，起到了连接map和reduce函数的作用。
5、reduce worker知道这些数据的位置后就去相应位置读取这些数据，并对这些数据按key进行排序。将排序后的数据序列放入reduce函数中进行合并和规约，最后每个reduce任务输出一个结果文件。
6、任务结束，master解除阻塞，唤醒用户。
以上是个人的一些理解，有不对的地方请指出。
三、BigTable，分布式的结构化数据存储系统？
BigTable是基于GFS和MapReduce之上的，那么google既然已经有了GFS，为何还要有BigTable呢（也是我原先的一个疑问）？后来想想这和已经有操作系统文件系统为何还要有SQL SERVER数据库一样的道理，GFS是更底层的文件系统，而BigTable建立在其上面，不仅可以存储结构化的数据，而且可以更好的管理和做出负载均衡决策。
以下是BigTable的架构图：
它完全是一个基于key/value的数据库，和一般的关系型数据库不同，google之所以采用BigTable，因为它在满足需求的同时简化了系统，比如去掉了事务、死锁检测等模块，让系统更高效。更重要的一点是在BigTable中数据是没有格式的，它仅仅是一个个key/value的pairs，用户可以自己去定义数据的格式，这也大大提高了BigTable的灵活性和扩展性。
四、总结
这篇随笔主要是一些总结性的内容，Google架构远远不止这些。
原文：Google Architecture
附：Google背后的IT架构策略揭秘
Google是与众不同的。它的独特不仅仅表现于革新的思维和充满创意的应用 (比如那个大堂里的地球模型)，更在于其有别常规的IT策略……
加利福尼亚州山景城(Mountain View)Google公司(Google，下称Google)总部有一个43号大楼，该建筑的中央大屏幕上显示着一个与Google地球(Google Earth)相仿的世界地图，一个转动的地球上不停地闪动着五颜六色的光点，恍如罗马宫廷的千万烛灯，每一次闪动标志着地球的这个角落一名Google用户发起了一次新的搜索。
这同时意味着Google又一次满足了人们对未知信息的好奇与渴望。
Google是与众不同的。它的独特不仅仅表现于革新的思维和充满创意的应用 (比如那个大堂里的地球模型)，更在于其有别常规的IT策略。从人们的常理来看，简单的硬件商品和免费软件是无法构建出一个帝国的，但是Google做到了。在性能调整后，Google把它们变成一个无可比拟的分布式计算平台，该平台能够支持大规模的搜索和不断涌现的新兴应用。我们原本认为这些应用都是个人消费级别的，但是Google改变了这一切。现在商业世界也在使用它们，这就令这家搜索公司显得那么与众不同。
GoogleWeb 服务背后的IT架构对无数使用搜索引擎的用户来说也许并不是非常重要，但它是Google几百位致力于把全球信息组织起来，实现“随处可达，随时可用”目标的工程师们的最核心工作。这就需要一个在覆盖范围和野心上都与Google的商业愿景完全相符的IT蓝图作为支撑。
Google 的经理们一直对公司的IT策略话题保持沉默，他们厌恶谈及特定的厂商或者产品，当被问到他们的服务器和数据中心时，他们总是闭口不谈。但与几位 Google的IT领导一起呆了一天后，我们最终得以揭示该公司的IT是如何运作的，那可不仅仅是一个运行在无数服务器集群上的、表面看来非常简单的搜索引擎。在其简单的外表下，蕴涵着许多内部研发软件、定制硬件、人工智能，以及对性能的执着追求和打破常规的人力管理模式。
IT理念方面，Google对同行有一条建议：尽量避免那些人人都在使用的系统和软件，以自己的方式做事会更有独特的竞争优势。
“企业文化决定了你的做事方式。”道格拉斯”美林(Douglas Merrill)，这位Google工程副总裁和事实上的首席信息官(CIO) 指出，“到了我们这样的发展阶段，企业观念和文化非常与众不同，这也反过来鞭策我们必须要采用与众不同的方式来运行那些他人看来很常规的系统。”
Google 最大的IT优势在于它能建造出既富于性价比(并非廉价)又能承受极高负载的高性能系统。因此IT顾问史蒂芬”阿诺德(Stephen Arnold)指出，Google与竞争对手，如亚马逊网站(Amazon)、电子港湾公司(eBay)、微软公司(Microsoft，下称微软)和雅虎公司 (Yahoo，下称雅虎)等公司相比，具有更大的成本优势。Google程序员的效率比其他Web公司同行们高出50%～100%，原因是Google已经开发出了一整套专用于支持大规模并行系统编程的定制软件库。据他估算，其他竞争公司可能要花上四倍的时间才能获得同等的效果。
打造服务器
Google 究竟是怎样做到这点的呢?其中一个手段，美林认为，“是因为我们自己动手打造硬件。”Google并不制造计算机系统，但它根据自己的参数定制硬件，然后像MTV的节目“靓车打造”(Pimp My Ride)那样自己安装和调整硬件系统。开源程序经理克里斯”迪博纳(Chris DiBona)评论道：“我们很善于购买商业服务器，并且改造他们为我们所用，最后把性能压榨和发挥到极致，以致有时候他们热得像要融化了似的。”
这种亲手打造的方式，来源于Google从车库诞生时与生俱来的节俭风格，更与Google那超大型的系统规模息息相关，良好的习惯一直延续至今。据说 Google在65个数据中心拥有20万～45万台服务器—这个数目会有偏差(取决于你如何定义服务器和由谁来做这项统计)。但是，不变的是持续上升的趋势。
Google不会去讨论这些资产，因为它认为保密也是一种竞争优势。事实上，Google之所以喜欢开源软件也是因为它的私密性。“如果我们购买了软件许可或代码许可，人们只要对号入座，就可以猜出Google的IT基础架构。”迪博纳分析说， “使用开源软件，就使我们多了一条把握自己命运的途径。”
Google喜欢规模化的服务器运行方式。当有成百上千台机器时，定制服务器的优势也会成倍增加，效果也会更趋明显。Google正在俄勒冈州哥伦比亚河边的达勒斯市建造一个占地30亩的数据中心，在那儿它可以获得运算和降温需要的低价水力电力能源(参见边栏《Google数据中心自有一套》)。
Google以“单元”(Cell)的形式组织这些运行 Linux操作系统的服务器，迪博纳把这种形式比喻成互联网服务的“磁盘驱动器”(但别和一直谣传的Google存储服务Gdrive混淆了，“并没有 Gdrive这回事。”一位Google女发言人明确表示。)，公司的软件程序都驻扎在这些并不昂贵的电脑机箱里，由程序员决定它们的冗余工作量。这种由很多单元组成的文件系统代替了商业存储设备;迪博纳表示Google这些单元设备更易于建造和维护，他还暗示他们能处理更大规模的数据。
Google 不会漏过对任何技术细节的关注。多年来，公司的工程师就在研究微处理器的内部工作机制，随着Google规模的持续壮大，必然会用到特别定制和调节过的芯片。知名工程师路易斯”巴罗索(Luiz Barroso)去年在一篇发表在工业杂志上的论文中证实，近年来Google的主要负荷都由单核设计的系统承担着。但许多服务器端的应用，如 Google搜索索引服务，所需的并行计算在单核芯片的指令级别上执行得并不好。
曾在数据设备公司(Digital Equipment)和康柏公司(Compaq)当过芯片设计师的巴罗索认为，随着AMD公司、英特尔公司(Intel)、太阳计算机系统公司(Sun)开始制造多核芯片，必将会出现越来越多芯片级别的并行计算。
Google 也曾考虑过自己制造计算机芯片，但从业界潮流来看，这个冒险的举动似乎不是很必要。“微处理器的设计非常复杂而且成本昂贵，”运营高级副总裁乌尔斯”霍尔茨勒(Urs Holzle)表示。Google宁愿与芯片制造商合作，让他们去理解自己的应用并设计适合的芯片。这是一种客户建议式的设计，其关注点在于总体吞吐量、效能，以及耗电比，而不是看单线程的峰值性能。霍尔茨勒表示，“这也是最近多核CPU的设计潮流与未来方向。”
裁缝般地定制软件
为了能尽量压榨硬件性能，Google开发了相当数量的定制软件。创新产品主要包括用于简化处理和创建大规模数据集的编程模型MapReduce;用于存储和管理大规模数据的系统BigTable;分析分布式运算环境中大规模数据集的解释编程语言Sawzall;用于数据密集型应用的分布式文件系统的 “Google文件系统”(Google File System);还有为处理分布式系统队列分组和任务调度的“Google工作队列”(Google Workqueue)。
正是从Sawzall这些工具里体现出Google对计算效率的执著关注。并不是每家公司都能从底层去解决效率问题，但是对Google来说，为常规关系型数据库无法容纳的大规模数据集专门设计一种编程语言是完全合理的。即使其他编程工具可以解决问题，Google的工程师们仍然会为了追求效率而另外开发一套定制方案。Google工程师认为，Sawzall能与C++中的MapReduce相媲美，而且它更容易编写一些。
Google 对效率的关注使它不可能对标准Linux内核感到满意;Google会根据自己的需要运行修改过的内核版本。通过调整Linux的底层性能，Google 工程师们在提高了整体系统可靠性的基础上，还一并解决了数据损坏和数据瓶颈等一系列棘手问题。对内核的修改也使Google的计算机集群系统因为通信效率的提高而运行得更快。
当然，Google偶尔也会出现系统故障，情况一旦发生，无数的用户就会受到影响了。三年前一次持续30分钟的系统故障使20%的搜索流量受到影响。
Google 开发了自己的网站服务器却没有使用开源的Apache服务器，尽管它在网站服务器的市场占有率超过60%。迪博纳认为，Google的网站服务器可以运行在更多数量的主机上，对Google站点上内容庞大又彼此互相依赖的应用程序来说，这种服务器的负载均衡能力远比Apache的能力更高。同时，在用标准公共网关接口(CGI)访问数据库动态网页方面，Google服务器的编程难度要比 Apache更高，但是最终运行速度却更快。“如果我们能够压榨出10%～20%的性能，我们就可以节省出更多系统资源、电量和人力了。”迪博纳在总结中指出。
Google还设计了自己的客户关系管理(CRM)系统用于支持自己基于竞价和点击的互联网广告收费业务。但对是否需要设计自己的工具，Google的态度也不是一成不变的。比如在财会软件上，它就使用了甲骨文公司(Oracle)的Financials软件。
美林拿着一只叉子举例说明现成的产品也可以带来价值。但在有些场合现成的软件产品就不一定适用了。“我们的文化在各个层面对我们的运作都有深远影响，”他表示，“所以我们不想让购买所得的工具改变我们的工作方式和文化层面。”
发表评论