January 2011 Archives

本文已经首发于InfoQ中文站，版权所有，原文为年度技术回顾之数据库、NoSQL、开源软件，如需转载，请务必附带本声明，谢谢。

InfoQ中文站是一个面向中高端技术人员的在线独立社区，为Java、.NET、 Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如QCon、免费迷你书下载如《架构师》等。

年终岁尾，做个总结吧。要说过去的这一年，起码国内的技术会议多了很多，甚至是几千块的门票也有市场了，可能也是物价上涨的副作用？像 QCon(Beijing)、SD 2.0 、微博开发者大会、TUP、UCD 年会、D2 年会、Verlocity(Beijing) 等会议，参会人都非常踊跃甚至有些会议一票难求，这是好现象，相信 2011 年有更多有价值的会议值得我们参加。再说说技术方面的事儿吧，下面是我的几个关注点。

数据库

Oracle RDBMS 、SQL Server 、DB2 等几大商业化产品似乎没什么值得一说的事件。Oracle 公司收购 Sun 之后，MySQL 前途曾一度堪忧，现在看起来 MySQL 生命力依旧顽强，只是在今年开发节奏明显慢了不少，也或许是 Oracle 在调整节奏，不过 5.5 版本的发布还是让不少 DBA 颇为惊喜，除了 InnoDB 成为默认的存储引擎之外，其他的一些特性倒是差不多都来自技术社区的反馈或是驱动，比如来自 Google、Facebook 的改进，多少对新的 MySQL 特性产生了一定影响。值得注意的是，这一年中 PostgreSQL 发展相当的迅猛，随着 9.0 的发布，引入了更为高级的复制技术，弥补了功能上的一个短板，MySQL 的命运多舛给 PostgreSQL 带来了契机，令人感慨。以前我期待的 SSD 虽说已经逐渐成熟，但似乎没有像预期的那样对数据库软件带来更大的影响。

NoSQL

在去年的回顾文章中我说到 "就数据管理方式的趋势来看，NoSQL在将来会成为一个非常重要的数据解决方案"。一年之后，NoSQL 的确已经成为网络架构中一个基础的组成部分了。涌现出来的 NoSQL 相关的产品，最成功的要数 MongoDB，在新型 Startup 中颇为流行，赢得了不少创业技术团队的青睐 (比如，引领创新潮流的 LBS 先驱 FourSquare就是采用的 MongoDB ，尽管为此吃了不小的亏 )，创建 MongoDB 的 10gen 技术团队甚至在年底拿到了红杉的风险投资。除了 MongoDB 之外， Redis 的发展也不错。来自名门大厂的 Cassandra、Dynamo、CouchDB 等产品的发展倒是稍显平淡。作为 MySQL 的 NoSQL 插件出现的 HandlerSocket 的让人感到惊喜。这个技术方案会给很多应用场景带来新的契机，相信新的一年会有很多技术团队大胆的采用 HandlerSocket。其它几个 DB，似乎到现在仍没有类似的解决方案出现。

我有一个猜测是 Redis 从 VM 转向 Diskstore 模式后，有可能超越 MongoDB 么？

开源试水

Yahoo! 发布的 S4 不出意外的话，极有可能成为 Hadoop 那样有影响力的项目，对于实时计算领域会带来极大的冲击 。相信今年国内会有用户进行尝试。LinkedIn 开源的 Kafka 也有必要关注一下。针对招聘类网站会有一定的借鉴意义。

2010 或许可以称之为中国互联网企业回馈开源领域的试水之年。先是淘宝网开源平台，淘蝌蚪 （code.taobao.org） 的上线并且推出分布式 Key-Value 存储及高性能缓存系统----TAIR，随后开放了淘宝文件系统以及 WebX 框架，足见诚意。說起 WebX，人人网也发布了自己的开源 Web 开发框架 Rose。然后有盛大创新院开源哼唱检索引擎，随后在互联网口水大战尘埃落定之后，金山的启动金山卫士开源计划，甚至百度也发布了 JavaScript 开发框架 Tangram --喊了一年终于开源了一个产品出来，颇为不易阿。而淘宝系的前端工程师们的开源项目 KISSY 发展也颇为迅猛，推荐关注。更早一些的开源项目，豆瓣的 BeansDB 在年底进行了大幅度更新，再次引起技术社区的注意。此外，射手播放器作者沈晟发布的基于MongoDB的短网址分支项目 SESO 也很有意思，希望能继续发展下去。基于 Key-Value 的开源产品多了不少，天涯也开放了一个 Memlink。

