May
19
搜索、照片、音乐、视频、混搭式应用(Mash-Ups)、维基(Wiki)、网络日志(Blog)、社区，还有那些来自各地展示天堂般美景的高清 晰图片——它们一起构成了Web2.0 热潮的丰富内容。但是对于正在成长的新一代Web服务来说，最重要的也许不是内容，而是通过浏览器窗口，让用户获得更有趣的体验。
要在这个Web世界里占有一席之地，你需要把握创建交互式网站的诀窍。而此类成功网站背后的诀窍和业务模式又是什么呢?
商界和技术领域的领袖们，包括亚马逊公司(Amazon.com，下称亚马逊)的杰夫·贝佐斯(Jeff Bezos)、微软公司(Microsoft，下称微软)的雷·奥奇(Ray Ozzie)和黛博拉·克拉帕蒂(Debra Chrapaty)、谷歌公司(Google，下称谷歌)的埃里克·施密特(Eric Schmidt)、Salesforce.com公司的马克·贝尼奥夫(Marc Benioff)和Skype公司的尼可拉斯·詹斯特罗姆(Niklas Zennstrom)最近在旧金山(San Francisco)共同探讨了Web新应用的未来。我们知道：Web2.0 需要全新的软件和服务器架构，以及不同以往的IT基础设施。下文将从6个方面分别讨论相关的核心话题：规模、内容管理、安全、开发技术、用户体验与社区。
规模效应
极少有人在网站上线不久就期待迎来百万或千万级别的访问量。但事情真的就这样发生了。根据互联网流量测量机构comScore Networks的数据显示，YouTube网站从一年前的十几万访问量上升到2006年9月的2,000多万次美国独立访问量(Unique Visitor)。
对多数网站来说，网络和IT架构其实并不如你想的那么重要。没错，没有可扩展和可用的IT资源，就谈不上业务——这是Web2.0公司共同的起步资 本，而不是将他们加以区分的个性化资源。尽管谷歌视频(Google Video)背后有成熟和强劲的技术架构，YouTube公司却超越了它，赢得了大量终端用户的支持，最后迫使谷歌购并了这个曾经的竞争对手。当然，基础 架构只是赌注。要稳操胜券还需拥有更多：创意、社区活力和独特的魅力等。
实际上，Web2.0 初创公司在开始阶段并不一定需要拥有自己的数据中心。在线零售商亚马逊就把自己的基础架构服务分割成小块，销售给一些需要强劲运算能力支持的初创公司。亚 马逊网络服务公司(Amazon Web Services)负责产品管理和研发人员关系的副总裁亚当·塞利普斯凯(Adam Selipsky)认为，尽管架构里的东西——比如服务器、操作系统、数据库软件、网络连接等都非常关键，但是对于用户体验而言却没有增加任何新内容。塞 利普斯凯指出，这些基础架构的东西可能会非常耗资源：公司需要投入70%的资源在搭建和维护自己的IT基础架构上。
与第一次Web扩张热潮不同，那时候大家都把购买上百万美元的服务器和迅速扩张奉为无上真理，而现在的2.0初创公司却不会纠缠于这些与运算能力有 关的底层部件。在线图片共享网站SmugMug的首席执行官(CEO)兼共同创始人唐·麦卡吉尔(Don MacAskill)表示：“我们当然不会认为底层数据中心是我们业务或价值定位的核心。”SmugMug公司采用亚马逊的S3存储服务，该服务通过存储 管理软件连接一个庞大的存储设备阵列，这样可以提升SmugMug公司内部的IT架构。
“这很简单，因为亚马逊为我们完成在多个数据中心和存储介质之间复制文件的复杂工作，”SmugMug公司总裁兼共同创始人克里斯·麦卡吉尔 (Chris MacAskill)认为。
SmugMug公司只有18位员工，却处理着18万付费用户和1.15亿张图片。“我们认为自己的价值定位是用户体验，” 唐·麦卡吉尔总结道，“这包括我们的Web用户界面和客户服务。”
麦卡吉尔认为，扩展客户服务也许比扩展服务器更困难。SmugMug公司在硅谷一个数据中心刚好与YouTube公司比邻，而两家公司都面临着同样 的基础架构挑战，如服务器、冗余与自愈型文件系统，他评论道：“如果我们不选择现成的商业化产品，而打算自己发明轮子，那实在有点犯傻。”
很多基础架构组成单元都有现成商品。根据在线视频编缉网站Eyespot的共同创始人兼首席技术官(CTO)大卫·杜达斯(David Dudas)介绍，这些现成商品中包括：价格便宜，但是功能强劲的英特尔(Intel)芯片服务器;由多个供应商提供的，并且价格比几年前大大降低的带宽 资源;廉价而且更节省空间的磁盘存储设备;以及开源软件，其中包括免费企业级操作系统(Fedora Linux)、关系型数据库(MySQL)、网络服务器(Apache)和应用框架(Ajax)。
杜达斯分析说，Eyespot公司的优势在于它能把这些零散的产品组合成一个可扩展规模的在线视频编缉平台。“如果你不知道怎样把它们正确地组合在 一起，那些廉价的硬件对你根本没用，当达到5,000万用户门槛时，差劲的架构会使系统发生故障或宕机。”
这的确是一个挑战。其中的一个要点是，把这些IT部件组合在一起，如服务器、数据库、路由器——但它们都能独立于彼此单独扩展。另一个要点是，认识 到不同的媒体服务功能，如流媒体、图片服务、网页服务、数据库等所需要的资源是不同的。
租用数据中心的方式也许只适用于当下。最近互联网排名增长第三位的Metacafe公司共同创始人兼CEO阿里克·泽涅克(Arik Czerniak)认为，到一定时候，“我们也需要建立自己的系统。”comScore Networks数据显示，去年9月Metacafe在全球有1,660万独立用户访问数，和4.92亿页读数。泽涅克认为，“到这种规模，要确保网站顺 畅地运行是一项巨大的技术挑战。”
共同创始人兼首席产品官(CPO)伊亚·赫索格(Eyal Hertzog)表示，Metacafe公司设计自己的软件架构，包括服务、模板库(Template Libraries)、统计评估、版本控制和架构监控等。同时，在线视频网站还依赖网络内容推送公司Limelight Networks公司的服务来缓存文件以提供更高效的访问，并由主机服务提供商RackSpace公司提供主机托管。Metacafe公司使用Lamp (代表Linux、 Apache、MySQL、 PHP等软件)组合软件包。
对Metacafe公司来说，有效的调整意味着原来需要几千台服务器现在则只需要几百台。 泽涅克指出：“如果我们现在还在用起步时的老一套技术，现在我们可能就需要一万台服务器了。”
内容管理
如果你要建一个网站，它包含照片、视频博客和其他用户生成内容(User-Generated Material)，你知道该如何应对吗?
对主要目标是产生内容、封装内容、然后推送给几百万用户的网站来说，挑战是找到管理这些文件的最佳方式。Web2.0 公司有可能需要开发自己的产品，因为Web2.0的交互性特点，如标签、评分、上传，在商业化的内容管理系统中支持得并不好。 网页设计公司Adaptive Path公司的用户体验策略总裁兼合伙人杰西·詹姆斯·加勒特(Jesse James Garrett)认为：“可扩展性是用户生成内容中的最大问题。”
加勒特表示，目前已有的内容管理架构不适合Web2.0公司，因为“Web2.0的内容管理定义与软件开发商在开发内容管理系统时想的完全两样。” 大多数企业使用的内容管理系统是为处理文件、电子表单、数据库和其他常规型文件而设计的，它们并没有考虑照片、视频或在线社区的需求。
照片共享网站SmugMug公司的CEO麦卡吉尔表示，他们的网站现在每天新增30万到50万张图片。他认为SmugMug公司的内容管理系统也不 是特别复杂，只是“一点‘胶水’，还不是大量的代码。”他最关心的是从亚马逊S3存储服务那里获得的大容量、万无一失的(Bulletproof)存储数 据，而与这个存储服务一起提供的还有用户友好的管理界面以及亚马逊的技术支持。这些“胶水”代码用来确保文件写操作失败时不会导致数据丢失。
使Web2.0公司的内容管理系统面临更大挑战的原因是他们还需要处理用户生成数据;这些公司做的每件事情都围绕着数据和数据管理。克里斯·麦卡吉 尔解释说，SmugMug公司在保存收到的文件之前，会做大量的工作，如确保图片的色彩空间无误，并提取可用作标题和关键字标签的信息，生成各种大小的复 件以加快显示速度。在这之后，亚马逊会把这些文件复制到多个数据中心和存储服务器上。
对Metacafe公司来说，挑战在于不但要处理大量的视频，还包括用户和研发人员产生的数据。这意味着需要选择合适的内容推送网络、追踪全球各地 的缓存时间、做各种研发工作以记录网页下载和数据库的压力。CEO泽涅克认为：“我们为用户做数据挖掘，返回收集的信息，这中间所牵涉的数据量非常之大， 在这点上Metacafe公司做得的确与众不同。”
该公司在生产和开发环境等各方面都用到了开源软件。首席产品官赫索格证实，公司用Wiki系统管理开发周期，同时用作主要的知识管理工具。“我们把 每个点子和想法都写到Wiki里去，再由公司人员评估和编辑。”他说，“一旦想法获得认可，我们继而为它订立标准、展开设计和编写测试计划。”
无论从哪方面来说，内容管理对Web2.0 公司来说都是困难的。但好消息是人们已在摸索中学习。加勒特指出，在20世纪90年代末期，许多网站碰了壁，因为他们缺乏可扩展性。他说：“过去5年里的 行业经验让我们获益良多，我们知道怎么从一开始就考虑灵活性，设计未来可以服务于庞大受众的系统架构。”
安全
Web2.0 有一个显而易见的特点：它并不比第一波网络热潮来得更安全。
Web2.0公司纷纷采用互动技术，他们会发现在更好地吸引和留住用户的同时，也把更大的风险带入了防火墙之内。
使用JavaScript的Ajax 开发者可以创建在访问者浏览器窗口里自动执行的程序。多种脚本语言都可在浏览器端执行并向服务器发出恶意代码，而JavaScript不过是其中最著名的 一种。其他脚本语言还包括微软的Visual Basic、以及微软开发的与JavaScript相对应的ECMAScript。另外还包括奥多比系统公司(Adobe)的 ActiveScript(另一种ECMAScript风格的脚本)，它可以在浏览器窗口通用的Flash播放器里运行，而98%～99%的互联网用户都 安装了这种播放器。
Ajax的一个组成部分是异步JavaScript，它是谷歌地图(Google Maps)应用的幕后功臣。谷歌地图可追踪用户光标在地图网格上的位置并把信息发回服务器。实际上，JavaScript程序是在告诉服务器，“用户正指 向北方。请返回更多他当前位置往北的数据。”
这种互动功能一直是个潜在威胁，因为尽管可以减轻危害，但却不可能完全根除它。对缺乏经验而意识不到自己的程序会出问题的程序员来说，经过培训也只 能做到缩减危害。因为Ajax应用程序可以在服务器端和浏览器里运行许多脚本代码，令黑客有可乘之机，攻击与应用程序通信的数据库。
即使经验丰富的程序员也可能中招。一年前，社交网络网站MySpace上存放着一位叫Samy的新用户的个人主页。在他提交的信息里有一个隐藏的 JavaScript蠕虫，它可以感染任何访问Samy空间的MySpace用户的浏览器，并把这段代码复制到该访问者的个人主页里。某种程度上，这纯粹 是场玩笑：Samy的目标是把“Samy是我的大英雄”这段文字复制到尽可能多的MySpace用户的“英雄”分类里。
感染开始迅速传播。在20小时内，这个JavaScript蠕虫已经感染了上百万MySpace用户。随着感染的增加，这个蠕虫引起的人为流量使 MySpace服务器陷于崩溃。MySpace谢绝就此事进行评论，但据Blog媒体Slashdot报道，该公司不得不临时关闭网站以清除感染。
这是为什么Web2.0 开发者必须从一开始就考虑安全问题的其中一个例子。Web2.0 技术的一个大危险在用户从表单或数据字段里提交回复时，开发者可能需要的是某个特定的输入，如名字或邮编，但很少有网站会仔细校验用户的输入。安全软件公 司SPI Dynamics公司的研发经理布赖恩·沙利文(Bryan Sullivan)评论说，“在客户端，你没法控制真正输入的内容。主导权全在用户手里。”
美国加州大学伯克利分校(University of California, Berkeley)计算机科学系的助教大卫·瓦格纳(David Wagner)警告说，可能有1,001种方式在HTML页面中隐藏JavaScript代码，比如在Wiki、MySpace、Yahoo Mail这类型的网站里。“但即使你拦截了其中1,000种，你还是可能会倒霉，”瓦格纳认为，“坏人更有优势。”
2005年春天，Yahoo的网页邮件(Web Mail)服务器就被一个用户上传的Yamanner蠕虫入侵了。如果一个懂行的用户在地址栏里输入一个SQL语句，这个语句就可以在服务器上可用的数据 库里得以执行。这种花招就叫SQL注入攻击。如果一个MySpace用户在自己的MySpace服务器上的网页里加入JavaScript蠕虫，蠕虫就可 以在访问者的浏览器窗口里执行。MySpace已经采取措施阻止会自我克隆的Samy蠕虫，但恶意程序的作者们下次肯定会尝试其他的方法。
不像以前的病毒，Samy蠕虫与操作系统无关。作为一种与网页相关的技术，Ajax不依赖于平台，而这也催生了一个跨平台蠕虫。无论苹果公司 (Apple)的Mac电脑、Linux工作站还是Windows PC都可以触发它。它默默地在后台窃取用户的信息，不会出现任何警告信息提示用户系统被感染了，而且还会继续感染他人。沙利文警告说：“想象一下，如果银 行网站上有Ajax蠕虫，那会是怎样的情景。”
轻量级开发
快速变更是Web2.0的一个标志性特点。网站可以非常迅速地添加和去除功能，有时候简直就是一天一个样。而一个固定的尺码肯定不适合所有的人。 Web2.0网站必须具有高度的可适应性，以适应用户常变的兴趣，对研发人员来说，轻量级的开发工具能帮上大忙。
两个受欢迎的选择是Ruby和Flash，与Ajax类似。Ajax是个轻量级的，基于浏览器的JavaScript和XML组合，已在谷歌地图和 其他许多互动网站里得到应用。Ruby和Flash这两种网站工具不像Ajax技术那么新，它们已有成熟的工具集支持。
传媒咨询公司Backchannelmedia公司就用 Ruby on Rails工具开发自己的网站，这是一套使用轻量级编程语言Ruby开发的专用网站平台。该网站为客户提供庞大的电视广告收视率数据库的快速访问。广告商 可以根据电视观众打到800免费电话的下单时间，结合当时不同地域投放电视广告的内容，来获知广告效果。
Backchannelmedia公司的首席信息官(CIO)玛德琳·诺兰德(Madeleine Noland) 表示，公司的25名员工里，有熟悉Java、Visual Studio .Net、Ruby和PHP技术的，一年多前他们决定重新设计客户交互服务，即电视直销(DRTV)研究时，最后选择了Ruby on Rails工具。 技术主管杰森?托伊(Jason Toy)证实这个服务只花了2个月就完成了，而如果选择Java则可能要花上9个月的时间。Ruby on Rails工具的代码量只有Java的十分之一。这个服务每天要添加250万条广告数据到数据库中，并根据用户请求提供上百万次不同的网页查询结果。
此外，耐克网上商店(NikeStore)是用Adobe系统(Adobe Systems)的Flash技术搭建的又一个交互式网站，Flash是可在浏览器窗口运行ActionScript脚本的多媒体引擎(该技术由 Adobe从Macromedia公司购并)，提供最新的购物互动体验。例如，访问者的光标移向标题的“男装”或“童装”位置，就会显现相关产品的下拉菜 单。而点击选中的货品，则会弹出一个新窗口，可展示不同颜色的同一产品和其他相关产品。改变就在瞬间发生，所在的页面无需重新加载。
用户体验
Web2.0 一个最大的挑战是如何定义和提高用户体验。谷歌用一个简洁、可快速加载的网页，展示了在搜索上可以做到多么与众不同。然而其他网页臃肿、速度缓慢的网站 ——比如MySpace——也仍然大获成功。成功的秘诀关键在于让用户感到惊喜和愉悦，在他们需要的功能以外，还提供连他们自己都未意识到会需要的功能。
极少有公司花在提高线上用户体验的时间比微软的MSN网站更多，它从1995年开始提供在线内容业务，至今仍然是互联网上最受欢迎的网站之一。但下 载音乐的人们会选择iTunes，而不会有选择微软的冲动，也没有类似iPod的产品制造者来和微软签订合作协议。人们会说去“Google”一下信息， 但不会说“MSN”一下信息。另外也是谷歌地图和谷歌地球(Google Earth)，而不是微软的虚拟地球(Virtual Earth)在地图定位和寻址上获得更多认可。所以到目前为止，显然微软网站还不太入引领潮流的年轻一代的法眼。
认识到这些问题，微软正计划一场Web革新。微软公司计划在这个财政年度花费5亿美元在互联网搜索引擎和其他可与谷歌和雅虎竞争的软件研发上。这个 投资计划里还包括一个新的数据中心，以支撑将来的家用型和商业软件。此外的产品包括新的Zune音乐播放器和音乐销售网站。微软的在线地图软件——搜索功 能广受好评的一个应用——也推出了较大的升级，把地图转换成赏心悦目的3D图像。
微软会用什么技术来提高虚拟地球的用户体验呢?我们可以从2006年早些时候的两项购并里一窥端倪。微软购并了Vexcel公司，该公司的 Photogrammetry技术可以通过航拍照片创建出城市和乡村的3D图像。微软还购并了Massive公司，这家软件公司的技术允许赞助商把广告插 入视频游戏里去。像谷歌和雅虎的地图软件一样，微软已经把虚拟地图的应用编程接口(API)授权给Best Buy、Expedia等公司。这样可以允许合作伙伴为这些应用注入自己的创新——毫无疑问这是十足的Web2.0特色。
谷歌去年年底发布了新版本的谷歌地球，也加入了一些新花样。包括来自发现网络公司(Discovery Networks)和国家地理杂志(National Geographic)对一些世界著名景点的描述、国家公园服务的扎营地点和旅游线路的信息，还提供把自己飞越谷歌地球上空时的影像录制成高清电视 (HDTV)的功能。这些功能呈现的前所未见景象，都可能会令用户眼前一亮。在这场对峙中，快速、细节和趣味性最为重要。
社区
Web2.0里最引人瞩目的一方面就是社区概念。从Web的初始阶段开始，大家都认可的一个观念就是，成功的网站需要锁定一批稳定的社区用户，他们 有共同的兴趣、乐于讨论和争辩、积极分享自己的音乐、照片、代码和观点。就在2006年10月底，谷歌购并了硅谷初创公司JotSpot公司，该公司用 Wiki软件让用户分享电子表单、日历和相册。
但在线社区也是一个令人困惑的概念。他们很少像这个词的表面含义那样意味着“我们都在这里”。奥莱利传媒公司(O’Reilly Media)首席执行官(CEO)蒂姆·奥莱利(Tim O’Reilly)在Web2.0 大会上直言不讳地说：“我讨厌‘社区’这个词，人们常用这个词来逃避认真思考什么是Web最核心的概念。”奥莱利传媒公司和 《InformationWeek》母公司CMP集团共同召开了Web2.0 大会。
在奥莱利的观点里，一些最成功的社区型网站实际上与人们印象中的和谐型互联网的分享想法可能完全背道而驰。比如在亚马逊鼓励下，其用户贡献了百万条 书评、乐评和产品评论等，这是在极力赚取用户的集体智慧(其中还包括许多的俏皮话)。“他们不断压榨用户，”奥莱利指出。亚马逊还是一个社区网站吗?
在线社区通常为用户提供交谈、分享和彼此联系的功能——但是最后对网站的业务模式却没有什么帮助。奥莱利认为这就是问题的关键。
以Flickr网站为例，这个雅虎旗下的照片共享网站非常受欢迎。分享照片是很不错，但Flickr网站充分利用了照片的单向链接，所以我可以看到 你的照片，而你却不知道我在看。这里面几乎没有交流可言。另一个非常受欢迎的网站是由用户驱动的Craigslist，但只是以本人的兴趣为中心，你回应 我的广告，而我受惠。
MySpace把社区的概念转化成了真金白银，但绝大多数模仿它的网站都失败了。甚至维基百科(Wikipedia)乌托邦式的理想是收集、编辑与 传播全球的知识，现在其实也是被一群核心作者主导着。
“真正的问题在于，用户可以为你的事业做出什么贡献?”奥莱利说道，“社区只不过是2.0大局里的一小部分。”
要在这个Web世界里占有一席之地，你需要把握创建交互式网站的诀窍。而此类成功网站背后的诀窍和业务模式又是什么呢?
商界和技术领域的领袖们，包括亚马逊公司(Amazon.com，下称亚马逊)的杰夫·贝佐斯(Jeff Bezos)、微软公司(Microsoft，下称微软)的雷·奥奇(Ray Ozzie)和黛博拉·克拉帕蒂(Debra Chrapaty)、谷歌公司(Google，下称谷歌)的埃里克·施密特(Eric Schmidt)、Salesforce.com公司的马克·贝尼奥夫(Marc Benioff)和Skype公司的尼可拉斯·詹斯特罗姆(Niklas Zennstrom)最近在旧金山(San Francisco)共同探讨了Web新应用的未来。我们知道：Web2.0 需要全新的软件和服务器架构，以及不同以往的IT基础设施。下文将从6个方面分别讨论相关的核心话题：规模、内容管理、安全、开发技术、用户体验与社区。
规模效应
极少有人在网站上线不久就期待迎来百万或千万级别的访问量。但事情真的就这样发生了。根据互联网流量测量机构comScore Networks的数据显示，YouTube网站从一年前的十几万访问量上升到2006年9月的2,000多万次美国独立访问量(Unique Visitor)。
对多数网站来说，网络和IT架构其实并不如你想的那么重要。没错，没有可扩展和可用的IT资源，就谈不上业务——这是Web2.0公司共同的起步资 本，而不是将他们加以区分的个性化资源。尽管谷歌视频(Google Video)背后有成熟和强劲的技术架构，YouTube公司却超越了它，赢得了大量终端用户的支持，最后迫使谷歌购并了这个曾经的竞争对手。当然，基础 架构只是赌注。要稳操胜券还需拥有更多：创意、社区活力和独特的魅力等。
实际上，Web2.0 初创公司在开始阶段并不一定需要拥有自己的数据中心。在线零售商亚马逊就把自己的基础架构服务分割成小块，销售给一些需要强劲运算能力支持的初创公司。亚 马逊网络服务公司(Amazon Web Services)负责产品管理和研发人员关系的副总裁亚当·塞利普斯凯(Adam Selipsky)认为，尽管架构里的东西——比如服务器、操作系统、数据库软件、网络连接等都非常关键，但是对于用户体验而言却没有增加任何新内容。塞 利普斯凯指出，这些基础架构的东西可能会非常耗资源：公司需要投入70%的资源在搭建和维护自己的IT基础架构上。
与第一次Web扩张热潮不同，那时候大家都把购买上百万美元的服务器和迅速扩张奉为无上真理，而现在的2.0初创公司却不会纠缠于这些与运算能力有 关的底层部件。在线图片共享网站SmugMug的首席执行官(CEO)兼共同创始人唐·麦卡吉尔(Don MacAskill)表示：“我们当然不会认为底层数据中心是我们业务或价值定位的核心。”SmugMug公司采用亚马逊的S3存储服务，该服务通过存储 管理软件连接一个庞大的存储设备阵列，这样可以提升SmugMug公司内部的IT架构。
“这很简单，因为亚马逊为我们完成在多个数据中心和存储介质之间复制文件的复杂工作，”SmugMug公司总裁兼共同创始人克里斯·麦卡吉尔 (Chris MacAskill)认为。
SmugMug公司只有18位员工，却处理着18万付费用户和1.15亿张图片。“我们认为自己的价值定位是用户体验，” 唐·麦卡吉尔总结道，“这包括我们的Web用户界面和客户服务。”
麦卡吉尔认为，扩展客户服务也许比扩展服务器更困难。SmugMug公司在硅谷一个数据中心刚好与YouTube公司比邻，而两家公司都面临着同样 的基础架构挑战，如服务器、冗余与自愈型文件系统，他评论道：“如果我们不选择现成的商业化产品，而打算自己发明轮子，那实在有点犯傻。”
很多基础架构组成单元都有现成商品。根据在线视频编缉网站Eyespot的共同创始人兼首席技术官(CTO)大卫·杜达斯(David Dudas)介绍，这些现成商品中包括：价格便宜，但是功能强劲的英特尔(Intel)芯片服务器;由多个供应商提供的，并且价格比几年前大大降低的带宽 资源;廉价而且更节省空间的磁盘存储设备;以及开源软件，其中包括免费企业级操作系统(Fedora Linux)、关系型数据库(MySQL)、网络服务器(Apache)和应用框架(Ajax)。
杜达斯分析说，Eyespot公司的优势在于它能把这些零散的产品组合成一个可扩展规模的在线视频编缉平台。“如果你不知道怎样把它们正确地组合在 一起，那些廉价的硬件对你根本没用，当达到5,000万用户门槛时，差劲的架构会使系统发生故障或宕机。”
这的确是一个挑战。其中的一个要点是，把这些IT部件组合在一起，如服务器、数据库、路由器——但它们都能独立于彼此单独扩展。另一个要点是，认识 到不同的媒体服务功能，如流媒体、图片服务、网页服务、数据库等所需要的资源是不同的。
租用数据中心的方式也许只适用于当下。最近互联网排名增长第三位的Metacafe公司共同创始人兼CEO阿里克·泽涅克(Arik Czerniak)认为，到一定时候，“我们也需要建立自己的系统。”comScore Networks数据显示，去年9月Metacafe在全球有1,660万独立用户访问数，和4.92亿页读数。泽涅克认为，“到这种规模，要确保网站顺 畅地运行是一项巨大的技术挑战。”
共同创始人兼首席产品官(CPO)伊亚·赫索格(Eyal Hertzog)表示，Metacafe公司设计自己的软件架构，包括服务、模板库(Template Libraries)、统计评估、版本控制和架构监控等。同时，在线视频网站还依赖网络内容推送公司Limelight Networks公司的服务来缓存文件以提供更高效的访问，并由主机服务提供商RackSpace公司提供主机托管。Metacafe公司使用Lamp (代表Linux、 Apache、MySQL、 PHP等软件)组合软件包。
对Metacafe公司来说，有效的调整意味着原来需要几千台服务器现在则只需要几百台。 泽涅克指出：“如果我们现在还在用起步时的老一套技术，现在我们可能就需要一万台服务器了。”
内容管理
如果你要建一个网站，它包含照片、视频博客和其他用户生成内容(User-Generated Material)，你知道该如何应对吗?
对主要目标是产生内容、封装内容、然后推送给几百万用户的网站来说，挑战是找到管理这些文件的最佳方式。Web2.0 公司有可能需要开发自己的产品，因为Web2.0的交互性特点，如标签、评分、上传，在商业化的内容管理系统中支持得并不好。 网页设计公司Adaptive Path公司的用户体验策略总裁兼合伙人杰西·詹姆斯·加勒特(Jesse James Garrett)认为：“可扩展性是用户生成内容中的最大问题。”
加勒特表示，目前已有的内容管理架构不适合Web2.0公司，因为“Web2.0的内容管理定义与软件开发商在开发内容管理系统时想的完全两样。” 大多数企业使用的内容管理系统是为处理文件、电子表单、数据库和其他常规型文件而设计的，它们并没有考虑照片、视频或在线社区的需求。
照片共享网站SmugMug公司的CEO麦卡吉尔表示，他们的网站现在每天新增30万到50万张图片。他认为SmugMug公司的内容管理系统也不 是特别复杂，只是“一点‘胶水’，还不是大量的代码。”他最关心的是从亚马逊S3存储服务那里获得的大容量、万无一失的(Bulletproof)存储数 据，而与这个存储服务一起提供的还有用户友好的管理界面以及亚马逊的技术支持。这些“胶水”代码用来确保文件写操作失败时不会导致数据丢失。
使Web2.0公司的内容管理系统面临更大挑战的原因是他们还需要处理用户生成数据;这些公司做的每件事情都围绕着数据和数据管理。克里斯·麦卡吉 尔解释说，SmugMug公司在保存收到的文件之前，会做大量的工作，如确保图片的色彩空间无误，并提取可用作标题和关键字标签的信息，生成各种大小的复 件以加快显示速度。在这之后，亚马逊会把这些文件复制到多个数据中心和存储服务器上。
对Metacafe公司来说，挑战在于不但要处理大量的视频，还包括用户和研发人员产生的数据。这意味着需要选择合适的内容推送网络、追踪全球各地 的缓存时间、做各种研发工作以记录网页下载和数据库的压力。CEO泽涅克认为：“我们为用户做数据挖掘，返回收集的信息，这中间所牵涉的数据量非常之大， 在这点上Metacafe公司做得的确与众不同。”
该公司在生产和开发环境等各方面都用到了开源软件。首席产品官赫索格证实，公司用Wiki系统管理开发周期，同时用作主要的知识管理工具。“我们把 每个点子和想法都写到Wiki里去，再由公司人员评估和编辑。”他说，“一旦想法获得认可，我们继而为它订立标准、展开设计和编写测试计划。”
无论从哪方面来说，内容管理对Web2.0 公司来说都是困难的。但好消息是人们已在摸索中学习。加勒特指出，在20世纪90年代末期，许多网站碰了壁，因为他们缺乏可扩展性。他说：“过去5年里的 行业经验让我们获益良多，我们知道怎么从一开始就考虑灵活性，设计未来可以服务于庞大受众的系统架构。”
安全
Web2.0 有一个显而易见的特点：它并不比第一波网络热潮来得更安全。
Web2.0公司纷纷采用互动技术，他们会发现在更好地吸引和留住用户的同时，也把更大的风险带入了防火墙之内。
使用JavaScript的Ajax 开发者可以创建在访问者浏览器窗口里自动执行的程序。多种脚本语言都可在浏览器端执行并向服务器发出恶意代码，而JavaScript不过是其中最著名的 一种。其他脚本语言还包括微软的Visual Basic、以及微软开发的与JavaScript相对应的ECMAScript。另外还包括奥多比系统公司(Adobe)的 ActiveScript(另一种ECMAScript风格的脚本)，它可以在浏览器窗口通用的Flash播放器里运行，而98%～99%的互联网用户都 安装了这种播放器。
Ajax的一个组成部分是异步JavaScript，它是谷歌地图(Google Maps)应用的幕后功臣。谷歌地图可追踪用户光标在地图网格上的位置并把信息发回服务器。实际上，JavaScript程序是在告诉服务器，“用户正指 向北方。请返回更多他当前位置往北的数据。”
这种互动功能一直是个潜在威胁，因为尽管可以减轻危害，但却不可能完全根除它。对缺乏经验而意识不到自己的程序会出问题的程序员来说，经过培训也只 能做到缩减危害。因为Ajax应用程序可以在服务器端和浏览器里运行许多脚本代码，令黑客有可乘之机，攻击与应用程序通信的数据库。
即使经验丰富的程序员也可能中招。一年前，社交网络网站MySpace上存放着一位叫Samy的新用户的个人主页。在他提交的信息里有一个隐藏的 JavaScript蠕虫，它可以感染任何访问Samy空间的MySpace用户的浏览器，并把这段代码复制到该访问者的个人主页里。某种程度上，这纯粹 是场玩笑：Samy的目标是把“Samy是我的大英雄”这段文字复制到尽可能多的MySpace用户的“英雄”分类里。
感染开始迅速传播。在20小时内，这个JavaScript蠕虫已经感染了上百万MySpace用户。随着感染的增加，这个蠕虫引起的人为流量使 MySpace服务器陷于崩溃。MySpace谢绝就此事进行评论，但据Blog媒体Slashdot报道，该公司不得不临时关闭网站以清除感染。
这是为什么Web2.0 开发者必须从一开始就考虑安全问题的其中一个例子。Web2.0 技术的一个大危险在用户从表单或数据字段里提交回复时，开发者可能需要的是某个特定的输入，如名字或邮编，但很少有网站会仔细校验用户的输入。安全软件公 司SPI Dynamics公司的研发经理布赖恩·沙利文(Bryan Sullivan)评论说，“在客户端，你没法控制真正输入的内容。主导权全在用户手里。”
美国加州大学伯克利分校(University of California, Berkeley)计算机科学系的助教大卫·瓦格纳(David Wagner)警告说，可能有1,001种方式在HTML页面中隐藏JavaScript代码，比如在Wiki、MySpace、Yahoo Mail这类型的网站里。“但即使你拦截了其中1,000种，你还是可能会倒霉，”瓦格纳认为，“坏人更有优势。”
2005年春天，Yahoo的网页邮件(Web Mail)服务器就被一个用户上传的Yamanner蠕虫入侵了。如果一个懂行的用户在地址栏里输入一个SQL语句，这个语句就可以在服务器上可用的数据 库里得以执行。这种花招就叫SQL注入攻击。如果一个MySpace用户在自己的MySpace服务器上的网页里加入JavaScript蠕虫，蠕虫就可 以在访问者的浏览器窗口里执行。MySpace已经采取措施阻止会自我克隆的Samy蠕虫，但恶意程序的作者们下次肯定会尝试其他的方法。
不像以前的病毒，Samy蠕虫与操作系统无关。作为一种与网页相关的技术，Ajax不依赖于平台，而这也催生了一个跨平台蠕虫。无论苹果公司 (Apple)的Mac电脑、Linux工作站还是Windows PC都可以触发它。它默默地在后台窃取用户的信息，不会出现任何警告信息提示用户系统被感染了，而且还会继续感染他人。沙利文警告说：“想象一下，如果银 行网站上有Ajax蠕虫，那会是怎样的情景。”
轻量级开发
快速变更是Web2.0的一个标志性特点。网站可以非常迅速地添加和去除功能，有时候简直就是一天一个样。而一个固定的尺码肯定不适合所有的人。 Web2.0网站必须具有高度的可适应性，以适应用户常变的兴趣，对研发人员来说，轻量级的开发工具能帮上大忙。
两个受欢迎的选择是Ruby和Flash，与Ajax类似。Ajax是个轻量级的，基于浏览器的JavaScript和XML组合，已在谷歌地图和 其他许多互动网站里得到应用。Ruby和Flash这两种网站工具不像Ajax技术那么新，它们已有成熟的工具集支持。
传媒咨询公司Backchannelmedia公司就用 Ruby on Rails工具开发自己的网站，这是一套使用轻量级编程语言Ruby开发的专用网站平台。该网站为客户提供庞大的电视广告收视率数据库的快速访问。广告商 可以根据电视观众打到800免费电话的下单时间，结合当时不同地域投放电视广告的内容，来获知广告效果。
Backchannelmedia公司的首席信息官(CIO)玛德琳·诺兰德(Madeleine Noland) 表示，公司的25名员工里，有熟悉Java、Visual Studio .Net、Ruby和PHP技术的，一年多前他们决定重新设计客户交互服务，即电视直销(DRTV)研究时，最后选择了Ruby on Rails工具。 技术主管杰森?托伊(Jason Toy)证实这个服务只花了2个月就完成了，而如果选择Java则可能要花上9个月的时间。Ruby on Rails工具的代码量只有Java的十分之一。这个服务每天要添加250万条广告数据到数据库中，并根据用户请求提供上百万次不同的网页查询结果。
此外，耐克网上商店(NikeStore)是用Adobe系统(Adobe Systems)的Flash技术搭建的又一个交互式网站，Flash是可在浏览器窗口运行ActionScript脚本的多媒体引擎(该技术由 Adobe从Macromedia公司购并)，提供最新的购物互动体验。例如，访问者的光标移向标题的“男装”或“童装”位置，就会显现相关产品的下拉菜 单。而点击选中的货品，则会弹出一个新窗口，可展示不同颜色的同一产品和其他相关产品。改变就在瞬间发生，所在的页面无需重新加载。
用户体验
Web2.0 一个最大的挑战是如何定义和提高用户体验。谷歌用一个简洁、可快速加载的网页，展示了在搜索上可以做到多么与众不同。然而其他网页臃肿、速度缓慢的网站 ——比如MySpace——也仍然大获成功。成功的秘诀关键在于让用户感到惊喜和愉悦，在他们需要的功能以外，还提供连他们自己都未意识到会需要的功能。
极少有公司花在提高线上用户体验的时间比微软的MSN网站更多，它从1995年开始提供在线内容业务，至今仍然是互联网上最受欢迎的网站之一。但下 载音乐的人们会选择iTunes，而不会有选择微软的冲动，也没有类似iPod的产品制造者来和微软签订合作协议。人们会说去“Google”一下信息， 但不会说“MSN”一下信息。另外也是谷歌地图和谷歌地球(Google Earth)，而不是微软的虚拟地球(Virtual Earth)在地图定位和寻址上获得更多认可。所以到目前为止，显然微软网站还不太入引领潮流的年轻一代的法眼。
认识到这些问题，微软正计划一场Web革新。微软公司计划在这个财政年度花费5亿美元在互联网搜索引擎和其他可与谷歌和雅虎竞争的软件研发上。这个 投资计划里还包括一个新的数据中心，以支撑将来的家用型和商业软件。此外的产品包括新的Zune音乐播放器和音乐销售网站。微软的在线地图软件——搜索功 能广受好评的一个应用——也推出了较大的升级，把地图转换成赏心悦目的3D图像。
微软会用什么技术来提高虚拟地球的用户体验呢?我们可以从2006年早些时候的两项购并里一窥端倪。微软购并了Vexcel公司，该公司的 Photogrammetry技术可以通过航拍照片创建出城市和乡村的3D图像。微软还购并了Massive公司，这家软件公司的技术允许赞助商把广告插 入视频游戏里去。像谷歌和雅虎的地图软件一样，微软已经把虚拟地图的应用编程接口(API)授权给Best Buy、Expedia等公司。这样可以允许合作伙伴为这些应用注入自己的创新——毫无疑问这是十足的Web2.0特色。
谷歌去年年底发布了新版本的谷歌地球，也加入了一些新花样。包括来自发现网络公司(Discovery Networks)和国家地理杂志(National Geographic)对一些世界著名景点的描述、国家公园服务的扎营地点和旅游线路的信息，还提供把自己飞越谷歌地球上空时的影像录制成高清电视 (HDTV)的功能。这些功能呈现的前所未见景象，都可能会令用户眼前一亮。在这场对峙中，快速、细节和趣味性最为重要。
社区
Web2.0里最引人瞩目的一方面就是社区概念。从Web的初始阶段开始，大家都认可的一个观念就是，成功的网站需要锁定一批稳定的社区用户，他们 有共同的兴趣、乐于讨论和争辩、积极分享自己的音乐、照片、代码和观点。就在2006年10月底，谷歌购并了硅谷初创公司JotSpot公司，该公司用 Wiki软件让用户分享电子表单、日历和相册。
但在线社区也是一个令人困惑的概念。他们很少像这个词的表面含义那样意味着“我们都在这里”。奥莱利传媒公司(O’Reilly Media)首席执行官(CEO)蒂姆·奥莱利(Tim O’Reilly)在Web2.0 大会上直言不讳地说：“我讨厌‘社区’这个词，人们常用这个词来逃避认真思考什么是Web最核心的概念。”奥莱利传媒公司和 《InformationWeek》母公司CMP集团共同召开了Web2.0 大会。
在奥莱利的观点里，一些最成功的社区型网站实际上与人们印象中的和谐型互联网的分享想法可能完全背道而驰。比如在亚马逊鼓励下，其用户贡献了百万条 书评、乐评和产品评论等，这是在极力赚取用户的集体智慧(其中还包括许多的俏皮话)。“他们不断压榨用户，”奥莱利指出。亚马逊还是一个社区网站吗?
在线社区通常为用户提供交谈、分享和彼此联系的功能——但是最后对网站的业务模式却没有什么帮助。奥莱利认为这就是问题的关键。
以Flickr网站为例，这个雅虎旗下的照片共享网站非常受欢迎。分享照片是很不错，但Flickr网站充分利用了照片的单向链接，所以我可以看到 你的照片，而你却不知道我在看。这里面几乎没有交流可言。另一个非常受欢迎的网站是由用户驱动的Craigslist，但只是以本人的兴趣为中心，你回应 我的广告，而我受惠。
MySpace把社区的概念转化成了真金白银，但绝大多数模仿它的网站都失败了。甚至维基百科(Wikipedia)乌托邦式的理想是收集、编辑与 传播全球的知识，现在其实也是被一群核心作者主导着。
“真正的问题在于，用户可以为你的事业做出什么贡献?”奥莱利说道，“社区只不过是2.0大局里的一小部分。”
May
19
这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构 了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环 境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是必须要面对的。
这里讨论一下大型网站需要注意和考虑的问题
1、海量数据的处理
众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个 索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何 级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。
2、数据并发的处理
在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而在 我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存 策略。
另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。
3、文件存贮的问题
对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文 件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个 巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。
也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何 解决?如果做分布式，那么我们的文件索引以及架构该如何规划。
所以我们不得不承认，文件存贮是个很不容易的问题
4、数据关系的处理
我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。
5、数据索引的问题
众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本会高 的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。
索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题，
6、分布式处理
对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面对一个绝大 的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。
7、Ajax的利弊分析
成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post 到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处 理是一目了然。对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。
8、数据安全性的分析
对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了(比如我们知道 的QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之 后，那么所谓的外挂，所谓的群发就会接踵而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实 现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空 间和qq空间的群发了。大家愿意试试，实际上并不是很难。
9、数据同步和集群的处理的问题
当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题 了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒或 者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题
10、数据共享的渠道以及OPENAPI趋势
Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到海内校内，都在考虑这个问题，它可以更有效的留住 用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口 的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。
这里讨论一下大型网站需要注意和考虑的问题
1、海量数据的处理
众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个 索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何 级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。
2、数据并发的处理
在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而在 我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存 策略。
另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。
3、文件存贮的问题
对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文 件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个 巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。
也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何 解决?如果做分布式，那么我们的文件索引以及架构该如何规划。
所以我们不得不承认，文件存贮是个很不容易的问题
4、数据关系的处理
我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。
5、数据索引的问题
众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本会高 的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。
索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题，
6、分布式处理
对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面对一个绝大 的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。
7、Ajax的利弊分析
成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post 到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处 理是一目了然。对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。
8、数据安全性的分析
对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了(比如我们知道 的QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之 后，那么所谓的外挂，所谓的群发就会接踵而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实 现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空 间和qq空间的群发了。大家愿意试试，实际上并不是很难。
9、数据同步和集群的处理的问题
当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题 了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒或 者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题
10、数据共享的渠道以及OPENAPI趋势
Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到海内校内，都在考虑这个问题，它可以更有效的留住 用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口 的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。
May
19
相信很多IT人士都有过搭建自己主页的经验，10多年前的个人主页都非常简单，很多由Frontpage构建，多属于静态HTML页面，最多加一点 特效而已。不过10年间，技术的进步是惊人的。现在，一个网站绝不可能仅仅由几个HTML页面构成。我们随便举一个例子，国内图片网站 yupoo.com，在 chinarank排名1000左右，而Alexa排名则为5000左右，这个网站不算大，就是这样一个中型站点，拥有超过60台服务器，架构中涉及的 Web服务器就包括了Lighttpd、Apache和 nginx。Yupoo的流量不算大，就已经拥有了60台服务器，事实上，排名前几位的网站，都拥有成千上万台服务器，如何协调这些服务器之间的工作负 载，如何统一指挥调度，如何维护这些服务器硬件都是棘手的挑战。
负载均衡：
负载均衡是所有大中型网站必备的部署。显然，大型网站每天上千万独立IP的访问量，一个Web服务器根本承担不了，网站后台必需有多台服务器共同工 作，因此各种负载均衡技术就应运而生了。
较早的负载均衡是DNS负载均衡。原理很简单，只要在域名解析的时候，将多个地址配置成同一个域名，负载均衡就完成了。不同用户点击同一个域名的时 候，实际上只解析给用户一个地址，这样用户实际上访问的是不同的Web服务器，就减轻了每个服务器的负担。这个DNS负载均衡方法，一般而言是随机抽取地 址。DNS负载均衡早期被广泛使用，优点是简单易用，但是DNS负载均衡还是有一些问题存在。如果某一台服务器发生了故障，而DNS的下一个刷新周期又没 到，这样就可能导致某些用户无法访问站点的情况发生。而另一个缺点在于DNS负载均衡随机性太强，比如一段时间内众多访问都被指向同一个地址，而另外的地 址却闲置，就造成了局部繁忙的不良现象。而且有时某处服务器正在运行其他应用而处于繁忙状态，DNS负载均衡也无从得知，而依旧平均的解析域名。
稍微复杂一点的负载均衡，是反向代理，当外部有请求到代理服务器，代理服务器再将该请求均匀的转发到内网的服务器上。这种方式被广泛采用，比如说上 面提到的又拍网yupoo.com，就采用了nginx作为反向代理。此外，现在还可以购买专业的硬件设备，比如 Plentyoffish.com(全球最大的婚介网站)就采用了网捷网络公司的Web交换器ServerIron作为硬件负载均 衡，ServerIron 能够有效地处理 16，000，000个并发连接，并且可以改善服务器负载均衡和缓冲转换，像ServerIron这类的硬件产品并非只有网捷一家提供，由于大型网站预算 充裕，因此也可以选择一些其他的硬件设备来做负载均衡。当然了，我们也别忽略了最基本的软件负载均衡——Windows Server就带有这样的功能。
负载均衡还有一个极为简单的方法，就是建立镜像站点。比如华军软件或者天空软件，都直接采用了镜像站点。这个方式很直接，省去了很多麻烦。以华军软 件园为例，登陆华军软件园的时候，我们将有多种选择，可选电信、网通等网络；而下载某一软件的时候，为了使用户得到更快的速度，天空和华军在中国各地都安 排了服务器，可以提供距离最近的下载服务。不过，也有一些麻烦，就是每一次选择都是人工手动选择。总之，这一系列负载均衡方法，都得以让大型网站的负载均 匀，不会有哪个服务器有太大的压力。
CDN：
CDN( Content Delivery Network)，内容分发网络也是大型网站必备的部署之一。CDN的原理不难理解，就是将网页内容存放到离用户更近的缓存服务器上，减少路由，从而加快 远距离的访问速度。比如说，你随意登陆一个国外小站，速度可能很慢。因为国外网站到国内的最终客户端的路径冗长，但是如果你登陆部署了CDN的网站，比如 Plentyoffish.com，你会发现速度非常快，跟国内的网站访问速度差异已经无法从感知上判断。依照Cache存放的位置不同，CDN也有一些 类别，不同的网站会根据具体需求，有不同的选择。CDN通常是由独立的CDN商提供的。举一个例子，就是网易，我的查询时间是2008年2月28日，我们 发现，同一个域名下的有很多个IP地址，这就说明了首页CDN的部署。
C:>nslookup www.163.com
Server: ns.lnpta.net.cn
Address: 202.96.64.68
Non-authoritative answer:
Name: www.cache.split.netease.com
Addresses: 202.108.9.37, 202.108.9.38, 202.108.9.39, 202.108.9.51
202.108.9.52, 202.108.9.31, 202.108.9.32, 202.108.9.33, 202.108.9.34
202.108.9.36
Aliases: www.163.com
而我们如果查询一个简单的个人网站，则不可能有CDN；另外，如果有兴趣，我们也可以仔细察看一个网站多个二级域名的CDN情况。
平台设计：
大型网站一般都有着非常复杂的与用户交互的内容，必须大量调用数据库，因此一个完善的数据库设计对于大型网站非常重要。例如上面提到的 Plentyoffish.com，这个站其实是个人网站，但流量大的惊人，该网站有一个主要的数据库，两个搜索数据库，早些时 候，plentyoffish.com的数据库设计问题频频，经常到数据库堵塞，所以站长花费时间最多的地方就是数据库优化。数据库优化没有什么特别的捷 径，其实很少有一次成型的完美数据库构建，只能是按照特定的需要来设计数据库，如有不足再去着手改进。不过大型网站还是有一些共性，比如说图片存储单独使 用图片数据库，尽量使用静态页面来减少数据库调用等等。
还有很多大型网站，都有着非常深厚的技术实力，可以开发属于自己的平台。比如说谷歌，Google.com就有着自己独特的平台，主要包括 GFS、MapReduce和 BigTable。因为海量数据存储，所以常规的数据库调用查询是非常恐怖的，每次查询都将调用百亿个页面，成千上万个并发检索足以使得谷歌系统崩溃，因 此Google File System将大量页面以独特的方法压缩之后再提供检索；整个系统一共包括超过两百个集群，再由MapReduce来协同作业。不仅仅谷歌，比如百度、中 搜等等网站也都有自己研发的独特的平台。
硬件配置：
大型网站的硬件配置一定就好吗？答案是否定的。比如说全球最大的网站谷歌，google.com的整个架构的基础是几十万台普通的PC级别服务器。 谷歌一些服务器的细节为商业机密，但是根据谷歌已经披露的资料显示，在2006年之前谷歌拥有45万台服务器，这些服务器都是非常普通的PC级服务器，甚 至硬盘接口都还是有些过时的IDE接口。这也是谷歌的独特架构决定的，而对比谷歌，维基百科则拥有非常强势的服务器，全部为SCSI硬盘，而且主要的主机 中都有多达6块硬盘，超过16GB内存。这比较容易理解，因为谷歌在全球拥有很多个数据中心，员工数量众多，完全有能力管理数以万计服务器的运行，而维基 百科则为非营利机构，主要依靠捐赠生存，员工数量非常稀少，因此必须配备强势的服务器。其实，每个网站都应该根据自己独特的情况来配置硬件，目前 1TB SATA硬盘已经步入了量产阶段，可是2年以前1TB的硬盘只能通过RAID 0来实现，可见硬件的更新速度非常惊人，所以即便预算充裕，在配置服务器的时候也应该多考虑实际用途，而不一定要拥有最好的配置。
总结：
以上只是大型网站的概括总结，其实每个网站都有自己独特的一面，所以以上的每一条规则都未必是死规定。比如说着重沟通的Twitter.com，本 质就是一个异步聊天室，因此静态页面就不见的有必要。总之，网站架构没有死定律，只要合适网站的，就是好的架构。
负载均衡：
负载均衡是所有大中型网站必备的部署。显然，大型网站每天上千万独立IP的访问量，一个Web服务器根本承担不了，网站后台必需有多台服务器共同工 作，因此各种负载均衡技术就应运而生了。
较早的负载均衡是DNS负载均衡。原理很简单，只要在域名解析的时候，将多个地址配置成同一个域名，负载均衡就完成了。不同用户点击同一个域名的时 候，实际上只解析给用户一个地址，这样用户实际上访问的是不同的Web服务器，就减轻了每个服务器的负担。这个DNS负载均衡方法，一般而言是随机抽取地 址。DNS负载均衡早期被广泛使用，优点是简单易用，但是DNS负载均衡还是有一些问题存在。如果某一台服务器发生了故障，而DNS的下一个刷新周期又没 到，这样就可能导致某些用户无法访问站点的情况发生。而另一个缺点在于DNS负载均衡随机性太强，比如一段时间内众多访问都被指向同一个地址，而另外的地 址却闲置，就造成了局部繁忙的不良现象。而且有时某处服务器正在运行其他应用而处于繁忙状态，DNS负载均衡也无从得知，而依旧平均的解析域名。
稍微复杂一点的负载均衡，是反向代理，当外部有请求到代理服务器，代理服务器再将该请求均匀的转发到内网的服务器上。这种方式被广泛采用，比如说上 面提到的又拍网yupoo.com，就采用了nginx作为反向代理。此外，现在还可以购买专业的硬件设备，比如 Plentyoffish.com(全球最大的婚介网站)就采用了网捷网络公司的Web交换器ServerIron作为硬件负载均 衡，ServerIron 能够有效地处理 16，000，000个并发连接，并且可以改善服务器负载均衡和缓冲转换，像ServerIron这类的硬件产品并非只有网捷一家提供，由于大型网站预算 充裕，因此也可以选择一些其他的硬件设备来做负载均衡。当然了，我们也别忽略了最基本的软件负载均衡——Windows Server就带有这样的功能。
负载均衡还有一个极为简单的方法，就是建立镜像站点。比如华军软件或者天空软件，都直接采用了镜像站点。这个方式很直接，省去了很多麻烦。以华军软 件园为例，登陆华军软件园的时候，我们将有多种选择，可选电信、网通等网络；而下载某一软件的时候，为了使用户得到更快的速度，天空和华军在中国各地都安 排了服务器，可以提供距离最近的下载服务。不过，也有一些麻烦，就是每一次选择都是人工手动选择。总之，这一系列负载均衡方法，都得以让大型网站的负载均 匀，不会有哪个服务器有太大的压力。
CDN：
CDN( Content Delivery Network)，内容分发网络也是大型网站必备的部署之一。CDN的原理不难理解，就是将网页内容存放到离用户更近的缓存服务器上，减少路由，从而加快 远距离的访问速度。比如说，你随意登陆一个国外小站，速度可能很慢。因为国外网站到国内的最终客户端的路径冗长，但是如果你登陆部署了CDN的网站，比如 Plentyoffish.com，你会发现速度非常快，跟国内的网站访问速度差异已经无法从感知上判断。依照Cache存放的位置不同，CDN也有一些 类别，不同的网站会根据具体需求，有不同的选择。CDN通常是由独立的CDN商提供的。举一个例子，就是网易，我的查询时间是2008年2月28日，我们 发现，同一个域名下的有很多个IP地址，这就说明了首页CDN的部署。
C:>nslookup www.163.com
Server: ns.lnpta.net.cn
Address: 202.96.64.68
Non-authoritative answer:
Name: www.cache.split.netease.com
Addresses: 202.108.9.37, 202.108.9.38, 202.108.9.39, 202.108.9.51
202.108.9.52, 202.108.9.31, 202.108.9.32, 202.108.9.33, 202.108.9.34
202.108.9.36
Aliases: www.163.com
而我们如果查询一个简单的个人网站，则不可能有CDN；另外，如果有兴趣，我们也可以仔细察看一个网站多个二级域名的CDN情况。
平台设计：
大型网站一般都有着非常复杂的与用户交互的内容，必须大量调用数据库，因此一个完善的数据库设计对于大型网站非常重要。例如上面提到的 Plentyoffish.com，这个站其实是个人网站，但流量大的惊人，该网站有一个主要的数据库，两个搜索数据库，早些时 候，plentyoffish.com的数据库设计问题频频，经常到数据库堵塞，所以站长花费时间最多的地方就是数据库优化。数据库优化没有什么特别的捷 径，其实很少有一次成型的完美数据库构建，只能是按照特定的需要来设计数据库，如有不足再去着手改进。不过大型网站还是有一些共性，比如说图片存储单独使 用图片数据库，尽量使用静态页面来减少数据库调用等等。
还有很多大型网站，都有着非常深厚的技术实力，可以开发属于自己的平台。比如说谷歌，Google.com就有着自己独特的平台，主要包括 GFS、MapReduce和 BigTable。因为海量数据存储，所以常规的数据库调用查询是非常恐怖的，每次查询都将调用百亿个页面，成千上万个并发检索足以使得谷歌系统崩溃，因 此Google File System将大量页面以独特的方法压缩之后再提供检索；整个系统一共包括超过两百个集群，再由MapReduce来协同作业。不仅仅谷歌，比如百度、中 搜等等网站也都有自己研发的独特的平台。
硬件配置：
大型网站的硬件配置一定就好吗？答案是否定的。比如说全球最大的网站谷歌，google.com的整个架构的基础是几十万台普通的PC级别服务器。 谷歌一些服务器的细节为商业机密，但是根据谷歌已经披露的资料显示，在2006年之前谷歌拥有45万台服务器，这些服务器都是非常普通的PC级服务器，甚 至硬盘接口都还是有些过时的IDE接口。这也是谷歌的独特架构决定的，而对比谷歌，维基百科则拥有非常强势的服务器，全部为SCSI硬盘，而且主要的主机 中都有多达6块硬盘，超过16GB内存。这比较容易理解，因为谷歌在全球拥有很多个数据中心，员工数量众多，完全有能力管理数以万计服务器的运行，而维基 百科则为非营利机构，主要依靠捐赠生存，员工数量非常稀少，因此必须配备强势的服务器。其实，每个网站都应该根据自己独特的情况来配置硬件，目前 1TB SATA硬盘已经步入了量产阶段，可是2年以前1TB的硬盘只能通过RAID 0来实现，可见硬件的更新速度非常惊人，所以即便预算充裕，在配置服务器的时候也应该多考虑实际用途，而不一定要拥有最好的配置。
总结：
以上只是大型网站的概括总结，其实每个网站都有自己独特的一面，所以以上的每一条规则都未必是死规定。比如说着重沟通的Twitter.com，本 质就是一个异步聊天室，因此静态页面就不见的有必要。总之，网站架构没有死定律，只要合适网站的，就是好的架构。
May
19
跟朋友聊天的时候，发现很多人对大型网站系统架构非常感兴趣，我也很感兴趣，经常会在家里2台笔记本和1台服务器组成的局域网环境里作些实验。我进 入IT行业的时间，大约是97，98年吧，那时候PC客户端软件最为盛行，做软件开发是一份很体面也很喜欢的工作。我从Win3.1上的VC1.5开始一 直到VC6.0，然后转为.Net开发，基本上都是从事客户端软件开发。本人的性格是危机意识向来严重，所以深感互联网必将盛行，传统软件必将走向没落， 于是转向了WEB开发。记得以前去某Portal网站应聘的时候，主考官就问我：你认为客户端开发和互联网开发有什么不同。我当时的回答是：互联网开发比 客户端软件开发简单多了，我再也不用考虑那么多的用户环境因素了，一点部署，何时何地都可用。
很多年过去了，我再想起当初我的回答，依然觉得那个回答是正确的。就产品开发层面来讲，互联网开发确实简单多了。这里首先澄清一个概念，我所说的互 联网开发并不是指所有的B/S应用，例如B/S方式的银行内部业务系统。我所说的互联网应用是指在互联网上服务于公众的应用。企业级的业务系统，它的特点 是业务逻辑是比较复杂的，但用户一般不太大；互联网应用则相反，业务逻辑一般很简单，但面对的是海量用户。
既然互联网应用开发的业务逻辑不复杂，但为什么大型网站都投入了那么多的技术人员呢？主要是因为运营的环境太复杂，这种复杂性形成的原因以下：
1、公开性
网站的服务是公开的，任何人都可以来访问，所以就会直接面对大量的不良用户，系统数据的安全面临很大的风险，一旦系统被攻入，结果将是灾难性的。
2、访问量大
访问量大，就意味着网站必须能够承受高并发大流量的考验，如果网站的服务能力和健壮性等达不到要求，你的系统就会被冲垮。
3、用户体验
用户体验要好，除了产品设计的因素之外，就要求访问网站的速度要快，具有高可用性，别用一会就挂。
网站各子系统如何进行部署，如何提高系统的健壮性和高可用性，如何实现网站的安全，如何提高访问速度，如何进行负载均衡，甚至于采用什么的硬件设 备，另外，网站发展的不同时期会可能会采用不同的架构，如何实现架构的平滑过渡，如何使目前的架构具有弹性，具备可扩展的能力，这都是大型网站必须解决的 问题，也是小网站成长过程中迟早会遇到的问题。我后面的文章将会逐步就这个话题展开。
网站机构包括网站的软件架构和系统架构两部分，软件架构主要是指子系统和逻辑层的划分结构；系统架构，一般是系统部署结构。
系统架构师的知识体系比较庞杂，所谓的见多识广，多数是由运维工程师成长起来的，他们开发能力不强，编码不多，但动手能力很强，脚本编写非常熟练， 经常会做各种类型的实验，密切跟踪最新技术最新产品的相关信息。当然，一个大型的网站，需要一个架构师团队，他们各自承担擅长领域的架构设计，比如安全架 构、存储架构等等。
我觉得一般的开发人员还是很难走上这条路的，这份工作需要经验，需要不断实践，但如果开发人员一旦走上了这条路，会有很大的发展，主要源于开发人员 的思考习惯和技术的深度。我的这系列文章，开发人员可以作为参考，比如如何开发可分布式部署的系统，另外很多朋友都是身兼数职，从开发到实施，到部署全部 包办。我个人深感精力有限，所以又特意找了几个朋友从Unix/Linux系统和Windows系统不同角度进行探索，以造福正在摸索中的朋友，有兴趣的 朋友也可以参与。
其实，这部分内容我一直在写，比如PHP深度探索系列，写了大量的关于apache的内容，我已经大体把apache代码阅读了一遍，很费时间，进 度缓慢，但我想这有助于我们理解apache的配置和调优。
在介绍网站架构之前，我们先介绍一些网站架构中最基础和常见的概念，以便更好的理解后面的有关负载均衡和分布式存储等技术。第一个，首先讲讲 CDN。
1、CDN是什么
CDN（Content Delivery Network），就是内容发布网或者内容分发网，它的主要目的：通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的 网络边缘，使用户可以就近取得所需的内容，从而提高用户访问网站的响应速度，提升用户体验，同时能够分散访问压力，把本来用户集中访问分散到各地去。网站 的内容提供商（比如新浪、搜狐、网易等等）使用CDN，就可以在宏观层解决一部分大流量、海量用户并发等令人头疼的问题。
2、CDN的组成
内容发布网(CDN)是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理４个要件，而内容管理和全局的网络流量 管理是CDN的核心所在。通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务，达到用户所要求的服务距用户仅 有”一跳”(Single Hop)之遥。
我们通常的内容发布模式都是将网站数据放到一处，然后应对来自世界各地的访问，我们多数考虑的是软件部署架构，很少考虑网络硬件架构。与之形成对比 的是，CDN则强调了网络在内容发布中的重要性。通过引入主动的内容管理层的和全局负载均衡，CDN从根本上区别于传统的内容发布模式。
内容提供商承担了他们不该干也干不好的内容发布服务。
3、互联网服务的产业链
纵观整个宽带服务的价值链，内容提供商和用户位于整个价值链的两端，中间依靠网络服务提供商将其串接起来。随着互联网工业的成熟和商业模式的变革， 在这条价值链上的角色越来越多也越来越细分，出现了内容运营商、托管服务提供商、骨干网络服务提供商、接入服务提供商等等。在这一条价值链上的每一个角色 都要分工合作、各司其职才能为客户提供良好的服务，从而带来多赢的局面。从内容与网络的结合模式上看，内容的发布已经走过了ICP的内容（应用）服务器和 IDC这两个阶段。IDC的热潮也催生了托管服务提供商这一角色。但是，IDC并不能解决内容的有效发布问题。内容位于网络的中心并不能解决骨干带宽的占 用和建立IP网络上的流量秩序。因此将内容推到网络的边缘，为用户提供就近性的边缘服务，从而保证服务的质量和整个网络上的访问秩序就成了一种显而易见的 选择，这就是CDN服务模式。CDN的建立解决了困扰内容运营商的内容”集中与分散”的两难选择，无疑对于构建良好的互联网价值链是有价值的，也是不可或 缺的最优网站加速服务。
4、CDN服务提供商
ChinaCache是中国最大的CDN服务提供商，是不是唯一未可知也。要想成为CDN服务提供商，恐怕要摆平电信、网通、铁通等等运营商，这得 需要什么样的能力和背景不得而知。它的服务节点在全球已经超过130个，其中国内节点超过80个，覆盖全国主要6大网络（所谓6线机房，就是这么来的）的 主要省份，象各大门户网站，比如新浪、网易等等都是租用了他们的服务。所以，你无论是在南方，或者北方，还是在北美，访问这些门户网站，感觉速度都很快， 最主要的原因之一就是CDN发挥了效果。一般小网站是用不起这服务的，所以慢点就慢点了吧，可以租用互联互通的6线机房，如果网络足够宽的话，用户也可以 忍受。如果想继续提升用户体验的话，就需要做一些网站镜像，部署在具有代表性的几个大城市，比如华南可以部署在广州，华东可以部署在上海，华北可以部署在 北京，不过内容镜像的过程，就需要自己去部署和维护。还有的网站，采用内容分割的方式，比如建立针对各地的分站，业务情况不同，可能部署的策略不同。 CDN可以认为是基础网络建设的一种策略。
前面介绍了cdn的一些原理和概念，以及提供cdn基础网络服务的途径。cdn看起来对于静态内容的，比如html,js,image是非常合适 的，通过cdn的部署，用户只需要一跳就可以访问到网站的内容。那对于动态内容怎么办呢？我回答一下：
动态内容按照存在形态可以分为三类。
第一类：内容长时间不需变化，这类内容一般是通过网页静化技术，实现动态内容转换成静态内容，从而达到cdn部署，典型的就是内容类网站，比如新 浪、搜狐、网易等等的内容发布系统cms，内容的增删改等管理工作被准实时同步到各个节点。
第二类：内容可能会短时间内发生变动，但是最终会稳定。比如论坛、博客等应用，这类服务提供的内容按照一定的时间间隔，实现批量静化，当然也有实时 静化，像Mop的大杂烩、网易社区就是使用了这样的策略。
第三类：内容会实时变化，非常个性化。比如邮箱应用，这类服务提供的内容无法实现静化，只能通过实行分区域部署和负载均衡等手段进行优化。
对于提供cdn服务的厂商来讲，静态内容的cdn自然没有问题，对于第三类服务，只能从通信链路层进行相应的优化。
对于很多网站的伪静化，有的出于Seo的考虑，有的出于安全性的考虑，手段基本上是rewrite Url。它只不过是一种外在的表现形式，与Html静化是两回事，它依然是一种动态内容。
1. 负载均衡的分类
负载均衡技术在网站运营过程中应用非常普遍，技术也很成熟。负载均衡技术按照软硬件形式分为软均衡和硬均衡。软均衡就是基于软件技术的均衡，硬均衡 是基于硬件技术的均衡；
按照网络协议划分又分为四层均衡和七层均衡。四层均衡就是基于OSI网络层的数据均衡，七层均衡是基于OSI应用层的数据均衡。
各种均衡方式在大型网站中均有采用，而且大多数情况下，是多种均衡方式的组合。
2. DNS轮询均衡
这种方式，算是比较独立的一种方式，不在上述划分之列，但使用比较广泛，一般用在网站最前端。你可以做个试验，在dos命令行中运行nslook命 令。比如：nslookup www.163.com，你会看到命令给出了一堆解析后的IP地址。这些地址就是www.163.com这个域名绑定的多条A记录。我们从浏览器发起的访 问请求http://www.163.com/，那么你输入的域名首先需要经过DNS服务器进行解析，Dns服务器的解析的过程就是按照A记录的顺序，依 次分配IP地址。Dns轮询方式实现均衡就是利用这个原理，在一个域名下面绑定N个IP地址，访问请求被均衡到不同的设备。Dns轮询方式提供的IP地 址，在大型网站中往往是一个集群的地址，可能是均衡交换机也可能是均衡服务器。对于小网站的话，挂接多台服务器也没有问题。
DNS轮询均衡的优点：
1、零成本：只是在Dns服务器上绑定几个A记录，域名注册商一般都提供；
2、部署简单：就是在网络拓扑进行设备扩增，然后在Dns服务器上添加记录。
DNS轮询均衡的缺点：
1、流量分配不均：Dns解析过程其实环节很多，而且是一种层层缓存的机制，你的dns服务器虽然进行更新，但是客户机、以及网络上其它的dns服 务器不会实时更新，所以流量很难保证100%的平均。目前，dns服务器都提供了多种手段可以调整dns轮询分配的策略，但是确实无法保证很完美的均衡。
2、健康检查：Dns服务器中A记录地址中的某一台服务器宕机，DNS服务器是无法知道的，仍旧会将访问分配到此服务器。所以需要人员或者工具进行 实时检测，在某台机器宕机之后，把备份机推上生产线，如果想要从A记录地址摘除某个地址，这个通知过程需要几个小时甚至更久才能扩散到所有的客户机。
Dns轮询方式推到服务的最前端还是很有效的，它通过最原始的方式，把访问用户映射到不同的服务集群上。对于大型网站来讲，对外服务的IP地址是不 可能经常变动的，而且后端的集群一旦宕掉，可以迅速推上冗余集群。再加上，一般都是经过CDN部署，服务被拆分到各个局部，所以在运营过程中不会产生太大 的影响。
3. OSI七层模型
我们接下来讲讲七层均衡。要理解四七层均衡的原理，就先要回忆一下大学课本里学的网络七层模型(OSI)。
OSI是一个开放性的通行系统互连参考模型，他是一个定义的非常好的协议规范。OSI模型有7层结构，每层都可以有几个子层。
OSI七层模型是一个很好的理论模型，但是在实际应用中都做了裁剪。尤其是TCP/IP的盛行，把7层结构压成了4层，
所以很多人都批评OSI七层模型过于复杂，但是作为一个完整的全面的网络模型，还是被大家非常认可的。OSI的7层从上到下分别是应用层、表示层、 会话层、传输层、网络层、数据链路层、物理层。
OSI 7层的功能描述：
（1）应用层：与其他计算机进行通讯的一个应用，它是对应应用程序的通信服务的。例如，一个没有通信功能的字处理程序就不能执行通信的代码，从事字 处理工作的程序员也不关心OSI的第7层。但是，如果添加了一个传输文件的选项，那么字处理器的程序员就需要实现OSI的第7层。示 例：telnet，HTTP,FTP,WWW,NFS,SMTP等。
（2）表示层：这一层的主要功能是定义数据格式及加密。例如，FTP允许你选择以二进制或ASII格式传输。如果选择二进制，那么发送方和接收方不 改变文件的内容。如果选择ASII格式，发送方将把文本从发送方的字符集转换成标准的ASII后发送数据。在接收方将标准的ASII转换成接收方计算机的 字符集。示例：加密，ASII等。
（3）会话层：他定义了如何开始、控制和结束一个会话，包括对多个双向小时的控制和管理，以便在只完成连续消息的一部分时可以通知应用，从而使表示 层看到的数据是连续的，在某些情况下，如果表示层收到了所有的数据，则用数据代表表示层。示例：RPC，SQL等。
（4）传输层：这层的功能包括是否选择差错恢复协议还是无差错恢复协议，及在同一主机上对不同应用的数据流的输入进行复用，还包括对收到的顺序不对 的数据包的重新排序功能。示例：TCP，UDP，SPX。
（5）网络层：这层对端到端的包传输进行定义，他定义了能够标识所有结点的逻辑地址，还定义了路由实现的方式和学习的方式。为了适应最大传输单元长 度小于包长度的传输介质，网络层还定义了如何将一个包分解成更小的包的分段方法。示例：IP,IPX等。
（6）数据链路层：他定义了在单个链路上如何传输数据。这些协议与被讨论的歌种介质有关。示例：ATM，FDDI等。
（7）物理层：OSI的物理层规范是有关传输介质的特性标准，这些规范通常也参考了其他组织制定的标准。连接头、针、针的使用、电流、电流、编码及 光调制等都属于各种物理层规范中的内容。物理层常用多个规范完成对所有细节的定义。
作者：王泽宾，系统架构师。先后供职于九城、新浪等公司，长期负责产品研发和技术管理等相关工作。
很多年过去了，我再想起当初我的回答，依然觉得那个回答是正确的。就产品开发层面来讲，互联网开发确实简单多了。这里首先澄清一个概念，我所说的互 联网开发并不是指所有的B/S应用，例如B/S方式的银行内部业务系统。我所说的互联网应用是指在互联网上服务于公众的应用。企业级的业务系统，它的特点 是业务逻辑是比较复杂的，但用户一般不太大；互联网应用则相反，业务逻辑一般很简单，但面对的是海量用户。
既然互联网应用开发的业务逻辑不复杂，但为什么大型网站都投入了那么多的技术人员呢？主要是因为运营的环境太复杂，这种复杂性形成的原因以下：
1、公开性
网站的服务是公开的，任何人都可以来访问，所以就会直接面对大量的不良用户，系统数据的安全面临很大的风险，一旦系统被攻入，结果将是灾难性的。
2、访问量大
访问量大，就意味着网站必须能够承受高并发大流量的考验，如果网站的服务能力和健壮性等达不到要求，你的系统就会被冲垮。
3、用户体验
用户体验要好，除了产品设计的因素之外，就要求访问网站的速度要快，具有高可用性，别用一会就挂。
网站各子系统如何进行部署，如何提高系统的健壮性和高可用性，如何实现网站的安全，如何提高访问速度，如何进行负载均衡，甚至于采用什么的硬件设 备，另外，网站发展的不同时期会可能会采用不同的架构，如何实现架构的平滑过渡，如何使目前的架构具有弹性，具备可扩展的能力，这都是大型网站必须解决的 问题，也是小网站成长过程中迟早会遇到的问题。我后面的文章将会逐步就这个话题展开。
网站机构包括网站的软件架构和系统架构两部分，软件架构主要是指子系统和逻辑层的划分结构；系统架构，一般是系统部署结构。
系统架构师的知识体系比较庞杂，所谓的见多识广，多数是由运维工程师成长起来的，他们开发能力不强，编码不多，但动手能力很强，脚本编写非常熟练， 经常会做各种类型的实验，密切跟踪最新技术最新产品的相关信息。当然，一个大型的网站，需要一个架构师团队，他们各自承担擅长领域的架构设计，比如安全架 构、存储架构等等。
我觉得一般的开发人员还是很难走上这条路的，这份工作需要经验，需要不断实践，但如果开发人员一旦走上了这条路，会有很大的发展，主要源于开发人员 的思考习惯和技术的深度。我的这系列文章，开发人员可以作为参考，比如如何开发可分布式部署的系统，另外很多朋友都是身兼数职，从开发到实施，到部署全部 包办。我个人深感精力有限，所以又特意找了几个朋友从Unix/Linux系统和Windows系统不同角度进行探索，以造福正在摸索中的朋友，有兴趣的 朋友也可以参与。
其实，这部分内容我一直在写，比如PHP深度探索系列，写了大量的关于apache的内容，我已经大体把apache代码阅读了一遍，很费时间，进 度缓慢，但我想这有助于我们理解apache的配置和调优。
在介绍网站架构之前，我们先介绍一些网站架构中最基础和常见的概念，以便更好的理解后面的有关负载均衡和分布式存储等技术。第一个，首先讲讲 CDN。
1、CDN是什么
CDN（Content Delivery Network），就是内容发布网或者内容分发网，它的主要目的：通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的 网络边缘，使用户可以就近取得所需的内容，从而提高用户访问网站的响应速度，提升用户体验，同时能够分散访问压力，把本来用户集中访问分散到各地去。网站 的内容提供商（比如新浪、搜狐、网易等等）使用CDN，就可以在宏观层解决一部分大流量、海量用户并发等令人头疼的问题。
2、CDN的组成
内容发布网(CDN)是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理４个要件，而内容管理和全局的网络流量 管理是CDN的核心所在。通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务，达到用户所要求的服务距用户仅 有”一跳”(Single Hop)之遥。
我们通常的内容发布模式都是将网站数据放到一处，然后应对来自世界各地的访问，我们多数考虑的是软件部署架构，很少考虑网络硬件架构。与之形成对比 的是，CDN则强调了网络在内容发布中的重要性。通过引入主动的内容管理层的和全局负载均衡，CDN从根本上区别于传统的内容发布模式。
内容提供商承担了他们不该干也干不好的内容发布服务。
3、互联网服务的产业链
纵观整个宽带服务的价值链，内容提供商和用户位于整个价值链的两端，中间依靠网络服务提供商将其串接起来。随着互联网工业的成熟和商业模式的变革， 在这条价值链上的角色越来越多也越来越细分，出现了内容运营商、托管服务提供商、骨干网络服务提供商、接入服务提供商等等。在这一条价值链上的每一个角色 都要分工合作、各司其职才能为客户提供良好的服务，从而带来多赢的局面。从内容与网络的结合模式上看，内容的发布已经走过了ICP的内容（应用）服务器和 IDC这两个阶段。IDC的热潮也催生了托管服务提供商这一角色。但是，IDC并不能解决内容的有效发布问题。内容位于网络的中心并不能解决骨干带宽的占 用和建立IP网络上的流量秩序。因此将内容推到网络的边缘，为用户提供就近性的边缘服务，从而保证服务的质量和整个网络上的访问秩序就成了一种显而易见的 选择，这就是CDN服务模式。CDN的建立解决了困扰内容运营商的内容”集中与分散”的两难选择，无疑对于构建良好的互联网价值链是有价值的，也是不可或 缺的最优网站加速服务。
4、CDN服务提供商
ChinaCache是中国最大的CDN服务提供商，是不是唯一未可知也。要想成为CDN服务提供商，恐怕要摆平电信、网通、铁通等等运营商，这得 需要什么样的能力和背景不得而知。它的服务节点在全球已经超过130个，其中国内节点超过80个，覆盖全国主要6大网络（所谓6线机房，就是这么来的）的 主要省份，象各大门户网站，比如新浪、网易等等都是租用了他们的服务。所以，你无论是在南方，或者北方，还是在北美，访问这些门户网站，感觉速度都很快， 最主要的原因之一就是CDN发挥了效果。一般小网站是用不起这服务的，所以慢点就慢点了吧，可以租用互联互通的6线机房，如果网络足够宽的话，用户也可以 忍受。如果想继续提升用户体验的话，就需要做一些网站镜像，部署在具有代表性的几个大城市，比如华南可以部署在广州，华东可以部署在上海，华北可以部署在 北京，不过内容镜像的过程，就需要自己去部署和维护。还有的网站，采用内容分割的方式，比如建立针对各地的分站，业务情况不同，可能部署的策略不同。 CDN可以认为是基础网络建设的一种策略。
前面介绍了cdn的一些原理和概念，以及提供cdn基础网络服务的途径。cdn看起来对于静态内容的，比如html,js,image是非常合适 的，通过cdn的部署，用户只需要一跳就可以访问到网站的内容。那对于动态内容怎么办呢？我回答一下：
动态内容按照存在形态可以分为三类。
第一类：内容长时间不需变化，这类内容一般是通过网页静化技术，实现动态内容转换成静态内容，从而达到cdn部署，典型的就是内容类网站，比如新 浪、搜狐、网易等等的内容发布系统cms，内容的增删改等管理工作被准实时同步到各个节点。
第二类：内容可能会短时间内发生变动，但是最终会稳定。比如论坛、博客等应用，这类服务提供的内容按照一定的时间间隔，实现批量静化，当然也有实时 静化，像Mop的大杂烩、网易社区就是使用了这样的策略。
第三类：内容会实时变化，非常个性化。比如邮箱应用，这类服务提供的内容无法实现静化，只能通过实行分区域部署和负载均衡等手段进行优化。
对于提供cdn服务的厂商来讲，静态内容的cdn自然没有问题，对于第三类服务，只能从通信链路层进行相应的优化。
对于很多网站的伪静化，有的出于Seo的考虑，有的出于安全性的考虑，手段基本上是rewrite Url。它只不过是一种外在的表现形式，与Html静化是两回事，它依然是一种动态内容。
1. 负载均衡的分类
负载均衡技术在网站运营过程中应用非常普遍，技术也很成熟。负载均衡技术按照软硬件形式分为软均衡和硬均衡。软均衡就是基于软件技术的均衡，硬均衡 是基于硬件技术的均衡；
按照网络协议划分又分为四层均衡和七层均衡。四层均衡就是基于OSI网络层的数据均衡，七层均衡是基于OSI应用层的数据均衡。
各种均衡方式在大型网站中均有采用，而且大多数情况下，是多种均衡方式的组合。
2. DNS轮询均衡
这种方式，算是比较独立的一种方式，不在上述划分之列，但使用比较广泛，一般用在网站最前端。你可以做个试验，在dos命令行中运行nslook命 令。比如：nslookup www.163.com，你会看到命令给出了一堆解析后的IP地址。这些地址就是www.163.com这个域名绑定的多条A记录。我们从浏览器发起的访 问请求http://www.163.com/，那么你输入的域名首先需要经过DNS服务器进行解析，Dns服务器的解析的过程就是按照A记录的顺序，依 次分配IP地址。Dns轮询方式实现均衡就是利用这个原理，在一个域名下面绑定N个IP地址，访问请求被均衡到不同的设备。Dns轮询方式提供的IP地 址，在大型网站中往往是一个集群的地址，可能是均衡交换机也可能是均衡服务器。对于小网站的话，挂接多台服务器也没有问题。
DNS轮询均衡的优点：
1、零成本：只是在Dns服务器上绑定几个A记录，域名注册商一般都提供；
2、部署简单：就是在网络拓扑进行设备扩增，然后在Dns服务器上添加记录。
DNS轮询均衡的缺点：
1、流量分配不均：Dns解析过程其实环节很多，而且是一种层层缓存的机制，你的dns服务器虽然进行更新，但是客户机、以及网络上其它的dns服 务器不会实时更新，所以流量很难保证100%的平均。目前，dns服务器都提供了多种手段可以调整dns轮询分配的策略，但是确实无法保证很完美的均衡。
2、健康检查：Dns服务器中A记录地址中的某一台服务器宕机，DNS服务器是无法知道的，仍旧会将访问分配到此服务器。所以需要人员或者工具进行 实时检测，在某台机器宕机之后，把备份机推上生产线，如果想要从A记录地址摘除某个地址，这个通知过程需要几个小时甚至更久才能扩散到所有的客户机。
Dns轮询方式推到服务的最前端还是很有效的，它通过最原始的方式，把访问用户映射到不同的服务集群上。对于大型网站来讲，对外服务的IP地址是不 可能经常变动的，而且后端的集群一旦宕掉，可以迅速推上冗余集群。再加上，一般都是经过CDN部署，服务被拆分到各个局部，所以在运营过程中不会产生太大 的影响。
3. OSI七层模型
我们接下来讲讲七层均衡。要理解四七层均衡的原理，就先要回忆一下大学课本里学的网络七层模型(OSI)。
OSI是一个开放性的通行系统互连参考模型，他是一个定义的非常好的协议规范。OSI模型有7层结构，每层都可以有几个子层。
OSI七层模型是一个很好的理论模型，但是在实际应用中都做了裁剪。尤其是TCP/IP的盛行，把7层结构压成了4层，
所以很多人都批评OSI七层模型过于复杂，但是作为一个完整的全面的网络模型，还是被大家非常认可的。OSI的7层从上到下分别是应用层、表示层、 会话层、传输层、网络层、数据链路层、物理层。
OSI 7层的功能描述：
（1）应用层：与其他计算机进行通讯的一个应用，它是对应应用程序的通信服务的。例如，一个没有通信功能的字处理程序就不能执行通信的代码，从事字 处理工作的程序员也不关心OSI的第7层。但是，如果添加了一个传输文件的选项，那么字处理器的程序员就需要实现OSI的第7层。示 例：telnet，HTTP,FTP,WWW,NFS,SMTP等。
（2）表示层：这一层的主要功能是定义数据格式及加密。例如，FTP允许你选择以二进制或ASII格式传输。如果选择二进制，那么发送方和接收方不 改变文件的内容。如果选择ASII格式，发送方将把文本从发送方的字符集转换成标准的ASII后发送数据。在接收方将标准的ASII转换成接收方计算机的 字符集。示例：加密，ASII等。
（3）会话层：他定义了如何开始、控制和结束一个会话，包括对多个双向小时的控制和管理，以便在只完成连续消息的一部分时可以通知应用，从而使表示 层看到的数据是连续的，在某些情况下，如果表示层收到了所有的数据，则用数据代表表示层。示例：RPC，SQL等。
（4）传输层：这层的功能包括是否选择差错恢复协议还是无差错恢复协议，及在同一主机上对不同应用的数据流的输入进行复用，还包括对收到的顺序不对 的数据包的重新排序功能。示例：TCP，UDP，SPX。
（5）网络层：这层对端到端的包传输进行定义，他定义了能够标识所有结点的逻辑地址，还定义了路由实现的方式和学习的方式。为了适应最大传输单元长 度小于包长度的传输介质，网络层还定义了如何将一个包分解成更小的包的分段方法。示例：IP,IPX等。
（6）数据链路层：他定义了在单个链路上如何传输数据。这些协议与被讨论的歌种介质有关。示例：ATM，FDDI等。
（7）物理层：OSI的物理层规范是有关传输介质的特性标准，这些规范通常也参考了其他组织制定的标准。连接头、针、针的使用、电流、电流、编码及 光调制等都属于各种物理层规范中的内容。物理层常用多个规范完成对所有细节的定义。
作者：王泽宾，系统架构师。先后供职于九城、新浪等公司，长期负责产品研发和技术管理等相关工作。
May
19
之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结 果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇 文章中将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，文 中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
架构演变第一步：物理分离webserver和数据库
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这 个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而 这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶 段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住 了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞 争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加， 发现系统又开始变的有些慢了，在尝 到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策 略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等。
架构演变第四步：数据缓存
在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是 开始变慢，经过查找，可能会发现系 统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完 毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
架构演变第五步： 增加webserver
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加 一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有：
1、 如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；
2、如何保持状态 信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、如何 保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；
4、如何让上传文件这些类似的功能继续正 常，这个时候通常会考虑的机制是使用共享文件系统或存储等；
在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了 以往的速度。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等）、 主备技术（包括但不限于ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共 享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。
架构演变第六步：分库
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、 更新的这些操作的部分数据库连接的 资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普 遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；
但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很 高的要求的。
架构演变第七步：分表、DAL和分布式缓存
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工 作，当然，这不可避免的会需要对程序 进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个 在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个 阶段可 能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察 和折磨，终于是将大量的数据缓存转移到分布式缓存上了。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistent hash算法等；
DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的 封装等；
架构演变第八步：增加更多的webserver
在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天， 发现系统的访问又开始有变慢的趋势 了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢，这还好办，一般来说，这个时候也会有些钱了，于是添加一些webserver服务器，在这个添加 webserver服务器的过程，有可能会出现几种挑战：
1、Apache的软负载或LVS软负载等无法承担巨大的web访问量（请求连接数、网 络流量等）的调度了，这个时候如果经费允许的话，会采取的方案是购 买硬件负载，例如F5、Netsclar、Athelon之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载 集群中；
2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分布式文件系 统等；
在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的解决方案就是不断的添加webserver。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
到了这一步，随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高，这个时候要求对所采用的技术都要有 更为深入的理解，并需要根据网站的需求来做更加定制性质的产品。
架构演变第九步：数据读写分离和廉价存储方案
突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导 致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离 的方案，当然，这个方案要实现并不 容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一 些更为廉价的存储方案，例如BigTable这种。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解，同时会要求具备自行实现的技术；
廉价存储方案要求对OS的文件存储有深入的掌握和理解，同时要求对采用的语言在文件这块的实现有深入的掌握。
架构演变第十步：进入大型分布式应用时代和廉价服务器群梦想时代
经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加webserver就可以支撑越来越高的访问量 了，对于大型网站而言，人气的重要毋 庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大 了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦， 因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导 致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将 系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战：
1、拆成分布式后需要 提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；
2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理 和系统依赖关系的控制等；
3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。
经过这一步， 差不多系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么多次演变过程吸取的经验来采用 其他各种各样的方法来支撑着越来越高的访问量。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步涉及的知识体系非常的多，要求对通信、远程调用、消息机制等有深入的理解和掌握，要求的都是从理论、硬件级、操作 系统级以及所采用的语言的实现都有清楚的理解。
运维这块涉及的知识体系也非常的多，多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。
说起来确实不怎么费力，整个网站架构的经典演变过程都和上面比较的类似，当然，每步采取的方案，演变的步骤有可能有不 同，另外，由于网站的业务不同，会有不同的专业技术的需求，这篇blog更多的是从架构的角度来讲解演变的过程，当然，其中还有很多的技术也未在此提及， 像数据库集群、数据挖掘、搜索等，但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量，因此在真实的发 展过程中还会有很多的不同，另外一个大型网站要做到的远远不仅仅上面这些，还有像安全、运维、运营、服务、存储等，要做好一个大型的网站真的很不容易，写 这篇文章更多的是希望能够引出更多大型网站架构演变的介绍。
原文地址：http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html
架构演变第一步：物理分离webserver和数据库
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这 个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而 这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶 段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住 了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞 争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加， 发现系统又开始变的有些慢了，在尝 到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策 略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等。
架构演变第四步：数据缓存
在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是 开始变慢，经过查找，可能会发现系 统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完 毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
架构演变第五步： 增加webserver
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加 一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有：
1、 如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；
2、如何保持状态 信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、如何 保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；
4、如何让上传文件这些类似的功能继续正 常，这个时候通常会考虑的机制是使用共享文件系统或存储等；
在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了 以往的速度。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等）、 主备技术（包括但不限于ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共 享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。
架构演变第六步：分库
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、 更新的这些操作的部分数据库连接的 资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普 遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；
但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很 高的要求的。
架构演变第七步：分表、DAL和分布式缓存
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工 作，当然，这不可避免的会需要对程序 进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个 在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个 阶段可 能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察 和折磨，终于是将大量的数据缓存转移到分布式缓存上了。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistent hash算法等；
DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的 封装等；
架构演变第八步：增加更多的webserver
在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天， 发现系统的访问又开始有变慢的趋势 了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢，这还好办，一般来说，这个时候也会有些钱了，于是添加一些webserver服务器，在这个添加 webserver服务器的过程，有可能会出现几种挑战：
1、Apache的软负载或LVS软负载等无法承担巨大的web访问量（请求连接数、网 络流量等）的调度了，这个时候如果经费允许的话，会采取的方案是购 买硬件负载，例如F5、Netsclar、Athelon之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载 集群中；
2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分布式文件系 统等；
在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的解决方案就是不断的添加webserver。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
到了这一步，随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高，这个时候要求对所采用的技术都要有 更为深入的理解，并需要根据网站的需求来做更加定制性质的产品。
架构演变第九步：数据读写分离和廉价存储方案
突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导 致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离 的方案，当然，这个方案要实现并不 容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一 些更为廉价的存储方案，例如BigTable这种。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解，同时会要求具备自行实现的技术；
廉价存储方案要求对OS的文件存储有深入的掌握和理解，同时要求对采用的语言在文件这块的实现有深入的掌握。
架构演变第十步：进入大型分布式应用时代和廉价服务器群梦想时代
经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加webserver就可以支撑越来越高的访问量 了，对于大型网站而言，人气的重要毋 庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大 了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦， 因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导 致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将 系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战：
1、拆成分布式后需要 提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；
2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理 和系统依赖关系的控制等；
3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。
经过这一步， 差不多系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么多次演变过程吸取的经验来采用 其他各种各样的方法来支撑着越来越高的访问量。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步涉及的知识体系非常的多，要求对通信、远程调用、消息机制等有深入的理解和掌握，要求的都是从理论、硬件级、操作 系统级以及所采用的语言的实现都有清楚的理解。
运维这块涉及的知识体系也非常的多，多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。
说起来确实不怎么费力，整个网站架构的经典演变过程都和上面比较的类似，当然，每步采取的方案，演变的步骤有可能有不 同，另外，由于网站的业务不同，会有不同的专业技术的需求，这篇blog更多的是从架构的角度来讲解演变的过程，当然，其中还有很多的技术也未在此提及， 像数据库集群、数据挖掘、搜索等，但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量，因此在真实的发 展过程中还会有很多的不同，另外一个大型网站要做到的远远不仅仅上面这些，还有像安全、运维、运营、服务、存储等，要做好一个大型的网站真的很不容易，写 这篇文章更多的是希望能够引出更多大型网站架构演变的介绍。
原文地址：http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html
