知名网站的技术发展历程

谷歌目前在Alexa 上排名第一。它诞生于1997年，当时是一个研究项目。该索引每月建立一次。构建的索引通过分片（shard by doc）的方式分布到多个服务器（Index Server）。具体的网页数据也通过分片的方式分发到多个服务器（Doc Server）。当用户提交请求时，前端服务器将请求提交给Index Server获取打分的倒排索引，然后从Doc Server中提取具体的网页信息。 （如网页的标题、匹配搜索关键词的片段信息等），最后展示给用户。

随着索引北京网站制作（www.tlkjt.com）的增加，这种结构可以通过增加Index Server和Doc Server来存储索引和网页数据，但是它仍然面临着许多其他问题，所以在这之后的十几年里一时间，谷歌已经做了很多事情来改进上面的结构。

1999 年，Google 增加了一个Cache Cluster 来缓存索引结果和文档片段信息，以供Cache 查询使用。同时通过Replicate把Index Server和Doc Server变成了Clusters。这两个改造的好处是网站的响应速度、可支持的访问量、可用性（Availability）都得到了提升。这种变化导致成本增加。谷歌的硬件风格一直是不使用昂贵的高端硬件，而是在软件层面保证系统的可靠性和高性能。于是在同一年，谷歌开始使用自行设计的服务器来降低成本。 2000年，谷歌开始设计自己的数据中心，采用各种方法（比如用其他冷却方式代替空调）来优化PUE（能源利用率），同时也对其自行设计的服务器进行了大量改进。 2001年，谷歌修改了Index的格式，将Index全部放入内存。这种改造的好处是网站的响应速度和可以支持的访问量都有了很大的提升。 2003 年，Google 发表了文章Google Cluster Architecture。其Cluster结构由硬件LB+Index Cluster+Doc Cluster+大量廉价服务器（如IDE硬盘、高性价比CPU等）组成，通过并行处理+分片保证硬件减少。请求时响应速度还是很快的。同年，Google 发表了一篇关于Google 文件系统（GFS 于2000 年推出）的论文。这篇论文很大程度上体现了谷歌不使用昂贵硬件的风格，通过GFS+大量廉价服务器可以存储大量数据。 2004年，谷歌再次修改了Index的格式，使网站的响应速度不断提高。同年，Google 发表了一篇关于MapReduce 的论文。通过MapReduce+大量廉价服务器，可以快速完成以往使用昂贵的小型机、中型机甚至大型机才能完成的计算任务。这显然为谷歌快速建立索引提供了很大的帮助。帮助。 2006年，Google发表了一篇关于BigTable（2003年开始上线）的论文，使得对海量数据的分析能够满足在线系统的要求，极大地帮助Google提高了网站的响应速度。

以上三篇论文彻底改变了业界存储、分析、检索海量数据的方式（八卦：谷歌完成了GFS、MapReduce、BigTable的替换），也奠定了谷歌在业界的技术领先地位。

在某些场景下，Google 也使用MySQL 来存储数据。同样，Google对MySQL也做了很多修改，其使用的MySQL资料可以从https://code.google.com/p/google-mysql/了解到。

2007年，谷歌将建立索引的时间缩短到分钟级。当一个新的网页出现时，几分钟后就可以在谷歌上搜索到。同时Index Cluster通过Protocol Buffers为Google的各种搜索（如网页、图片、新闻、书籍等）提供服务，除了Index Cluster提供的服务外，还有很多其他的服务，比如如广告、词法检查等。谷歌搜索大概需要调用50多个内部服务，这些服务主要是用C++或Java编写的。 2009年，谷歌的一篇《How Google uses Linux》文章透露，谷歌在提高机器利用率方面也做了很多努力，比如在同一台机器上部署不同资源消耗类型的应用程序。

后来谷歌开发了Colossus（下一代类GFS文件系统）、Spanner（下一代类BigTable海量存储和计算架构）、实时搜索（基于Colossus），主要是提高实时搜索和更高效的存储。多个数据。除了在海量数据相关技术上的创新，谷歌还在业界传统技术上不断创新，比如增加TCP的初始拥塞窗口值、改进HTTP的SPDY协议、新的图片格式WebP等。