以团队为单位进行的产品开源，很容易变成一个只是"公开代码"的项目，开源，还应积极鼓励技术团队成员积极的与技术社区互动，输出更多文档，用更多的案例支撑，这样才能相辅相成，才能取得真正的收益。否则的话，容易被看成为了开源这个"名"而开源，有始无终。

期待在 2011 年，腾讯能在开源领域做点表率？还是网易开源一个游戏引擎呢？只有拭目以待了。也期待国内互联网企业能积极支持开源社区，不要只顾着开源自己的那几个产品。开源比封闭更值得欣赏，心态也比姿态更为重要。

说到开源，顺便说一下"开放平台"，2009年喊着做开放平台的各大网站，现在已基本偃旗息鼓，国内这一年中也没有一家将所谓的"开放平台"真正的做起来，倒是经过一年多的铺垫，新浪以微博为基础的的应用平台已经具备了一定的潜力和规模，2011年值得期待。如果说开源，看的是心态，那么，开放平台，则看的是企业的心胸。

2011 做点什么？

眼看着越来越多的解决方案，越来越开放的技术分享，不由得让人生疑：架构是否已经不再重要？其实，构建一般中到大型的站点，已经没什么秘密技术可言（比如，还有人一度放出来"腾讯大讲堂"这样的内部信息资料，颇为戏剧性，但大家看了之后也就是新鲜几天而已，网络中更有价值的信息已经是比比皆是了）。重要的是如何用成熟的技术将产品做好，加快开发节奏，更快改进产品质量。

