Jun
1
一、不要过设计：never over design
这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计 大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构Web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做 出最快最有效的响应。
eBay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是eBay架构师的能力有问题，他们 设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架 构。
Web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计， 是不现实的。
二、Web架构生命周期：Web architecture‘s life cycle
既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你。
所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下 一个10倍间的增长。
google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然 而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的。
三、缓存：Cache
空间换取时间，缓存永远计算机设计的重中之重，从CPU到IO，到处都可以看到缓存的身影，Web架构设计重，缓存设计必不可少，关于怎样设计合理 的缓 存，JBossCache的创始人，淘宝的创始人是这样说的：其实设计Web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而Web缓存，简单快 速为好。
缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中， 采用怎样的同步策略常常需要和业务绑定。
老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列 表，MemCache也是一个常常用到的工具。
Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，My SQL提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?
我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于 请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存。
四、核心模块一定要自己开发：DIY your core module
这点我们是深有体会。钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的。如果涉及，那么就要小心了，因 为当访问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全 掌握其代码是非常可怕的。
五、合理选择数据存储方式：reasonable data storage
我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什 么不干脆用文件来代替他呢？
首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能：一个是数据存储，一个是数据检索。
在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的TSQL就知道了。
select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id
select a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d,review as e where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id and a.Id=e.Reviewid group by a.Id ……………………………………….
我们可以看出需要数据库关联，排序的能力，这个能力在某些情况下非常重要，但是如果你的网站的常规操作，全是这样复杂的逻辑，那效率一定是非常低 的，所以我们常常在数据库里加入许多冗余字段，来减小简单查询时关联等操作带来的压力，我们看看下面这张图，可以看到数据库的设计重心，和网站(指内容型 社区)需要面对的问题实际是有一些偏差的。
同样其他一些软件产品也遇到同样的问题所以具我了解，有许多特殊的运用都有自己设计的特殊数据存储结构与方法，比如有的大型服务程序采取树形数据存 储结构，Lucene使用文件来存储索引和文件。
从另外一个角度上看，使用数据库，意味着数据和表现是完全分离的（这当然是经典的设计思路），也就是说当需要展示数据时，不得不需要一个转换的过 程，也可以说是绑定的过程，当网站具备一定规模的时候，数据库往往成为效率的瓶颈，所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑定。
这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫，而是我们在设计数据的持久化时，需要根据实际情况来选择存储方式，而数据库不过是其中一 个选项。
六、搞清楚谁是最重要的人：Who’s the most important guy?
在用例需求分析的时候常常讲到涉众，就是和你的设计息息相关的人，在Web中我们一定以为最重要的涉众莫过于用户了。在一个传统的互动社区开发中， 最重要的东西是内容，用户产生内容，所以用户就是上帝，至于内容挑选工具，不就是给坐我后面三排的妹妹们用的吗？凑或行了，实在有问题我就在数据里手动帮 你加得了。
这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题：实际上网站每天产生的内容非常的多，普通人是不可能看完 的，而编辑负责把精华的内容推荐到首页上，所以很多用户读到的内容其实都依赖于编辑的推荐，所以设计让编辑工作方便的工具也是非常重要， 有时甚至是最重要的。
七、不要执着于文档：Don’t be crazy about document
Web开发的文档重要吗？什么文档最重要？我的看法是Web开发中交流>文档，现在大的软件公司比较流行的做法是：
注重产品设计文档，在这种方法里，产品文档非常详尽，并且没有歧义，开发人员基于设计文档开发，测试人员基于设计文档制定测试方案，任何新人都可以 通过阅读产品设计文档来了解项目的概况。
而Web项目从概念到实现的时间是非常短的，而且越短越好，并且由于变化迅速，要想写出完整的产品和需求文档是几乎不可能的，大多数情况是等你写出 完备的文档，项目早就是另外一个样子，但是没有文档的问题是，如果团队发生变化，添加新成员怎样才能了解软件的结构和概念呢?一种是每个人都了解软件的整 个结构，除非你的团队整体消失，否则任何一个人都能够担当培养新人的责任，这种面对面交流比文档有效率很多。
于是就有了前office开发者，现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差，他说：“我们的项目是吵出来的”，我听完会心一笑。
八、团队：team
不要专家团队，而要外科手术式的团队。你的团队里一定要有清道夫，需要有弓箭手，让他们和项目一起成长，才是项目负责人的最大成就。
总 结：架构是一种权衡
Web开发的特点是是：没有太复杂的技术难点，一切在于迅速的把握需求，其实这正式敏捷开发的要旨所在，一切都可以非常快速的建立，非常快速的重 构，我们的开发工具，底层库和框架，包括搜索引擎和web文档提供的帮助，都提我们供给了敏捷的能力。
此外，相应的，最有效率的交流方式必须留给 Web开发，那就是面对面，不要太担心你的设计不能被完备的文档所保留下来，他们会以交流，代码和小卡片的方式保存下来。
人的因素会更加重要，无论是对用户的需求，还是开发人员的素质。
这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计 大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构Web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做 出最快最有效的响应。
eBay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是eBay架构师的能力有问题，他们 设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架 构。
Web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计， 是不现实的。
二、Web架构生命周期：Web architecture‘s life cycle
既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你。
所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下 一个10倍间的增长。
google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然 而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的。
三、缓存：Cache
空间换取时间，缓存永远计算机设计的重中之重，从CPU到IO，到处都可以看到缓存的身影，Web架构设计重，缓存设计必不可少，关于怎样设计合理 的缓 存，JBossCache的创始人，淘宝的创始人是这样说的：其实设计Web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而Web缓存，简单快 速为好。
缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中， 采用怎样的同步策略常常需要和业务绑定。
老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列 表，MemCache也是一个常常用到的工具。
Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，My SQL提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?
我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于 请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存。
四、核心模块一定要自己开发：DIY your core module
这点我们是深有体会。钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的。如果涉及，那么就要小心了，因 为当访问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全 掌握其代码是非常可怕的。
五、合理选择数据存储方式：reasonable data storage
我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什 么不干脆用文件来代替他呢？
首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能：一个是数据存储，一个是数据检索。
在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的TSQL就知道了。
select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id
select a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d,review as e where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id and a.Id=e.Reviewid group by a.Id ……………………………………….
我们可以看出需要数据库关联，排序的能力，这个能力在某些情况下非常重要，但是如果你的网站的常规操作，全是这样复杂的逻辑，那效率一定是非常低 的，所以我们常常在数据库里加入许多冗余字段，来减小简单查询时关联等操作带来的压力，我们看看下面这张图，可以看到数据库的设计重心，和网站(指内容型 社区)需要面对的问题实际是有一些偏差的。
同样其他一些软件产品也遇到同样的问题所以具我了解，有许多特殊的运用都有自己设计的特殊数据存储结构与方法，比如有的大型服务程序采取树形数据存 储结构，Lucene使用文件来存储索引和文件。
从另外一个角度上看，使用数据库，意味着数据和表现是完全分离的（这当然是经典的设计思路），也就是说当需要展示数据时，不得不需要一个转换的过 程，也可以说是绑定的过程，当网站具备一定规模的时候，数据库往往成为效率的瓶颈，所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑定。
这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫，而是我们在设计数据的持久化时，需要根据实际情况来选择存储方式，而数据库不过是其中一 个选项。
六、搞清楚谁是最重要的人：Who’s the most important guy?
在用例需求分析的时候常常讲到涉众，就是和你的设计息息相关的人，在Web中我们一定以为最重要的涉众莫过于用户了。在一个传统的互动社区开发中， 最重要的东西是内容，用户产生内容，所以用户就是上帝，至于内容挑选工具，不就是给坐我后面三排的妹妹们用的吗？凑或行了，实在有问题我就在数据里手动帮 你加得了。
这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题：实际上网站每天产生的内容非常的多，普通人是不可能看完 的，而编辑负责把精华的内容推荐到首页上，所以很多用户读到的内容其实都依赖于编辑的推荐，所以设计让编辑工作方便的工具也是非常重要， 有时甚至是最重要的。
七、不要执着于文档：Don’t be crazy about document
Web开发的文档重要吗？什么文档最重要？我的看法是Web开发中交流>文档，现在大的软件公司比较流行的做法是：
注重产品设计文档，在这种方法里，产品文档非常详尽，并且没有歧义，开发人员基于设计文档开发，测试人员基于设计文档制定测试方案，任何新人都可以 通过阅读产品设计文档来了解项目的概况。
而Web项目从概念到实现的时间是非常短的，而且越短越好，并且由于变化迅速，要想写出完整的产品和需求文档是几乎不可能的，大多数情况是等你写出 完备的文档，项目早就是另外一个样子，但是没有文档的问题是，如果团队发生变化，添加新成员怎样才能了解软件的结构和概念呢?一种是每个人都了解软件的整 个结构，除非你的团队整体消失，否则任何一个人都能够担当培养新人的责任，这种面对面交流比文档有效率很多。
于是就有了前office开发者，现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差，他说：“我们的项目是吵出来的”，我听完会心一笑。
八、团队：team
不要专家团队，而要外科手术式的团队。你的团队里一定要有清道夫，需要有弓箭手，让他们和项目一起成长，才是项目负责人的最大成就。
总 结：架构是一种权衡
Web开发的特点是是：没有太复杂的技术难点，一切在于迅速的把握需求，其实这正式敏捷开发的要旨所在，一切都可以非常快速的建立，非常快速的重 构，我们的开发工具，底层库和框架，包括搜索引擎和web文档提供的帮助，都提我们供给了敏捷的能力。
此外，相应的，最有效率的交流方式必须留给 Web开发，那就是面对面，不要太担心你的设计不能被完备的文档所保留下来，他们会以交流，代码和小卡片的方式保存下来。
人的因素会更加重要，无论是对用户的需求，还是开发人员的素质。
May
23
作者：曾宪杰。2002年毕业于浙江大学计算机系。先后在中科院下属企业、先锋电子(中国)就职。积累了丰富的Windows平台、企业级系统设计经验。现任淘宝网平台架构部架构师，主要研究方向为大规模集群环境下的消息中间件设计、分布式数据层和分布式系统。
淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。那么对于淘宝 网这样大规模的一个网站，我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是完全采 用的商业软件。那么下面我就简单的介绍一下淘宝网中应用的开源软件。
对于规模稍大的网站来说，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。对于像淘宝网这样规模 的网站而言，就是应用也分成很多组。那么下面，我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。
操作系统
我们首先就从应用服务器的操作系统说起。一个应用服务器，从软件的角度来说他的最底层首先是操作系统。要先选择操作系统，然后才是操作系统基础上的 应用软件。在淘宝网，我们的应用服务器上采用的是Linux操作系统。Linux操作系统从1991年第一次正式被公布到现在已经走过了十七个年头，在 PC Server上有广泛的应用。硬件上我们选择PC Server而不是小型机，那么Server的操作系统供我们选择的一般也就是Linux，FreeBSD, windows 2000 Server或者Windows Server 2003。如果不准备采用微软的一系列产品构建应用，并且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么还是应该在Linux和 FreeBSD之间进行选择。可以说，现在Linux和FreeBSD这两个系统难分伯仲，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应 该是各有所长。那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉，这个熟悉一方面是系统管理方面，另外一方面是对于内核的熟悉，对内 核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。而应用全面的优化、提升性能也是从操作系统的优化开始的。
应用服务器
在确定了服务器的硬件、服务器的操作系统之后，下面我们来说说业务系统的构建。淘宝网有很多业务系统应用是基于JEE规范的系统。还有一些是C C++构建的应用或者是Java构建的Standalone的应用。那么我们要选择一款实现了JEE规范的应用服务器。我们的选择是JBoss Applcation Server。JBoss AS是RedHat的一个开源的支持JEE规范的应用服务器。在几年前，如果采用Java技术构建互联网应用或者企业级应用，在开源软件中的选择一般也就 是Apache组织的Tomcat、JBoss的 JBoss AS和Resin。严格意义上讲，Tomcat和Resin并不能算是一个应用服务器，他们是实现了部分J2EE规范的一个容器。而商业软件的选择就是 IBM的WebSphere和BEA的WebLogic。到了现在，除了JBoss AS外，Apache的Geronimo，Sun的Glassfish也都是很优秀的JEE应用服务器。也给现在的开发人员提供了更多的选择。具体对于目 前JEE应用服务器的比较。这边就不在赘述。
在应用服务器前端，我们采用了Web Server做了一次转发，我们选择的Web服务器是大名鼎鼎的Apache。几年前，Apache几乎是Linux系统上开源Web Server的唯一选择。那个时候虽然也有一些其他的开源的Web Server，但是从功能和稳定性上来说都无法和Apache相对。在今天来说，Lighty也会是一个非常好的选择。Lighty是一个非常轻量级、占 用内存资源也比较少的Web Server。虽然功能上没有Apache强大，但是在不少场景下，性能是非常出色、强于Apache的。而微软的IIS，就只能工作在Windows的 系统上了。并且使用IIS的话，基本上也就是选择了ISAPI、ASP或者ASP.NET进行Web应用的开发了。
数据库
说完了我们采用的操作系统、应用服务器、WebServer后，下面就来谈谈我们的数据库。在淘宝网的应用中，采用了两种关系型数据库管理系统。一 个是 Oracle公司的Oracle 10g，另外一个是Sun MySQL的MySQL。Oracle是一款优秀的、广泛采用的商业数据库管理软件。有很强大的功能和安全性，可以处理相对海量的数据。而MySQL是一 款非常优秀的开源数据库管理软件，非常适合用多台PC Server组成多点的存储节点阵列(这里我所指的不是MySQL自身提供的集群功能)，每单位的数据存储成本也非常的低廉。用多台PC Server安装MySQL组成一个存储节点阵列，通过MySQL自身的Replication或者应用自身的处理，可以很好的保证容错(允许部分节点失 效)，保证应用的健壮性和可靠性。可以这么说，在关系数据库管理系统的选择上，可以考虑应用本身的情况来决定。
一个互联网应用，除了服务器的操作系统，Web Server软件，应用服务器软件，数据库软件外，我们还会涉及到一些其他的系统，比如一些中间件系统、文件存储系统、搜索、分布式框架、缓存系统等等。 在淘宝网，这些系统都是自主开发的，没有采用目前商业的或者开源的产品。有些系统，会存在着一些开源的产品或者商业产品。但是，考虑到淘宝网自己的需求和 大并发量的压力，这些系统都选择了自主开发框架。
前面谈的都是系统级的产品，下面我们说说开发框架的使用。可能有朋友想问，作为一个如此大规模的网站，淘宝网的Web展现层采用的是什么框架，是怎 么实现的呢？曾经也有到淘宝的应聘者问过我这个问题，他问我说是不是用的 struts。我告诉他说不是的。其实淘宝网的Web展现层的框架用的不是struts，不是webwork，不是spring mvc等等。淘宝网的Web展现层的框架用的是集团内部自主开发的一套Web框架。这个框架能够解决一些其他Web框架不能解决的、在淘宝的应用中又会出 现并需要解决的问题。在淘宝的多个应用中，也采用了一些开源的框架，比如Spring、iBatis、jBPM、Hessian、Mina等等。这些开源 软件的采用为我们构建应用系统提供了很大的帮助。
采用开源软件构建系统，我想有两个很大的好处：
一个是降低成本。假设你有1000台应用服务器，如果你每台服务器上采用的不是JBoss AS或者其他开源的软件，而是使用商业的Oracle BEA的Weblogic或者IBM的WebSphere，那么为这1000台机器的应用购买License的费用是非常高的。
另外一个好处(我觉得最大的好处)是你可以看到软件的源码，你可以研究了解软件内部的工作过程、原理。这对于应用设计、开发、查错、优化都是非常有 帮助的。
淘宝网的开源观
对于开源软件的应用，有些人可能担心质量的问题，有些人可能担心软件本身发展更新的问题，等等。对于质量的问题，我想现在很多的开源软件尤其是一些 很著名的开源软件都有很完善的组织，有完善的开发、测试、发布流程。在一个新版本完成前，会有多次的测试版本发布，最后才是正式版。这和商业软件是一样 的。并且因为代码公开，反而更加的容易发现错误，提高质量。至于第二个问题，我想跟第一个问题一样，关键是组织和规划而不在是否开源，并且在很多著名的开 源软件背后，会有厂商在进行支持。软件本身的发展应该是不会成为问题的，不太会出现软件突然停止发展的情况。
在今后的发展中，我们还是会一如既往的关注开源软件的发展，也还会根据需要采用不同的开源软件。在选择一个开源产品的时候，我会考虑以下几点：
1. 这个软件目前的功能和它的RoadMap
2. 软件本身的架构
3. 该软件开发的活跃度
4. 该开源软件是否是遵守该领域内的国际规范的
5. 在同类产品中，要挑选有比较优势的。并且要考虑可能存在的移植代价。这个移植指的是采用了这款开源软件后现有系统的移植，或者是从这个开源软件到其他软件 的移植。
对于企业级系统、互联网应用来说，采用开源软件不仅可以降低成本，更重要的是能够真正了解软件的内部工作机制。还可以在现在的基础上进行增强和定 制，也能够从开源软件中借鉴到很多好的设计和实现。希望国内能有更多的企业在使用开源软件的同时，也能开源自身的一些软件，或者能够成为一些开源软件的贡 献者。而作为淘宝网，我们也会非常积极的参与到开源的活动中，也会努力为开源的发展做出我们应有的贡献。
淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。那么对于淘宝 网这样大规模的一个网站，我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是完全采 用的商业软件。那么下面我就简单的介绍一下淘宝网中应用的开源软件。
对于规模稍大的网站来说，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。对于像淘宝网这样规模 的网站而言，就是应用也分成很多组。那么下面，我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。
操作系统
我们首先就从应用服务器的操作系统说起。一个应用服务器，从软件的角度来说他的最底层首先是操作系统。要先选择操作系统，然后才是操作系统基础上的 应用软件。在淘宝网，我们的应用服务器上采用的是Linux操作系统。Linux操作系统从1991年第一次正式被公布到现在已经走过了十七个年头，在 PC Server上有广泛的应用。硬件上我们选择PC Server而不是小型机，那么Server的操作系统供我们选择的一般也就是Linux，FreeBSD, windows 2000 Server或者Windows Server 2003。如果不准备采用微软的一系列产品构建应用，并且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么还是应该在Linux和 FreeBSD之间进行选择。可以说，现在Linux和FreeBSD这两个系统难分伯仲，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应 该是各有所长。那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉，这个熟悉一方面是系统管理方面，另外一方面是对于内核的熟悉，对内 核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。而应用全面的优化、提升性能也是从操作系统的优化开始的。
应用服务器
在确定了服务器的硬件、服务器的操作系统之后，下面我们来说说业务系统的构建。淘宝网有很多业务系统应用是基于JEE规范的系统。还有一些是C C++构建的应用或者是Java构建的Standalone的应用。那么我们要选择一款实现了JEE规范的应用服务器。我们的选择是JBoss Applcation Server。JBoss AS是RedHat的一个开源的支持JEE规范的应用服务器。在几年前，如果采用Java技术构建互联网应用或者企业级应用，在开源软件中的选择一般也就 是Apache组织的Tomcat、JBoss的 JBoss AS和Resin。严格意义上讲，Tomcat和Resin并不能算是一个应用服务器，他们是实现了部分J2EE规范的一个容器。而商业软件的选择就是 IBM的WebSphere和BEA的WebLogic。到了现在，除了JBoss AS外，Apache的Geronimo，Sun的Glassfish也都是很优秀的JEE应用服务器。也给现在的开发人员提供了更多的选择。具体对于目 前JEE应用服务器的比较。这边就不在赘述。
在应用服务器前端，我们采用了Web Server做了一次转发，我们选择的Web服务器是大名鼎鼎的Apache。几年前，Apache几乎是Linux系统上开源Web Server的唯一选择。那个时候虽然也有一些其他的开源的Web Server，但是从功能和稳定性上来说都无法和Apache相对。在今天来说，Lighty也会是一个非常好的选择。Lighty是一个非常轻量级、占 用内存资源也比较少的Web Server。虽然功能上没有Apache强大，但是在不少场景下，性能是非常出色、强于Apache的。而微软的IIS，就只能工作在Windows的 系统上了。并且使用IIS的话，基本上也就是选择了ISAPI、ASP或者ASP.NET进行Web应用的开发了。
数据库
说完了我们采用的操作系统、应用服务器、WebServer后，下面就来谈谈我们的数据库。在淘宝网的应用中，采用了两种关系型数据库管理系统。一 个是 Oracle公司的Oracle 10g，另外一个是Sun MySQL的MySQL。Oracle是一款优秀的、广泛采用的商业数据库管理软件。有很强大的功能和安全性，可以处理相对海量的数据。而MySQL是一 款非常优秀的开源数据库管理软件，非常适合用多台PC Server组成多点的存储节点阵列(这里我所指的不是MySQL自身提供的集群功能)，每单位的数据存储成本也非常的低廉。用多台PC Server安装MySQL组成一个存储节点阵列，通过MySQL自身的Replication或者应用自身的处理，可以很好的保证容错(允许部分节点失 效)，保证应用的健壮性和可靠性。可以这么说，在关系数据库管理系统的选择上，可以考虑应用本身的情况来决定。
一个互联网应用，除了服务器的操作系统，Web Server软件，应用服务器软件，数据库软件外，我们还会涉及到一些其他的系统，比如一些中间件系统、文件存储系统、搜索、分布式框架、缓存系统等等。 在淘宝网，这些系统都是自主开发的，没有采用目前商业的或者开源的产品。有些系统，会存在着一些开源的产品或者商业产品。但是，考虑到淘宝网自己的需求和 大并发量的压力，这些系统都选择了自主开发框架。
前面谈的都是系统级的产品，下面我们说说开发框架的使用。可能有朋友想问，作为一个如此大规模的网站，淘宝网的Web展现层采用的是什么框架，是怎 么实现的呢？曾经也有到淘宝的应聘者问过我这个问题，他问我说是不是用的 struts。我告诉他说不是的。其实淘宝网的Web展现层的框架用的不是struts，不是webwork，不是spring mvc等等。淘宝网的Web展现层的框架用的是集团内部自主开发的一套Web框架。这个框架能够解决一些其他Web框架不能解决的、在淘宝的应用中又会出 现并需要解决的问题。在淘宝的多个应用中，也采用了一些开源的框架，比如Spring、iBatis、jBPM、Hessian、Mina等等。这些开源 软件的采用为我们构建应用系统提供了很大的帮助。
采用开源软件构建系统，我想有两个很大的好处：
一个是降低成本。假设你有1000台应用服务器，如果你每台服务器上采用的不是JBoss AS或者其他开源的软件，而是使用商业的Oracle BEA的Weblogic或者IBM的WebSphere，那么为这1000台机器的应用购买License的费用是非常高的。
另外一个好处(我觉得最大的好处)是你可以看到软件的源码，你可以研究了解软件内部的工作过程、原理。这对于应用设计、开发、查错、优化都是非常有 帮助的。
淘宝网的开源观
对于开源软件的应用，有些人可能担心质量的问题，有些人可能担心软件本身发展更新的问题，等等。对于质量的问题，我想现在很多的开源软件尤其是一些 很著名的开源软件都有很完善的组织，有完善的开发、测试、发布流程。在一个新版本完成前，会有多次的测试版本发布，最后才是正式版。这和商业软件是一样 的。并且因为代码公开，反而更加的容易发现错误，提高质量。至于第二个问题，我想跟第一个问题一样，关键是组织和规划而不在是否开源，并且在很多著名的开 源软件背后，会有厂商在进行支持。软件本身的发展应该是不会成为问题的，不太会出现软件突然停止发展的情况。
在今后的发展中，我们还是会一如既往的关注开源软件的发展，也还会根据需要采用不同的开源软件。在选择一个开源产品的时候，我会考虑以下几点：
1. 这个软件目前的功能和它的RoadMap
2. 软件本身的架构
3. 该软件开发的活跃度
4. 该开源软件是否是遵守该领域内的国际规范的
5. 在同类产品中，要挑选有比较优势的。并且要考虑可能存在的移植代价。这个移植指的是采用了这款开源软件后现有系统的移植，或者是从这个开源软件到其他软件 的移植。
对于企业级系统、互联网应用来说，采用开源软件不仅可以降低成本，更重要的是能够真正了解软件的内部工作机制。还可以在现在的基础上进行增强和定 制，也能够从开源软件中借鉴到很多好的设计和实现。希望国内能有更多的企业在使用开源软件的同时，也能开源自身的一些软件，或者能够成为一些开源软件的贡 献者。而作为淘宝网，我们也会非常积极的参与到开源的活动中，也会努力为开源的发展做出我们应有的贡献。
May
20
Squid是一个缓存Internet数据的高性能代理服务器软件。当一个用户想要访问一个网页或下载一个文件时，会首先向Squid发出访问请求，由Squid代替其进行网页或文件下载，Squid在把该网页或文件传给用户的同时会在本机保留一个缓存备份。当别的用户访问同样的网页时，Squid会把保存的网页备份立即传给用户，使用户觉得速度相当快，同时也降低了后端数据来源Web服务器的压力。Squid可以代理HTTP、FTP、GOPHER、SSL和WAIS协议，暂不能代理POP3、NNTP等协议。Squid可以工作在很多操作系统中，如AIX、Digital、Unix、FreeBSD、HP-UX、Irix、Linux、NetBSD、Nextstep、SCO、Solaris、OS/2等。
目前Squid已经在新浪、搜狐、网易、腾讯等各大门户网站广泛使用，成为必不可少的服务器软件之一。
《Squid中文权威手册》由Squid创始人 Duane Wessels 所著的英文版《Squid: The Definitive Guide》翻译而来，其译者曾在新浪、网易工作过。
在线版：http://blog.s135.com/book/squid/ （便于阅读与查询）
PDF版：http://ishare.iask.sina.com.cn/cgi-bin/fileid.cgi?fileid=1998985 （排版规范，可下载后打印出来看）
目前Squid已经在新浪、搜狐、网易、腾讯等各大门户网站广泛使用，成为必不可少的服务器软件之一。
《Squid中文权威手册》由Squid创始人 Duane Wessels 所著的英文版《Squid: The Definitive Guide》翻译而来，其译者曾在新浪、网易工作过。
在线版：http://blog.s135.com/book/squid/ （便于阅读与查询）
PDF版：http://ishare.iask.sina.com.cn/cgi-bin/fileid.cgi?fileid=1998985 （排版规范，可下载后打印出来看）
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到海内校内，都在考虑这个问题，它可以更有效的留住 用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口 的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。