在谷歌的发展过程中，其技术的转型主要围绕可扩展性、性能、成本和可用性四个方面展开。谷歌不采用昂贵的硬件和领先的风格

其他网站的数据量决定了其技术改造基本都是对传统的软硬件技术的革新。

Facebook目前Alexa排名第2。它采用LAMP构建，随着业务的发展，它也在技术上做了很多改造。
作为改造的第一步，Facebook首先在LAMP结构中增加了Memcached，用来缓存各种数据，从而大幅度提升系统的响应时间以及可支撑的访问量，之后又增加了Services层，将News Feed、Search等较通用的功能作为Service提供给前端的PHP系统使用，前端的系统通过Thrift访问这些Service。Facebook采用了多种语言来编写各种不同的Service，主要是针对不同的场景选择合适的语言，例如C++、Java、Erlang。

大量使用Memcached以及访问量的不断上涨，导致访问Memcached的网络流量太大，交换机无法支撑，Facebook通过改造采用UDP的方式来访问Memcached，以降低单连接上的网络流量。除此之外，还有其他一些改造，具体信息可以查看http://on.fb.me/8R0C。

PHP作为脚本语言，优势是开发简单、易上手，劣势是需要消耗较多的CPU和内存。当Facebook的访问量增长到了一定规模后，这个劣势就比较突出了，于是从2007年起，Facebook就尝试多种方法来解决这个问题，最后诞生于Facebook Hackathon的HipHop产品成功地脱颖而出。

HipHop可以自动将PHP转化为C++代码，Facebook在使用HipHop后，同等配置的机器，可支撑的请求量是之前的6倍，CPU的使用率平均下降了50%，从而为Facebook节省了大量主机。将来Facebook还会对HipHop进行再次改进，通过HipHop将PHP编译为bytecode，放入HipHop VM中执行，再由HipHop VM来编译为机器代码，方式与JIT类似。

2009年，Facebook研发了BigPipe，借助此系统，Facebook成功让网站的速度提升了两倍。随着Facebook访问量的上涨，收集众多服务器上的执行日志也开始面临挑战，于是Facebook研发了Scribe来解决此问题。对于存储在MySQL中的数据，Facebook采用垂直拆分库和水平拆分表的方式来支撑不断增长的数据量。作为Facebook技术体系中重要的一环，Facebook也对MySQL进行了很多优化和改进，例如Online Schema Change等，更多信息可见http://www.facebook.com/MySQLAtFacebook。

发展之初的Facebook采用了高端的存储设备（例如NetApp、Akamai）来存图片，随着图片不断增加，成本也大幅提高，于是2009年Facebook开发了Haystack来存储图片。Haystack可采用廉价的PC Server进行存储，大幅度降低了成本。

Facebook除了使用MySQL存储数据外，近几年也开始摸索采用新的方式。在2008年Facebook开发了Cassandra，在Message Inbox Search中作为新的存储方式。不过在2010年，Facebook又放弃了Cassandra，转为采用HBase作为其Messages的存储，并在2011年将HBase应用在了Facebook更多的项目上（例如Puma、ODS）。据说，现在Facebook更是在尝试将其用户以及关系数据从MySQL迁移到HBase。
从2009年开始，Facebook尝试自行设计DataCenter以及服务器，以降低其运行成本，并对外开放了其构建的PUE仅1.07的DataCenter的相关技术。Facebook在技术方面的基本原则是：“在能用开源产品的情况下就用开源，根据情况对其进行优化并反馈给社区”。从Facebook的技术发展历程上可以看到这个原则贯彻始终，Facebook的技术改造也主要是围绕在可伸缩、性能、成本和可用性4个方面。