所以，对我自己而言，新的一年重要的还是回归基本技术，和团队一起将丁香园( http://dxy.com )的产品做好，"望着天上的星，也要看着脚下的坑"，关注新东西，更要避免因为技术冒进造成不必要的人力物力浪费，说起来容易，真的做起来，怕是也没那么简单。

--EOF--

前几天有一位网志⁽¹⁾读者发来反馈，我的个人站点文章分类的分页功能出了问题。读者的意见不能不重视，于是花了一点时间修复了一下。作为国内少数还在使用 Movable Type (MT) 作为网志发布工具的用户，处理的过程中不由使我再次涌起迁移到 WordPress (WP)的冲动，到现在 MT 甚至都不具备一个良好的原生的分页机制，不得不再次借助于第三方的插件来做到。不管承认与否，Movable Type 已经被 WordPress 全方位的无情的超越。如今的 Movable Type，已经不像当年那样被人津津乐道，甚至被 VideoEgg 收购的消息都没引起多大的反响。这是怎么一回事? 这几年发生了什么？在这个时间回顾一下，或许别具意义。

Movable Type 是如何被 WordPress 超越的？

让我们回到 2001 年，短暂无业闲暇中的 Perl 工程师 Ben Trott 为了满足妻子 Mena Trott 在网上书写的热情而创作了 Movable Type，9 月份作为个人项目发布了 Movable Type(这个单词也是"活字印刷"的意思)初始版本，10月份发布了 1.0 版本(Refer)。很快，免费（严格来说是 Donation-Ware 的版权形式）而精致优雅的 Movable Type 赢得了不少用户，引起了业界广泛注意。Ben 夫妇的夫妻店名为 Six Apart , 这个名字的由来据说是因为两个人的生日相差六天，和什么"六度分割"理论没什么直接联系。2004 年拿到第二轮融资。2003 年，Ben 夫妇二人拿到了来自伊藤穰一(Joi Ito) 的第一笔风险投资，2004 年拿到第二轮融资。资本一旦进入，情况似乎就发生了变化。在 2004 年发布的 3.0 版本引发了轩然大波，Six Apart 短视的将 Movable Type 的版权进行了调整，打算开始收费，这一杀鸡取卵的举措引来了大量用户的不满与诟病，从而使得不少用户转投当时并不成熟的 WordPress 的怀抱。到现在为止，我们似乎得到了 Movable Type 落败的第一个原因：错误的时机采用了错误的收费策略。

WordPress 的最初发展过程似乎没有什么秘密可言，在维基百科上可以找到关于 WordPress 发展的方方面面的信息。当时只有 19 岁的的 Matt Mullenweg 在 b2/cafelog 的基础上开发了 WordPress，遵循 Web 标准，于 2003 年 5 月以 GPL 版权形式发布。随后的两年中，Matt 被 CNET 雇佣，退学，在几位 WordPress 开发者的努力下推出了 1.5 这个重要的版本，2005 年 Matt 从 CNET 离职而全力投入 WordPress 项目，正式成立了 Automattic，随后发布了 Akismet 项目(用以对抗垃圾信息)， WordPress.com 相继正式对公共开放，看起来似乎是无心插柳柳成荫，其实是很大程度上依靠着开源社区的力量驱动。而 Movable Type 的版权形式让用户心怀芥蒂，直到 2007 年，Six Apart 才重新修改版权形式为 GPL (GPLv2) 。这个时候已经无法改变什么了。这几年中，Movable Type 几乎没有什么革新的功能出来，版本 3 和 Spam 较劲了许久，然后 4.0 解决了 Spam 问题后则是跟性能问题斗争，现在的版本 5 倒是有些中规中矩，只是时不我待。WordPress 的开发者分为 Lead Developer、Contributing Developer、Developer ，这种形式更能激发贡献者的热情，形成了一个相对更为健康的结构，而对于 Movable Type ，即使在开源后也几乎找不到这样的结构，只是知道目前日本的 Perl 技术社区承担了很大一部分开发改进工作。如果要总结一下 Movable Type 被 WordPress 超越的第二个原因：WordPress 吸引了开源社区的力量。

如果说语言决定运势，似乎有些技术巫婆的味道。Ben Trott 用 Perl 语言开发的 Movable Type ，而 WordPress 则是用 PHP 进行开发。很不幸的是，Perl 差不多是过去 10 年最让人扼腕的一门语言，从 Perl 5 之后一直停滞不前，直到去年 Perl 6 才姗姗来迟，Perl 没有凤凰涅槃，终究彻彻底底的成为了一门小众语言。Perl 功能超级强大，但有个相当大的弊端，那就是一个人写出来的程序，换一个人很难读懂。这意味着 Perl 写出来的 Movable Type 很难借助于群体的力量而继续改进，终究将 MT 变成属于小众群体的工具。2003 年的时候，PHP 还不够先进，但是 PHP 一直在迅速进化，而 PHP 用户群也越来越大，PHP 语言越来越流行²。WordPress 尽管开始粗糙，但是经过不断的改进后最终变得功能强大甚至完美。很多国内 Blogger 应该记忆犹新，选择 Movable Type 的话，必须要找能够支持 Perl 环境的虚拟主机，而虚拟主机支持 PHP 则几乎是"标配"。语言的选择决定了一个产品的基因，从某种程度上也决定了产品的命运。这是两种技术文化的碰撞，这是 Movable Type 被 WordPress 超越的第三个原因：选择 Perl 是一种错误。

Six Apart 步步抢得先机，却总是被后发的 WordPress 超过。Six Apart 在 2003 年就正式推出了 TypePad 这个 Blog 托管平台，远比 WordPress.com 起步早。做平台，非常关键的一点是需要一个好的生态来维系。Movable Type 想从软件 License 中赚钱的想法实际上已经注定了构建不出这样相对开放的生态。而 WordPress 则不然，始终坚持开源，团结技术社区。WordPress 逐步发展成为最流行的网志发布工具，而广泛的用户群则给 WordPress 带来了大量有价值的反馈，技术爱好者则进一步贡献了数不清的插件，很多用户因为 WordPress 有着这么多的插件而放弃 Movable Type，也难怪，到现在 MT 还没有一个合适的插件让用户很方便的显示相关文章，而 WordPress 下面类似的插件比比皆是，只是有的写的糟糕，有的写得精致而已。不难看出，WordPress 走了一条农村包围城市的路线，逐渐培养了大量的基础用户。时至今日，WordPress.com 是全球前 20 名的网站，而 TypePad 排名是 200 左右。 Movable Type 被 WordPress 超越的第四个原因：WordPress 构建了一个更好的产品生态，进而培育了一个成功的平台。

关于"生态"，我想说一下国内的一些开源产品，比如 Discuz!，较少得到来自技术社区的贡献，说是开源，仅仅是把代码公开，缺乏与技术社区良好的互动，形成不了良好的技术生态。

不知是不是 Ben Trott 最初单枪匹马写出来的 MT 的缘故，Six Apart 团队另一个特别的地方是没有出现有影响力的技术明星。在 2005 年，Six Apart 收购了 LiveJournal 背后的公司 Danga 。Danga 这个技术团队在 Web 2.0 历史上是值得纪念的，给业界贡献了 Memcached 、MogileFS 这样经典的开源产品，让无数创业团队受益，相信今天很多公司都在使用 Danga 团队开源的产品或是从 Memcached 中借鉴了 Key-Value 产品的设计理念。甚至那篇 LiveJournal's Backend 也给了国内很多技术人员以启迪，我甚至认为这是 Web 2.0 技术大潮中最重要的 PPT 之一。遗憾的是，Brad Fitzpatrick 这位大牛没多久就离开了 Six Apart ，加入了 Google。这一次收购似乎没有给 Six Apart 带来什么。除此之外，业界很少有优秀的 Perl 为主导的技术团队了。后来， Six Apart 又有几次收购，似乎也都是为了技术团队而进行的。反观 Automattic ，迄今为止只进行过两三次收购而已，而且都是为了完善 WordPress 产品功能。第五个原因，Six Apart 的收购没有做到价值最大化。在雅虎的收购上我们也看到了类似的失败的做法。

抛开这两个产品的其它方面不谈，一个成功的产品和一个走向没落的产品之间的差异是一点一点产生的。我们能看到结局，但回到 2001 年的时候，没有人能预料到这些。当然，今天的 Movable Type 绝非一无是处，尤其是模板结构，现在也要比 WordPress 优秀，但是没办法，WordPress 好的模板主题更多。另外，MT 的 静态⁽³⁾页面发布功能依然是一个不可替代的优秀特性，虽说 WordPress 启用了 Cache 之后，MT 这一点已经不具备多大的优势了。当然，难以割舍的还有习惯和一种别样的感情，所以，至今国内仍有不少出色的网志是构建在 Movable Type 之上的。

两个产品似乎从没剑拔弩张相向过，但我想 WordPress 至少是将 Movable Type 作为一个对手并一步一步将其超越的。我知道，作为 Movable Type 或是 WordPress 忠实用户的你，一定还有其它看法。

Movable Type is Dead, Long Live Movable Type.

--EOF--

注1: 为了纪念过去的一些原则上的争论，这里"Blog"一律译作"网志"。

注2: 关于 Perl 和 PHP 的那一段言论会引发争论。请原谅我的偏见和无知吧。

注3: MT 的静态发布，对于单个页面的访问，Web 服务器来说减轻了压力，但是对于需要频繁交互的应用需求，比如类似留言这样的操作，MT 就太慢了。

延伸阅读：这里有一篇老外写的分析文章，大部分观点都是类似的。

看到微博上《程序员杂志》在征集"一分钟先生"的话题：如何做好公司/团队的技术选型？其实大公司或者大一点的团队选型几乎不需要太多讨论的 -- 最后会不可避免的绕到技术官僚的话题上去。这里我想简单说说技术型创业团队技术上的选型问题。

拥抱开源技术

如果只能选择微软的技术路线，比如团队几个人只会用微软的技术做开发，甚至也不想学别的，那么似乎没有别的办法，将就一下吧。如果还有的选择，尽量选择使用开源技术。这样的好处是你不但可以有效的降低软硬件成本，还有更多的部署方案供选择，服务器上线甚至还能避免病毒的侵袭。开源技术的好处是出了问题，你总有办法可以找到答案，避免再次犯类似的错误。而用了微软的产品之后，可能平时不出问题，但一旦出了问题，你根本没什么办法，实际上，微软的产品使用门槛倒是低，但是复杂度可是一点都不小，而且随着发展，成本越来越高。国内有几个大中型网站，比如天涯、5173、大众点评、京东等，怕是深有感触吧，有的因为成本太高而继续被捆绑在贼船上，有的则破釜沉舟要摆脱这种束缚，但不管怎么说，总要付出一定的开销才可以掉头了。

好了，恭喜你选择了红色药丸，现在选择开源技术路线了，离开了微软的专卖店，进入到一个超级庞大的百货商店，这里还有数种分支供你选择呢，然后怎么办？选择大路货，选择可以掌控的技术产品，开源语言、开源程序、开源框架，乃至开源的解决方案。比如 PHP，比不上 Ruby 阳春白雪，但是用户基数大，你总能找到不错的工程师。PHP 虽然粗糙，但是管用。以 PHP 作为开发语言的成功产品不计其数，甚至很多东西根本不需要你再开发了，稍加定制即可使用。技术本身没有高下之分，差别在于使用技术的人。

Note：Paypal 和 X.com 合并之后，果断的将整个架构从微软的平台迁移到 Unix 平台；用微软技术体系构建的 MySpace 至今还在用微软的平台，被全面使用开源技术的 Facebook 短时间内全面超越。技术体系的选择是成功与否的唯一因素么？肯定不是。但至少是因素之一吧。

避免过度炫技

技术人员创业最容易犯的一个错误就是"炫技"。什么新用什么，使用最时髦的开发语言、部署的软件产品、调试最新版本的开发工具... 没错，用最新的东西容易给技术人员以满足感，但也很快会将你的时间资源消耗进去，除非你准备做的是一款基础产品。否则的话，你要花时间去学新的规范、熟悉新的功能、对付新出现的软件BUG... 可是这时候，最需要你做的是开发你要开发的产品，而不是捣鼓其它东西。一些新的技术或者方案，可以花一些时间分析一下但没必要立刻就用，确保将来有一天能真的使用上的时候，对一些重大的陷阱或是缺陷能够了然即可。

很多人神往 37Signals 的成功，但你一定要知道类似 37Signals 的团队，默默无闻的夭折掉的不知道有多少。每当我看到创业团队的就那么一两个人还整天在捣鼓 Go 、Erlang 这些东西，并想硬生生的用到他们的产品中去，我就知道，这样的团队要悬了。有这些精力，有这样的能力，应该想办法尽快让技术变现，研究一下怎么改进产品，怎么给用户带来更大的价值，这些不一定用最好的技术才能做出来。想办法尽快让产品发布，尽快接受更多人给你第一轮反馈，只凭创业团队几个人闭门冥想是很难出来好产品的，有的时候，产品推出的时机比完备的功能更为重要。要知道 GroupOn 最早也不过是搭建在 WordPress 上的几个页面，而阿里巴巴网站最初也不过是一个论坛，你又何必等到所有细节都打磨好呢？

拥抱开源技术，避免过度炫技，如果技术型团队创业(做互联网)，这两条都能坚持的话，我想你已经抓住了问题的 80% 的部分，基本上你不会做太多的无用功。

再说说如何找到合适的技术伙伴，刚刚启动的时候不要直接上来就找什么技术总监、技术经理、架构师这些看起来级别很高的人，因为这样级别的人未必认同你的想法和你的现在的团队，相反，我建议找能实现你产品想法的人。找一个合作者要比找一个管理者更为重要。最后有一点必须要说一下，不要因为一个人的技术喜好而舍弃整个技术团队，在任何时候这都是很愚蠢的事情。

这篇文章是比较有针对性写的，所以不具有普遍性，路过的朋友不要挑刺。

--EOF--

Updated：留言中有网友质疑"技术型团队"该怎么定义，按照他的说法，他心目中的技术型团队应该是"天才团队"，就这样。

在 O'Reilly Velocity China 2010 大会上，业界最有影响里的 Web 性能技术专家 Steve Souders 宣告 Web Performance Optimization (WPO) 时代已经到来。这是个颇为重要的主题演讲，要知道，Google 已经开网站载入时间纳入到搜索排名因素之中(refer)，或许 Web 性能优化，商业网站要考虑作为一项战略来对待了。

我们看一组数据（信息来源）:

• Amazon: 增加 100ms 延迟将导致收入下降 1%；
• Google: 400 ms 延迟将导致每用户搜索请求下降 0.59%；
• Yahoo!: 400ms 延迟会导致流量下降 5-9%；
• Bing: 2 秒的延迟将导致收入降低 4.3%/用户(请问，首页用个那么大的背景图干啥?);
• Mozilla 将下载页时间缩短 2.2 秒之后下载量增加 15.4%;
• Google Maps 将文件大小减少 30% 后请求增加了 30%；
• Netflix 在服务器端启用 gzip ，页面快了 13-25%，节省了 50% 的网络流量；
• Shopzilla 将页面载入时间从 7秒缩减到 2秒，转化率提升了 7-12%，页面请求增加 25%，只用一半服务器就够了

要注意，这些只是数据，实际上，我们没有办法验证这些数据的真实性。但是可以肯定的是，网站访问速度过慢，一定对用户有负面影响。严重一些的，国外有 Friendster 因为网站访问过慢而导致的用户流失可以作为前车之鉴；网站访问速度快也可以增加竞争优势，比如Tumblr 一骑绝尘而将竞争对手 Posterous 甩在后面。国内这方面的例子比如优酷，斥重金改进用户访问速度，很大程度上保持了竞争优势。

相比投资在硬件上，我个人认为技术团队在 WPO 上的投入是可以用来评估团队技术能力的。有一次在和一位投资人聊起国内的分类网站哪个技术团队更具优势，我毫不犹豫的说看好百姓网，为何？访问一下同类网站，比较一下最终页面访问速度就知道了。这是体现一个技术团队意识和能力的地方。

当前最需要 WPO （甚至有些落后的) 的可能要数电子商务网站以及那些依托于大型 C2C 站点上的网店了。很多电子商务网站负责人非常重视 SEO，但在 SEO 已经快成为一种伪技术的今天，被忽视许久的 WPO 更应该引起重视。举例来说，可能绝大多数淘宝上的大卖家都不懂 Web 相关技术，当然也就无所谓什么 Web 性能优化了。我曾经见过有的卖家首页上一个页面放置几百个图片，一个页面动辄 7-8 Mb，用户访问速度可想而知，如果用户正常浏览都无法做到的话，要想购买产品恐怕也就无从谈起了。如果能对这一部分用户进行有针对性的处理，投入产出的价值还是显而易见的。说起图片来，可能这是最影响电子商务网站访问速度的一个因素，没有针对 Web 优化的图片、过大的尺寸或是失真的压缩图片比比皆是，无疑会严重影响用户体验与购买欲望(这里推荐做电子商务的朋友不妨关注一下 Yupoo.com 专门针对用户的这个需求而推出的图片管家服务)。

WPO 的好处？增加网站营收，降低运营开销，提升访问量，进而提升竞争力。

WPO 做起来其实并没有那么难，通过一些特定的准则(比如 YSlow 14条, refer)即可取得一些卓有成效的改进。期待 WPO 能早日成为 Web 工程师必备的常识。也建议每一个技术团队的负责人应该将 WPO 作为一项战略来抓，而不是只是一两个技术人员的事情。从现在就开始吧。

--EOF--

补充："快比慢好"，Google 把这句话作为十大价值观之一(refer)。而 Facebook 从创立至今，也一直将提升页面访问速度作为一项重要的策略。

补充一篇必读文章：WPO - Web Performance Optimization