Tag Archives: Web2.0

给提供 Widget 服务的站点几个建议 

花到三春颜色消，月过十五光明少
--轮回乐队《月残花落》

现在的 Web 2.0 站点，如果没有提供 Widget ，你都不好意思。Widget 也是能很好衡量一个站点服务的一个指标。前前后后，我这个 Blog 上也算用过不少家的 Widget 了，简单的给这些站点提几个小意见。

1) 界面 ，注意界面

Widget 一般只会占据 Blog 页面的一角，如果 UI 过不去的话，怕是没有几个人喜欢用。如果 Widget 输出内容没有拿的出手的 用户界面，还不如不提供了。

3) 性能，注意性能

如果性能太差或者站点根本支撑不了用户带来的 PV 压力，还请三思而行。Qos 总要考虑一下嘛。如果在提供脚本的同时能够提供一个页面放置指导建议，还是会让用户心生好感的。

3) Logo, 注意 Logo

Logo 当然重要，但是尺寸要适可而止。要看反面例子的话，去看看（以前)饭否的 Widget 输出的 Logo 就知道了(现在似乎调整小了)。Logo 当然重要，但最好不要喧宾夺主。输出内容是主，Logo 只是“宾”。

4) 空间，注意空间

Widget 在页面上一般也就占个豆腐块大的地方。内容布局还是要尽量合理。太紧凑或者太稀疏都不好。若邻提供的 Widget 布局就不怎么好。

5) 素质，注意素质

有的 Widget 时不时的偷梁换柱，夹杂一点私货：广告。这一点 Donews 以前就干过。当然，现在那个服务早没戏了。

暂时想到这么多，谁对这些 Widget 服务有意见请补充!

–EOF–

淘宝的 Web 2.0 应用

其实淘宝的社区已经比较 Web 2.0 了，但是非常奇怪的是在主站点这边一直比较谨慎。前一段时间淘宝的收藏功能上线，经过一段时间的考验，据说效果非常好。

 聚宝盆 = Del.icio.us + Digg + BI

del.icio.us 和 digg 的模式如果模仿起来并不难，但是淘宝很巧妙的和 BI 结合起来，这个产品的核心价值还在与 BI 的运用：智能推荐产品，“婴幼儿智力开发用品关联到丰胸露和产后塑身”，我开始看到还以为是搞笑，仔细一想还是比较惊讶的，几乎可以和著名的”尿布与啤酒”的 BI 案例相比了。

灵活的运用已有的应用模式，其实也是很好的创新。

–EOF–

Yupoo 照片墙活动

又拍网(Yupoo.com) 的社区活动很多，这个 照片墙 倒真是有一段时间了。Yupoo 的朋友给我留了一个位置，不过没有头像，只有 “DBA” 三个字母，挺好，一看就知道是我。哈。刚才挑了几张照片按照活动规则加上标签，如果每个照片都加上一个小故事，那就更好玩了。

前两天他们在文三路搞的拍摄活动本来想去的，事情不凑巧。等有机会去 Yupoo 办公室，一定把他们的照片墙拍一大张回来。

马上就国庆了，驴友们出游回来又有不少好照片可看了。

–EOF–

YouTube 的架构扩展

在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。

Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)

简单的说 YouTube 的数据流量, “一天的YouTube流量相当于发送750亿封电子邮件.”, 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,”每天有10亿次下载以及6,5000次上传”, 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 YouTube 就没法子比了.

Web 服务器

YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)

视频

视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。

出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 “迷你 Cluster” 就是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些”漏网”的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。

数据库

YouTube 用 MySQL 存储元数据–用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。

最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是”分区”,这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)

YouTube 也用 Memcached.

很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?

–EOF–