Twitter目前Alexa排名第8。在2006年诞生之时是采用Ruby On Rails+ MySQL构建的，2007年增加了Memcached作为Cache层，以提升响应速度。基于Ruby on Rails让Twitter享受到了快速的开发能力，但随着访问量的增长，其对CPU和内存的消耗也让Twitter痛苦不堪，于是Twitter做了不少改造和努力，例如编写了一个优化版的Ruby GC。

2008年Twitter决定逐步往Java迁移，选择了Scala作为主力的开发语言（理由是“难以向一屋子的Ruby程序员推销Java”），采用Thrift作为其主要的通信框架，开发了Finagle作为其Service Framework，可将后端各种功能暴露为Service提供给前端系统使用，使得前端系统无需关心各种不同的通信协议（例如对于使用者可以用同样的调用服务的方式去访问Memcache、Redis、Thrift服务端），开发了Kestrel作为其消息中间件（替代之前用Ruby写的Starling）。

Twitter的数据存储一直采用MySQL，发展过程中出现的小插曲是，当Facebook开源了Cassandra时，Twitter本计划使用，但最终还是放弃，仍然保持了使用MySQL，Twitter的MySQL版本已开源（https://github.com/twitter/mysql）。Twitter也是采用分库分表的方式来支撑大数据量，使用Memcached来Cache tweet，timeline的信息则迁移为用Redis来Cache。
2010年，Twitter在盐湖城拥有了第一个自建的DataCenter，主要是为了增加可控性。从Twitter的发展过程看，6年来它的技术改造主要围绕可伸缩以及可用性。

作为一家电子商务网站的员工，请允许我在此介绍这个Alexa排名21的著名电子商务网站的技术演变。
1995年，eBay诞生，当时采用CGI编写，数据库采用的是GDBM，最多只能支撑5万件在线商品。1997年，eBay将操作系统从FreeBSD迁移到Windows NT，另外将数据库从GDBM迁移为Oracle。1999年，eBay将前端系统改造为Cluster（之前只有一台主机），采用Resonate作为负载均衡，后端的Oracle机器升级为Sun E1000小型机，同年给数据库增加了一台机器作为备库，提升可用性。前端机器随着访问量不断增加还可以应付，但数据库机器在1999年11月时已经达到了瓶颈（已经不能再加CPU和内存了），于是在11月开始将数据库按业务拆分为多个库。2001-2002年，eBay将数据表进行了水平拆分，例如按类目存储商品，同时部署Oracle的小型机换为Sun A3500。2002年，将整个网站迁移为用Java构建，在这个阶段，做了DAL框架来屏蔽数据库分库分表带来的影响，同时还设计了一个开发框架以供开发人员更好地上手进行功能开发。从eBay的整个发展过程来看，技术改造主要围绕在可伸缩性和可用性两点。

腾讯目前Alexa排名第9。最初QQ IM采用的是单台接入服务器来处理用户的登录和状态保持，但在发展到一百万用户同时在线时，这台服务器已经无法支撑。于是QQ IM将所有单台服务器改造为了集群，并增加了状态同步服务器，由其完成集群内状态的同步，用户的信息存储在MySQL中，做了分库分表，好友关系存储在自行实现的文件存储中。为了提升进程间通信的效率，腾讯自行实现了用户态IPC。之后腾讯将状态同步服务器也改造为同步集群，以支撑越来越多的在线用户。在经历了前面几次改造后，已基本能支撑千万级别的用户同时在线，但可用性比较差，于是腾讯对QQ IM再次进行改造，实现了同城跨IDC的容灾，加强了监控和运维系统的建设。此后腾讯决定对QQ IM架构完全重写（大概是2009年持续到现在），主要是为了增强灵活性、支持跨城市的IDC、支撑千万级的好友。在这次大的技术改造过程中，腾讯的数据都不再存储于MySQL中，而是全部存储在了自己设计的系统里。
从QQ IM的技术演变来看，其技术改造主要是围绕在可伸缩性和可用性上。

