服务器google服务器架构

Google服务器架构图解简析

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需要提交并且公开自己计算机系统的详细配置)不过根据文献资料可以肯定的是这45万台服务器都不是什么昂贵的服务器而是非常普通的PC级别服务器其中的服务器硬盘在两年前还普遍是IDE接口、并且采用PC级主板而非昂贵的服务器专用主板。Google的集群也全部是自己搭建的没有采用Myricom的Myrin et或者G iganet的cLAN等先进昂贵的集群连接技术Google各个数据中心和服务器间不同的耦合程度都随需而定自行连接。

那么google的存储呢Google存储着海量的资讯近千亿个网页、数百亿张图片。早在2004年 Google的存储容量就已经达到了5PB。可能很多读者一开始都认为Google采用了诸如EMC Symmetrix系列磁盘阵列来保存大量的资讯但是Google的实际做法又一次让我们大跌眼镜——Google没有使用任何磁盘阵列 哪怕是低端的磁盘阵列也没用。 Google的方法是将集群中的每一台PC级服务器配备两个普通IDE硬盘来存储。不过Google倒也不是都是什么设备都落后至少这些硬盘的转速都很高而且每台服务器的内存也还算比较大。最大的电脑DIY消费者是谁恐怕Google又登上了这个DIY宝座。Google的绝大部分服务器甚至也不是采购什么大品牌而是购买各种廉价零件而后自行装配的。有趣的是 Google非常不满意现存的各种PC电源的功耗甚至还自行设计了Google专用服务器电源。

很快我们就有了疑问。这样的一个以PC级别服务器搭建起来的系统怎么能承受巨大的工作负载呢怎么能保证高可用性呢的确这些低端的服务器经常出现故障——硬盘坏道、系统宕机这类的事故其实每天都在45万台服务器中发生。而Google的方法是设立镜像站。以Google主站为例 2003年就在美国硅谷和弗吉尼亚设立了多个镜像站。这些镜像站其实不是传统的镜像站。真正的镜像站是双机热备当一台服务器宕机时另一台服务器接管相关任务。而Google的镜像站其实真正的职责是DNS负载均衡所以有的Google镜像站本身还有自己的镜像站。这里举例说明Google镜像站的作用一个访问 DNS正常解析到A处但当A处负载过大时 DN S服务就将域名解析到B处这样既达到了冗余也缩减了投资。 由于不是双机热备某一时间镜像站的内容可能略有不同不过对于精确度要求不那么高的普通检索而言并不是问题。

平台 GFS/MapReduce/B igT able/Linux

GFS/MapRedu ce/BigTabl e/这三个平台是Googl e最引以为傲的平台全部架构在L inux之上。

