书名：撬动地球的GOOGLE
副标题：全面揭密GOOGLE快速成长之谜
作者：[美]戴维·怀斯 马克·马西德著
出版社：中信出版社
书号：ISBN7-5086-0709-0/f.1053
价格：35.00元
出版时间：2006年9月
前言：
GOOGLE在特制的计算机上运行拥有其专利的特殊软件，以支持搜索功能及其相关服务，我们称他为GOOGLEWARE。
约翰·享尼西：GOOGLE在众多可能的竞争对手面前保持不败的技术优势是，GOOGLE的技术人员能够整合公司使用的个人电脑来进行搜索，以满足用户的需要。这恐怕就是GOOGLE保守得最好的秘密。
他们操纵着世界上最庞大的计算机系统，其他任何系统都望尘莫及。
GOOGLE将个人电脑一台压着一台码在冰箱尺寸相当的支架上，然后利用其专有的软件和连线方式将这些计算机连接起来。
这些计算机先将查询的内容分解成极微小的部分，再将他们与事先与已经完成索引和归类的互联网内容的复本进行比对，进而找出相关的内容。
斯坦福大学同雅虎，ALTAVISTA和其他一些重要的搜索引擎及技术公司接洽，试图以100万美元将GOOGLE 的搜索技术出售给它们，这些公司都对拒绝了。
GOOGLE找到了赋予网络广告更高效的方法，这就是将广告信息传播到进行搜索的个体，而此时正是个体最有可能需要这些信息的时候。
在GOOGLE人们从来都不把一个项目的获得能力当做衡量其优劣的尺度。在别的公司里，经营者和产品经理一般都是先考虑什么样的服务可能赚钱，然后再开发提供这种服务的产品。而在GOOGLE，人们首要的目的是找到解决问题的方法，然后，才会考虑怎样把这些技术转化成钱。
公司工作的重中之重就是为GOOGLE用户利益的最大化服务。而这些受益的用户就成为公司最好的宣传者。
GOOGLE并不追求在最短的时间里获得最大的经济利益。
埃里克·施米特担负起了公司日常经营的重担
布林是商务谈判的好手
佩奇对成本控制有一套，在GOOGLE计算机的供电和冷却系统这些关键环节的能耗节约方面他的工作卓有成效。
在GOOGLE，技术人员更愿意以3人为小组进行工作，而县城每个人都享有20%的自由支配时间用于发展任何他感兴趣的想法。
GOOGLE拥有比任何机构都要强大的计算机处理能力，他们的数据库的规模已经远远超过了美国政府。10年内，GOOGLE就可以提供一项服务，帮助人们了解自己的遗传密码和统计学编码。
GOOGLE已经开始心着对斯坦福大学、哈佛大学、密歇根大学、牛津大学图书馆以及纽约市立图书馆藏的数百万本书籍进行数据化处理了，GOOGLE的目标是将尽可能多的书籍的信息放到网络上，使人们可以找到它们，从而打破图书馆的物理界限。
第一章：一切皆有可能
佩奇：在设定自己目标的时候，你需要一点儿傻劲儿，我们应该做大部分人不会做，或不会去做的事情。
光有灵感不够，还要付出辛勤的汗水，在开始的时候，我们从来不休假，而且繁天都加班加点，他们先是将GOOGLE介绍给朋友，然后越来越多的人开始使用它，很快斯坦福大学，我们每天就提供1万将搜索服务了。
布林：我们在同时进行很多事情。而成功的唯一途径就是要先经历失败。
佩奇：GOOGLE代表一个非常大的数字，它是1后面跟100个0，我们在为自己的发明取名字的时候，忘了它到底该怎么拼写而实际上我们拼错了，这个数学术语本来的拼写应该是“GOOGOL”，这才是正确的拼写，所幸的是，大部分人都不知道这个词其实拼错了。
佩奇：我们的竞争对手一开始是EXCITE，ALTAVISTA有以其他搜索引擎，但是它们都没有能够集中精力做搜索，所以我们没有费太大的力气就胜过了它们。现在最难的部分是我们是否可以长期地坚持下去，变成一家有10年或20年历史的公司，或者说，我们是否可以不被别的公司超越。
第三章：独特的PAGERANK技术
蒂姆·伯纳斯·李：信息饥渴的计算机用户可能点击突出显示的文本，从一个文件跳到另一个文件。网络就是链接。
佩奇和布林都生长在学术世家，非常重视发表在学术期刊上引用了诸多相关文献的学术研究成果。如果你的成果在相关科学文献中被大量引用，就说明，你的工作非常重要，因为很多人觉得它值得一提，佩奇认为这同样适用于网站
他们从来没有着重其事地坐下来，然后说，“让我们来发明下一个伟大的搜索引擎吧。”他们只是想要解决有趣的问题，又碰巧想到了一些不错的创意。
其他引擎主要依赖将搜索与名中的词语同网页上的词语进行比对来进行搜索，而PAGERANK则更进一步，将搜索结果以逻辑形式排序之后呈现给搜索用户。
1997年秋天，布林和佩奇决定给BackRub起一个新的名字。
佩奇绞尽脑汁却还是想不出一个从来没有人用过，而且容易引起人们注意的名字，所以他请同一办公室的肖恩 · 安德森来帮忙想一个。
“所以，我就走到白色书写板前面开始进行头脑风暴，写下一个又一个名字，而他不停地说‘不行，不好’。”安德森回忆说。这种情况持续了几天。“他几乎绝望了，所以我们又进行了一次头脑风暴。
我坐在白色书写板前面，提出一个又一个创意，最后我问，‘Googleplex怎么样？你们不是要建立一个通过搜索和索引巨大的数据库来使人们对信息进行组织的公司。
Googleplex是一个巨大的数字。’他很喜欢这个名字，说，‘那么，我们就用Google怎么样？’因为他喜欢短一点的。
我在我的工作站中键入G-o-o-g-l-e，不过我把这个词拼错了，而这个词还没有被注册。拉里认为这个名字可以接受，于是当天晚上我们就用这个名字注了册，并在白板上写道：Google.com。
同雅虎和亚马逊一样，这个名字很有互联网公司的气质。第二天我一进办公室就发现塔玛拉留了一个条子说：‘你们拼错了。正确的拼写是G-o-o-g-o-l。’可是，注册已经被接受了。”
表面上看，雅虎应该愿意买下他们的技术，因为它主要依靠人工编辑的地址目录来搜索网络，而缺乏快速搜索的办法。可是，它也拒绝购买Google技术或者其使用许可。在一定程度上，雅虎拒绝这个搜索引擎是因为它希望计算机用户花更多的时间在它自己的网站上。而Google搜索引擎创造出来，是为人们提供快捷的答案，使他们可以迅速到达最相关的网站的。
第四章:神奇的GOOGLE
“他们想要把这个世界数字化并且为人们所用，没有人愿意做这件事，虽然很多人知道这件事的必要性。他们并肩作战，打破一切限制，清除所有阻碍，居然凭借着一点点运气，使这项工程运转起来了。”
布林和佩奇向贝托尔斯海姆演示了Google的性能，并向他介绍了他们的想法。贝托尔斯海姆非常欣赏他们的发明，而且也理解了帮助Google提供更高明的搜索结果的技术突破。他还非常赞赏布林和佩奇的另外一些做法：他们没有花大笔的钱进行广告宣传，或是购买高端的硬件设备，而是购买主板以及其他一些便宜的零部件来组装自己的计算机。他们希望先开发出一个可以用于搜索的数据库，然后再去同风险投资公司接洽相关投资事宜。他们希望用自己的搜索引擎来说明一切。
“每次当你建立一个链接的时候，”拉里对教室里鸦雀无声的听众说道，“你就建立了一个引用。但是如果你像搜索引擎那样开始计算网络上引用的数量，你就会遇到新的问题。
网络不像科学文献，任何人都能够制作网页。”
“一种看待PageRank的方式，”他解释说，“就是把它当成一个用户模型。假设有一个随意的网络冲浪者，从某种意义上来说，它就是一只猴子，每天到处地跑，点击一个又一个链接，但这种乱点行为却不包含智力成分。你也可以说，这与人们在网络上的行为类似。”佩奇停顿了一下，听众们发出窃笑声，然后他又接着讲。
“从根本上讲，PageRank算法假设，如果有人用链接指向你，那么你就可以分得一部分属于他们的重要性。具体来说，如果一个非常重要的人指向你，这就比一个无关紧要的网站的主人指向你要有价值得多。比如，假如雅虎的主页指向你的网页，这就是件非常了不起的事。即使你只有一个在雅虎主页上的链接，这就已经很好了。要让重要的网站链接你，你要么付很多钱给别人，要么你的网页本身非常不错。而如果你在我的主页上有一个链接，估计没有人会把它当做一回事。”然后，佩奇解释了他是怎么找到产生分等级的搜索结果的配方的。“我们大体上根据那些网页的重要性，为他们赋值。一张网页的等级就由指向它的所有网页的重要性数值的总和来决定。”
第五章:10条为GOOGLE工作的理由
1998年秋天，布林和佩奇带着建立世界上最棒的搜索引擎的梦想，离开了斯坦福大学。他们把计算机、小机械和玩具搬进了门罗公园附近的一所房子的车库和几个房间里，这所房子还带有温水池。这所房子的主人，也就是他们的第一任房东，名叫苏珊 · 沃吉西基（Susan Wojcicki）。因为她读书时的室友是布林的女朋友，所以她认识了布林。布林和佩奇本来可以用1 500美元每个月的价格租下这几间房，但是他们坚持要支付1 700美元，额外的200美元用来支付各项费用和税金。他们希望从一开始就以恰当的方式来做每件事情。9月7日，
|
他们正式建立了Google公司，然后，他们在银行开了公司的第一个账户，将贝托尔斯海姆的10万美元支票转存入新账户。他们还雇用了一个朋友，也是他们在斯坦福的博士生同学克雷格 · 希尔维斯通（Craig Silverstein），作为他们的首位雇员。“就像任何一家优秀的硅谷新创公司会做的那样，我们找到了一个有富余空间的地方，然后在车库里工作。”希尔维斯通说。不过，沃吉西基有一点惊讶，她本来以为车库里那些家伙只有在她白天外出的时候才来上班。“我们想，反正他们只有白天工作的时候才会在那里，我们甚至都不会注意到他们，”沃吉西基说，“可是，他们一天24小时都在那里，一整天都在。不过后来，我们也适应了。而且，托他们的福，我们可以免费上网了。”
5个月后，沃吉西基的车库已经装不下布林和佩奇的公司了。因此，1999年初，他们搬到了帕洛阿尔托中心的大学街的几间办公室。之后，公司还先后换过几次办公地点，而每次搬迁都标志着公司文化的进一步形成和公司的发展。他们希望工作的过程引人入胜、充满乐趣，而且决心保持这样的风格。一座时尚的大学城市中心建筑的二楼是一个理想的选址，这里离斯坦福大学还不到1英里，而且比办公花园要有活力得多。他们两个都不清楚公司要通过什么样的方式来赚钱，不过，他们觉得只要自己的搜索引擎足够好，总会有一些机构想要在内部使用它的。最重要的是，他们都对帮助人们在网上更快捷地找到相关的信息这项工作抱有持久的热情，这一直是他们的首要动机。“因为对目前的搜索引擎不满意，所以我们创办了这家公司，”佩奇说，“即使我们的公司成功了，它也只是一个副产品。”
这些综合门户网站一心想要满足所有人的所有需求，最终却失去了自己的特色，无法满足任何一个特殊的或者专门的需求。而互联网的发展方向却是个性化。
第六章:GOOGLE涂鸦
GOOGLE邀请了16个人到斯坦福大学盖茨杰楼的地下室接受测试。
他们在地址栏键入www.google.com,看着主页出现在屏幕上，然后继续等待，15秒钟过去了，20秒，45秒，迈耶不明白到底发生了什么，但是并不想干涉他们，后来，她问他们到底在等待什么。他们回答说在等剩下的网页加载完毕（用户总会做出我们想象之外的行为）。
迈耶和她的团队得出结论，他们必须在网页的底部加上版权声明和页脚，倒不是为了法律原因，而是为了让用户知道：就这么多了，这就是全部，请开始搜索吧。
拉里和谢尔盖找了一位脑科医生吉姆·里斯，来强化GOOGLE的计算机网络体系。里斯毕业于哈佛和耶鲁医学院。他1999年进入GOOGLE公司，成为其18号雇员，在此之前他在斯坦福的研究室工作。里斯被任命为GOOGLE的运行主管，任务是管理公司迅速增加的计算机硬件设施。
GOOGLE没有花80万美元向IBM公司购置高端系统，而是到RACKSAVER网站去购买，在那里，他们找到了由一套88台计算机组成的，拥有同等计算机处理能力和多出几倍内存的系统，只花了25万美元。他们还使用免费的linux操作系统，而不是从微软那里购买软件。
GOOGLE的个人电脑平均服役斯是2-3年，然后就要用新的电脑替换掉。
GOOGLE的大部分计算机都放置于普通的恒温仓库中，20世纪90年代末，数据中心般是按每平方米仓库面积来收取费用，而不是按照客户公司的耗电量来计费，这使得GOOGLE将自己计算机一台压着一台码放起来。
里斯刚刚加入GOOGLE的时候，公司才拥有大约300台计算机，不过，经过疯狂的设备添置，一个月后，他们就拥有了2000台计算机，而在第一年夏天，这个数字就增加了一倍。
而系统冗余系统的建立，使得某一批计算机出故障或地震而毁于一旦的话，其他的计算机君中还储存着互联网以及其他数据的副本，可以很快填补它们的空白。
第七章：全新的GOOGLE
广告也是用户可能会需要的一种信息形式
有一家公司吸引了布林的注意，只有一个简单的原因：它通过出售同搜索结果一同出现的广告而赚钱，这家公司就是GOTO.COM公司，它后来更名为overture公司。
他们不仅仅显示愿意出最高价的卖家的广告，而是根据一个充分考虑了广告商出价和计算机用户点击广告频率的方程来为广告排序。更受欢迎的广告会爬升到最上面的位置，而比较不受欢迎的广告排位将会下滑。
一条广告出现的位置取决于顾客的拉动，而不是企业的推动。
确定你会为用户提供最具针对性的广告是一种很好的公关活动。
第八章：GOOGLE的第一桶金
当时，拉里·佩奇担任Google的首席执行官，而谢尔盖·布林任总裁。公司共有85名雇员，他们常常需要加班，而公司把他们当做家人来对待，他们可以享用免费的食物、有益健康的果汁，还有各种丰富的小零食。Google的员工还能够享受到一大堆各式各样的生活便利，比如说可以在工作场合接受洗衣服务、头发造型服务，可以看牙和看病，还能够洗车，后来，公司还增加了托儿所、配备私人教练的健身房以及一个专业的女按摩师。这些设施实际上消除了离开办公室的必要。沙滩排球、桌上足球、滚轴冰球、单轮滑板车、棕榈树、豆袋椅甚至还有狗，在Google，这些东西应有尽有。它们的作用是娱乐以及培育一种有创造性的充满乐趣的环境。Google的大部分雇员虽然都是年轻的未婚人士，但他们大部分清醒的时间都是在公司度过的。Google甚至还在公司的通勤车上安装了无线网络接口，这样Google的员工在往返于旧金山和公司的路上也可以保持旺盛的创造力，将他们的能量倾注到手提电脑上，而不必担心途中的时间无法打发。
Google采取的这些反常规的措施，使其经营理念中纳入了真诚的元素。
早年间，在Google还只有5个雇员，却有大约100万人在使用Google的时候，Google独立组装的这个计算机处理系统的威力就体现出来了。
那个时候，他们一定得确保搜索用户不知道公司的电话号码，因为他们根本就对付不了那么多电话。事实证明他们是打造品牌的高手，他们并未通过任何大规模的广告战来打造品牌，而是让用户和新闻媒体自己去评价。“他们的服务是如此出色，因此他们实现了健康自然的有机成长。”前可口可乐公司市场部主管彼得·希利（Peter Sealey）这样评价道。
“通过签署联属合约，你可以在你的网站上添加一个Google搜索框，而且每当有人在你的网站上使用Google搜索服务，我们就会支付给你3美分。”布林和佩奇宣布，“这是我们感谢你宣传Google搜索服务的方式。”
GOOGLE60%的搜索请求来自美国之外，而公司广告收入中仅有5%是来自北美洲之外的。
第九章：空降的首席执行官
尽管2000年12月，埃里克 · 施米特走进了Google公司同谢尔盖 · 布林和拉里 · 佩奇会面，他却根本就没有兴趣拜访Google。当他走进去的时候，他注意到的第一件事就是，那两个人把他的简历投影在了办公室的墙上。他曾经听说过Google是个古怪的地方，而他所看到的景象似乎证实了这个说法。“我认为那简直太奇怪了。”他说。他想尽一切办法逃避过这次会面，但是KPCB的约翰 · 多尔，也是施米特所认识的最强悍的风险投资家，总是不肯放弃说服他会见Google的那两个家伙，要求他至少同他们谈谈加入公司管理队伍的可能性
|
。施米特尊敬多尔，也非常珍视同多尔的关系。多尔给Google投资，成为该公司董事会成员，并同其建立了千丝万缕的联系，如果不是因为多尔的关系，施米特肯定会一口拒绝这次会面。2000年10月，多尔在一次为当地一位国会议员募集政治资金的集会上同他谈到此事，虽然不得不买多尔的面子应承下来，他还是想方设法拖延这次会面。
“去和Google的人谈谈。”多尔说。
“没有人真正对搜索感兴趣。”施米特回答道。
“去Google看看，”多尔又说道，“这是一块需要打磨的璞玉。”
就施米特所知，在由科技公司和顶级金融家组成的小圈子里，多尔在很长一段时间内保持不败的纪录是无人能够超越的。同多尔的关系是值得维持的关系，即使同布林和佩奇的会面最终会证明是浪费时间。施米特当时是软件制造商Novell的首席执行官，他也确实在寻求新的工作机会，因为他知道在完成了手头的合并案之后自己就得另外谋职了。不过，即使他已经做好了跳槽的准备，Google也不是这个商业管理博士会选择的公司。尽管多尔对它充满热情，但Google不过就是一个小小的搜索引擎。当时硅谷人士普遍认为搜索引擎毫无前途，包罗万象的门户网站才是首选的商业模式。施米特的信条是：只有那几个提供新闻、天气、购物和电子邮件服务的大门户网站才是用户在网络上驻留的地方。
他百思不得其解，为什么多尔对Google那么热心。也许，只是也许，他很担心自己能否收回投资，希望施米特能够充当救火队员，做一些补救工作。无论如何，埃里克 · 施米特还是心不甘情不愿地走进了会面的办公室，准备见过那两位年轻的创业者、完成对多尔的许诺之后，再回到Novell继续工作。
谢尔盖和拉里对于会见施米特同样缺乏兴趣。他不过是他们为了取悦公司的风险资本投资人莫里茨和多尔而不得不浪费时间来会见的一系列技术主管人选中最近的一个而已。布林和佩奇已经做好准备，施米特从哪里来就得回哪里去，就像其他人一样。事实是，他们还是不想让任何人在Google的地位凌驾于自己之上，而他们最不需要的就是一个管账的人。将公司式的控制强加于Google只会伤害和僵化创新，阻碍公司的进步。而且，他还会向KPCB以及红杉公司发去耸人听闻的财务报表，让这两家公司相信他们正在浪费金钱。许多来自商界的高级管理人员根本就理解不了他们所创造出来的公司文化，因为Google更像是大学校园的研究生培养项目，而不像一家以首次公开募股为前进方向的公司，而以赚钱为目的的风险投资家们最终追求的就是公开发行股票。
他们想尽一切办法来吓退多尔派来的许多候选人，而他们也都被吓得不愿意同这两个人共事了。
施米特走进的那间办公室里摆放着盛食物的餐盘，墙壁上还投射着他的背景资料。这间办公室坐落在芒廷维尤的一栋建筑内，这座建筑原来属于太阳微系统公司。施米特原来曾经担任过太阳公司的首席技术官，不过很久以前他就已经离开太阳公司到Novell公司去应付新的挑战了。而现在，几乎就从他入座之时开始，谢尔盖就开始抨击他，称施米特在Novell所采取的策略是“愚昧的表现”。“我尽力予以回击，”施米特回忆说，“我们争论了近90分钟。”他们你来我往，进行辩论，质疑对方的意见，不时进行学术争辩。当时的施米特已经为在几个月内离开Novell铺平了道路。但当他走出这间办公室的时候他最初的打算似乎初摇了，他对于自己同Google这两个家伙的对话有两个想法：这是他在相当长的一段时间内进行的最精彩的一次争论；另外，他预感自己也许最终会同Google公司建立某种形式的联系。
莫里茨觉得他们就像是青春期的孩子，只是为了挑战父母权威而拒绝他们的建议。“就算想要指导拉里和谢尔盖的人是天神，他们还是会提出问题的。”他说。
在别人看来，施米特身上的一些经历是他的弱势，但布林和佩奇却把那当做他的优势：他曾经有过失败的经历。在太阳微系统公司任职期间，他领导了Java程序的开发以对抗微软公司，Java是一种独立的程序语言。而且，施米特为太阳公司制定了互联网市场战略。尽管他的努力在很大程度上是不成功的，但是这表明施米特并不惧怕挑战比尔·盖茨和微软公司以计算机为基础的操作系统，他的挑战方式是为企业和个人用户提供选择的机会，而不是将系统强加在他们身上。要做到这一点需要相当的独立精神，这正是布林和佩奇尊敬他的地方。这还意味着施米特知道太阳公司挑战微软权威的做法错在哪里。对于Google的这两个家伙来说，施米特的优势在于，如果他们想要开发一个以互联网为基础的新软件，他们不会再犯不必要的错误，而是可以从施米特和太阳公司所犯的战略和策略失误中吸取教训。
谢尔盖和拉里打电话同他讨论具体的细节。
“你打算怎么做呢？”Google的两个家伙问施米特。
“我现在正在忙着出售公司。”施米特提醒他们。他不打算在自己正试图领导Novell完成并购程序的时候离开这家公司。
“我很高兴成为Google的董事长，”他说，“因为这个职务不需要承担日常管理的责任。至于首席执行官，则要迟些时候再说。”
“我们现在也不需要你。”拉里告诉他，“不过我们也认为将来会需要你。”
“我同意，随着公司的成长，我的经验会起作用的。”埃里克回答说。
有两个因素促成了这笔交易。首先，施米特同意出资100万美元来购买自己想要的Google股票。他在2001年初决定这样做，当时公司正缺乏资金，所以这笔钱真正具有商业意义。
另外，布林和佩奇认识到约翰 · 多尔对他们还是有影响力的。他和莫里茨为Google投入了2 500万美元，现在一年半过去了，他们有充分的理由指责拉里和谢尔盖没有履行聘用一名首席执行官的诺言。这两家风险公司现在可以要求Google返还它们最初的投资，而无论是在财务上还是声誉方面，Google都承担不了这样的后果。
施米特上任后很快发现，Google这家科技公司成立3年以来，经营它的那两位技术工作者在人力资源、产品和用户身上投入了大量的心血，但是，对于公司的内部管理事务他们却几乎没有投入任何金钱和时间。他搬进了离拉里和谢尔盖共享的办公室不远的一间9平方米大小的办公室。拉里和谢尔盖的办公室里总是挤满了人、玩具、计算机设备和其他乱七八糟的东西。“他们的办公室总是像个动物园。”施米特说。他知道自己应该做什么，不过他也明白自己必须首先说服谢尔盖和拉里相信建立企业管理体系的必要性。比如说，公司进行财务记录管理和薪金支付使用的是Quicken公司生产的现成的财务软件，而那是人们在计算自己的所得税或者经营非常小的企业时才会采用这种软件。“对于一家新创公司来说，用它没有问题，但是对于一家有200名雇员，收入2 000万美元的公司来说，这个办法行不通。”施米特说。
这是一场决定性的战役。施米特希望能够从甲骨文购买一个大型的商业和财务记账体系。这是他的工作。但是拉里和谢尔盖认为这是个坏主意，是白白浪费资金。这让埃里克觉得自己要完成最基本的任务都需颇费一番周折。“这是场硬仗。”施米特回忆说，“他们无法想象为什么要付那么多钱给甲骨文，Quicken就能用。”
布林和佩奇还是很喜欢调皮捣蛋。他们搞了一系列的恶作剧来考验施米特的勇气，破坏他的形象，挑战他的权威，让他明白自己在这里的位置。“我到那里的时候，”施米特说，“公司有许多没有记在个人名下的信用卡，拉里和谢尔盖常常把信用卡拿给别人用。我做的第一件事就是取消了拉里和谢尔盖控制的那张信用卡之外的所有的卡。他们为了表示对我的不满，将他们的卡交给别人去买东西。有一天，我的办公室里出现了一个公用电话亭。我问道，‘是谁弄来的这个电话亭？’最后追查的结果是，一个拥有他们的信用卡号码的人买的。这很有意思。又有一天，蹦出来好几张按摩椅。谁买了这些椅子？我不知道。小小的恶作剧总是不断出现。”
第十章：一举定乾坤
如果它不能出现在前30条匹配的结果中，就好像你把广告牌立在了森林中，没有人会找到它
在GOOGLE，家庭作坊式企业同福布斯500强企业拥有同等的接触数百万客户的机会
GOOGLE的广告排序参考两个因素：一家公司愿意为广告支付的价格以及计算机用户点击该广告的频率。
雅虎执行严格的资本主义原则：只要你比别人付更多的钱，你就是第一名
GOOGLE却更具有社会主义倾向，他们愿意给自己的用户一定的决定权
第十一章：GOOGLE经济
互联网与传统的媒体有许多相通的地方，而且它可以被看做向全世界的用户传达内容和广告的手段。
ASK JEEVES公司CDO伯科威茨：我希望在拆散它之前找到修理它的办法，你不能在驾驶的时候更换汽车的轮胎
2001年秋天，Ask Jeeves的眼光落在了一个名不见经传的7人小公司身上。这家公司坐落在远离硅谷的新泽西州的皮斯卡塔韦，名字叫做Teoma。（Teoma在苏格兰最古老的语言——盖尔语中的意思是“专家”，不过他的名字是个希腊人起的。）它最初是由五角大楼资助的，是由几个新泽西若歌大学的教授创办的。至少在伯科威茨和兰佐尼眼中，Teoma是“第三代搜索引擎”。在他们看来，第一代是AltaVista，第二代是Google，而第三代就是Teoma。后来Ask Jeeves把它称为Expert Rank（专家序列）。Teoma的技术中使用的数学方程和计算方法，比Google以受欢迎程度为基础的PageRank系统考虑了更多因素。事实上，谢尔盖和布林在斯坦福就读期间所写的论文中曾经引用过这个算法的概念原型。他们说这是一种可以根据搜索请求来为索引网站排序的方法。“布林和佩奇说自己的方法是根据‘广泛的受欢迎度’来为索引网站排序的，而这种办法是根据‘局部受欢迎度’来排序的，也就是说，Teoma是将网站分解成更细小的部分来检查，找出权威来源的身份。”兰佐尼说。他说布林和佩奇的结论是，局部受欢迎度难以很好地操作，因为这非常复杂，要实现实时操作就需要太多的处理资源，要不然就得耗费太长的时间来处理。
2001年9月11日一大早，他谈成了生意，以450万美元的价格买下了Teoma。后来看来，这是笔非常合算的交易，不过当时这可是比Ask Jeeves公司股票市值的1/10还高的金额。这笔交易是在恐怖袭击之前一点点达成并向外宣布的。开发出Teoma计算的希腊天才既没有表达达成协议的喜悦，也没有表达因为那场悲剧产生的绝望，而是开始了写作。“阿波斯托洛斯写了一首诗献给当时他还不认识的公司全体人员，”兰佐尼说，“然后他开始问我们要如何应对到Ask Jeeves网站来了解9 · 11事件情况的用户。其实这时候他大可以好好算算自己能拿到多少钱，置身事外。可是，他却因为对创造和发明的热情提出了上面的问题。”
2001年12月，Ask Jeeves搜索开始在Teoma技术的基础上运行了，这让伯科威茨看到了公司的未来。“这是Ask Jeeves重生的时刻，”伯科威茨说，“它定义了本公司用户的搜索体验。”
虽然伯科威茨从根本上强化了公司的品牌形象，又改进了搜索技术，但是他还是没有找到重要的生财之道。这时Google出现了。2002年春天，Ask Jeeves同另外一家公司的搜索广告合同到期了。伯科威茨感觉这是一个可以同Google进行接触的时机，他打算同Google商讨合作事宜，由Google向Ask Jeeves提供广告，然后双方分享广告点击的收入。
在一个迅速成长的市场上，同心协力培育市场比将竞争对手赶尽杀绝而造成市场缩水要明智得多。”Google还允许Ask Jeeves在谈判过程开始之前，以试用的方式测试Google的广告传送体系
事实上，这是一次双赢的合作。对于Ask Jeeves来说，这为他们带来了急需的收入。而对Google来说，这可以证明其他网站和搜索引擎同Google合作的时候不必担心自己的访问流量会被Google窃取。
Google经济为伯科威茨带来了他期待的广告和收入。Ask Jeeves渡过了难关，并从2002年第四季度开始盈利。同时，它也为Google带来了其从别的渠道无法获得的客户。这两家搜索引擎的用户重合得非常小，所以这次合作对双方都很有意义。Google还利用同Ask Jeeves的合作来促进自己的广告合作网络开发，签下了各种规模的合作网站加入Google经济来发布Google广告。
而鼎盛的Google经济也有自我强化的作用：点击Google广告的用户越多，这些网站的主人获得的收益就越高。他们获益越多，急于将Google搜索和广告技术添加到自己网站服务项目中的人就越多。而这个网络体系的规模越大，其他人挑战这一体系的困难就越大。
想要量化Google经济的威力，我们可以看看Ask Jeeves的财务业绩，因为它的大部分收入都是通过Google获得的。2002年它还是亏损的，而2003年他的收入达到了1?郾07亿美元，而2004年这个数字翻了一番还多，达到2?郾61亿美元，其中利润额高达5 000余万美元。双方的合作非常成功，因此他们后来决定将合作延长至2007年。Ask Jeeves成为了健全管理和Google经济的最大获益者。“我们期待同Google继续保持合作，在继续向我们的用户提供良好的搜索经验的同时，开发付费搜索的巨大商机。”伯科威茨说。
第十二章：每周的第五天
伯哈拉特构想的基础是一套数学方程，它能够自动地模拟有经验的报纸编辑决定新闻的内容和版式的过程。他利用群集技术，将新闻报道分成不同的类别，从国际新闻到政治、到财经、再到体育，然后观察某个特定新闻所吸引的编辑行为的多寡。然后，他开始根据这些报道的来源来决定他们的评级，给美国各大报纸和有线新闻网络的记者采写的报道更多的权重，这些大的机构包括《纽约时报》、《华盛顿邮报》，联合新闻还有路透社等。同时，兼收并蓄也很重要，所以不管一家媒体多大或多小，多么有名望或多么不为人知，伯哈拉特都想方设法将它包括进来。
考虑到新闻更新的重要性还有新闻的实时性特点，伯哈拉特的方程还为比较新的报道评定了较高的级别。“必须不停地进行处理，因为这是一个实时性的操作。”他说。为了给他的在线新闻网站创造不同的编辑风格，他还在方程中添加了相关性因素。比如说，其他条件相同的情况下，对美国的用户来讲，美国的报道比加拿大的报道要更有意义，反之亦然。伯哈拉特的项目被取名为Google新闻，当不同版本的Google新闻出现的时候，这个特点就特别有价值了。
在2001年底或2002年初的时候，他开发出了StoryRank的最初版本，这是用于生成Google搜索结果的PageRank程序的姊妹算法。不过他认识到这个方程还是不够完善，因为仅仅显示标题是不够的。因此，在其他人的帮助下，他为自己收集的新闻添加了搜索功能。实际存在的新闻总是比任何一张主页上能够显示的要多，不过新闻搜索功能就可以让用户自己用Google的方式决定突出显示哪些内容。
他们还充分考虑了用户在“折边以上”能够看到的内容的质量。这个词指的是报纸头版的上半页的内容，用在网页上，就是指用户无须翻滚网页就能够看到的内容。
“对其价值的证明经常是这样的——拉里说，‘我想要买一台新的数码相机’，然后他就把‘数码相机’输入了Froogle。或者谢尔盖说，‘我知道有一种发出绿色光束的激光指示器刚刚上市。我们来看看能不能在Froogle上找到它们。’渐渐地，问题变为，‘你能不能找到那些新的或是不起眼的产品？’也就是那些Google擅长在网络的犄角旮旯里找到的东西。这是最根本的问题，而它对拉里和谢尔盖又有什么用？”
“对一个处于萌芽状态的项目而言，被允许和被鼓励之间有着显著的差别，”贝达说道，“在Google，工程师被积极鼓励去进行“20%项目”。这不是一个你在业余时间做点什么的问题，而是积极地找时间来做事情的问题。遗憾的是，我还没有一个像样的“20%项目”，而我急需这么一个项目。如果我想不出什么好主意的话，我确定这对我的形象会有负面影响。
“在Google，人与人之间的关系非常具有活力。如果有人想到了好主意，人们最常见的态度就是为这个想法感到激动兴奋，并集思广益、广泛交换对它的意见。而权术、政治，还有争夺这个创意所有权之类的情况则很少出现。自从我到Google以来，我还没见过有谁真正提高嗓门争吵或是大打出手。”贝达说。
“20%计划”在其他公司也行得通吗？我确信会有别的公司尝试这种做法的。不过，我认为必须要认识到这种做法是与公司环境和哲学相适应的，它不是一个能够简单移植的做法。在这里我想要强调一点，以上都是我的个人观点，而不代表任何Google公司的官方态度。请不要随意得出这是公司策略之类的结论。
但是一位微软公司的技术人员有着不同意见。他宣称，Google也许并不像这家公司及其员工假装出来的那样与众不同。“为什么微软没有‘20%原则’？从我自己的角度看来，如果比尔 · 盖茨告诉我说我可以自由支配20%的时间，我会说，‘这很好，比尔。不过我已经在做我想做的事情了。’也许你会说我在微软是个异类，但是我并不这样认为。如果任何一位雇员不喜欢他待的地方，他有很多的机会换个职位。事实上，我需要花20%的时间去做那些我讨厌做的事情，比如说做成本报告或处理杂务。现在要是有人能够帮我做这些杂事，我会把这当成是我真正需要的员工福利。”
第十三章：风靡全球的GOOGLE
第十四章：gmail风波
第十五章：不作恶
为了改进我们的搜索质量，马特做了许多工作，确保你不会遇到各种让你惊讶的东西。迈耶说，有些用户不希望在进行搜索的时候看到刺激的内容，或是潜在地具有类似内容的搜索结果，马特的工作就是为这些用户清除此类内容，即使用户没有激活SAFESEARCH功能，他也会为他们清除以伪装形式出现的色情内容。
虽然GOOGLE不断地同人们不希望看到的色情内容作斗争，不过，它每年通过发布在搜索结果旁边的色情广告可获利数百万美元，GOOGLE以其他互联网搜索引擎每天收到到的处理的请求中，1/4是同色情内容有关的。
2004年初，GOOGLE对BOOBLE网站提起了诉讼。这家网站是个专门搜索色情内容的网站。GOOGLE认为它在名称，外观，标志和色彩都同GOOGLE网站相似，这会误导消费者，也侵犯了GOOGLE的商标权。而这家公司称自己为成人搜索引擎和色情网页目录的英国网站回击说，根据第一宪法修正案，他们拥有仿拟GOOGLE的权利
BOOBLE的标志将中间的两个O用一对乳房来代替。GOOGLE上有个“我感觉手气不错”的按钮，而BOOBLE为其用户提供了一个写着“我想要玩玩儿”的按钮。
第十六章：GOOGLE上市
作为私人公司的好处多得很，他们不愿意放弃这些好处。最糟糕的是，一旦上市，竞争对手微软和雅虎就会知道GOOGLE到底有多么赚钱，也会了解公司动作领域的细节。一旦这些信息曝光，竞争会更加激烈。但是联邦法律规定，一旦公司具有一定数量的资产和持股人，它就必须公布自己的财务状况。
当公司还是私有制的时候，公司的创办人和员工都勤劳而精明，可是上市之后他们都迷失了方向。在很多例子中，上市的不幸结果是，数百名员工一夜之间成了百万富翁，而之前其中有许多人甚至没有钱购买私人轿车，然后，他们就推动了干劲和专注的态度。
布林和佩奇本来非常不愿让自己的公司上市，但是即使决定要做，他们就要使这个过程尽可能地平民化。
两位创办人决定，他们将只为华尔街支付比平时通行的价格低一半多的费用，如果哪家经纪公司对此不满，他们可以选择不参与这笔交易。而且，他们还制定了详尽的计划来争夺控制权，要抵制不公平的定价过程以及丑闻缠身的华尔街的股票分配过程，同时还保留在最后一分钟根据自己的意愿取消交易的权利。说得客气一点，这两个Google来的家伙在向华尔街传递“死亡信息”。如果Google成功了，这笔交易有可能大幅削减上市费用，并削弱其他公司首次公开募股过程中的中间人的作用。
拉里和谢尔盖还拒绝任命任何人担任Google上市过程中的董事会主席。这个职务一直是空缺的。这是很不寻常的，它是拉里和谢尔盖保持控制权的另一个措施。首席执行官埃里克·施米特将担任董事会执行委员会的主席，这样，他可以履行成为上市公司后必要的礼仪和法律责任。而他们两个可以控制施米特的行为，并共同经营Google。只要他们愿意，他们以后还可以提名新的董事长。
每一家同Google接洽，讨论其处理Google的IPO事宜的华尔街公司，都必须签署严格的保密协定。当瑞士信贷第一波士顿银行（CSFB）和摩根士丹利银行被选择管理股票发售过程之后，Google要求他们在每次会议之后都签署新的保密协定。另外，Google向这些公司披露的财务和经营状况也少之又少，并且尽可能拖延它们知道具体状况的时间。Google还提醒整个华尔街，一旦它们在IPO之前或之后泄露任何情况，它们将要承担的法律责任是非常严重的，所以，投资银行家和他们的律师都抱怨说自己从来没有见过像Google那样不可理喻的人。
第十七章：一波三折的ipo进程
政府的律师翻阅《花花公子》，他们在认真阅读Google专访时，还要假装自己并没有看到跨页图片。
《花花公子》特约编辑戴维 · 谢夫（David Sheff）是实施采访的记者。他在文中写道，当他到Googleplex的时候，“布林其实正在进行娱乐活动，他在开放的草坪上玩心爱的排球游戏。他从球场走下来，进屋的时候都没有穿鞋，一边认真地考虑问题，一边不时吃几口沙拉。在整个访问过程中，他和穿着鞋的佩奇都很少坐下来。他们或是站着，靠在椅背上，或是爬到椅子上，在开着窗子的会议室里来回窜。似乎如果一个人正在从事改变世界的事业，他就根本安静不下来。”
GOOGLE为那些广告贴上了“赞助商链接”的标签，避免明确它们的特点，这个说法没有“广告”的意味，结果，更多的人点击它们。GOOGLE的广告出奇的有效，因为大部分用户并没有意识到它们是广告。
第十八章：GOOGLE版炸鸡
诚征厨师长：GOOGLE人饿了！
硅谷最热闹，增长最迅速的互联网公司正在寻找有经验，有创意的高级厨师来管理GOOGLE公司餐厅的所有食物。在这个职位上，你的责任是管理餐厅，从菜单的制定到最终的上菜。经验丰富的上选厨师在计划GOOGLE人菜单的时候要有创造力，懂得营养搭配。这里有一群见多识广，吃喝考究的人热切渴望美食大餐。
这是唯一可以得到股份的厨师职位！
谢尔盖和拉里想要为每个人提供免费的健康食品，这是个别有用心的福利。它可以使大家聚在一起，不离开自己的桌子，阻止他们养成不良的饮食习惯而影响创造力。同时节约他们出去吃午餐和计划午餐食谱所浪费的时间，而且还能够创造出一家人的氛围。
第十九章：GOOGLE最重要的计划
2004年秋天，在飞往西班牙的路上，谢尔盖和拉里得到一个坏消息，雅虎战胜了GOOGLE，赢得了美国在线欧洲互联网服务的所有广告业务，布林非常想拿到美国在线的欧洲业务，他下决心一定要试一试自己是否可以逆转形势。
布林没有问太多问题，马上展开行动，给科德斯塔尼下达作战指令：通知美国在线欧洲分公司的总裁菲利浦·罗利，GOOGLE的创办人的飞机将要改道，着陆伦敦。他们希望会见罗利本人，而且希望当天就能够见面。他还命令科德斯塔尼提高GOOGLE为美国在线欧洲业务的出价。
罗利直接拒绝了GOOGLE，告诉他美国在线已经同雅虎达成了合作意向，事情已经没有转圜的余地，这件事已经结束了，罗利说。
但布林不能接受否定的答案，从9000米的高空，他命令科德斯塔尼向罗利保证，同布林和佩奇的会面将对他和美国在线都非常有利，所以请他暂时不要同雅虎签约，他还表示，要是罗利能够给他这个机会，他本人会非常感激，他最后说，他们的飞机已经在驶往伦敦的航线上了，他希望知道今天自己什么时候，在哪里见罗利。
罗利不知道该如何处理这种情况，于是把情况汇报给了公司首席执行官乔恩·米勒。米勒决定，要是GOOGLE那两个家伙专程跑到伦敦，提出的条件却仅仅比雅虎的条件好一点点的话，美国在线就还是同雅虎签约，如果GOOGLE将事情带入一个全新的境界，那么，重新开放竞争并告知雅虎GOOGLE所提出的惊人条件也就合情合理了，因为他们同雅虎也没有签署任何文件。罗利决定在公司外面安排一次同GOOGLE的秘密会面,同时随时向米勒报告情况。
布林是个热爱竞争，目标明确的人，对于临时改变航向飞往伦敦去争取这笔生意，他乐在其中。他不希望没有做最大的努力，就白白放弃这个能够加速GOOGLE在全球范围增长的机会，在飞机上，布林和佩奇分析了局势，并决定认真听取罗利的说辞，然后提出让他无法拒绝的条件，同时，他们也希望自己的出现还不是太迟，还来得及改变局面。
在美国在线欧洲总部办公室附近的迈尔斯通大饭店，布林和佩奇会见了罗利，并很快提出了一系列令人无法抗拒，利润丰厚而且没有风险的条件，其中包括高达数千万美元的收入保证，比GOOGLE或雅虎过去提出过的任何条件都要优越，没有继续计价还价的必要了。
GOOGLE的努力的动力并非是同哪个对手之间的竞争，而且，它一直避免创造出一个所谓的劲敌。GOOGLE不针对任何人，大部分公司都需要一个竞争对手，这是他们激励自己的办法，但GOOGLE受自己使命感激励，很显示，他们考虑问题的方式与众不同，信念和经营目标是他们前进的动力。
在GOOGLE新的办公大楼里，这栋楼中央楼梯的底部，长长的门廊里挂着一块招摇的巨大白板，上面写满了五颜六色的关于项目和技术的涂鸦，它的标签上写着“GOOGLE最重要的计划”
第二十章：麻烦不断的GOOGLE
GOOGLE与GEICO的官司
第二十一章：打造数字图书馆
根据互联网，世界开始1996年
要从网上找到严肃的，权威的，经过时间考验的信息，其查找过程还是令人大失所望（有广度没深度）
在美国，1923年之后出版的书籍，几乎每一本的版权都由政府，作者或第三方拥有
在美国，版权法是一个充满陷阱的领域，其中存在各种利益冲突和大量误解。而GOOGLE一头跳进了这个荆棘密布的领域。版权保护使得出版公司和作者能够通过创造性的作品来赚钱。尽管这一图书馆数字人项目的核心是免费传播知识，但是它却隐藏着巨大的经济风险。不同的团体会提出抗议，并采取法律手段，这只是个时间问题。
这个项目的规模一开始就是惊人的，GOOGLE的协议要求将密歇要图书馆的700万册藏书，牛津大学图书馆100余万册19世纪藏书，哈佛大学4万册藏书，纽约市立图书馆12000册藏书，还有数量没有公开的来自斯坦福图书馆的藏书全部数字化。
在法国，这个项目被看作美国实施文化霸权的又一个行动，法国国家图书馆主席让·诺埃尔·让纳内说GOOGLE的做法带来一种风险，也就是，美国将其看法强加到新一代的人头上，将会影响他们对世界的看法，我不希望法国大革命的历史被美国人选择的书重新讲述。
第二十二章：作弊点击
GOOGLE的广告商受这个问题困扰最为严重，这在很大程度上是因为GOOGLE是这个飞速民展的市场中最大的玩家，不过这也并非全部原因。如果对点击欺诈置之不理的话，它会打击市场对这种广告形式的信心，从而迫使人们采取自我补救措施。广告商也许会降低他们愿意支付的费用，或者要求建立一个全新的体系。
咔嗒、咔嗒、咔嗒，鼠标点击的声音对于GOOGLE及布林和佩奇而言，是金钱甜蜜的声音，是GOOGLE收银机抽屉开合的声音。这是世界各地的数百万计算机用户在点击GOOGLE免费搜索结果右侧的小小的文本广告的声音，每一次鼠标点击都为GOOGLE带来20美分到50多美元不等的广告收入。广告商们通过信用卡付帐，购买将描述自己的产品或服务的小小的文本显示到GOOGLE搜索结果旁边的机会。日日夜夜，世界各地的计算机机用户在单位，家里，学校，或者网吧点击这些广告，同时，数十种货币形式的广告费流入了GOOGLE的帐户。
每年，通过广告点击，GOOGLE的收入超过10亿美元，也就是平均每个月1亿多美元，每天300万美元，无论公司的雇员醒着，睡着，在玩沙滩排球，还是正在参加公司组织的滑雪旅行，金钱都会从互联网中源源不断地流入公司。
GOOGLE并没有采取SNAP网站的解决方案。这家搜索引擎采取了按照用户表现收费的方式，也就是说，只有在计算机用户既点击了广告又完成了某个特点的交易时，广告商才需要为此付费。这个交易行为可以是购买某件商品，也可以是填写一份申请。
第二十三章：进攻微软
Google是全世界最好的工作单位，而微软是个衰老的巨人，其黄金时代已经过去了。根据施米特对世界的描述，由盖茨带领的这家公司根植于较早的技术阶段，这个阶段已经被互联网革命的理论超越了。从这个角度来讲，微软的作用将越来越小，而Google的作用将越来越大。
同微软过去的竞争对手不同，Google凭借自己以互联网为基础的基本构架、开发不需要分销和市场推广成本的免费软件的优势，吸引了世界各地数百万名计算机用户。
第一个问题是询问项目小组的规模，这是个简单的问题。Google最擅长的就是以3~5人的小组为单位来进行不计其数的创新活动。这些小组的领导者被称为UTL，也就是超级团队领导。“我们努力保持小的团队。如果团队的人数太多的话，生产能力就降低了。”施米特说。学生们发出的球都没有什么杀伤力，下一个问题问的是公司推出新产品的周期。“我们开发新产品的步伐比业内任何人都要快，而且速度大大领先于我们的竞争对手。”他直言不讳地说。下一个问题，更是施米特迫不及待想要回答的问题，因为他知道在座的计算机科学家有多么热爱自己的独立性。这个问题是关于公司对技术人员的管理的。“我们的秘诀不是如何管理人，而是如何选择员工，”他说，“这种模式只有在你选对了人的时候才能发挥作用。如果在某个组织里，而且在进行规模很大的项目，人们希望别人告诉自己该做什么，那么，在这个组织里，这种模式会彻底失败。我们尽力减少中间管理层，因为他们总是碍手碍脚。”
第二十四章：大马力的赚钱机器
几年前，硅谷由繁花似锦变成满目疮痍，那个时期出现了许多好高骛远的公司；很多人错误地将Google的股票同那些公司的股票相提并论。那时候，有些公司的财务报告中也提到了大量的广告收入，但是这些广告大部分都是由互联网公司出钱购买的。而Google的广告收入主要来自成千上万的中小型企业，其中有许多公司过去从来没有在网络上做过广告。而且，其中既有网络企业，也有存在于现实世界的公司。亚马逊和eBay都是Google的大广告客户，这两家网站在Google网站上购买目标性广告，借此吸引数量众多的计算机用户到自己已经被广泛接受的网站上来。Google还避开了那些计算机用户讨厌的广告形式，通过由搜索激发的文本广告牟利。从某种意义上讲，它掌握的是与大众市场推广相反的广告形式。在网络搜索和冲浪的过程中看到Google提供的广告，就好像在沿着公路驾驶的过程中只看到同你们当时正在思考或者讨论的内容有关的广告一样。
Google商业模式的规模是惊人的，因为它拥有世界上最先进的硬件和软件来支持这个体系。即使在其发展壮大的过程中，公司也几乎完全通过在线自助服务来注册新的广告客户。这削减了成本，增加了收入，并且扩大了包括广告客户、网络出版商、顾客和Google在内的各方的发展机遇。
米勒欣赏的另外一个竞争优势是Google的品牌知名度。在历史上，还没有另外哪一家公司能够这样无须花费大笔广告和市场推广费用就获得这种水平的国际认可。而且，Google的合作网站体系也是一个别人很难复制的优势。这个体系中包括数千家网站，其中包括美国在线、纽约时报网，还有Univision网站，他们网站上的显著位置都添加了Google搜索框、Google的名称和标志。随着这个体系的壮大，Google品牌的知名度也会变大。
事实上，数千家大大小小的网络出版商毫无争议地在自己的网络上发布Google提供的广告，这家搜索公司事实上成为了网络广告代理商。在公司的合作网站，即使不是一贯，这些广告也通常都标注着“广告由Gooooooogle提供”的标签。Google将慷慨地与合作网站分享这些广告的收入，因此这些公司非常希望这个搜索引擎能够维持其财务成功，因为这意味着它们也能够从中受益。但是，虽然Google每个月都给这些出版商送支票，但是Google却不愿意告诉他们自己是怎样计算应付金额的。因为竞争的关系，它还拒绝透露关于某个特定广告效果的硬性指标数据，所以内容发布网站别无选择，只能选择信任Google，或者干脆退出这个收益丰厚的网络体系。
尽管如此，因为这个体系的获益实在太丰厚了，许多网站还是兴高采烈地加入了。其中最引人注目的是Ask Jeeves。在加入Google广告体系之后，Ask Jeeves公司的价值激增，2005年的时候，它成为一个价值18.6亿美元的收购目标，这充分显示了Google经济的力量。Ask Jeeves几乎所有的收入都同Google向企业出售广告的能力以及在其搜索引擎上发布广告的做法有关系。
数百万热爱这个搜索引擎的人还是理解不了Google依靠什么来赚钱，因为他们是免费使用它的。还有很多人分辨不出免费搜索结果同其旁边出现的广告的区别。即使是那些理解其中差异的用户，因为很少点击那些广告，也不理解Google是怎么赚到数十亿美元的，尤其是，每次点击的价格通常是以美分而不是以美元来计算的。
就像Google其他的奥秘一样，这也是个单纯的数学问题。Google运作的规模大得惊人，每天提供数亿个搜索结果，只要每10~15个搜索者中，有一个人点击了一个广告，而假定每次点击的平均价格是50美分，公司就可以轻而易举地得到它在2004年取得的季度收入。
普通用户很难理解Google是怎样赚到数十亿美元的，而华尔街的分析师们也还在为公司特立独行的运作方式而困扰不已。这个公司为世界各地的数百万计算机用户的查询提供答案，可是，从某些角度看来，它却将自己藏在了暗处。它故意选择不像别的公司一样为分析师们提供未来产品信息和季度利润报告。谢尔盖和拉里不得不允许公司上市，但是这并不意味着Google就会从此公布能帮助竞争对手参破公司未来发展战略的信息。相反，公司三驾马车组成的领导集体频繁宣称在扩张过程中，Google将会采取机会主义的方式，不过，也会忠实于自己的使命。
第二十五章：微软的反攻
但是在这个重视大众观点的时代，微软被许多技术人员看成了软件行业的前苏联，是个无法适应数字化新千年迅速前进步伐的笨拙巨人。微软是一家围绕个人电脑建立起来的成熟公司，它缺乏使Google成为互联网宠儿的那种性感的魅力。
这两位创办人计划持有自己的大部分股票，但是他们不希望像其他硅谷创业者一样，爱上自己公司的股票、从来不出售，最后在公司垮掉之后变得一文不名。所以，不管Google的股票是涨还是跌，他们都会在每个月固定的日子定期出售同样数量的股份。
第二十六章：用GOOGLE搜索你的基因
佩奇：终极的搜索引擎，能够准确地理解你的意思，并提供给你恰好需要的那个答案。
Leakon.com 将在近期提供 英文PDF 下载 和 简体中文 doc 文件下载，敬请关注！
April 29th, 2006 at 1:00 pm
各模块间或者进程间的通信普遍异步化队列化也相当重要，可以兼顾轻载重载时的响应性能和系统压力,数据库压力可以通过file cache分解到文件系统，文件系统io压力再通过mem cache分解，效果很不错.
April 30th, 2006 at 4:40 pm
写得好！现在，网上像这样的文章不多，看完受益匪浅
May 1st, 2006 at 8:13 am
完全胡说八道!
“大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的”,你以为是在内存中动态生成图片啊.无论是什么文件,在容器输出时只是读文件,输出给response而已,和是什么文件有什么关系.
关键是静态文件和动态页面之间应该采用不同策略,如静态文件应该尽量缓存,因为无论你请求多少次输出内容都是相同的,如果用户页面中有二十个就没有必要请求二十次,而应该使用缓存.而动态页面每次请求输出都不相同(否则就应该是静态的),所以不应该缓存.
所以即使在同一服务器上也可以对静态和动态资源做不同优化,专门的图片服务器那是为了资源管理的方便,和你说的性能没有关系.
May 2nd, 2006 at 1:15 am
动 态的缓存案例估计楼上朋友没有遇到过，在处理inktomi的搜索结果的案例中，我们使用的全部是面对动态的缓存，对于同样的关键词和查询条件来说，这样 的缓存是非常重要的，对于动态的内容缓存，编程时使用合理的header参数可以方便的管理缓存的策略，比如失效时间等。
我们说到有关图片影响性能的问题，一般来说都是出自于我们的大部分访问页面中图片往往比html代码占用的流量大，在同等网络带宽的情况下，图片传 输需要的时间更长，由于传输需要花很大开销在建立连接上，这会延长用户client端与server端的http连接时长，这对于apache来说，并发 性能肯定会下降，除非你的返回全部是静态的，那就可以把 httpd.conf 中的 KeepAlives 为 off ，这样可以减小连接处理时间，但是如果图片过多会导致建立的连接次数增多，同样消耗性能。
另外我们提到的理论更多的是针对大型集群的案例，在这样的环境下，图片的分离能有效的改进架构，进而影响到性能的提升，要知道我们为什么要谈架构？架构可能为了安全、为了资源分配、也为了更科学的开发和管理，但是终极目都是为了性能。
另外在RFC1945的HTTP协议文档中很容易找到有关Mime Type和Content length部分的说明，这样对于理解图片对性能影响是很容易的。
楼上的朋友完全是小人作为，希望别用guest跟我忽悠，男人还害怕别人知道你叫啥？再说了，就算说错了也不至于用胡说八道来找茬！大家重在交流和学习，我也不是什么高人，顶多算个普通程序员而已。
June 3rd, 2006 at 3:42 pm
Michael 您好，这篇文章我看几次了，有一个问题，您的文章中提到了如下一段：
“对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。”
对于大型的站点来说，他的数据库和 Web Server 一般都是分布式的，在多个区域都有部署，当某个地区的用户访问时会对应到一个节点上，如果是对社区内的帖子实时静态化，有更新时再重新静态化，那么在节点 之间如何立刻同步呢？数据库端如何实现呢？如果用户看不到的话会以为发帖失败？造成重复发了，那么如何将用户锁定在一个节点上呢，这些怎么解决？谢谢。
June 3rd, 2006 at 3:57 pm
对于将一个用户锁定在某个节点上是通过四层交换来实现的，一般情况下是这样，如果应用比较小的可以通过程序代码来实现。大型的应用一般通过类似LVS和硬件四层交换来管理用户连接，可以制定策略来使用户的连接在生命期内保持在某个节点上。
静态化和同步的策略比较多，一般采用的方法是集中或者分布存储，但是静态化却是通过集中存储来实现的，然后使用前端的proxy群来实现缓存和分担压力。
June 10th, 2006 at 6:38 pm
希望有空跟你学习请教网站负载问题。
June 19th, 2006 at 4:14 pm
Great website! Bookmarked! I am impressed at your work!
June 21st, 2006 at 10:39 am
一般对于一个中型网站来说，交互操作非常多，日PV百万左右，如何做合理的负载？
June 23rd, 2006 at 3:15 pm
交互如果非常多，可以考虑使用集群加Memory Cache的方式，把不断变化而且需要同步的数据放入Memory Cache里面进行读取，具体的方案还得需要结合具体的情况来分析。
June 27th, 2006 at 5:39 pm
请问，如果一个网站处于技术发展期，那么这些优化手段应该先实施哪些后实施哪些呢？
或者说从成本（技术、人力和财力成本）方面，哪些先实施能够取得最大效果呢？
June 27th, 2006 at 9:16 pm
先从服务器性能优化、代码性能优化方面入手，包括webserver、dbserver的优化配置、html静态化等容易入手的开始，这些环节争取 先榨取到最大化的利用率，然后再考虑从架构上增加投入，比如集群、负载均衡等方面，这些都需要在有一定的发展积累之后再做考虑比较恰当。
June 30th, 2006 at 4:39 pm
恩，多谢Michael的耐心讲解
July 6th, 2006 at 11:58 am
写得好,为人也不错.
July 17th, 2006 at 2:39 pm
Very good site. Thanks for author!
September 1st, 2006 at 2:28 pm
赞一个先，是一篇很不错的文章，不过要真正掌握里面的东西恐怕还是需要时间和实践！
先问一下关于图片服务器的问题了！
我的台球网站故人居9tmd.com也使用了图片服务器架构上的分离，目前是仅仅是架构上分离，物理上没有分离，由于没有钱买更多的服务器:)，大家可以看到故人居上的图片连接都是类似img.9tmd.com或者img1.9tmd.com的URL。
这个，楼主这个img.9tmd.com是虚拟主机吧，也就是说是一个apache提供的服务吧，这样的话对于性能的提高也很有意义吗？还是只是铺垫，为了方便以后的物理分离呢？
September 1st, 2006 at 3:05 pm
这位朋友说得很对，因为目前只有一台服务器，所以从物理上无法实现真正的分离，暂时使用虚拟主机来实现，是为了程序设计和网站架构上的灵活，如果有 了一台新的服务器，我只需要把图片镜像过去或者同步过去，然后把img.9tmd.com的dns解析到新的服务器上就自然实现了分离，如果现在不从架构 和程序上实现，今后这样的分离就会比较痛苦:)
September 7th, 2006 at 4:59 pm
谢谢lz的回复，现在主要实现问题是如何能在素材上传时直接传到图片服务器上呢，总不至于每次先传到web，然后再同步到图片服务器吧
September 7th, 2006 at 11:25 pm
通过samba或者nfs实现是比较简单的方法。然后使用squid缓存来降低访问的负载，提高磁盘性能和延长磁盘使用寿命。
September 8th, 2006 at 9:42 am
多谢楼主的耐心指导，我先研究下，用共享区来存储确实是个不错的想法!
September 8th, 2006 at 11:16 am
不客气，欢迎常交流！
September 11th, 2006 at 2:26 pm
Michael，谢谢你的好文章。仔细看了，包括回复，受益匪浅。
尤其这个部分很是有用，因为我也正在建一个电子商务类的网站，由于是前期阶段，费用的问题毕竟有所影响，所以暂且只用了一台服务器囊括过了整个网站。除去 前面所说的图片服务器分离，还有什么办法能在网站建设初期尽可能的为后期的发展做好优化（性能优化，系统合理构架，前面说的websever、 dbserver优化，后期譬如硬件等扩展尽可能不要过于烦琐等等）？ 也就是所谓的未雨绸缪了，尽可能在先期考虑到后期如果发展壮大的需求，预先做好系统规划，并且在前期资金不足的情况下尽量做到网站以最优异的性能在运行。关于达到这两个要求，您可以给我一些稍稍详细一点的建议和技术参考吗？谢谢！
看了你的文章，知道你主要关注*nix系统架构的，我的是.net和win2003的，不过我觉得这个影响也不大。主要关注点放在外围的网站优化上。
谢谢!希望能得到您的一些好建议。
September 11th, 2006 at 2:55 pm
回复fanstone：
关于如何在网站的前期尽可能低成本的投入，做到性能最大化利用，同时做好后期系统架构的规划，这个问题可以说已经放大到超出技术范畴，不过和技术相关的部分还是有不少需要考虑的。
一个网站的规划关键的就是对阶段性目标的规划，比如预测几个月后达到什么用户级别、存储级别、并发请求数，然后再过几个月又将什么情况，这些预测必 须根据具体业务和市场情况来进行预估和不断调整的，有了这些预测数据作为参考，就能进行技术架构的规划，否则技术上是无法合理进行架构设计的。
在网站发展规划基础上，考虑今后要提供什么样的应用？有些什么样的域名关系？各个应用之间的业务逻辑和关联是什么？面对什么地域分布的用户提供服务？等等。。。
上面这些问题有助于规划网站服务器和设备投入，同时从技术上可以及早预测到未来将会是一个什么架构，在满足这个架构下的每个节点将需要满足什么条件，就是初期架构的要求。
总的来说，不结合具体业务的技术规划是没有意义的，所以首先是业务规划，也就是产品设计，然后才是技术规划。
September 11th, 2006 at 8:52 pm
谢谢解答，我再多看看！
March 22nd, 2007 at 11:48 pm
很 好的文章，楼主说的方法非常适用，目前我们公司的网站也是按照楼主所说的方法进行设计的，效果比较好，利于以后的扩展，另外我再补充一点，其实楼主也说 了，网站的域名也需要提前考虑和规划，比如网站的图片内容比较多，可以按应用图片的类型可以根据不同的业务需求采用不同的域名img1~imgN等，便于 日后的扩展和移至，希望楼主能够多发一些这样的好文章。
April 3rd, 2007 at 9:08 am
图片服务器与主数据分离的问题。
图片是存储在硬盘里好还是存储在数据库里好？
请您分硬盘和数据库两种情况解释下面的疑问。
当存放图片的服务器容量不能满足要求时如何办？
当存放图片的服务器负载不能满足要求时如何办？
谢谢。
April 3rd, 2007 at 2:29 pm
肯定是存储在硬盘里面，出现存储在数据库里面的说法实际上是出自一些虚拟主机或者租用空间的个人网站和企业网站，因为网站数据量小，也为了备份方便，从大型商业网站来说，没有图片存储在数据库里面的大型应用。数据库容量和效率都会是极大的瓶颈。
你提到的后面两个问题。容量和负载基本上是同时要考虑的问题，容量方面，大部分的解决方案都是使用海量存储，比如专业的盘阵，入门级的磁盘柜或者高 级的光纤盘阵、局域网盘阵等，这些都是主要的解决方案。记得我原来说过，如果是考虑低成本，一定要自己使用便宜单台服务器来存储，那就需要从程序逻辑上去 控制，比如你可以多台同样的服务器来存储，分别提供NFS的分区给前端应用使用，在前端应用的程序逻辑中自己去控制存储在哪一台服务器的NFS分区上，比 如根据Userid或者图片id、或者别的逻辑去进行散列，这个和我们规划大型数据库存储散列分表或者分库存储的逻辑类似。
基本上图片负载高的解决办法有两种，前端squid缓存和镜像，通过对存储设备（服务器或者盘阵）使用镜像，可以分布到多台服务器上对外提供图片服务，然后再配合squid缓存实现负载的降低和提高用户访问速度。
希望能回答了您的问题。
April 3rd, 2007 at 2:41 pm
April 4th, 2007 at 11:39 pm
非常感谢您的回复，
希望将来有合作的机会。
再次感谢。
April 9th, 2007 at 2:50 pm
刚才一位朋友把你的 BLOG 发给我看，问我是否认识你，所以我就仔细看了一下你的 BLOG，发现这篇文章。
很不错的一篇文章，基本上一个大型网站需要做的事情都已经提及了。我自己也曾任职于三大门户之一，管理超过 100 台的 SQUID 服务器等，希望可以也分享一下我的经验和看法。
1、图片服务器分离
这个观点是我一直以来都非常支持的。特别是如果程序与图片都放在同一个 APAHCE 的服务器下，每一个图片的请求都有可能导致一个 HTTPD 进程的调用，而 HTTPD 如果包含有 PHP 模块的的时候，就会占用过多的内存，而这个是没有任何必要的。
使用独立的图片服务器不但可以避免以上这个情况，更可以对不同的使用性质的图片设置不同的过期时间，以便同一个用户在不同页面访问相同图片时不会再次从服务器（基于是缓存服务器）取数据，不但止快速，而且还省了带宽。还有就是，对于缓存的时间上，亦可以做调立的调节。
在我过往所管理的图片服务器中，不但止是将图片与应用及页面中分离出来，还是为不同性质的图片启用不同的域名。以缓解不同性质图片带来的压力。例如 photo.img.domain.com 这个域名是为了摄影服务的，平时使用 5 台 CACHE，但到了 5.1 长假期后，就有可能需要独立为他增加至 10 台。而增加的这 5 台可以从其他负载较低的图片服务器中调动过来临时使用。
2、数据库集群
一套 ORACLE RAC 的集群布置大概在 40W 左右，这个价格对于一般公司来说，是没有必要的。因为 WEB 的应用逻辑相对较简单，而 ORACLE 这些大型数据库的价值在于数据挖掘，而不在于简单的存储。所以选择 MySQL 或 PostgreSQL 会实际一些。
简单的 MySQL 复制就可以实现较好的效果。读的时候从 SLAVE 读，写的时候才到 MASTER 上更新。实际的情况下，MySQL 的复制性能非常好，基本上不会带来太高的更新延时。使用 balance （http://www.inlab.de/balance.html）这个软件，在本地（127.0.0.1）监听 3306 端口，再映射多个 SLAVE 数据库，可以实现读取的负载均衡。
3、图片保存于磁盘还是数据库？
对于这个问题，我亦有认真地考虑过。如果是在 ext3 的文件系统下，建 3W 个目录就到极限了，而使用 xfs 的话就没有这个限制。图片的存储，如果需要是大量的保存，必须要分隔成很多个小目录，否则就会有 ext3 只能建 3W 目录的限制，而且文件数及目录数太多会影响磁盘性能。还没有算上空间占用浪费等问题。
更更重要的是，对于一个大量小文件的数据备份，要占用极大的资源和非常长的时间。在这些问题前面，可能将图片保存在数据库是个另外的选择。
可以尝试将图片保存到数据库，前端用 PHP 程序返回实际的图片，再在前端放置一个 SQUID 的服务器，可以避免性能问题。那么图片的备份问题，亦可以利用 MySQL 的数据复制机制来实现。这个问题就可以得到较好的解决了。
4、页面的静态化我就不说了，我自己做的 wordpress 就完全实现了静态化，同时能很好地兼顾动态数据的生成。
5、缓存
我自己之前也提出过使用 memcached，但实际使用中不是非常特别的理想。当然，各个应用环境不一致会有不一致的使用结果，这个并不重要。只要自己觉得好用就用。
6、软件四层交换
LVS 的性能非常好，我有朋友的网站使用了 LVS 来做负责均衡的调度器，数据量非常大都可以轻松支撑。当然是使用了 DR 的方式。
其实我自己还想过可以用 LVS 来做 CDN 的调度。例如北京的 BGP 机房接受用户的请求，然后通过 LVS 的 TUN 方式，将请求调度到电信或网通机房的实际物理服务器上，直接向用户返回数据。
这种是 WAN 的调度，F5 这些硬件设备也应用这样的技术。不过使用 LVS 来实现费用就大大降低。
以上都只属个人观点，能力有限，希望对大家有帮助。 ：）
April 9th, 2007 at 8:17 pm
很少见到有朋友能在我得blog上留下这么多有价值的东西，代表别的可能看到这篇文章的朋友一起感谢你。
balance （http://www.inlab.de/balance.html） 这个东西准备看一下。
April 16th, 2007 at 1:29 am
如 果要说3Par的光纤存储局域网技术细节，我无法给您太多解释，我对他们的产品没有接触也没有了解，不过从SAN的概念上是可以知道大概框架的，它也是一 种基于光纤通道的存储局域网，可以支持远距离传输和较高的系统扩展性，传统的SAN使用专门的FC光通道SCSI磁盘阵列，从你提供的内容来看，3Par 这个东西建立在低成本的SATA或FATA磁盘阵列基础上，这一方面能降低成本，同时估计3Par在技术上有创新和改进，从而提供了廉价的高性能存储应 用。
这个东西细节只有他们自己知道，你就知道这是个商业的SAN （存储局域网，说白了也是盘阵，只是通过光纤通道独立于系统外的）。
April 16th, 2007 at 2:10 am
myspace和美国的许多银行都更换为了3Par
请您在百忙之中核实一下，是否确实像说的那么好。
下面是摘抄：
Priceline.com是一家以销售空座机票为主的网络公司，客户数量多达680万。该公司近期正在内部实施一项大规模的SAN系统整合计划， 一口气购进了5套3PARdata的服务器系统，用以替代现有的上百台Sun存储阵列。如果该方案部署成功的话，将有望为Priceline.com节省 大量的存储管理时间、资本开销及系统维护费用。
Priceline.com之前一直在使用的SAN系统是由50台光纤磁盘阵列、50台SCSI磁盘阵列和15台存储服务器构成的。此次，该公司一举 购入了5台3Par S400 InServ Storage Servers存储服务器，用以替代原来的服务器系统，使得设备整体能耗、占用空间及散热一举降低了60%。整个系统部署下来，总存储容量将逼近 30TB。
Priceline的首席信息官Ron Rose拒绝透露该公司之前所使用的SAN系统设备的供应商名称，不过，消息灵通人士表示，PriceLine原来的存储环境是由不同型号的Sun系统混合搭建而成的。
“我们并不愿意随便更换系统供应商，不过，3Par的存储系统所具备的高投资回报率，实在令人难以抗拒，”Rose介绍说，“我们给了原来的设备供应 商以足够的适应时间，希望它们的存储设备也能够提供与3Par一样的效能，最后，我们失望了。如果换成3Par的存储系统的话，短期内就可以立刻见到成 效。”
Rose接着补充说，“原先使用的那套SAN系统，并没有太多让我们不满意的地方，除了欠缺一点灵活性之外：系统的配置方案堪称不错，但并不是最优化的。使用了大量价格偏贵的光纤磁盘，许多SAN端口都是闲置的。”
自从更换成3Par的磁盘阵列之后，该公司存储系统的端口数量从90个骤减为24个。“我们购买的软件许可证都是按端口数量来收费的。每增加一个端 口，需要额外支付500-1,500美元，单单这一项，就为我们节省了一笔相当可观的开支，”Rose解释说。而且，一旦启用3Par的精简自动配置软 件，系统资源利用率将有望提升30%，至少在近一段时间内该公司不必考虑添置新的磁盘系统。
精简自动配置技术最大的功效就在于它能够按照应用程序的实际需求来分配存储资源，有效地降低了空间闲置率。如果当前运行的应用程序需要额外的存储资源 的话，该软件将在不干扰应用程序正常运行的前提下，基于“按需”和“公用”的原则来自动发放资源空间，避免了人力干预，至少为存储管理员减轻了一半以上的 工作量。
3Par的磁盘阵列是由低成本的SATA和FATA（即：低成本光纤信道接口）磁盘驱动器构成的，而并非昂贵的高效能FC磁盘，大大降低了系统整体成本。
3Par推出的SAN解决方案，实际上是遵循了“允许多个分布式介质服务器共享通过光纤信道SAN 连接的公共的集中化存储设备”的设计理念。“这样一来，就不必给所有的存储设备都外挂一个代理服务程序了，”Rose介绍说。出于容灾容错和负载均衡的考 虑，Priceline搭建了两个生产站点，每一个站点都部署了一套3Par SAN系统。此外，Priceline还购买了两台3Par Inservs服务器，安置在主数据中心内，专门用于存放镜像文件。第5台服务器设置在Priceline的企业资料处理中心内，用于存放数据仓库；第6 台服务器设置在实验室内，专门用于进行实际网站压力测试。
MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。在3PAR的系统里，仍能在逻辑上按容量划分数据存 储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时，任何空闲磁盘都可以马上完成 这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数据时，也不会使SAN的任何组件过载。
3PAR宣布，VoIP服务供应商Cbeyond Communications已向它订购了两套InServ存储服务器，一套应用于该公司的可操作支持系统，一套应用于测试和开发系统环境。3PAR的总 部设在亚特兰大，该公司的产品多销往美国各州首府和大城市，比如说亚特兰大、达拉斯、丹佛、休斯顿、芝加哥，等等。截至目前为止，3PAR售出的服务器数 量已超过了15,000台，许多客户都是来自于各行各业的龙头企业，它们之所以挑选3PAR的产品，主要是看中了它所具备的高性能、可扩展性、操作简单、 无比伦比的性价比等优点，另外，3PAR推出的服务器系列具有高度的集成性能，适合应用于高速度的T1互联网接入、本地和长途语音服务、虚拟主机（Web hosting）、电子邮件、电话会议和虚拟个人网络（VPN）等服务领域。
亿万用户网站MySpace的成功秘密
◎ 文 / David F. Carr 译 / 罗小平
高速增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统，以期与自身的成长同步 ——目前，该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分，但那些指望迈入庞大在线市场的人，可以从 MySpace的成长过程学到知识。
MySpace开发人员已经多次重构站点软件、数据库和存储系统，以满足爆炸性的成长需要，但此工作永不会停息。“就像粉刷金门大桥，工作完成之 时，就是重新来过之日。”（译者注：意指工人从桥头开始粉刷，当到达桥尾时，桥头涂料已经剥落，必须重新开始）MySpace技术副总裁Jim Benedetto说。
既然如此，MySpace的技术还有何可学之处？因为MySpace事实上已经解决了很多系统扩展性问题，才能走到今天。
Benedetto说他的项目组有很多教训必须总结，他们仍在学习，路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统，以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。
背景知识
当然，这么多的用户不停发布消息、撰写评论或者更新个人资料，甚至一些人整天都泡在Space上，必然给MySpace的技术工作带来前所未有的挑战。而 传统新闻站点的绝大多数内容都是由编辑团队整理后主动提供给用户消费，它们的内容数据库通常可以优化为只读模式，因为用户评论等引起的增加和更新操作很 少。而MySpace是由用户提供内容，数据库很大比例的操作都是插入和更新，而非读取。
浏览MySpace上的任何个人资料时，系统都必须先查询数据库，然后动态创建页面。当然，通过数据缓存，可以减轻数据库的压力，但这种方案必须解决原始数据被用户频繁更新带来的同步问题。
MySpace的站点架构已经历了5个版本——每次都是用户数达到一个里程碑后，必须做大量的调整和优化。Benedetto说，“但我们始终跟不上形势的发展速度。我们重构重构再重构，一步步挪到今天”。
在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫。最后，技术团队必须为此修订系统策略。
虽然自2005年早期，站点账户数超过7百万后，系统架构到目前为止保持了相对稳定，但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚，Benedetto说，“我们已经尽可能把事情做到最好”。
里程碑一：50万账户
按Benedetto 的说法，MySpace最初的系统很小，只有两台Web服务器和一个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。
单个数据库就意味着所有数据都存储在一个地方，再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样，三服务器架构很快不堪重负。此后一个时期内，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。
但到在2004年早期，MySpace用户数增长到50万后，数据库服务器也已开始汗流浃背。
但和Web服务器不同，增加数据库可没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下，让多个数据库分担压力。
在第二代架构中，MySpace运行在3个SQL Server数据库服务器上——一个为主，所有的新数据都向它提交，然后由它复制到其他两个；另两个全力向用户供给数据，用以在博客和个人资料栏显示。这 种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。
里程碑二：1-2百万账户
MySpace注册数到达1百万至2百万区间后，数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中，距离上次数据库系 统调整不过数月。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇“主要矛盾”，Benedetto说，这意味着 MySpace永远都会轻度落后于用户需求。
“有人花5分钟都无法完成留言，因此用户总是抱怨说网站已经完蛋了。”他补充道。
这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。
垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace将投入新的数据库予以支持它。账户到达2百万后，MySpace还从存 储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运 行时间和可靠性，Benedetto说。
里程碑三：3百万账户
当用户继续增加到3百万后，垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立，但有些信息必须共享。在这个架构里，每个数据库必须有各自 的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时，该条账户记录必须在9个不同数据库上分别创建。但在个别情况下，如果其 中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完全创建，最终导致此用户的该项服务无效。
另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。
2004年中，MySpace面临Web开发者称之为“向上扩展”对“向外扩展”（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）的抉择——要么扩展到更大更强、也更昂贵的服务器上，要么部署大量相对便宜的服务器来分担数据库压力。一般来说，大型站 点倾向于向外扩展，因为这将让它们得以保留通过增加服务器以提升系统能力的后路。
但成功地向外扩展架构必须解决复杂的分布式计算问题，大型站点如Google、Yahoo和Amazon.com，都必须自行研发大量相关技术。以Google为例，它构建了自己的分布式文件系统。
另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分布式服务器上运行。“搞不好，开发人员的所有工作都将白费”，Benedetto说。
因此，MySpace首先将重点放在了向上扩展上，花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说，“那时候，这个方案看似可能解决一切问题。”如稳定性，更棒的是对现有软件几乎没有改动要求。
糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto说，“换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。”
因此，MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将 应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在 相同数据库。
既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库服务器是无能为力 的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。目前，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约2百万用户。Benedetto指出，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。
当然，还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后，保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大，但它只负责用户登录，功能单一，所以负荷还是比较容易控制的。
里程碑四：9百万到1千7百万账户
2005年早期，账户达到9百万后，MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言，吸收了C++和 Java的优点，依托于Microsoft .NET框架（Microsoft为软件组件化和分布式计算而设计的模型架构）。ASP.NET则由编写Web站点脚本的ASP技术演化而来，是 Microsoft目前主推的Web站点编程环境。
可以说是立竿见影，MySpace马上就发现ASP.NET程序运行更有效率，与ColdFusion相比，完成同样任务需消耗的处理器能力更小。据技术 总监Whitcomb说，新代码需要150台服务器完成的工作，如果用ColdFusion则需要246台。Benedetto还指出，性能上升的另一个 原因可能是在变换软件平台，并用新语言重写代码的过程中，程序员复审并优化了一些功能流程。
最终，MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码，也从Cold-Fusion服务器搬到了 ASP.NET，因为他们得到了BlueDragon.NET（乔治亚州阿尔法利塔New Atlanta Communications公司的产品，它能将ColdFusion代码自动重新编译到Microsoft平台）的帮助。
账户达到1千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
原因之一是每数据库1百万账户的分割策略，通常情况下的确可以将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据库上线后，仅仅7天就被塞满了，主要原因是佛罗里达一个乐队的歌迷疯狂注册。
某个数据库可能因为任何原因，在任何时候遭遇主要负荷，这时，SAN中绑定到该数据库的磁盘存储设备簇就可能过载。“SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。”Benedetto说。
最初，MySpace通过定期重新分配SAN中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程，“大概需要两个人全职工作。”Benedetto说。
长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。
在3PAR的系统里，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据 库需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数 据时，也不会使SAN的任何组件过载。
当2005年春天账户数达到1千7百万时，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器之 间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。换句话说，100个用户请求同一份资料，以 前需要查询数据库100次，而现在只需1次，其余都可从缓存数据中获得。当然如果页面变化，缓存的数据必须从内存擦除，然后重新从数据库获取——但在此之 前，数据库的压力已经大大减轻，整个站点的性能得到提升。
缓存区还为那些不需要记入数据库的数据提供了驿站，比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课，“我是数据库存储狂热分子，因此我总是想着将万事万物都存到数据库。”但将像会话跟踪这类的数据也存到数据库，站点将陷入泥沼。
增加缓存服务器是“一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。”Benedetto补充道。
里程碑五：2千6百万账户
2005年中期，服务账户数达到2千6百万时，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器。但Benedetto说，“这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴 求。”支持64位的数据库可以管理更多内存。
更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器，能同时使用的内存最多只有4G。切换到64位，就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。
意外错误
如果没有对系统架构的历次修改与升级，MySpace根本不可能走到今天。但是，为什么系统还经常吃撑着了？很多用户抱怨的“意外错误”是怎么引起的呢？
原因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月，超出SQL Server最大同时连接数，MySpace系统崩溃。Benedetto说，这类可能引发系统崩溃的情况大概三天才会出现一次，但仍然过于频繁了，以致 惹人恼怒。一旦数据库罢工，“无论这种情况什么时候发生，未缓存的数据都不能从SQL Server获得，那么你就必然看到一个‘意外错误’提示。”他解释说。
去年夏天，MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击（黑客使用很多客户机向服务器发起大量连接请求，以致服务器 瘫痪）。MySpace和其他很多顶级大站点一样，肯定会经常遭受攻击，但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则，大量 MySpace合法用户连接时也会引起服务器反击。
“我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。”Benedetto说。最后，通过Microsoft的帮助，他们才知道该怎么通知服务器：“别开枪，是友军。”
紧接着是在去年7月某个周日晚上，MySpace总部所在地洛杉矶停电，造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以 预防单点故障。本来，MySpace还有其他两个数据中心以应对突发事件，但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN，Web服务 器除了恳求你耐心等待，不能提供任何服务。
Benedetto说，主数据中心的可靠性通过下列措施保证：可接入两张不同电网，另有后备电源和一台储备有30天燃料的发电机。但在这次事故中，不仅两张电网失效，而且在切换到备份电源的过程中，操作员烧掉了主动力线路。
2007年中，MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下，每个SAN都能负担三分之一的数据访问量。而在紧急情况下，任何一个站点都可以独立支撑整个服务，Benedetto说。
MySpace仍然在为提高稳定性奋斗，虽然很多用户表示了足够信任且能原谅偶现的错误页面。
“作为开发人员，我憎恶Bug，它太气人了。”Dan Tanner这个31岁的德克萨斯软件工程师说，他通过MySpace重新联系到了高中和大学同学。“不过，MySpace对我们的用处很大，因此我们可 以原谅偶发的故障和错误。” Tanner说，如果站点某天出现故障甚至崩溃，恢复以后他还是会继续使用。
这就是为什么Drew在论坛里咆哮时，大部分用户都告诉他应该保持平静，如果等几分钟，问题就会解决的原因。Drew无法平静，他写道，“我已经两次给 MySpace发邮件，而它说一小时前还是正常的，现在出了点问题……完全是一堆废话。”另一个用户回复说，“毕竟它是免费的。”Benedetto坦承 100%的可靠性不是他的目标。“它不是银行，而是一个免费的服务。”他说。
换句话说，MySpace的偶发故障可能造成某人最后更新的个人资料丢失，但并不意味着网站弄丢了用户的钱财。“关键是要认识到，与保证站点性能相比，丢 失少许数据的故障是可接受的。”Benedetto说。所以，MySpace甘冒丢失2分钟到2小时内任意点数据的危险，在SQL Server配置里延长了“checkpoint”操作——它将待更新数据永久记录到磁盘——的间隔时间，因为这样做可以加快数据库的运行。
Benedetto说，同样，开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险，但这样做可以更快实现新功能。而 且，因为进行大规模真实测试不具可行性，他们的测试通常是在仅以部分活跃用户为对象，且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能 做真实的加载测试，他们做的测试通常都是针对站点。
“我们犯过大量错误，”Benedetto说，“但到头来，我认为我们做对的还是比做错的多。”
April 16th, 2007 at 2:15 am
了解联合数据库服务器
为达到最大型网站所需的高性能级别，多层系统一般在多个服务器之间平衡每一层的处理负荷。SQL Server 2005 通过对 SQL Server 数据库中的数据进行水平分区，在一组服务器之间分摊数据库处理负荷。这些服务器独立管理，但协作处理应用程序的数据库请求；这样一组协作服务器称为“联合 体”。
只有在应用程序将每个 SQL 语句发送到包含该语句所需的大部分数据的成员服务器时，联合数据库层才能达到非常高的性能级别。这称为使用语句所需的数据来配置 SQL 语句。使用所需的数据来配置 SQL 语句不是联合服务器所特有的要求。群集系统也有此要求。
虽然服务器联合体与单个数据库服务器对应用程序来说是一样的，但在实现数据库服务层的方式上存在内部差异，
April 16th, 2007 at 3:18 am
关 于MySpace是否使用了3Par的SAN，并且起到多大的关键作用，我也无法考证，也许可以通过在MySpace工作的朋友可以了解到，但是从各种数 据和一些案例来看，3Par的确可以改善成本过高和存储I/O性能问题，但是实际应用中，除非电信、银行或者真的类似MySpace这样规模的站点，的确 很少遇到存储连SAN都无法满足的情况，另外，对于数据库方面，据我知道，凡电信、金融和互联网上电子商务关键数据应用，基本上Oracle才是最终的解 决方案。 包括我曾经工作的Yahoo，他们全球超过70%以上应用使用MySQL，但是和钱相关的或者丢失数据会承担责任的应用，都是使用Oracle。在UDB 方面，我相信Yahoo的用户数一定超过MySpace的几千万。
事实上，国内最值得研究的案例应该是腾讯，腾讯目前的数据量一定是惊人的，在和周小旻的一次短暂对话中知道腾讯的架构专家自己实现了大部分的技术，细节我无法得知。
April 16th, 2007 at 3:23 am
图 片存储到数据库我依然不赞同，不过一定要这么做也不是不可以，您提到的使用CGI程序输出到用户客户端，基本上每种web编程语言都支持，只要能输出标准 的HTTP Header信息就可以了，比如PHP可以使用 header(”content-type:image/jpeg\r\n”); 语句输出当前http返回的文件mime类型为图片，同时还有更多的header()函数可以输出的HTTP Header信息，包括 content-length 之类的（提供range 断点续传需要），具体的可以参考PHP的手册。 另外，perl、asp、jsp这些都提供类似的实现方法，这不是语言问题，而是一个HTTP协议问题。
April 16th, 2007 at 8:52 am
早晨，其实已经是上午，起床后，
看到您凌晨3：23的回复，非常感动。
一定注意身体。
好像您还没有太太，
太太和孩子也像正规程序一样，会良好地调节您的身体。
千万不要使用野程序调节身体，会中毒。
开个玩笑。
April 16th, 2007 at 8:59 am
看到您凌晨3：23的回复，
非常感动！
一定注意身体，
好像您还没有太太，
太太和孩子就像正规程序一样，能够良好地调节您的身体，
千万不要使用野程序调节身体，会中毒。
开个玩笑。
April 16th, 2007 at 11:04 am
哈哈，最近我是有点疯狂，不过从大学开始，似乎就习惯了晚睡，我基本多年都保持2点左右睡觉，8点左右起床，昨晚有点夸张，因为看一个文档和写一些东西一口气就到3点多了，临睡前看到您的留言，顺便就回复了。
April 18th, 2007 at 1:38 pm
感谢楼主写了这么好的文章，谢谢！！！
April 27th, 2007 at 11:04 pm
看ㄋ你的文章，很有感覺的說．我自己也做網站，希望可以多多交流一下，大家保持聯繫．
http://www.gameon9.com/
http://www.gameon9.com.tw/
May 9th, 2007 at 8:22 pm
关于两位老大讨论的：图片保存于磁盘还是数据库
个人觉得数据库存文件的话，查询速度可能快点，但数据量很大的时候要加上索引，这样添加记录的速度就慢了
mysql对大数据量的处理能力还不是很强，上千万条记录时，性能也会下降
数据库另外一个瓶颈问题就是连接
用数据库，就要调用后台程序（JSP/JAVA,PHP等）连接数据库，而数据库的连接连接、传输数据都要耗费系统资源。数据库的连接数也是个瓶颈问题。 曾经写过一个很烂的程序，每秒访问3到5次的数据库，结果一天下来要连接20多万次数据库，把对方的mysql数据库搞瘫痪了。
May 19th, 2007 at 12:07 am
抽空儿回这里浏览了一下，
有收获，
“写真照”换了，显得更帅了。
ok
May 19th, 2007 at 12:17 am
哈哈，让您见笑了
May 30th, 2007 at 3:27 pm
很好，虽然我不是做web的，但看了还是收益良多。
June 13th, 2007 at 10:23 am
感谢Michael
June 13th, 2007 at 10:12 pm
回复:说说大型高并发高负载网站的系统架构 …
好文章!学习中………….
June 15th, 2007 at 4:29 pm
推荐nginx
June 16th, 2007 at 11:54 pm
拜读
June 16th, 2007 at 11:59 pm
欢迎分享Nginx方面的经验:)
June 21st, 2007 at 11:40 pm
[…] 来源：http://www.toplee.com/blog/archives/71.html 时间：11:40 下午 | 分类：技术文摘 标签：系统架构, 大型网站, 性能优化 […]
June 23rd, 2007 at 11:35 am
看到大家都推荐图片分离，我也知道这样很好，但页面里的图片的绝对网址是开发的时候就写进去的，还是最终执行的时候替换的呢？
如果是开发原始网页就写进去的，那本地调试的时候又是怎么显示的呢？
如果是最终执行的时候替换的话，是用的什么方法呢？
June 23rd, 2007 at 8:21 pm
都可以，写到配置文件里面就可以，或者用全局变量定义，方法很多也都能实现，哪怕写死了在开发的时候把本地调试也都配好图片server，在hosts文件里面指定一下ip到本地就可以了。
假设用最终执行时候的替换，就配置你的apache或者别的server上的mod_rewrite模块来实现，具体的参照相关文档。
June 25th, 2007 at 6:43 pm
先谢谢博主的回复，一直在找一种方便的方法将图片分离。
看来是最终替换法比较灵活，但我知道mod_rewrite是用来将用户提交的网址转换成服务器上的真实网址。
看了博主的回复好像它还有把网页执行的结果进行替换后再返回给浏览器的功能，是这样吗？
June 25th, 2007 at 11:00 pm
不是，只转换用户请求，对url进行rewrite，进行重定向到新的url上，规则很灵活，建议仔细看看lighttpd或者apache的mod_rewrite文档，当然IIS也有类似的模块。
June 25th, 2007 at 11:56 pm
我知道了，如果要让客户浏览的网页代码里的图片地址是绝对地址，只能在开发时就写死了(对于静态页面)或用变量替换(对于动态页面更灵活些)，是这样吗？
我以为有更简单的方法呢，谢博主指点了。
July 24th, 2007 at 1:25 pm
请教楼主：
我正在搞一个医学教育视频资源在线预览的网站，只提供几分钟的视频预览，用swf格式，会员收看预览后线下可购买DVD光碟。
系统架构打算使用三台服务器：网页服务器、数据库服务器、视频服务器。
网页使用全部静态，数据库用SQL Server 2000，CMS是用ASP开发的。
会员数按十万级设计，不使用库表散列技术，请楼主给个建议，看看我的方案可行不？
July 24th, 2007 at 11:56 pm
这个数量级的应用好好配置优化一下服务器和代码，三台服务器完全没有问题，关键不是看整体会员数有多少，而是看同时在线的并发数有多少，并发不多就完全没有问题了，并发多的话，三台的这种架构还是有些问题的。
July 26th, 2007 at 10:46 pm
看了楼主的文章及各位大师的讨论,感到受益非浅!真希望自己有机会亲自接触一下这样的大型服务系统。希望楼主多写些好文章！
August 11th, 2007 at 11:04 pm
这是一篇很棒的文章，里面有两篇回复也很好。高访问量的网站架构策略是很多网站开发时需要的。如果文章能更细节一些就更好了，建议楼主将这方面的内容写成一本书，我相信一定有很多人想要它，省去了后来者艰难的探索。
August 12th, 2007 at 5:23 am
看了大型网站的架够,很想了解关于大型网络架够的防DDOS处理是怎么搞的,刚建了个小站,经常被攻击,导致用户严重流失,已经快关了,所以希望,能对DDOS的攻击处理方法提供一些详细的方案!
August 17th, 2007 at 9:12 am
Hi Michael,
I’m developing my own eCommerce product based on DotNetNuke and your article gives me a lot of inspiration.
Thank you so much for sharing.
Frank
August 17th, 2007 at 10:38 am
客气了，欢迎常来交流。
September 13th, 2007 at 10:59 am
Michael大虾，我是一个Web方面的小菜鸟，目前工作是负责开发和维护公司的实时系统，不过一直对网站建设很感兴趣。
看了你的文章感觉非常受用，希望能和你更进一步的交流，或者说直接点就是向你请教向你学习。我的qq：116901807，非常急切的想和你联系，希望你能抽空和我聊聊，谢谢！！！
September 14th, 2007 at 1:34 am
最近几天公司事情实在太多，每天都工作到凌晨两三点，blog也少了，刚看到你的留言，欢迎和我交流，在blog里面有我的联系方式，包括QQ。
周末或者晚上11点以后我时间会稍微多一点，其他时间估计都很难有足够的时间聊天，请多多包涵和理解
September 29th, 2007 at 10:29 pm
有人说图片没必要分离，那是错的
虽然我没有做web，但是图片一般都是一些小文件
读的时候，非常占用io的，比起http建立所耗的时候更恐怖
一个磁盘的io数必定是非常有限的
我开发过一个文件服务器，所以很明白….
September 29th, 2007 at 10:53 pm
我们在做web server的cache的时候使用tangosol coherence.
September 30th, 2007 at 12:28 am
这位兄弟说太好了，说真的，中国的计算机科学最缺乏的就是对基础科学深刻理解的高手，这位兄弟接触的就是这个部分，是真正的高手。
September 30th, 2007 at 9:25 am
讲的都是最普通的，没有什么特别之处
September 30th, 2007 at 10:11 am
抛砖引玉，的确都不深入。
September 30th, 2007 at 3:09 pm
非常不多，虽然不是很详细。但是至少能给与像我这样还在黑暗中摸索的人给了一个探索的方向。
不知道能不能给几个机会讨论一下。我是从事。net方向的。
October 1st, 2007 at 8:34 am
交流一下
开发文件服务器做什么用？在什么平台下？
October 1st, 2007 at 2:57 pm
非常不错， 唯一的不足就是还是比较粗。 更细一些更好
还有很多问题 希望能得到解答： 如果更好的控制权限。 我们知道静态页面的好处是 快，而没有动态语言加载在里面 我们对文件控制就成了问题。 好比 假设我们有一个图库网站。 我们如何控制不同用户的权限？ 如果在用户可能猜出所有图片编码规则的前提下，很难控制。
用户数目的继续增加 如何管理数据库，它的 读取 锁定，如何保持高效。 前提是 数据库已经分散到了多个。 他们之间如何建立更强的逻辑的结构？和脏数据的问题？
October 1st, 2007 at 9:49 pm
图 片的权限有两种方法，一种方法是通过前端动态程序读取后端图片然后通过程序往外输出图片数据，这样可以实现任何复杂逻辑，不过性能不是很好，对于商业图片 之类的领域，是好的实现方式。 另一种就是通过判断referer之类的参数来进行图片服务器的设置，这个其实是可以通过web server的配置来得到的，如果使用Lighttpd做图片web server，可以结合 lua 语言来得到更复杂一些的逻辑处理，不过这种方法最大的优势是性能，在复杂逻辑方面还是无法满足需求的，理论上，编码规则是可以做到不可被猜到的，比如做成 不可逆再加上针对每个id的一个干扰随机salt值，然后再加以运算，相信是无法根据id猜到的。
更多的情况下，图片服务器对于除了防止非法引用外的需求外，其他的复杂逻辑是大部分的互联网产品遇不到的。
对于相当大的用户数据，建议使用LDAP取代普通的数据库存储，如果使用收费的商业的类似ORACLE一类的解决方案，另当别说。
如果一定使用普通的数据库分表或者分库，需要建立一个核心的索引表（库），存储分库或者分表的逻辑对应数据信息，通过这个索引数据达到逻辑结构的维护。
知道的大概就是这些，更深的内容我也谈不上太熟悉。
October 1st, 2007 at 11:50 pm
您好，看了您的文章，受益匪浅
我现在在开发一个php的社区程序，关于是否应该使用静态生成的问题，我曾经问过一些人，他们的答案大多认为这样做是不划算的。论坛程序是频繁更新的，在 每次回复都需要再次生成静态，生成静态本身是有开销的。这之间的权衡一直困扰着我。我想问您，如果10个浏览着中创造一个回复，那么我生成静态是否划算 呢？
October 2nd, 2007 at 6:28 pm
说 句实在话，除非你有非常好的逻辑便于实现静态话，比如更新用户在线状态、积分、广告投放、模板统一更新等。 否则我不建议论坛生成静态页面，如今因为smarty等模板引擎的缓存功能，配合各种各样的PHP缓存模块，加上硬件处理能力和硬件成本的降低，完全可以 用冬天语言来直接提供用户访问请求。
October 2nd, 2007 at 9:41 pm
确实啊，使用静态对于日后的管理会造成麻烦。
您的意思是推荐使用smarty等模板引擎的缓存功能来降低数据库的查询吗？
October 2nd, 2007 at 10:13 pm
我还是楼上的，事实上我总觉得用模板技术反而会加大程序的运算量，所以一直在考虑是否引入模板。也许smarty会好一些，但是对于内容频繁更新的网页还合适吗？
October 2nd, 2007 at 10:22 pm
建议结合APC、Xcache之类的PHP缓存技术提高PHP处理性能，然后结合类似Discuz的文件缓存进一步提高性能（也可以使用一些开源的 文件缓存代码），最后还可以参照Vbb的使用Memcached内存缓存的方法提高性能，在上述优化基础上，合理结合Smarty的缓存对一些静态块进行 缓存（事实也是文件缓存），这样基本上就能处理大型应用了。
October 2nd, 2007 at 10:32 pm
我曾经也有过类似的疑问，但是对于论坛来说，如果是想产品化并支持多样的皮肤、风格，那模板技术显然也是不可避免的需要采用。假设不需要这些，当然，PHP和HTML的混排一定是最高效的。
另外，模板技术的采用，对于如今的cpu处理运算能力来说，基本上消耗可以忽略不计，一个系统的性能往往是卡在IO操作、数据库、Socket连接等环节。
October 4th, 2007 at 10:43 am
（入门级问题）请问要实现图片服务器的架构，在具体程序中应该怎么做？包括文件服务器。
Baidu、Google上都不好搜。
期待楼主告知相关的一些文章或网站的链接：）
October 5th, 2007 at 10:35 pm
很高兴能看到这么经典的文章，感觉受益非浅！
我们现在也大量采用缓存、模块分离等方法来提高性能，同时降低系统的耦合性。
但是还是没有考虑到图片对WEB性能的消耗，图片分离将作为我们接下来的重点，谢谢您的指导。
我们程序是基于PHP模板技术的，准备将模板缓存起来以降低系统的IO消耗，不知道这样对系统性能是否有促进作用。
另，对开发一个行业网站群，也就是一套程序适合多套模板和风格，从而生成多个不同的行业网站，对于这样架构的网站，楼主可否提供好的建议，再次拜谢！
October 8th, 2007 at 3:18 pm
对于PHP的模板IO性能提高，可以通过Xcache、APC这样的PHP扩展模块来实现，比别的方式效果都要好。
一套程序对应多套模板和风格，这样的应用其实很多，比如blog、bbs之类的，还有一些网站的个人空间都是这样的策略，也没有什么特别需要注意 的，这样的网站最大的问题就是可能要注意设计一个合理的底层架构，比如用户系统、cookie使用、子域名等方面都要考虑合理。更多的问题就需要落实到细 节的时候才能针对性的来说。
October 8th, 2007 at 3:23 pm
图片服务器，考虑好下面几个方面：
1. 使用最轻量级的web server，配置web server支持功能简单、单一。
2. 存储时合理的目录散列策略，保证散列均匀、初期设计足够长期使用。
3. 备份、同步等需要考虑，如果你需要考虑CDN负载均衡之类的。
4. 合理的CDN配合squid缓存分布，这是图片服务器必须考虑的，否则无法满足各地用户对图片的快速访问。
5. 防盗链，如果需要的话（通过配置web server来实现）
6. 成本，大量图片带来的存储、带宽之类的消耗问题
… 其他可能一时我也没有想到的
October 13th, 2007 at 10:06 pm
[…] By Michael 转载请保留出处：俊麟 Michael’s blog (http://www.toplee.com/blog/?p=71) Trackback Url : […]
October 15th, 2007 at 5:36 pm
看了你的文章好是受益匪浅，
最近碰到一个难题，求经不顺。
特意来向你请教。
还是图片服务器的问题，
我有两台服务器，一台web,一台image
而且图片有60w张之多（接近20G）
如果我要在web上传图片，在image浏览图片
该怎么做？
先谢过！
October 29th, 2007 at 11:18 am
我有两台服务器，一台web,一台image
而且图片有60w张之多（接近20G）
如果我要在web上传图片，在image浏览图片
该怎么做？
我想在images服务器上使用squid作加速缓存，图片地址都使用images服务器的，图片上传到web后，访问时再缓存到images上。
October 29th, 2007 at 11:19 am
我想在images服务器上使用squid作加速缓存，图片地址都使用images服务器的，图片上传到web后，访问时再缓存到images上。
November 1st, 2007 at 11:20 am
好久没有看到这么好我文章和这么经典的回复，最近也在做一电子商务平台的架构，受益非浅。
这篇文章使我对大型网站的架构肃然起劲。
谢谢Michael，我会一直关注你的Blog。
November 30th, 2007 at 4:48 pm
受益颇多~~~~~~~~~~~~~~
December 28th, 2007 at 11:20 pm
首先感谢博主有这么好的帖
我有点困惑：smarty是不是很好呢？最近在搞个政府类的门户网站，目前是将各类服务分开的：2台WEB、1台数据库、1台文件(含一些上传的 image)+后台管理，采用的是php+html混排方式，目前速度并不是很理想，这也许和我配置的Linux服务器有关，呵呵，我配Linux还不是 拿手。
我想将程序采用smarty编写，不知道和纯静态有什么好处。
December 29th, 2007 at 12:16 am
Smarty 有个缓存功能，减少动态运算，降低服务器消耗。除此外最大的好处就是MVC结构的改善，让代码逻辑和界面展示的开发以及逻辑上可以分离。
关键的，如果代码效率高，服务器配置好，那种开发方式都不应该是瓶颈。 不过混排还是建议尽快改掉，太原始和不科学了
December 29th, 2007 at 1:00 pm
朋友,很开心你守侯在这样一个技术和心灵家园,我会支持你的,希望我们可以多交流.
我擅长应用服务器的开发,目前对于web网站的架构正在积极探索和研究,因为我有个不错的idea,我跟你差不多,也工作了将近7年了,也没混出来 什么名堂,期间也创过一次业,以失败告终,目前在上海一家证券软件的公司做应用服务器的架构与开发.我的msn是 hook_ghy@hotmail.com,我会加你的.
December 30th, 2007 at 7:09 pm
谢谢你的意见，我也是想换成Smarty，但不知道是否可行？我想知道大家都是怎么用PHP的。
再次感谢！
December 31st, 2007 at 4:11 pm
嘿 嘿，不错，说的还是比较全。不过貌似缺乏一定的条理。图片服务器的分离存储被单独作为一大条了。个人感觉这只是根据文件类型分离存储的一部分，目的是为了 减少浏览器和服务器的请求交互时间—这点上还有很多可以做的，比如合理安排 html 结构，让浏览器优先载入部分资源以尽快把页面显示给用户—这方面相关的东西 Oreilly 出了一本叫 High Performance Web Sites 上说的比较多。
另外，Cache 那块似乎缺点什么，尤其是内存 Cache ，可以蔓延到数据库、静态页面甚至说的图片等其他静态文件，甚至 xcache 等一般是把动态程序编译(加速一次)后 Cache 到内存(再次加速)里。
有些东西好象确实很难理清
January 12th, 2008 at 12:12 am
很开心能找到这个博客
本人也是个SA.既然作为SA
不可避免的就是面对越来越庞大的pv数值
以及需要对应的解决方案
在国内的网络环境来说
做大以后.CDN必不可少.或者至少是双线机房.
如果使用PHP的话
我建议大家使用FASTCGI方式
前端使用lighthttpd(会有内存泄漏问题)
或者使用ngnix(从sina博客SA的BLOG处获知)
ngnix+fastcgi我做过简单的压力测试
确实比apache好不止1,2倍
推荐大家使用.
其实架构方面的东西最后都会比较趋于同化.
SQUID(或者更好的varnish)+lighthttpd(或者更好的ngnix)+PHP(fastcgi)+memcached+Mysql(CLUSTER加上M/S模式或者加上实验性的MYSQL PROXY将读/写分开)
最最往后的.可能还是得看DBA和网站程序员的本事了.
希望能和大家交流.共同进步
我的博客www.hiadmin.com
January 12th, 2008 at 12:18 am
很多东西讲到后面就会越说越细了.
最后被支枝蔓蔓缠住吧.
呵呵.其实架构这方面
很多和程序有关
只是纯从物理结构以及服务器结构来说.没有程序配合还是不行的.
比如数据库分片.或者数据库读写分离等等.
甚至上传图片的路径和存放方式
都是程序端的东西.
很多时候.SA对这块东西挺无奈.而网站程序可能对一些系统性的东西又不是很了解.例如图片什么方法存储系统会响应的更好一些.
所以一个好的SA必然需要会编程.而且要善于调试程序.理解系统瓶颈.
谁说SA会比程序员轻松的.呵呵
February 6th, 2008 at 7:42 pm
The Future Of Web Design Is Content Management!…
The Future Of Web Design Is Content Management! By: Martin Lemieux…
February 18th, 2008 at 4:01 pm
大哥，多来点这类文章吧
February 21st, 2008 at 1:49 am
客气了，过些日子有空了是要准备多写一些技术文章，好久没有整理了，一直忙。
March 6th, 2008 at 4:17 pm
我感觉查询是不是很消耗网站服务器的资源？
March 10th, 2008 at 11:03 pm
Michael的文章写的太棒了，上边跟贴的人也很牛！学习了！
最近恰好开始学习架构方面的东西，热烈欢迎类似文章。向各位大虾致敬了！
March 11th, 2008 at 10:38 am
[quote]我感觉查询是不是很消耗网站服务器的资源？[/quote]
不同的网站有不同类型的瓶颈
例如交易型网站,则插入数据可能会是瓶颈.因为需要做事务来保证操作的不可分割性.
对于其他绝大多数类网站,查询一般来说是最消耗数据库服务器资源的操作.
至于网页服务器.则需要根据流量分析来判断了.因为即便有一块程序效率十分低下.但是调用次数非常少的话,也不会成为整体网站的瓶颈.
而只有10来句的语句,如果每个页面都要调用,也会成为整个网站的瓶颈.
March 11th, 2008 at 3:09 pm
就别夸我了，我好久没有继续整理技术文章了，这篇文章过去一年多了，实际上有些地方还是需要改进的，有些新的思路还值得和大家交流。
March 21st, 2008 at 2:10 am
最近一直对大型网站的架构感兴趣，无意之中搜到博主的文章，受益匪浅，谢谢～
March 21st, 2008 at 9:42 am
谢谢留言，欢迎常来交流，最近国外有本书《High Performance Web Sites》 刚出来，感觉有些细节说得还是不错的，更多的是从开发的角度在讲，回头我给整理一些读后感出来。
March 21st, 2008 at 10:10 am
High Performance Web Sites
博文视点应该已经开始翻译了.
是YAHOO的WEB PERFOEMEANCE团队的LEADER写的
很棒的一本书.
从页面设计一直讲到系统构架.
March 22nd, 2008 at 3:53 pm
这哥们好像要去google了，对yahoo还真是个小小的损失，呵呵。
当年在yahoo工作的时候，我就每天都沉浸在yahoo backyard engineering 网站上，全是多年来的精英们的经验，其实这些书里的东西，在里面也都能找到，只是没有这样明确的有调理的写成书。
这两天看了一部份这本书，暂时不评论，过些日子看完了再说，工作太忙了，还真是不一定每天都能有时间看。
March 22nd, 2008 at 10:36 pm
搞本英文影印版的来…:D
March 27th, 2008 at 3:51 pm
楼主，向您请教个问题。
我是用.net做的CS业务应用软件，也遇到了伸缩性和并发性的类似问题。
我采用的做法是：
1、在应用服务层，用分布式事务处理器，协调事务。
2、通过配置组件的连接字符串或程序设置来来决定（当前是通过配置文件），该组件的数据到底是保存在哪个数据库里的。
3、多个数据库的数据在应用服务器（层）进行数据组装，对客户端提供透明数据。
4、当单表数据量过大的时候，就再用数据分区处理。
5、对于一些变化不频繁的数据，再以Cache缓存。
在我进行的测试中暂时还没有出现过什么问题。
向楼主请教一下，这样处理方式会不会带来什么问题，可能什么地方会形成瓶颈？
March 28th, 2008 at 2:12 pm
昨晚在QQ上和您交流过了，半个老乡
今后保持联络，相互学习。
March 29th, 2008 at 5:23 pm
谢谢，楼主
以后要多麻烦您了。
April 2nd, 2008 at 5:44 pm
从两年前看到现在，用了一下午时间，不过这时间花的值，感谢楼主的奉献，再次感谢，这个我已经做下了记号。
April 9th, 2008 at 4:18 pm
一口气从头看完，受益不浅。
我是半路出家学编程的，很多架构和底层的东西都不熟，现在主要用.net+sql server2005+windows server 2003建网站，最近建了个建材网，全站不用静态页，也没使用缓存，有朋友说如果服务器不好，同时100人访问就可能不行了。
上面提到很多大型网站架构的知识，我是一知半解！楼主，对于我这样的情况，想在架构网站方面有所提高，您有何好建议呢？热切盼望您的帮忙！谢谢了！
April 15th, 2008 at 2:40 pm
Michael大大实在太好人了，百忙当中都可以抽时间详细回复我的问题，狂赞！o(∩_∩)o…
May 9th, 2008 at 2:15 pm
注意身体 呵呵！
May 29th, 2008 at 4:30 pm
受益匪淺啊`:) 謝謝樓主分享,也希望樓主能有更多關于高并發,高訪問量的的解決心得發布:,期待
May 31st, 2008 at 10:05 pm
还得需要大家多指点。
June 6th, 2008 at 10:28 am
[…] 说说大型高并发高负载网站的系统架构（更新） – 24,997 views […]
June 6th, 2008 at 5:38 pm
Michael，谢谢你，从文章到评论我一气看完了，除了感谢你的文章，也被大家这种浓烈的分享精神感动了，也学人家，在这里留个脚印。
June 10th, 2008 at 7:11 pm
Robert wrote related post…
Silk posts and stories…
June 15th, 2008 at 7:41 pm
想问下多大并发才算是高负载 像6.cn这样的站最大并发多少
June 15th, 2008 at 9:57 pm
可以从alexa上得到一个网站一天的pv数量，然后再一除就大概知道并发多少了。
视频网站和传统的网站pv还有较大差别，比如新浪的一个pv就是看一个页面或者新闻，但是视频网站一个pv可能是几十分钟的一个片子。
June 17th, 2008 at 5:02 pm
Blog 主您好，看了您的文章有一些问题想要请教一下，首先是目前我这边的情况，前端负载均衡使用netscale，然后分布到多个Squids，最后面是IIS 的WebSite，数据是html静态页面+xml存储在SAN上，存储时按ID号和类型区别分布在3套Cluster的20个映射驱动器上，目前遇到的 问题如下
1、前台UI在保存xml(非html，静态页面完全由后台程序生成，前台页面只是写数据库和xml然后发送MSMQ，最后由后台程序生成静态页面)时偶尔会报写缓存失败导致保存用户信息的xml无法生成，目前看来应该是大量并发的原因，不知道有什么建议？
2、由于目前我没有找到任何资料显示Squids可以一对多台后端服务器，所以现在使用的的是netscale–>Squids(多 台)–>netscale（2个VIP分组）–>每个分组中包含的IIS服务器，这样一来所有的网络流量在负载设备基本上就翻了一翻，所以想 请教一下有没有什么好的办法可以解决这个。
3、netscale的负载均衡策略可以选择最小连接数优先和最小响应时间优先以及平均分配，不知道使用哪一个会比较合理一些。
先谢谢了，我的msn是pollux_sky#hotmail.com(#换成@)，希望能有更多的机会交流。
June 18th, 2008 at 1:20 am
1. 大量并发导致写文件失败是很常见的情况，基本上也很难避免，减小并发写操作是追求的目标，这要从产品层面来考虑。
2. 从你的信息来看，你目前的架构是因为按照id分组的文件太多导致，不过我没有理解，既然是squid，为什么后端需要那么多的web服务器？ 理论上 Load balance->squids->web servers 就ok了，这方面我估计需要了解你的细节。
3. netscale我没有用过，也是第一次听说，不过从你现在的情况来看，我建议使用别的7层交换设备或者软件来替换，这样可以根据你描述的文件的id来进 行划分到不同的squid群，当然，如果继续使用netscale，由于大部分是静态页面，还是建议最小连接数的策略更高效。
June 18th, 2008 at 11:24 am
M总，领教了
June 18th, 2008 at 12:22 pm
嘿嘿，你手好了吗？ 好久没来打球了，周末过来一起玩儿吧。
好像你又开始折腾新东西了，小豆瓣 是新搞的吗？
June 18th, 2008 at 1:51 pm
感 谢Michael深夜回复，还是要多多注意身体啊。关于我的第2个问题，目前是这样子的，因为netscale设备的缓存机制是使用内存，非常小，所以主 要是用它作负载均衡这块的，而Squid才是用来做缓存代理服务的，缓存代理的对象就是后端的Web服务器的内容，但由于访问量相当大，现在的相状就是后 端的Web服务器比Squid服务器数量多出很多，而Squid因为是改hosts来实现指向某一台后端服务器，没有办法一对多，所以Squid只好再指 回负载均衡设备netscale，由它再一对多到后端的Web Server上面。
June 18th, 2008 at 4:24 pm
多台squid指向同一个web服务器，这是通常的做法，访问量大是增加squid，而不是增加web服务器，你尝试这样调整一下。
June 20th, 2008 at 10:11 pm
采 购squid服务器的预算被枪毙了，主要是要实现squid服务器和web服务器1对1增加的服务器不在少数，而且网站现在动态的东西也不少，squid 服务器并不能拦下来所有的访问请求，现有的web服务器平均iis并发连接都在30左右，个别二级域的站点服务器iis并发峰值都在100以上，所以 web服务器已经不能再减少了，想请问一下Michael，挪一些web服器换成squid服务器以达到1：1的比例我，不知道会不会比现在这种web服 务器多于squid服务器要好呢？
June 22nd, 2008 at 1:26 pm
这两天我的服务器硬盘有一块出错，昨晚刚恢复，没及时回复，抱歉。
如果你们的技术架构是你负责，你就应该要坚持你的观点，通常来说，web服务器一般都是部署在某个核心机房，各地的squid群起到负载均衡的作 用，从这个角度来说，如果各地的点比较多，squid必然会比web服务器多很多，这是常规的做法，如果你要想让web服务器也分布太多点，这样架构会很 复杂，没有太成熟的做法。
假如你的站点主要集中在一个点上，那你说的那种比例没有什么问题。
另外，你们的并发连接那个数量级，其实很小，因为你的内容主要还是静态的，虽然有动态的部分，实际上，动态的内容，有些情况下还是可以缓存的，需要更细致的去挖掘。
June 23rd, 2008 at 3:03 pm
谢 谢Michael，因为这个架构我也是接手在做，而关于这块的架构我目前只有建议的权限，决定权还是在高管层，squid也不是如您说的那样分布在各地， 而是同web server一样，在同一机房，用于解决各地的访问的缓存是通过购买CDN服务实现的。关于动态的一些缓存，目前只是做到了数据库级，即对一些可能系统开 销比较大，查询结果更改又不是太频繁的数据做了session database，不知道还有什么需要注意的地方。
June 25th, 2008 at 11:59 am
从架构上来说，有多少资源用多少资源也是原则，不能为了追求架构而不考虑投入也是不可取的，你目前的情况来看，代码、服务器本身的配置优化看来应该有空间可改进，这个需要根据你具体的产品和代码来判断了。
有关数据库的缓存，又回到我文章里面谈的一些观点了，大概就是这些方法，万变不离其宗。