« May 2006 | Main | July 2006 »
June 29, 2006
央视才是黄健祥事件的最大赢家
昨天在网上发现一篇以前的文章《向电视学习，超越新浪》竟然被一家杂志发表了，人生第一次，庆祝一下。说起来这篇文章跟黄健祥事件还有点关系。文章中提到以前规矩的新闻播报方式逐渐被目前以主持人为中心的播报方式所取代，建议互联网公司围绕主持人打造个个性频道、栏目，改变传统的平铺直叙的新闻报道方式，用更加人性化，人性化，社会化的方式组织信息，即使有争议，也只有好处没坏处，让风格不同的主持人去竞争，让用户自己去判断和选择，把权力交给人民，以实现访问量和利益的最大化。
黄健祥这次又火了，而且是史前的巨火，以前的几次小火较之这次根据不值一提，无数的音频视频在网上流传，各大搜索引擎的热门排行都少不了他的身影。本来不看球的人这下子也要看看球了，说不定就赶上下一出黄健祥事件了。而央视估计一方面也承受着不小的压力，一方面也在心里偷着乐呢，这下收视率又上去了。至于检讨一下，肯定是要的，不然交待不过去，辞职？笑话，这么牛的人才怎么能放走？
Posted by yudunde at 12:47 PM | Comments (1) | TrackBack
June 27, 2006
mixi.jp：使用开源软件搭建的可扩展SNS网站
于敦德 2006-6-27
Mixi目前是日本排名第三的网站，全球排名42，主要提供SNS服务：日记，群组，站内消息，评论，相册等等，是日本最大的SNS网站。Mixi从2003年12月份开始开发，由现在它的CTO - Batara Kesuma一个人焊，焊了四个月，在2004年2月份开始上线运行。两个月后就注册了1w用户，日访问量60wPV。在随后的一年里，用户增长到了21w，第二年，增长到了200w。到今年四月份已经增长到370w注册用户，并且还在以每天1.5w人的注册量增长。这些用户中70%是活跃用户（活跃用户：三天内至少登录一次的用户），平均每个用户每周在线时间为将近3个半小时。
下面我们来看它的技术架构。Mixi采用开源软件作为架构的基础：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前为止已经有100多台MySQL数据库服务器，并且在以每月10多台的速度增长。Mixi的数据库连接方式采用的是每次查询都进行连接，而不是持久连接。数据库大多数是以InnoDB方式运行。Mixi解决扩展问题主要依赖于对数据库的切分。
首先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。然后是水平切分，根据用户的ID将不同用户的内容再划分的不同的数据库中，这是比较通常的做法，也很管用。划分的关键还是在于应用中的实现，需要将操作封装在在数据层，而尽量不影响业务层。当然完全不改变逻辑层也不可能，这时候最能检验以前的设计是否到位，如果以前设计的不错，那创建连接的时候传个表名，用户ID进去差不多就解决问题了，而以前如果sql代码到处飞，或者数据层封装的不太好的话那就累了。
这样做了以后并不能从根本上解决问题，尤其是对于像mixi这种SNS网站，页面上往往需要引用大量的用户信息，好友信息，图片，文章信息，跨表，跨库操作相当多。这个时候就需要发挥memcached的作用了，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期，这样应用层基本上就可以解决大部分问题了，只会有很小一部分请求穿透应用层，用到数据库。Mixi的经验是平均每个页面的加载时间在0.02秒左右（当然根据页面大小情况不尽相似），可以说明这种做法是行之有效的。Mixi一共在32台机器上有缓存服务器，每个Cache Server 2G内存，这些Cache Server与App Server装在一起。因为Cache Server对CPU消耗不大，而有了Cache Server的支援，App Server对内存要求也不是太高，所以可以和平共处，更有效的利用资源。
图片的处理就显得相对简单的多了。对于mixi而言，图像主要有两部分：一部分是经常要使用到的，像用户头像，群组的头像等等，大概有100多GB，它们被Squid和CDN所缓存，命中率相对比较高；另一部分是用户上传的大量照片，它们的个体访问量相对而言比较小，命中率也比较低，使用Cache不划算，所以对于这些照片的策略是直接在用户上传的时候分发到到图片存储服务器上，在用户访问的时候直接进行访问，当然图片的位置需要在数据库中进行记录，不然找不到放在哪台服务器上就郁闷了。
文章参考：Batara Kesuma在MySQL Users Con 2006上的发言
Posted by yudunde at 08:23 PM | Comments (5) | TrackBack
FeedBurner:基于MySQL和JAVA的可扩展Web应用
于敦德 2006-6-27
FeedBurner（以下简称FB，呵呵）我想应该是大家耳熟能详的一个名字，在国内我们有一个同样的服务商，叫做FeedSky。在2004年7月份，FB的流量是300kbps，托管是5600个源，到2005年4月份，流量已经增长到5Mbps，托管了47700个源；到2005年9月份流量增长到20M，托管了109200个源，而到2006年4月份，流量已经到了115Mbps，270000个源，每天点击量一亿次。
FB的服务使用Java实现，使用了Mysql数据库。我们下面来看一下FB在发展的过程中碰到的问题，以及解决的方案。
在2004年8月份，FB的硬件设备包括3台Web服务器，3台应用服务器和两台数据库服务器，使用DNS轮循分布服务负载，将前端请求分布到三台Web服务器上。说实话，如果不考虑稳定性，给5600个源提供服务应该用不了这么多服务器。现在的问题是即使用了这么多服务器他们还是无法避免单点问题，单点问题将至少影响到1/3的用户。FB采用了监控的办法来解决，当监控到有问题出现时及时重启来避免更多用户受到影响。FB采用了Cacti(http://www.cacti.net)和Nagios(http://www.nagios.org)来做监控。
FB碰到的第二个问题是访问统计和管理。可以想象，每当我们在RSS阅读器里点击FB发布的内容，都需要做实时的统计，这个工作量是多么的巨大。大量写操作将导致系统的效率急剧下降，如果是Myisam表的话还会导致表的死锁。FB一方面采用异步写入机制，通过创建执行池来缓冲写操作；只对本日的数据进行实时统计，而以前的数据以统计结果形式存储，进而避免每次查看访问统计时的重复计算。所以每一天第一次访问统计信息时速度可能会慢，这个时候应该是FB在分析整理前一天的数据，而接下来的访问由于只针对当日数据进行分析，数据量小很多，当然也会快很多。FB的Presentation是这样写，但我发现好像我的FB里并没有今天实时的统计，也许是我观察的不够仔细-_-!
现在第三个问题出现了，由于大多数的操作都集中在主数据库上，数据库服务器的读写出现了冲突，前面提到过Myiasm类型的数据库在写入的时候会锁表，这样就导致了读写的冲突。在开始的时候由于读写操作比较少这个问题可能并不明显，但现在已经到了不能忽视的程度。解决方案是平衡读写的负载，以及扩展HibernateDaoSupport，区分只读与读写操作，以实现针对读写操作的不同处理。
现在是第四个问题：数据库全面负载过高。由于使用数据库做为缓存，同时数据库被所有的应用服务器共享，速度越来越慢，而这时数据库大小也到了Myisam的上限-4GB，FB的同学们自己都觉得自己有点懒。解决方案是使用内存做缓存，而非数据库，他们同样使用了我们前面推荐的memcached，同时他们还使用了Ehcache(http://ehcache.sourceforge.net/)，一款基于Java的分布式缓存工具。
第五个问题：流行rss源带来大量重复请求，导致系统待处理请求的堆积。同时我们注意到在RSS源小图标有时候会显示有多少用户订阅了这一RSS源，这同样需要服务器去处理，而目前所有的订阅数都在同一时间进行计算，导致对系统资源的大量占用。解决方案，把计算时间错开，同时在晚间处理堆积下来的请求，但这仍然不够。
问题六：状态统计写入数据库又一次出问题了。越来越多的辅助数据（包括广告统计，文章点击统计，订阅统计）需要写入数据库，导致太多的写操作。解决方案：每天晚上处理完堆积下来的请求后对子表进行截断操作：
– FLUSH TABLES; TRUNCATE TABLE ad_stats0;
这样的操作对Master数据库是成功的，但对Slave会失败，正确的截断子表方法是：
– ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats1,ad_stats2);
– TRUNCATE TABLE ad_stats0;
– ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats0,ad_stats1,ad_stats2);
解决方案的另外一部分就是我们最常用的水平分割数据库。把最常用的表分出去，单独做集群，例如广告啊，订阅计算啊，
第七个问题，问题还真多，主数据库服务器的单点问题。虽然采用了Master-Slave模式，但主数据库Master和Slave都只有一台，当Master出问题的时候需要太长的时间进行Myisam的修复，而Slave又无法很快的切换成为Master。FB试了好多办法，最终的解决方案好像也不是非常完美。从他们的实验过程来看，并没有试验Master-Master的结构，我想Live Journal的Master-Master方案对他们来说应该有用，当然要实现Master-Master需要改应用，还有有些麻烦的。
第八个问题，停电!芝加哥地区的供电状况看来不是很好，不过不管好不好，做好备份是最重要的，大家各显神通吧。
这个Presentation好像比较偏重数据库，当然了，谁让这是在Mysql Con上的发言，不过总给人一种不过瘾的感觉。另外一个感觉，FB的NO们一直在救火，没有做系统的分析和设计。
最后FB的运维总监Joe Kottke给了四点建议：
1、 监控网站数据库负载。
2、 “explain”所有的SQL语句。
3、 缓存所有能缓存的东西。
4、 归档好代码。
最后，FB用到的软件都不是最新的，够用就好，包括：Tomcat5.0，Mysql 4.1，Hibernate 2.1，Spring，DBCP。
文章参考了Joe Kottke在MySQL Users Conference 2006上的发言。
Posted by yudunde at 01:58 PM | Comments (7) | TrackBack
June 22, 2006
豆瓣也要做旅游？
最近从各种消息来源听说了豆瓣要做旅游的消息，感觉还是有点不太相信，阿北应该不会这么看不清目前的局势吧。
其实如果是真的话，这也不是豆瓣的第一次失误。它的第一次失误是做了一个英文版的douban.net。可能是基于收入的考虑，为英文用户提供服务收入可能会更高，但到目前为止，我们可以看到整个项目并不理想。在英文书市场，Amazon做的远远比当当，卓越要好，不仅仅是一个在线交易的平台，更是爱书人的交流平台。而国内正是由于当当，卓越做的不到位，才给了douban崛起的机会，在这个背景下要做英文douban，与Amazon竞争，无异于与虎谋皮，所以在开始我就不看好这一举措。
如果豆瓣要做旅游，存在两种方式，一种方式是直接在目前douban.com内添加旅游的分类，与书、电影、音乐并列，同时添加“我游‘；另一种方式是像www.douban.net那样重新搭建一套系统，以更好的适应旅游行业的特点。
我之所以认为豆瓣不应该做旅游有两个原因。
一，豆瓣目前的网站尚存在很多问题。将近半年，没年到douban有什么实质性的改进了，虽然最近加入了三位好汉，但仅凭这股新加入的力量，能否在恢复原有发展速度的基础上再度支撑起旅游的社区是个很大的问号。从Alexa排名也可以看出，douban的发展已经有将半年徘徊在1500名左右了，如果在半年前就能够引入更多的人手的话，相信目前douban绝对不止这个排名。1500名是个很尴尬的排名，要取得比较好的投资认同，没有500名以内的实力很难说话。而在停滞近半年后要恢复往日发展的速度靠新增加旅游内容并不是个好主意。如果在目前这个阶段就陷入靠增加内容领域来获得增长的难堪局面的话，很难说服人相信这个网站可以在未来有更大的更本质的提升。而在目前已有的领域，还有相当多的工作需要做。把douban继续完善成一个没有任何争议的最大书、音乐、电影社区还有相当长的路要走。说实话目前假如某一个大网站像新浪或者猫扑要全力推书、音乐、电影社区的话，虽然我们从精神上支持douban，但以douban目前的实力肯定会非常被动，弄不好就是个狗熊掰玉米，到头来什么都没剩下的结果。
二，做旅游将极大削弱豆瓣的专注。目前的书，电影，音乐主题基本相似，而如果加上旅游，网站的定位就必然面临一个极大的调整，而照这个态势发展下去的话，必然出现一系列大而全带来的问题。在这个时候引入新的用户群体必然会面临口味的不同，所谓众口难调。以前douban可以在《读书》上打广告，以后还能在哪里打广告呢？这个时候如果出现一个更加纯粹的书或者电影或者音乐的社区，douban将同样非常被动。毕竟douban现在的增长就是由于专注在了一个特定的领域。如果要论广度的话，那绝非douban的强项。
其它零碎问题还有很多，也就不再一一列举，继续密切关注douban的动态，希望不要出现上面的局面。
Posted by yudunde at 10:22 PM | Comments (4) | TrackBack
失败的摇篮新版宝贝主页
从99年底开始运行的摇篮网是国内育儿网站的老牌了，也是目前国内最大的育儿网站。最近育儿网站的竞争呈现比较激烈的境况，各个育儿网站争相改版，而摇蓝也不甘落后，前些天推出了酝酿很久的新版宝贝主页。开始我是怀着比较期待的心情来看这个新产品的，毕竟摇篮是一个值得尊敬的竞争对手，在育儿行业坚持了这么久，仅凭这一点就值得尊敬。但新产品推出后却不能不让我感到深深的失望，从UE到UI，从功能到速度没有一样值得称道。或许作为竞争对手，我的说法不值得相信，但大量用户在站务论坛表现出的不满也明确的表明了用户的态度：对新产品失望透顶。
我到现在也不理解摇篮为什么能设计出这样一款失败的产品，并且还让它上线了。抛弃在系统迁移过程中的问题，单就产品来看，宝贝主页首页的设计让人扼腕：
一根没有经过任何处理的黑线条勾出了一个房子的形状，烟囱，和冒出来的烟，让我想起当年没有photoshop的时候用的画笔勾出来的涂鸭，用这个来做宝贝主页的门面实在是说不过去。而把宝宝的成长记录作为博客来处理又显示出了摇篮对博客认识的浅薄，竟然直接截取了前面一段文字作为标题。除了名字叫博客以外，看不出博客精神的一点体现。另外首页一大块地方用来放小家，但相信不是每个用户都需要这个功能，是否可以添加一个可选项，让用户自己选择是否显示？相册里的图片缩略图没有经过处理，直接显示原图出来，在一定程序上决定了用户打开速度必然会慢。另外还有一点想不通的是，右边两个巨大的图标占据了页面1/4的空间，顶上一个屋顶又占据了页面1/5的空间，而主要的内容只能挤在剩下的小空间内，要多别扭，有多别扭。
当然好的地方也有，在原有的基础上提供了装饰小家的功能，应该是想利用这一新特性来探索赢利的模式。不过在目前的境状下，这一新功能还是显得有些突兀，节奏没有掌握好。
总而言之，摇篮作为目前育儿网站的老大，还需要在这次改版中吸取教训，完善产品设计，有一个好的竞争对手也可以帮助育儿网更好的成长。
Posted by yudunde at 09:50 PM | Comments (1) | TrackBack
使用Red5和FFMpeg搭建在线Flash流媒体分享平台
最近视频的东西比较火，前些天我也稍微了解了一下使用开源软件建在线Flash流媒体播放平台的解决方案，还是有一些收获。
Red5是一款基于java的开源的Flash流媒体Server软件，可以作为取代Macromedia提供的商业版本FMS。Red5使用RSTP作为流媒体传输协议，内置了一些示例，这些示例实现了在线录制，flash流媒体播放，在线聊天，视频会议等一些基本的功能。由于系统本身是开源的，在碰到问题的时候也比较容易解决，大不了直接改代码，在成本方面也可以省下一笔不小的开销，为未来的功能扩展也提供了充分的空间。
如果仅仅是实现在线录制，在线播放，那么Red5也就差不多够了，但可能我们有时候还需要用户上传自己拍摄的视频文件，而要把这些视频文件转成可播放的flv文件就需要视频编码软件了。FFMpeg提供了录制，播放，视频流处理的完整解决方案。它自身也带了一个基于HTTP的流媒体广播程序以及其它几个实用的程序，但我们的重点还是它的视频转换程序，似乎Google Video也是用的它的程序作为视频转换工具。
我用FFMpeg转了几个视频，效果还可以，在声音上碰到了一些问题，在不添加参数的情况下，有一部分视频的声音会有问题，有的视频无论怎么添加参数，都出不来声音，报错提示的是不支持所带的声音采样格式，只支持几种固定的格式，我看了一下代码，确实是这样子，但理论上应该是能够解决的。FFMpeg自带的libavcodec是一套很牛的编码库，为了保证质量和性能，里面的很多codec都是从头开发的。
这两个加起来，实现一些简单的在线视频功能就差不多了。
PS:今天刚看到古永锵也开始做小视频分享网站：优酷。
Posted by yudunde at 10:34 AM | Comments (2) | TrackBack
June 21, 2006
结构化内容的复用-博客与图片博客
博客的出现是一个巨大的变革，不仅仅体现在提供了一种新的表达交流方式，革命性的为互联网内容引入了结构化数据。虽然xml的应用在之前的几年已经被炒的很火，但真正的基于xml的互联网应用还是少的可怜，无论是基于soap的web service还是xmp-rpc都应用不是非常广泛。而博客带来的rss,atom随着博客的大潮，已经慢慢的得到越来越广泛的应用，无论是rss阅读还是博客搜索，一下子将xml的应用普及开来。
实际上博客输出的rss不仅仅可以阅读，不仅仅可以搜索，还可以做更丰富的处理，应用到更多的网站中，更好的实现去中心化。我们认识到基于结构化的数据可以进行复用，当时举的例子主要是在网站内部的复用，而通过rss，我们可以实现跨网站的内容复用。例如一个景点:东方明珠，不仅仅有自己的图片，文字，还将Flickr上的照片和博客的内容重新以景点为中心重新进行组织，构成一个新的内容结构，从而给用户呈现展现更丰富的内容。同样的道理，在各种行业网站中几乎都可以使用这一模式，而不需要提供自己的博客，自己的图片博客，充分的利用互联网上已有的信息，避免信息的过载与冗余，降低信息共享的成本。
在这个过程里实际上博客搜索和rss托管服务都可以起到很关键的作用，对信息重组要求不高的应用可以直接使用博客搜索输出的数据，而要求比较高的应用则可能需要自己抓取数据建立索引。后一种方式需要大量的rss源，而且是本行业内有针对性的rss源，而拥有这一资源的，应该是rss托管服务商，似乎这可以成为rss托管服务商一个不错的服务项目。
最近由于多种原因（主要是赢利模式），博客的发展不被看好。但有一点我们必须清醒的认识到，博客是未来互联网不可缺少的一个组成部分，而且是最为基础的一环，它将为一系列的网站提供基础内容服务，绝对不能因为目前短暂的赢利困境而放弃对博客的信任与坚持。当年QQ要以100万卖出的时候，谁会想到它今天能值40亿美金？我们之所以想信博客会产生类似的增值是基于对未来互联网结构的充分分析，是有理论依据的。
Posted by yudunde at 11:16 PM | Comments (0) | TrackBack
June 18, 2006
使用开源软件，设计高性能可扩展网站
2006-6-17 于敦德
上次我们以LiveJournal为例详细分析了一个小网站在一步一步的发展成为大规模的网站中性能优化的方案，以解决在发展中由于负载增长而引起的性能问题，同时在设计网站架构的时候就从根本上避免或者解决这些问题。
今天我们来看一下在网站的设计上一些通常使用的解决大规模访问，高负载的方法。我们将主要涉及到以下几方面：
1、 前端负载
2、 业务逻辑层
3、 数据层
在LJ性能优化文章中我们提到对服务器分组是解决负载问题，实现无限扩展的解决方案。通常中我们会采用类似LDAP的方案来解决，这在邮件的服务器以及个人网站，博客的应用中都有使用，在Windows下面有类似的Active Directory解决方案。有的应用（例如博客或者个人网页）会要求在二级域名解析的时候就将用户定位到所属的服务器群组，这个时候请求还没到应用上面，我们需要在DNS里解决这个问题。这个时候可以用到一款软件bind dlz，这是bind的一个插件，用于取代bind的文本解析配置文件。它支持包括LDAP，BDB在内的多种数据存储方式，可以比较好的解决这个问题。
另外一种涉及到DNS的问题就是目前普遍存在的南北互联互通的问题，通过bind9内置的视图功能可以根据不同的IP来源解析出不同的结果，从而将南方的用户解析到南方的服务器，北方的用户解析到北方的服务器。这个过程中会碰到两个问题，一是取得南北IP的分布列表，二是保证南北服务器之间的通讯顺畅。第一个问题有个笨办法解决，从日志里取出所有的访问者IP，写一个脚本，从南北的服务器分别ping回去，然后分析结果，可以得到一个大致准确的列表，当然最好的办法还是直到从运营商那里拿到这份列表(update:参见这篇文章)。后一个问题解决办法比较多，最好的办法就是租用双线机房，同一台机器，双IP，南北同时接入，差一些的办法就是南北各自找机房，通过大量的测试找出中间通讯顺畅的两个机房，后一种通常来说成本较低，但效果较差，维护不便。
另外DNS负载均衡也是广泛使用的一种负载均衡方法，通过并列的多条A记录将访问随即的分布到多台前端服务器上，这种通常使用在静态页面居多的应用上，几大门户内容部分的前端很多都是用的这种方法。
用户被定位到正确的服务器群组后，应用程序就接手用户的请求，并开始沿着定义好的业务逻辑进行处理。这些请求主要包括两类静态文件(图片，js脚本,css等)，动态请求。
静态请求一般使用squid进行缓存处理，可以根据应用的规模采用不同的缓存配置方案，可以是一级缓存，也可以是多级缓存，一般情况下cache的命中率可以达到70%左右，能够比较有效的提升服务器处理能力。Apache的deflate模块可以压缩传输数据，提高速度，2.0版本以后的cache模块也内置实现磁盘和内存的缓存，而不必要一定做反向代理。
动态请求目前一般有两种处理方式，一种是静态化，在页面发生变化时重新静态页面，现在大量的CMS，BBS都采用这种方案，加上cache，可以提供较快的访问速度。这种通常是写操作较少的应用比较适合的解决方案。
另一种解决办法是动态缓存，所有的访问都仍然通过应用处理，只是应用处理的时候会更多的使用内存，而不是数据库。通常访问数据库的操作是极慢的，而访问内存的操作很快，至少是一个数量级的差距，使用memcached可以实现这一解决方案，做的好的memcache甚至可以达到90%以上的缓存命中率。10年前我用的还是2M的内存，那时的一本杂事上曾经风趣的描述一对父子的对话：
儿子：爸爸，我想要1G的内存。
爸爸：儿子，不行，即使是你过生日也不行。
时至今日，大内存的成本已经完全可以承受。Google使用了大量的PC机建立集群用于数据处理，而我一直觉得，使用大内存PC可以很低成本的解决前端甚至中间的负载问题。由于PC硬盘寿命比较短，速度比较慢，CPU也稍慢，用于做web前端既便宜，又能充分发挥大内存的优势，而且坏了的话只需要替换即可，不存在数据的迁移问题。
下面就是应用的设计。应用在设计的时候应当尽量的设计成支持可扩展的数据库设计，数据库可以动态的添加，同时支持内存缓存，这样的成本是最低的。另外一种应用设计的方法是采用中间件，例如ICE。这种方案的优点是前端应用可以设计的相对简单，数据层对于前端应用透明，由ICE提供，数据库分布式的设计在后端实现，使用ICE封装后给前端应用使用，这路设计对每一部分设计的要求较低，将业务更好的分层，但由于引入了中间件，分了更多层，实现起来成本也相对较高。
在数据库的设计上一方面可以使用集群，一方面进行分组。同时在细节上将数据库优化的原则尽量应用，数据库结构和数据层应用在设计上尽量避免临时表的创建、死锁的产生。数据库优化的原则在网上比较常见，多google一下就能解决问题。在数据库的选择上可以根据自己的习惯选择，Oracle，MySQL等，并非Oracle就够解决所有的问题，也并非MySQL就代表小应用，合适的就是最好的。
前面讲的都是基于软件的性能设计方案，实际上硬件的良好搭配使用也可以有效的降低时间成本，以及开发维护成本，只是在这里我们不再展开。
网站架构的设计是一个整体的工程，在设计的时候需要考虑到性能，可括展性，硬件成本，时间成本等等，如何根据业务的定位，资金，时间，人员的条件设计合适的方案是件比较困难的事情，但多想多实践，终究会建立一套适合自己的网站设计理念，用于指导网站的设计工作，为网站的发展奠定良好的基础。
Posted by yudunde at 12:22 AM | Comments (8) | TrackBack
June 07, 2006
结构化内容的复用
以前在好几篇文章中提到结构化内容的复用是互联网的一个重要发展方向，下面来详细阐述一下。
前些日子Blog圈有一个新活动，讲述自己从小到大读书的经历，没有用到结构化的内容，只是简单的把书名和简介列出来，这可以看作是结构化内容的雏形。
我记得原来Dearbook有类似的功能，基于它的数据结构，把一本本书列出来，形成一张推荐书单，里面的书集中在某一领域，同时在阅读时有先后的顺序。Douban也有类似的功能，叫豆列，做的简单易用，不过忽视了很重要的一点：时间维度，没有了时间维度，列表就少了人的味道，平常的很。
豆瓣，途牛等网站因为已经有了很多最小内容单位：书或者景点，已经可以在这个基础之上，创建更为复杂的结构，例如豆列，以及类似的其它他Feature，空间十分广阔。
做这些Feature会让人产生一些疑惑，它的价值在哪里？实际是针对单本书，唱片，电影，景点的评论大家已经很熟悉了，以时间为基础的列表首先给人的就是耳目一新的印象，最重要的是人的因素在这里面可以得到更深层次的体现，不仅仅是独立于书之外的评论等附加信息，本身就是组成书单的主导，人是列表的灵魂，书，电影，音乐，景点只是绘画时用的颜料而已。
在育儿领域，结构化的最小内容单位可能是一件母婴用品，可以是一所幼儿园(育儿网幼儿园)，可以是一座医院，可以是一个商家。他们组成的就是宝宝学龄前0-6岁的成长记录，相同年龄的妈妈可以通过这些信息互相学习，提高信息的通明程度和流通速度，同时对后来的妈妈有巨大的指导意义，有巨大的借鉴价值。而附加于其上的对商家、商品信息的统计数据，以及其它延伸产品更是有着巨大的商业价值。这样不但有在行业产业链下游的用户，还有上游的商家，真正形成一个有价值的渠道和平台。
在旅游领域里，结构化内容的复用表现为路线图，将一个人旅行的足迹按时间顺序排列出来，辅助以在每个景点的体验，或者将某个历史大事件（例如长征）表现出来，都是比目前的专题更吸引人的表现形式。路线图在这里就是一个由简单数据结构组成的更复杂的数据结构。
不同行业的核心产品不同的结构是目前互联网网站向专业化方向发展的一个重要原因，提供了行业网站纵深发展的可能。行业网站不再只是发发新闻，发发贴（文章+论坛），而会逐渐发展成为具有行业特点，体现行业特征的人性化，个性化，社会化平台。
补充一点：flickr的图集也可以看作是结构化内容复用的一种。
Posted by yudunde at 01:37 PM | Comments (1) | TrackBack