2012中国软件开发者大会（SDCC）
http://www.csdn.net/article/a/2012-09-08/2809730
于9月8-9日在国家会议中心召开，本次大会由CSDN、《程序员》杂志、ITEye合办
Twitter高级软件工程师岳峣解读Twitter基础架构
Twitter的基础架构及迁移
Twitter的创意自始至终都非常简单，一直只是这样一个基本模型，基本上核心业务第一是时间线，第二条内容单位是推文，第三是推文所有者以及用户ID。基本来说Twitter所有核心计算都是围绕着这三类基本数据进行的。
它的计算类型，当一个用户生成一条推文的时候必须存储在一个可靠的文件里，所以这个步骤是有很高实质性要求的。每一秒钟，Twitter大概有 5000条推文生成，但可能有几十万条不同的读取请求。读一条可能要用几十条、上百条的推文，这个数据量很大，所以读通路和写通路大大不同，读通路需要写 通路配合，使得通路获得最新的信息，这个过程会提高写通路的延时。最后一类是用户不容易见到的离线通路，比如说做一个数据统计或者分析，可能会经过一些比 较复杂的计算，但是它的时时要求是最迫切的。
在存储和数据提取中有用户存储、用户交互关系存储、推文的存储。用户对推文有几个所有关系，从开始到现在没有特别大的变动。但是对上面的数据处理以 及对数据进行渲染，都是基于一个应用完成的。随着Twitter的逐步增长，Twitter将一些核心功能抽取出来，将体系从单片化转向模块化，从 Ruby转向了JVM。
模块化的利与弊
模块化有很多好处，单位开发时间缩短了，第二有了系统边界以后，一个系统服务失效发生异常不容易扩散到系统其他部分。另外在资源规划的时候，系统各个部件增长不见得同步，模块化也有些问题，以前在本机上的操作现在可以通过远程调用，网络的复杂性和不确定性、延时需要考虑。
Twitter意识到在大型系统中要知道系统是否可靠，很重要的是对系统各个部件进行有效观测，大概两年前Twitter完全从底层开始设计了系统 运营数据收集、存储、表达和系统健康状况预警，同时还支持分布式的追踪。分布式系统测往往需要一个驱动器，还有接口生成标准等等。
如何管理成品环境
成品环境在软件开发早期，人为干涉、人为管理在你有成千上万服务器的时候就完全失效了，而且对于一个快速发展的公司来说有一个问题，成品环境的管理是需要很长周期建设的，不是说今天人为管理，明天就可以精细化管理，这需要公司有远见及早进行这方面的投资。
成品管理有几个目标，第一个是可用性，然后你的硬件资源还要有效使用，当达到一定规模的时候要是自动化的。Twitter的答案是Mesos，我们 一般操作系统中由内核负责资源分配和程序的调用，Mesos就是在一个分布式系统中的新内核。Mesos首先整合资源，就是这些服务器，把它拿过来进行统 计，根据不同应用需求，任何应用只要向Mesos请求资源，Mesos都能够给予支持。
2009系统架构师大会
http://focus.it168.com/focus/201007/saccing/include/3.html
知名网站的技术发展历程
《构建高性能web站点》/gouijiangaoxingnengwebzhandian
http://baike.baidu.com/view/2721734.htm
http://item.zhigou.com/bookschina/q23862332.html
http://ishare.iask.sina.com.cn/f/8427790.html?from=isnom
http://static.ishare.down.sina.com.cn/8810742.pdf?ssig=F8eq662iNw&Expires=1350144000&KID=sina,ishare&ip=1350045290,221.226.47.&fn=%E6%9E%84%E5%BB%BA%E9%AB%98%E6%80%A7%E8%83%BDWEB%E7%AB%99%E7%82%B9.pdf
该书深入分析了常见高性能Web技术，轻松搭建高性能Web站点。涵盖了Web站点性能优化的几乎所有内容，通过通俗易懂的文字和生动有趣的配图，让读者充分并深入理解高性能架构的真相。
作者： 郭欣
ISBN： 9787121093357
页数： 402
定价： 59元
出版社： 电子工业出版社
出版时间： 2009-8-1
装帧： 平装
开本： 16开
目录
编辑推荐
作者简介
目录
展开
编辑本段编辑推荐
《构建高性能Web站点》是作者在Web系统领域多年工作、实践和探索的结晶。本书涉及Web系统优化的各个方面，从浏览器、Cache到Web、数据库和分布式文件系统等；穿插了大量的实际测试数据和很多流行开源软件的使用方法与案例；内容丰富，文字生动，对比形象。对于网络系统架构师、运维和开发人员，这是很好的参考书目；对于想了解Web性能并希望动手实践的人员，这是由浅入深的学习书籍。
——章文嵩博士，LVS作者，Linux内核作者之一
本书深入分析了常见的高性能Web技术的方法和原理，对搭建高性能Web站点具备很强的可操作性。
——张松国，腾讯网技术总监
这是一个令人兴奋的领域，这一系列准则和方法在TopN的互联网公司中都有大规模的实践和应用，作者在书中进行了详细而量化的论述。如果你正在为日益庞大的应用而手足无措，那么你唯一要做的就是拥有这本书，并且实践它。
——朱鑫，Memcache DB作者，新浪网研发中心平台部高级工程师
互联网寄托着我们的梦想，它改变了人们的生活，从社交网站到网络游戏，从搜索引擎到电子商务，成功的秘诀在于如何构建高性能Web站点。郭欣在这本书中几乎涵盖了Web性能优化的所有内容，并从多个角度进行了全面的阐述，你可以通过其通俗易懂的文字深入理解高性能站点架构的真相，并开拓视野，从而对性能瓶颈对症下药。本书可谓是高性能站点的必读精作。
——沈翔，Google Developer Advocate，加州总部
内容简介
本书围绕如何构建高性能Web站点，从多个方面、多个角度进行了全面的阐述，涵盖了Web站点性能优化的几乎所有内容，包括数据的网络传输、服务器并发处理能力、动态网页缓存、动态网页静态化、应用层数据缓存、分布式缓存、Web服务器缓存、反向代理缓存、脚本解释速度、页面组件分离、浏览器本地缓存、浏览器并发请求、文件的分发、数据库I/O优化、数据库访问、数据库分布式设计、负载均衡、分布式文件系统、性能监控等。在这些内容中充分抓住本质并结合实践，通过通俗易懂的文字和生动有趣的配图，让读者充分并深入理解高性能架构的真相。同时，本书充分应用跨学科知识和科学分析方法，通过宽泛的视野和独特的角度，将本书的内容展现得更加透彻和富有趣味。
编辑本段作者简介
郭欣，曾在腾讯网基础平台研发团队，负责诸多Web应用的开发和技术管理，并致力于性能研究和实践推广。在加入腾讯之前，获得国家系统分析师职称，目前在工作之余从事独立研究，其中包括高性能Web架构和Web敏捷开发框架，并且积极投身开源事业，同时在为Smart Developer系列进行创作。
编辑本段目录
第1章 绪论
1.1 等待的真相
1.2 瓶颈在哪里
1.3 增加带宽
1.4 减少网页中的HTTP请求
1.5 加快服务器脚本计算速度
1.6 使用动态内容缓存
1.7 使用数据缓存
1.8 将动态内容静态化
1.9 更换Web服务器软件
1.10 页面组件分离
1.11 合理部署服务器
1.12 使用负载均衡
1.13 优化数据库
1.14 考虑可扩展性
1.15 减少视觉等待
第2章 数据的网络传输
2.1 分层网络模型
2.2 带宽
2.3 响应时间
2.4 互联互通
第3章 服务器并发处理能力
3.1 吞吐率
3.2 CPU并发计算
3.3 系统调用
3.4 内存分配
3.5 持久连接
3.6 I/O模型
3.7 服务器并发策略
第4章 动态内容缓存
4.1 重复的开销
4.2 缓存与速度
4.3 页面缓存
4.4 局部无缓存
4.5 静态化内容
第5章 动态脚本加速
5.1 opcode缓存
5.2 解释器扩展模块
5.3 脚本跟踪与分析
第6章 浏览器缓存
6.1 别忘了浏览器
6.2 缓存协商
6.3 彻底消灭请求
第7章 Web服务器缓存
7.1 URL映射
7.2 缓存响应内容
7.3 缓存文件描述符
第8章 反向代理缓存
8.1 传统代理
8.2 何为反向
8.3 在反向代理上创建缓存
8.4 小心穿过代理
8.5 流量分配
第9章 Web组件分离
9.1 备受争议的分离
9.2 因材施教
9.3 拥有不同的域名
9.4 浏览器并发数
9.5 发挥各自的潜力
第10章 分布式缓存
10.1 数据库的前端缓存区
10.2 使用memcached
10.3 读操作缓存
10.4 写操作缓存
10.5 监控状态
10.6 缓存扩展
第11章 数据库性能优化
11.1 友好的状态报告
11.2 正确使用索引
11.3 锁定与等待
11.4 事务性表的性能
11.5 使用查询缓存
11.6 临时表
11.7 线程池
11.8 反范式化设计
11.9 放弃关系型数据库
第12章 Web负载均衡
12.1 一些思考
12.2 HTTP重定向
12.3 DNS负载均衡
12.4 反向代理负载均衡
12.5 IP负载均衡
12.6 直接路由
12.7 IP隧道
12.8 考虑可用性
第13章 共享文件系统
13.1 网络共享
13.2 NFS
13.3 局限性
第14章 内容分发和同步
14.1 复制
14.2 SSH
14.3 WebDAV
14.4 rsync
14.5 Hashtree
14.6 分发还是同步
14.7 反向代理
第15章 分布式文件系统
15.1 文件系统
15.2 存储节点和追踪器
15.3 MogileFS
第16章 数据库扩展
16.1 复制和分离
16.2 垂直分区
16.3 水平分区
第17章 分布式计算
17.1 异步计算
17.2 并行计算
第18章 性能监控
18.1 实时监控
18.2 监控代理
18.3 系统监控
18.4 服务监控
18.5 响应时间监控
参考文献
索引
http://code.taobao.org/
《程序员》
http://www.programmer.com.cn/category/architecture/
《程序员》杂志2011年01期，
《程序员》官网地址：http://www.programmer.com.cn/4544/ ）
架构师接龙：盛大许式伟 VS 金山张宴
http://blog.s135.com/architect_solitaire
ebay,youku,facebook等架构文档
http://yuquan-nana.iteye.com/blog/551835
taobao_arch_qcon_2009.pdf
http://dl.iteye.com/topics/download/5f6b4174-a5ca-3cf4-a27f-7e01f7b1f1e8
douban_qcon2009_beijing.pdf
http://dl.iteye.com/topics/download/8d2de6d8-d9de-3463-aef4-e36253502c11
youku_arch_qcon2009_beijing.pdf
http://dl.iteye.com/topics/download/6db9765c-196a-3af6-8306-11534a141f61
facebook_architecture.pdf
http://dl.iteye.com/topics/download/eadf1705-1419-363b-8b57-c2345d8ec03c
ebay_architecture.pdf
http://dl.iteye.com/topics/download/97a9dd28-0db8-3d49-b956-e607dc619ba3
amazon_dynamo_sosp2007.pdf
http://dl.iteye.com/topics/download/e707550c-15e3-39f1-bb15-41c601567acd
google_mapreduce.pdf
http://dl.iteye.com/topics/download/4c39c182-4328-3103-b57a-22c7d2b38659
门户级网站架构设计
1、 新浪
新浪采用了ChinaCache做的CDN系统，ChinaCache在全国分布了四十多个点，同时采用基于动态DNS分配的全球服务器负载均衡技术。
从新浪的站点结构可以看出：
> www.sina.com.cn
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: libra.sina.com.cn
Addresses: 61.135.152.71, 61.135.152.72, 61.135.152.73, 61.135.152.74 61.135.152.75, 61.135.152.76, 61.135.153.181, 61.135.153.182, 61.135.53.183, 61.135.153.184, 61.135.152.65, 61.135.152.66, 61.135.152.67, 61.135.12.68, 61.135.152.69, 61.135.152.70
Aliases: www.sina.com.cn, jupiter.sina.com.cn
在北京地区ChinaCache将www.sina.com.cn的网址解析到libra.sina.com.cn，然后 libra.sina.com.cn做了DNS负载均衡，将libra.sina.com.cn解析到61.135.152.71等16个ip上，这16 个ip分布在北京的多台前台缓存服务器上，使用squid做前台缓存。如果是在其它地区访问www.sina.com.cn可能解析到本地相应的服务器， 例如pavo.sina.com.cn，然后pavo又对应了很多做了squid的ip。这样就实现了在不同地区访问自动转到最近的服务器访问，达到加快 访问速度的效果。
我们再看一个新浪其它频道是指到哪里的：
> news.sina.com.cn
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: libra.sina.com.cn
Addresses: 61.135.152.65, 61.135.152.66, 61.135.152.67, 61.135.152.68 61.135.152.69, 61.135.152.70, 61.135.152.71, 61.135.152.72, 61.135.152.73 61.135.153.178, 61.135.153.179, 61.135.153.180, 61.135.153.181, 61.135.153.182 61.135.153.183, 61.135.153.184
Aliases: news.sina.com.cn, jupiter.sina.com.cn
可以看出，各个频道的前台缓存集群与www.sina.com.cn的前台缓存集群是相同的。
2、 搜狐
Sohu与新浪的原理差不多，下面是nslookup的结果：
> www.sohu.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: pagegrp1.sohu.com
Addresses: 61.135.132.172, 61.135.132.173, 61.135.132.176, 61.135.133.109 61.135.145.47, 61.135.150.65, 61.135.150.67, 61.135.150.69, 61.135.150.74 61.135.150.75, 61.135.150.113, 61.135.150.145, 61.135.131.73, 61.135.131.91 61.135.131.180, 61.135.131.182, 61.135.131.183, 61.135.132.65, 61.135.
132.80
Aliases: www.sohu.com
只不过libra.sina.com.cn换成了pagegrp1.sohu.com
我们再来看一下sohu的频道：
> news.sohu.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: pagegrp1.sohu.com
Addresses: 61.135.145.47, 61.135.150.65, 61.135.150.67, 61.135.150.69 61.135.150.74, 61.135.150.75, 61.135.150.113, 61.135.150.145, 61.135.131.73 61.135.131.91, 61.135.131.180, 61.135.131.182, 61.135.131.183, 61.135.132.65 61.135.132.80, 61.135.132.172, 61.135.132.173, 61.135.132.176, 61.135.133.109
Aliases: news.sohu.com
同新浪相同，用的是同样的服务器群，这可能是因为他们用的都是ChinaCache的服务吧，不过sohu的名字起的有点土，pagegrp1，没有libra，pavo好听，这名字听起来有点像法语，比较浪漫。
3、 网易
网易似乎没用ChinaCache的服务，下面是nslookup结果：
> www.163.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: www.163.com
Addresses: 202.106.168.103, 202.106.168.104, 202.106.168.109, 202.106.168.121 202.108.36.153, 202.108.36.155, 202.108.36.156, 202.108.36.167, 202.108.36.172 202.108.36.196
直接在www.163.com 这个域名上做了DNS负载均衡。这样的话就要求服务器必须放的非常靠近主节点，才能保证各地的用户访问的速度。
但163不同的频道是放在不同的缓存集群上的，这与sina，sohu有些不同，等于sina，sohu是按照地区划分服务器集群，而网易按照频道划分服务器集群。
> 163.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: 163.com
Addresses: 202.108.36.205, 202.108.36.206, 202.108.36.207, 202.108.36.201 202.108.36.202, 202.108.36.203, 202.108.36.204
显然，这和www.163.com不是一个集群，我们再来试一个：
> sports.163.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: channel.cache.163.com
Addresses: 202.108.36.136, 202.108.36.208, 202.108.36.209, 202.108.36.210 202.108.36.211, 202.108.36.212, 202.108.36.213
Aliases: sports.163.com
可以看出，和上面的集群也是不同的。
4、 百度
百度的前台服务器就不是很多了：
> www.baidu.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: www.baidu.com
Addresses: 202.108.250.249, 202.108.249.134
> baidu.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: baidu.com
Address: 202.108.250.228
> mp3.baidu.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: mp3.baidu.com
Address: 202.108.249.131
只有www.baidu.com做了两台服务器的集群，频道都用了一台服务器做前台
5、 一搜
> yisou.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: yisou.com
Addresses: 202.165.102.114, 202.43.217.14, 202.43.217.15, 202.43.217.16 202.43.217.17, 202.165.102.111, 202.165.102.112, 202.165.102.113
> www.yisou.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: www.yisou.com
Addresses: 202.43.217.17, 202.165.102.111, 202.165.102.112, 202.165.102.113 202.165.102.114, 202.43.217.14, 202.43.217.15, 202.43.217.16
> mp3.yisou.com
Server: UnKnown
Address: 192.168.1.254
Non-authoritative answer:
Name: www.yisou.com
Addresses: 202.165.102.113, 202.165.102.114, 202.43.217.14, 202.43.217.15 202.43.217.16, 202.43.217.17, 202.165.102.111, 22.165.102.112
Aliases: mp3.yisou.com
前台做了8台服务器的缓存集群，www.yisou.com和 yisou.com以及mp3.yisou.com是用的同一个集群。
通过前面的分析我们可以得到一个结论：sina和sohu使用了CDN与GSBL与DNS负载均衡技术，每个地区一组前台服务器群，网易，百度使用了DNS负载均衡技术，每个频道一组前台服务器，一搜使用了DNS负载技术，所有频道共用一组前台服务器集群。
1，站点页面分析
1-1，主页面整体分析
1-2，浏览器兼容性分析
1-3，元标记检查
1-4，下载时间检查和图片检查
1-5，链接检查
1-6，原代码设计检查
2，站点运用技术和设计分析
2-1，站点采用技术及合理性
2-2，站点艺术性、设计创意和导航性分析
3，站点交互性分析
3-1，站点查询
3-2，电子邮件组
3-3，反馈信息表单
3-4，BBS
3-5，定单表单
4，站点内容分析
4-1，站点主线、版块安排与风格
4-2，页面中标题
4-3，产品或服务价值描述
4-4，产品或服务外附加有价值信息
4-5，站点信息吸引力
4-6，站点信任度
4-7，站点内容唯一性
4-8，站点信息源
5，电子商务运行环境分析
5-1，电子商务平台的运行环境
5-2，数据库开发与支持
5-3，商务平台运行的稳定性
中文题目： LTE 与2G/ 3G 系统互操作研究 （例）
投稿日期： 2012-09-28（例） 字数： 2500 （例）
中文摘要：
为确保现有移动用户良好的业务体验感知， LTE 对不同系统间的互操作做了较为完备的规定，
但带来了现网设备复杂的升级和高昂的投入 本文通过对其他运营商和技术制式实现方法的介绍，
提出了LTE建设初期与2G/3G系统间互操作的要求（例）
中文关键字： LTE；互操作；电路域语音回退；单射频语音连续控制 （例）
中心：***部门：*** 作者（推荐人）姓名：***工号：***联系方式：***邮箱地址：***
正文：
Google （尾注） 在2003年到2004年公布了关于GFS、MapReduce和BigTable三篇技术论文，
这也成为后来云计算发展的重要基石，如今Google在后Hadoop时代的新 “三驾马车”——Caffeine、Pregel、Dremel再一次影响着全球大数据技术的发展潮流。（例）
参考文献：
尊敬的各位hadoop亲们，
大家好！根据公司的发展的需要，我们将在公司内部进行Hadoop方面技术探索的需要，现在面向部门招募一些有Hadoop经验（或者非常感兴趣）的人。主要要求如下：
1. IT技术管理中心内部员工；
2. 具有良好的java开发功底——面向Hadoop的开发，具有并行化、分布式和算法基础的；
3. 具有良好的测试功底——面向Hadoop和分布式系统的测试，数量掌握分布式测试环境的测试原理，具有Hadoop基础知识；
4. 具有良好的运维功底——面向Hadoop的后期运维，具有系统、网络、硬件的基本知识，具有Hadoop、HDFS和HBase的知识的员工；
5. 对Hadoop熟悉或者非常感兴趣，有兴趣进行探索的员工。
众所周知，IT未来的核心是云商战略，而Hadoop是google云计算理论基础的开源实现，也是目前各大互联网公司用于云计算、大数据和数据挖掘的核心技术。把握未来云计算，把握未来职场先机。
有兴趣的亲们，请在动漫广场5栋3层12072613@CNS*****.COM处报名，请写明“工号+姓名+方向”。
李*国*亮
知名网站的技术发展历程
Google 目前 Alexa 排名第1。它诞生于 1997 年，当时是一个研究性项目，每个月 build 一次索引，build 出来的索引通过 sharding（shard by doc）的方式分散到多台服务器（Index Server）上，具体的网页数据同样通过 sharding 的方式分散到多台服务器（Doc Server）上，当用户提交请求时，通过前端的一台服务器将请求提交给 Index Server 获得打了分的倒排索引，然后从 Doc Server 提取具体的网页信息（例如网页标题、搜索关键词匹配的片段信息等），最终展现给用户。
随着索引的网页增加，这个结构可通过增加 Index Server 以及 Doc Server 来存储索引以及网页的数据，但仍然会面临其他很多方面的问题，于是在这之后的十多年的时间里，Google 做了很多事情来改进上面的结构。
1999年，Google 增加了一个 Cache Cluster，用来 Cache 查询的索引结果和文档片段信息，同时将 Index Server 和 Doc Server 通过 Replicate 的方式变成了 Cluster。这两个改造带来的好处是网站的响应速度、可支撑的访问量以及可用性（Availability）得到了提升。这个变化造成了成本的增 加，Google 在硬件方面的风格始终是不用昂贵的高端硬件，而是在软件层面来保证系统的可靠性及高性能，于是同年，Google 开始采用自行设计的服务器来降低成本。2000年，Google 开始自行设计 DataCenter，采用了各种方法（例如采用其他的制冷方法来替代空调）来优化 PUE（能源利用率），同时对自行设计的服务器也做了很多化。2001年，Google 对 Index 的格式进行了修改，将所有的 Index 放入内存， 这次改造带来的好处是网站的响应速度以及可支撑的访问量得到了极大的提升。2003年，Google 发表了文章 Google Cluster Architecture，其 Cluster 结构组成为硬件 LB+Index Cluster+Doc Cluster+ 大量廉价服务器（例如 IDE 硬盘、性价比高的 CPU 等），通过并行处理 +sharding 来保证在降低对硬件要求的同时，响应速度仍然很快。同年 Google 发表了关于 Google 文件系统的论文（GFS 在 2000 年就已经上线），这篇论文很大程度也体现了 Google 不用昂贵硬件的风格，通过 GFS+ 大量廉价的服务器即可存储大量的数据。2004年，Google 再次对 Index 的格式进行了修改，使得网站的响应速度继续提升。同年 Google 发表关于 MapReduce 的论文，通过 MapReduce+ 大量廉价的服务器即可快速完成以前要使用昂贵小型机、中型机甚至是大型机才能完成的计算任务，而这显然对于 Google 快速地构建索引提供了很大的帮助。2006年，Google 发表了关于 BigTable 的论文（2003年开始上线），使得海量数据的分析能够达到在线系统的要求了，这对于 Google 提升网站的响应速度起到了很大的帮助。
以上 3 篇论文彻底改变了业界对于海量数据的存储、分析和检索的方法（小道消息：Google 内部已完成了 GFS、MapReduce、BigTable 的替换），也奠定了 Google 在业界的技术领导地位。
在一些场景中，Google 也采用 MySQL 来存储数据。同样，Google 对 MySQL 也做了很多修改，它使用的 MySQL 信息可以从 https://code.google.com/p/google-mysql/了解。
2007年，Google 将 build 索引的时间缩短到分钟级，当新网页出现后，几分钟后即可在 Google 搜索到，同时将 Index Cluster 通过 Protocol Buffers 对外提供 Service，以供 Google 各种搜索（例如网页、图片、新闻、书籍等）使用，除了 Index Cluster 提供的 Service 外，还有很多其他的 Service，例如广告、词法检查等。Google 的一次搜索大概需要调用内部 50 个以上的 Service，Service 主要用 C++ 或 Java 来编写。2009年，Google 的一篇《How Google uses Linux》文章，揭示了 Google 在提升机器利用率方面也做了很多的努力，例如将不同资源消耗类型的应用部署在同一台机器上。
在之后，Google 又研发了 Colossus（下一代类 GFS 文件系统）、Spanner（下一代类 BigTable 海量存储和计算架构）、实时搜索（基于 Colossus 实现），主要都是为了提升搜索的实时性以及存储更多数据。除了在海量数据相关技术上的革新外，Google 也不断对业界的传统技术进行创新，例如提高 TCP 的初始拥塞窗口值、改进 HTTP 的 SPDY 协议、新的图片格式 WebP 等。
在 Google 的发展过程中，其技术的改造主要围绕在可伸缩性、性能、成本和可用性 4 个方面，Google 不采用昂贵硬件的风格以及领先其他网站的数据量决定了其技术改造基本都是对传统的软硬件技术的革新。
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。
2009系统架构师大会 / System Architect Coference China 2009
http://focus.it168.com/focus/201007/saccing/include/3.html
架构师-刘国庆-13588827425 / 携程、苏*宁*易*购、杭州
分布式对象存储sdoss / weedfs / weed-fs
分布式文件系统SDFS / GlusterFS
分布式文件存储产品 / fastDFS
end
相关推荐
Imagine what a large-scale web project would look like if frontend development were not treated as an add-on, but as an equal partner with backend development and content strategy. This practical book...
Imagine what a large-scale web project would look like if frontend development were not treated as an add-on, but as an equal partner with backend development and content strategy. This practical book...
ia in a project Who does ia? ia for non Web before you start 1 3 9 19 31 37 51 53 75 85 97 113 Understanding people Learning about your users anaLysing user research communicating about ...
are associated with web services and service-oriented architecture(SOA). The testing aspect of web services in particular is one of the key topics which needs to be discussed when you work with web ...
Scalable Big Data Architecture covers real-world, concrete industry use cases that leverage complex distributed applications , which involve web applications, RESTful API, and high throughput of large...
Documentation is handled by The FreeBSD Documentation Project and includes all documents surrounding the FreeBSD project, including the web pages. There were during 2004 101 people making commits to ...
In order to achieve the objective, a real life business requirement is taken and the sample project is built step by step from requirements gathering till deployment and support. The book includes ...
Spring MVC is a modern web application framework built upon the Spring Framework, and Spring Web Flow is a project that complements Spring MVC for building reusable web controller modules that ...
Scalable Big Data Architecture covers real-world, concrete industry use cases that leverage complex distributed applications , which involve web applications, RESTful API, and high throughput of large...
Scalable Big Data Architecture covers real-world, concrete industry use cases that leverage complex distributed applications , which involve web applications, RESTful API, and high throughput of large...
Key Features Explore Raspberry Pi 2's hardware through the Assembly, C/C++, and Python programming languages Experiment with connecting electronics up to your Raspberry Pi 2 and ... Final Project
Are you a project manager who wants to know how to manage an effective web content management implementation? Are you trying to select a CMS but are confused about the promises, terminology, and ...
setting up the Beego project architecture, writing controllers, views, and filters, implementing caching backed with Redis, and monitoring and deploying the Beego application with Nginx. Chapter 9, ...
The Nokia Web Browser is built upon S60WebKit, a port of the open source WebKit project to the S60 platform. WebKit contains the WebCore ...Figure 1 explains the architecture for the Nokia Web Browser.
services available on the Web, notably on GitHub and on sites like InfoQ. In addition, the scope of this domain is big and we can only go so deep on the topics we cover. For more background on the ...
Chapter 1: Web 2.0, Python, and Frameworks 3 The Starting Line 4 What’s Web 2.0? 4 The History of Application Design for Content Creation (In One Easy Dose) 4 The Role of AJAX in Web 2.0 10 ...
the new enterprise Invoicing management system source code sharing, C#.Net ERP easyUI mvc4 project program code, B/S framework, using web easy UI development framework the website, completely open ...
the new enterprise Invoicing management system source code sharing, C#.Net ERP easyUI mvc4 project program code, B/S framework, using web easy UI development framework the website, completely open ...
Part 2: React architecture Chapter 12: The Webpack build tool Chapter 13: React routing Chapter 14: Working with data using Redux Chapter 15: Working with data using GraphQL Chapter 16: Unit testing ...
Extensive and detailed coverage of the enterprise ... Written by Deepal Jayasinghe, a key architect and developer of the Apache Axis2 Web Service project; and Afkham Azeez, an elected ASF and PMC member.