2003年，淘宝诞生，直接购买了一个商业的phpAuction的软件，在此基础上改造产生了淘宝。2004年，将系统由PHP迁移到Java，MySQL迁移为Oracle（小型机、高端存储设备），应用服务器采用了WebLogic。2005-2007年的发展过程中，用JBoss替代了WebLogic，对数据库进行了分库，基于BDB做了分布式缓存，自行开发了分布式文件系统TFS以支持小文件的存储，并建设了自己的CDN。2007-2009年对应用系统进行垂直拆分，拆分后的系统都以Service的方式对外提供功能，对数据采用了垂直和水平拆分。
在进行了数据的垂直和水平拆分后，Oracle产生的成本越来越高，于是在之后的几年，淘宝又开始将数据逐渐从Oracle迁移到MySQL，同时开始尝试新型的数据存储方案，例如采用HBase来支撑历史交易订单的存储和检索等。近几年淘宝开始进行Linux内核、JVM、Nginx等软件的修改定制工作，同时也自行设计了低能耗服务器，同时在软硬件上进行优化，以更好地降低成本。
从淘宝的整个发展过程来看，技术改造主要围绕在可伸缩性和可用性两点，现在也开始逐渐将精力投入在了性能和成本上。目前淘宝的Alexa排名为第14。
总结
从上面这些Alexa排名靠前网站的技术发展过程来看，每家网站由于其所承担的业务不同、团队人员组成不同、做事风格相异，在技术的不同发展阶段中会采用不同的方法来支撑业务的发展，但基本都会围绕在可伸缩性、可用性、性能以及成本这4点上，在发展到比较大规模后，各网站在技术结构上有了很多的相似点，并且这些结构还将继续进行演变。
原作者林昊，就职于淘宝，2007-2010年负责设计和实现淘宝的服务框架，此服务框架在淘宝大面积使用，每天承担了150亿+的请求；2011年开始负责HBase在淘宝的落地，目前淘宝已有20个以上的在线项目在使用HBase。
其它: Cassandra
设计Cassandra存储的时候，书中建议要围绕着查询建模，而不是最先对数据进行建模。有人反对这个，认为查询的类型变化太快了。作者是这样反驳的：查询类型和数据本身都有变化的。Cassandra最根本的模型是简单的kv，所以，还是得尽可能的围绕查询建模。这里怎么更好的协调，是一个有挑战的事情。
Cassandra的column family就像一个表结构，修改了要重启，一个cf单独一个文件，一行数据可以有多个column family。user是一个family, user_ext一个family, row key 为uid, 感觉cassandra用起来会更像db，

Youtube的社交趋势经理Kevin Allocca解释最火的youtube视频的三个共同点。1、Tastemakers － 达人的推荐。 2、Community － 志气相投的群体。 3、Surprise － 意想不到的惊奇。
Cassandra在360的应用，用户收藏夹、图床、垂直搜索等在线业务有大量存储需求，考虑到MySQL不能满足需求，但是HBase有Availabilty的缺点，所以选择了Cassandra，目前规模是600~700台，年底预计1500左右，目前没有出过大的故障。估计是全球最大规模Cassandra集群

Key-Value，Column oriented，Document oriented三个概念的区别和联系谁能帮我解释清楚。看了图中的划分，我彻底糊涂了。我一直以为三者是一回事
：息队列传输：kafka，timetunnel，kestrel，scribe；列存储数据库领域hbase；kv型数据库：cassandra，riak，voldemort，tair；文档数据库：mongodb，couchdb；图形数据库：neo4j，pregel，flockdb；流式计算：storm，iprocess；实时计算：prom；图形计算：pregel，apache hama；离线计算：hive，spark。

facebook 局部kv过期用复杂的中间层解决
mysql上没有join查询，并采用昂贵的Fusion IO。nginx好于lighttpd。scribe是个好东西
本文发布于北京网站制作公司推来客http://www.tlkjt.com/

我们专注高端建站，小程序开发、软件系统定制开发、BUG修复、物联网开发、各类API接口对接开发等。十余年开发经验，每一个项目承诺做到满意为止，多一次对比，一定让您多一份收获！