首先我们来看一看GFS Google File SystemGoogle文件系统。我们知道一般的数据中心检索时候需要用到数据库系统。但是Google的情况很特殊——Google拥有全球上百亿个Web文档如果用常规数据库系统检索那么检索速度就可想而知了。因此 当Crawlers采集到许多新的Web后 Google将很多的Web都汇集到一个文件里进行存储管理而且Google将Web文件压缩成Chunk块进一步减少占用空间(64MB一个chunk)。最后Google只检索压缩后的部分。而GFS(GoogleFile System正是在这样的检索技术上构建的文件系统 GFS包括了GFS Master服务器和Chunk服务器。如下图所示系统的流程从GFS客户端开始 GFS客户端以chunk偏移量制作目录索引并且发送请求——GFS Ma ster收到请求通过chunk映射表映射反馈客户端——客户端有了chunk handle和chunk位置并将文件名和chunk的目录索引缓存 向chunk服务器发送请求——chunk服务器回复请求传输chunk数据。

如果读者您读着有点迷糊这很正常 因为只有少数搜索引擎企业才采用这样的技术。简单来说是这样 Google运用GFS大大简化了检索的难度。

除了GFSMapReduce对Google也是功不可没。 Google拥有不少于45万台服务器看起来每台服务器的职能都非常明确但是其中却有重要的协同问题有待解决如何并发计算如何分布数据如何处理失败如何负载均衡我们可以预见无数的代码将被用在协同问题上而且很可能效率低下。这时候MapReduce就派上用场了。MapReduce是Google开发的C++编程工具用于大规模数据集的并行运算。MapReduce主要功能是提供了一个简单强大的接口可以将计算自动的并发和

分布执行。这样一来就可以通过普通PC的集群实现高性能。MapReduce主要从两方面提升了系统首先是失效的计算机问题。如果某一台计算机失效了或者是I/O出现了问题——这在Google以廉价服务器组建的集群中极为常见

MapReduce的解决方法是用多个计算机同时计算一个任务一旦一台计算机有了结果其它计算机就停止该任务而进入下一任务。另外在MapReduce之间传输的数据都是经过压缩的节省了很多带宽资源。至于B igTable这是一个用来处理大数据量的系统适合处理半结构化的数据。

Google心经

Google总是尝试用最少的钱做最多的事情。不要小看那些便宜、不牢靠的PC级服务器一台服务器也许确实不牢靠但是45万台的有机集成却成为了全球最完善、最稳定的系统之一。在采购服务器方面 Google也从未一次性大量购买都是有了需求再选购。另一个能够体现Google精打细算的方面是Google尽量压缩所有能够压缩的文件。

包括软件和硬件 Google的设计构想都很前卫 Google尝试过许多还在实验室里的萌芽技术如上文所说很多都取得了巨大成功。Google早先的目标是0.5秒钟做出搜索结果但实际上目前的平均时间已经缩减到了0.25秒。而且 Google从来没有停止研究的脚步现在还在测试OpenSoalris观察O pen Soalris是否能够替代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台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取

数据集群总的读写吞吐量可以达到每秒40兆字节

目前在Google有6000个MapReduce程序而且每个月都写成百个新程序BigTable伸缩存储几十亿的URL几百千千兆的卫星图片和几亿用户的参数选择堆栈

Google形象化它们的基础组织为三层架构

1产品搜索广告 email地图视频聊天博客

2分布式系统基础组织 GFSMapReduce和BigTable

3计算平台一群不同的数据中心里的机器

4确保公司里的人们部署起来开销很小

5花费更多的钱在避免丢失日志数据的硬件上其他类型的数据则花费较少可信赖的存储机制GFS(Google File System)

1可信赖的伸缩性存储是任何程序的核心需求。 GFS就是Google的核心存储平台

2 Google File System–大型分布式结构化日志文件系统 Google在里面扔了大量的数据

3为什么构建GFS而不是利用已有的东西因为可以自己控制一切并且这个平台与别的不一样 Google需要

-跨数据中心的高可靠性

-成千上万的网络节点的伸缩性

-大读写带宽的需求

-支持大块的数据可能为上千兆字节

-高效的跨节点操作分发来减少瓶颈

4系统有Master和Chunk服务器

-M aster服务器在不同的数据文件里保持元数据。数据以64 M B为单位存储在文件系统中。客户端与Ma ster服务器交流来在文件上做元数据操作并且找到包含用户需要数据的那些Chunk服务器

-Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创建冗余来避免服务器崩溃。一旦被M ast er服务器指明客户端程序就会直接从Chunk服务器读取文件

6一个上线的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群

7关键点在于有足够的基础组织来让人们对自己的程序有所选择 GFS可以调整来适应个别程序的需求

使用Map Reduc e来处理数据

1现在你已经有了一个很好的存储系统你该怎样处理如此多的数据呢比如你有

许多TB的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大这就是MapReduce出现的原因

2MapReduce是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值对来生成一个中间的键/值对还有一个reduce方法来合并所有关联到同样的中间键的中间值。许多真实世界的任务都可以使用这种模型来表现。 以这种风格来写的程序会自动并行的在一个大量机器的集群里运行。运行时系统照顾输入数据划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这允许程序员没有多少并行和分布式系统的经验就可以很容易使用一个大型分布式系统资源

3为什么使用MapReduce

-跨越大量机器分割任务的好方式

-处理机器失败

-可以与不同类型的程序工作例如搜索和广告。几乎任何程序都有map和reduce类型的操作。你可以预先计算有用的数据、查询字数统计、对TB的数据排序等等

4MapReduce系统有三种不同类型的服务器

-Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态-Map服务器接收用户输入并在其基础上处理map操作。结果写入中间文件-Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操作

5例如你想在所有Web页面里的字数。你将存储在GFS里的所有页面抛入MapReduce。这将在成千上万台机器上同时进行并且所有的调整、工作调度、失败处理和数据传输将自动完成

-步骤类似于GFS->Map->Shuffle->Reduction->Store Results back into GFS-在MapReduce里一个map操作将一些数据映射到另一个中产生一个键值对在我们的例子里就是字和字数

-Shuffling操作聚集键类型

-Reduction操作计算所有键值对的综合并产生最终的结果

6 Google索引操作管道有大约20个不同的map和reduction。

7程序可以非常小如20到50行代码

8一个问题是掉队者。掉队者是一个比其他程序慢的计算它阻塞了其他程序。掉队者可能因为缓慢的IO或者临时的CPU不能使用而发生。解决方案是运行多个同样的计算并且当一个完成后杀死所有其他的

9数据在Map和Reduce服务器之间传输时被压缩了。这可以节省带宽和I/O。在BigT abl e里存储结构化数据

1 B igTabl e是一个大伸缩性、错误容忍、 自管理的系统它包含千千兆的内存和1000000000000000的存储。它可以每秒钟处理百万的读写

2 Big Tabl e是一个构建于G FS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询

3它提供查询机制来通过键访问结构化数据。 GFS存储存储不透明的数据而许多程序需求有结构化数据

4商业数据库不能达到这种级别的伸缩性并且不能在成千上万台机器上工作

5通过控制它们自己的低级存储系统Google得到更多的控制权来改进它们的系统。例如如果它们想让跨数据中心的操作更简单这个特性它们可以内建它

6系统运行时机器可以自由的增删而整个系统保持工作

7每个数据条目存储在一个格子里它可以通过一个行key和列key或者时间戳来访问

8每一行存储在一个或多个tablet中。一个tablet是一个64 KB块的数据序列并且格式为SSTable

9 B igTable有三种类型的服务器

-M aster服务器分配tablet服务器它跟踪tabl et在哪里并且如果需要则重新分配任务

-Tablet服务器为tab let处理读写请求。当tab let超过大小限制(通常是

100M B-200M B)时它们拆开tabl et。当一个Tablet服务器失败时则100个Tabl et服务器各自挑选一个新的tablet然后系统恢复。

-Lock服务器形成一个分布式锁服务。像打开一个tabl et来写、M aster调整和访问控制检查等都需要互斥

10一个locality组可以用来在物理上将相关的数据存储在一起来得到更好的locality选择

11 t a bl et尽可能的缓存在RAM里

硬件

1 当你有很多机器时你怎样组织它们来使得使用和花费有效

2使用非常廉价的硬件

3A 1,000-fold computer power increase can be had for a 33 times lower cost ifyou you use a failure-prone infrastructure rather than an infrastructure built onhighly reliable components.You must build reliability on top of unreliability forthis strategy to work.

4 Linux in-hou se rack design PC主板低端存储

5 Price per wattage on performance basis isn’t getting better.Have huge powerand cooling issues

6使用一些collocation和Google自己的数据中心

其他

1迅速更改而不是等待QA

2库是构建程序的卓越方式

3一些程序作为服务提供

4一个基础组织处理程序的版本这样它们可以发布而不用害怕会破坏什么东西

Google将来的方向

1支持地理位置分布的集群

2为所有数据创建一个单独的全局名字空间。 当前的数据由集群分离

3更多和更好的自动化数据迁移和计算

4解决当使用网络划分来做广阔区域的备份时的一致性问题(例如保持服务即使一个集群离线维护或由于一些损耗问题)

学到的东西

1基础组织是有竞争性的优势。特别是对Google而言。Google可以很快很廉价的推出新服务并且伸缩性其他人很难达到。许多公司采取完全不同的方式。许多公司认为基础组织开销太大。Google认为自己是一个系统工程公司这是一个新的看待软件构建的方式

2跨越多个数据中心仍然是一个未解决的问题。大部分网站都是一个或者最多两个数据中心。我们不得不承认怎样在一些数据中心之间完整的分布网站是很需要技巧的

3如果你自己没有时间从零开始重新构建所有这些基础组织你可以看看Hadoop。Hado op是这里很多同样的主意的一个开源实现

4平台的一个优点是初级开发人员可以在平台的基础上快速并且放心的创建健全的程序。如果每个项目都需要发明同样的分布式基础组织的轮子那么你将陷入困境因为知道怎样完成这项工作的人相对较少

5协同工作不一直是掷骰子。通过让系统中的所有部分一起工作则一个部分的改进将帮助所有的部分。改进文件系统则每个人从中受益而且是透明的。如果每个项目使用不同的文件系统则在整个堆栈中享受不到持续增加的改进

6构建自管理系统让你没必要让系统关机。这允许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级

7创建可进化的基础组织并行的执行消耗时间的操作并采取较好的方案

8不要忽略学院。学院有许多没有转变为产品的好主意。Most of what Google hasdone has prior art, just not prior large scale deployment.

9考虑压缩。当你有许多CPU而IO有限时压缩是一个好的选择。

G oogle主要以GFS、Map Reduce、BigTabl e这三大平台来支撑其庞大的业务系统我称他们为Google三剑客 网上也有说是Google的三架马车。

一、GFS Google File System

这是Google独特的一个面向大规模数据密集型应用的、可伸缩的分布式文件系统由于这个文件系统是通过软件调度来实现的所以Google可以把GFS部署在很多廉价的PC机上来达到用昂贵服务器一样的效果。

下面是一张Google GFS的架构图

从上图我们可看到Google的GFS主要由一个master和很多chunkserver组成m aster主要是负责维护系统中的名字空间、访问控制信息、从文件到块的映射以及块的当前位置等元素据并通过心跳信号与chunkserver通信搜集并保存chunkserver的状态信息。 chunkserver主要是用来存储数据块 g oogle把每个数据块的大小设计成64 M至于为什么这么大后面会提到每个chunk是由m aster分配的chunk-handle来标识的为了提高系统的可靠性每个chunk会被复制3个副本放到不同的chunkserver中。

当然这样的单master设计也会带来单点故障问题和性能瓶颈问题 Google是通过减少cli ent与m aster的交互来解决的client均是直接与chunks erver通信m ast er仅仅提供查询数据块所在的chunkserver以及详细位置。下面是在GFS上查询的一般流程

1、 client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引chunk index 。

2、给m ast er发送一个包含文件名和块索引的请求。

3、master回应对应的chunk handle和副本的位置多个副本 。

4、 client以文件名和块索引为键缓存这些信息。 handle和副本的位置 。

5、 Client向其中一个副本发送一个请求很可能是最近的一个副本。请求指定了chunk handlechunkserver以chunk handle标识chunk和块内的一个字节区间。

6、除非缓存的信息不再有效cache for a limited time或文件被重新打开否则以后对同一个块的读操作不再需要client和m aster间的交互。

不过我还是有疑问 google可以通过减少client与master通信来解决性能瓶颈问题但单点问题呢一台m ast er挂掉岂不是完蛋了总感觉不太放心可能是我了解不够透彻不知道哪位朋友能解释一下谢谢 

二、MapReduc e Google的分布式并行计算系统

如果上面的GFS解决了Google的海量数据的存储那这个MapReduce则是解决了如何从这些海量数据中快速计算并获取指定数据的问题。我们知道Google的每一次搜索都在零点零几秒能在这么短时间里环游世界一周这里MapReduce有很大的功劳。

Map即映射 Reduce即规约 由master服务器把map和reduce任务分发到各自worker服务器中运行计算最后把结果规约合并后返回给用户。这个过程可以由下图来说明。

按照自己的理解简单对上图加点说明