Doctrine 从 2006 开始建立项目以来就一直使用的 LGPL 授权协议，最近其刚刚宣布由 LGPL 修改为 MIT，以更加开放，使开发者不会有太多的顾虑。

Doctrine 是一个 PHP 的 ORM （对象关联映射框架），基于强大的 DBAL (数据库抽象层)。其中一个最主要的功能就是使用面向对象的方式执行数据库查询，受 Hibernate HQL 的影响，Doctrine 使用一种叫 DQL 的查询语句进行数据库查询。

就在刚刚，我在「Ubuntu App Developer」把「Tweak for Ubuntu」提交上去了。

咦？怎么不是Ubuntu Tweak？这个「Tweak for Ubuntu」有何不同？于是，我又打算讲一个不长不短的故事了。

Ubuntu Tweak之最初梦想

2007年9月，Ubuntu Tweak作为我大一暑假时闲的蛋疼时学习编程的产物，就在两个月的时间内，被我折腾出来了。

它一开始就叫「Ubuntu Tweak」，因为我只打算给Ubuntu做这么个工具。后来我想让他更本地化一点，开发中途尝试改叫「Ubuntu优化大师」，但是挡不住舆论的压力， 又改回了「Ubuntu Tweak」。记得当时有人说了句很经典的话——「Windows才需要优化呢！」

就这样折腾了一个暑假，2007年9月9月，也就是开学的时候，我就把第一个版本Ubuntu Tweak 0.1.2发布出来了。

我展开了我至今为止都没有再度使用过的强大的舆论宣传攻势，在IMTX上、在LDCN上、在cnBeta上、在Ubuntu中文论坛上，甚至在对岸的Ubuntu正体中文站上，宣传着我那个又丑又烂的Ubuntu Tweak。

很多时候都是不知者无畏啊，现在我都不敢这样去宣传了，当时我真是「年少轻狂」。哈哈。

这里不打算讲完整的故事，我就来讲讲我的野心变化与奋斗史吧。

Ubuntu Tweak之野心膨胀

尽管当时我水平相当的菜，无论是编程、UI设计、UX设计，都不咋的。但是这不妨碍我有具大的野心，当然这个野心是慢慢地发展而且变化的。

做了几个版本以后，特别是在后来用Python重写了以后，我慢慢地让Ubuntu Tweak不再那么「Ubuntu Only」了，甚至模块的加载也是「Lazy Load」了，加载失败也不会影响其他功能的使用了。这个时候我的野心就大起来了，想让Ubuntu Tweak登陆其他所有可能登陆的Linux平台，于是在朋友的帮助下，2008年的时候，我推出了「Ubuntu Tweak for Fedora」。

当然结果是没有什么反响，于是我就收敛了一下野心，先好好专注做Ubuntu平台吧。

在做Ubuntu平台的时候，我通过做了一个「Source Center」（当时叫Third-Party Sources）的功能，去解决了用户想安装更新的软件和安装默认源不包括的软件的问题。以往用户只能通过敲命令行，或者手动去下载更新的方式去解决。

这个功能基本上成为Ubuntu Tweak的杀手级功能，每个版本都在不断改善，甚至后来我直接因为这个，去更深入学习了Web开发，跟Kevin、Keke等人一起做了UTCOM这个网站，专门动态去提供更新源的数据。

这个时候，Ubuntu Tweak也有了越来越多的用户，当时社区的朋友，如Aron、Freeflying，就来帮我把Ubuntu Tweak提交到源里去，因为加到源里后，就可以让用户直接安装，更加方便，也会因此有更多用户吧。

但是事情不是这么简单，因为Ubuntu Tweak提供了「软件源」的功能，而这些软件源包括的更新的软件（甚至一些测试版、Alpha的），可能会对用户的电脑造成潜在影响，此外还有一些设计上的原因，总之被驳回了。

当时我肯定是不高兴了，但是也没影响我继续开发下去。反正用户还能接着用，就没关系。而且可能因此反而更有动力了，哼，不让它进源是吧，那我就把这些功能做的更好更安全，让你们没有理由驳回。

然后又是过了很久很久……Ubuntu的软件中心，推出一个特殊的频道，不论是开源软件还是商业软件，都可以提交至这个特殊的分类中，甚至可以给软件定价格出售。

这时，我又想到把Ubuntu Tweak提交至这个分类中去了，当时我发布0.6.0没多久，这个版本天然没有「Source Center」（因为当时还没来得及Port），我想这下没有理由把它再驳回了吧。

于是我又把Ubuntu Tweak 0.6.0提交到这个地方去了，这次终于好些了，指出一些打包的问题外，还提到了Trademark的问题。大意是Ubuntu是注册商标，非官方项目建议不使用该名字。

好歹有点希望了，我就先继续开发0.7版本，待下个周期再提交好了。

Ubuntu Tweak之回头是岸

开发着0.7版本，一不小心又把「Source Center」的功能给搞回来了。这也是上个月的事情了。

这个时候，我已经忘记了把它提交至软件中心的事情了，我的开发蓝图继续更新着——既然Software Center又有了，不如继续改善，继续把我心目中的0.8、0.9给开发下去好了，直到1.0版本。

然而，在发布0.7至今一个月的时间内，我一直在纠结，到底有没有必要？现在它已经不是纯粹的「Tweak」了，做的太多功能的话，我一个人要负责的也太多，我怕到时承受不起。虽然我已经计划好，提交一个阉割版本的给软件中心，同时继续做自己的一个版本。

但是，此刻，就在这个时候，我回想了一下过去近五年，我已经很满足了。

按照五年前刚做Ubuntu Tweak的那时野心还没有膨胀的我来说，当时我只是想做一个配置工具，方便自己配置Ubuntu，毕竟Ubuntu对当时的用户特别是中文用户来说，还 完全没有开箱即用。而经过这么多年的发展，Ubuntu已经有了显著的进步，以前我用Ubuntu必换字体、必换主题、必用Dock，现在……我用着默认 的Unity桌面、默认的中文字体、默认的主题，完全不需要自己去折腾，我很习惯和适应这些。我已经习惯不「Tweak」的Ubuntu了。

而开发Ubuntu Tweak本身对我带来的收获，则已经是彻底地、完完全全地超过我当初的预想了：

• 我的编程技能、设计技能、项目管理技术，都有了很大的提升，而且比较彻底地熟悉了整个Ubuntu的环境；
• 我因为写这个软件，认识了非常多的朋友，这些朋友在我现在的工作和生活中给了我很多帮助；
• 不善言辞的我都在复旦、清华、北邮的讲台上演讲过了；
• 我一不小心成为了「主席」；
• 我一不小心地进入了Ubuntu的背后的公司——Canonical；
• 还有很多很多的无法统计给我带来深刻影响的「一不小心」……
• ……

可以说，最初的出发点，已经完全满足了。当前的Tweak，也不如曾经那么重要了。更何况，我已经不是在野了，很多问题，我可以直接尝试在上游解决，毕竟我已经成功打入内部了嘛！

于是，我很自然地想通了，把Ubuntu Tweak改名成了「Tweak for Ubuntu」，禁用了「Source Center」功能，重新打了个包，提交给了Ubuntu软件中心 。当然，再一次的，定价0.00美元，依然永远免费。

接下来，无论「Tweak for Ubuntu」是否能顺利地进软件中心，我都会不断妥协，有什么不安全的功能，砍！有什么不必要的功能，砍！直到成为一个真正的「Tweak」，进入软件中心。

然后，我会继续做它的维护和小幅更新工作，让它在未来的Ubuntu 12.10上能正常工作，在Ubuntu 13.04上能正常工作，与此同时，不断bump版本号，某年某月某月，它终将达到1.0版本。

毕竟我不是要停止更新，只是说停止无止尽地加Feature，所以大家还是放心，未来它还是会继续存在。

我只是进入一个准退休的状态，享受过去努力带来的成果，并且展望一下新的未来神马的。

晚安！

文/imtx

互联网已经发展多年，其中不乏脱颖而出者，这些网站多数都已存在了接近10年或10年以上，在如此长时间的发展过程中，除了业务上面临的挑战，在技术上也 面临了很多的挑战。我挑选了一些Alexa排名较前的网站（排名截止到2012年4月21日），看看它们在技术上是如何应对业务发展过程中的挑战的。

Google目前Alexa排名第1。它诞生于1997年，当时是一个研究性项目，每个月build一次索引，build出来的索引通过 sharding（shard by doc）的方式分散到多台服务器（Index Server）上，具体的网页数据同样通过sharding的方式分 散到多台服务器（Doc Server）上，当用户提交请求时，通过前端的一台服务器将请求提交给Index Server获得打了分的倒排索引，然后从 Doc Server提取具体的网页信息（例如网页标题、搜索关键词匹配的片段信息等），最终展现给用户。

随着索引的网页增加，这个结构可通过增加Index Server以及Doc Server来存储索引以及网页的数据，但仍然会面临其他很多方面的问题，于是在这之后的十多年的时间里，Google做了很多事情来改进上面的结构。

1999年，Google增加了一个Cache Cluster，用来Cache查询的索引结果和文档片段信息，同时将Index Server和 Doc Server通过Replicate的方式变成了Cluster。这两个改造带来的好处是网站的响应速度、可支撑的访问量以及可用性 （Availability）得到了提升。这个变化造成了成本的增加，Google在硬件方面的风格始终是不用昂贵的高端硬件，而是在软件层面来保证系统 的可靠性及高性能，于是同年，Google开始采用自行设计的服务器来降低成本。2000年，Google开始自行设计DataCenter，采用了各种 方法（例如采用其他的制冷方法来替代空调）来优化PUE（能源利用率），同时对自行设计的服务器也做了很多化。

2001年，Google对Index的格式进行了修改，将所有的Index放入内存， 这次改造带来的好处是网站的响应速度以及可支撑的访问量得 到了极大的提升。2003年，Google发表了文章Google Cluster Architecture，其Cluster结构组成为硬件LB + Index Cluster + Doc Cluster + 大量廉价服务器（例如IDE硬盘、性价比高的CPU等），通过并行处理+sharding来保证在降低对硬件要求的同时，响应速度仍然很快。同年 Google发表了关于Google文件系统的论文（GFS在2000年就已经上线），这篇论文很大程度也体现了Google不用昂贵硬件的风格，通过 GFS+大量廉价的服务器即可存储大量的数据。

2004年，Google再次对Index的格式进行了修改，使得网站的响应速度继续提升。同年Google发表关于MapReduce的论文，通 过MapReduce + 大量廉价的服务器即可快速完成以前要使用昂贵小型机、中型机甚至是大型机才能完成的计算任务，而这显然对于Google快速地构建索引提供了很大的帮助。 2006年，Google发表了关于BigTable的论文（2003年开始上线），使得海量数据的分析能够达到在线系统的要求了，这对于Google提 升网站的响应速度起到了很大的帮助。

以上3篇论文彻底改变了业界对于海量数据的存储、分析和检索的方法（小道消息：Google内部已完成了GFS、MapReduce、BigTable的替换），也奠定了Google在业界的技术领导地位。

在一些场景中，Google也采用MySQL来存储数据。同样，Google对MySQL也做了很多修改，它使用的MySQL信息可以从 https://code.google.com/p/google-mysql/ 了解。

2007年，Google将build索引的时间缩短到分钟级，当新网页出现后，几分钟后即可在Google搜索到，同时将 Index Cluster通过Protocol Buffers对外提供Service，以供Google各种搜索（例如网页、图片、新闻、书籍等）使 用，除了Index Cluster提供的Service外，还有很多其他的Service，例如广告、词法检查等。Google的一次搜索大概需要调用 内部50个以上的Service，Service主要用C++或Java来编写。2009年，Google的一篇 《How Google uses Linux》文章，揭示了Google在提升机器利用率方面也做了很多的努力，例如将不同资源消耗类型的应用部署在同 一台机器上。

在之后，Google又研发了Colossus（下一代类GFS文件系统）、Spanner（下一代类BigTable海量存储和计算架构）、实时 搜索（基于Colossus实现），主要都是为了提升搜索的实时性以及存储更多数据。除了在海量数据相关技术上的革新外，Google也不断对业界的传统 技术进行创新，例如提高TCP的初始拥塞窗口值、改进HTTP的SPDY协议、新的图片格式WebP等。

在Google的发展过程中，其技术的改造主要围绕在可伸缩性、性能、成本和可用性4个方面，Google不采用昂贵硬件的风格以及领先其他网站的数据量决定了其技术改造基本都是对传统的软硬件技术的革新。

Facebook目前Alexa排名第2。它采用LAMP构建，随着业务的发展，它也在技术上做了很多改造。

作为改造的第一步，Facebook首先在LAMP结构中增加了Memcached，用来缓存各种数据，从而大幅度提升系统的响应时间以及可支撑的 访问量，之后又增加了Services层，将News Feed、Search等较通用的功能作为Service提供给前端的PHP系统使用，前端的系统 通过Thrift访问这些Service。Facebook采用了多种语言来编写各种不同的Service，主要是针对不同的场景选择合适的语言，例如 C++、Java、Erlang。

大量使用Memcached以及访问量的不断上涨，导致访问Memcached的网络流量太大，交换机无法支撑，Facebook通过改造采用UDP的方式来访问Memcached，以降低单连接上的网络流量。除此之外，还有其他一些改造，具体信息可以查看http://on.fb.me/8R0C。

PHP作为脚本语言，优势是开发简单、易上手，劣势是需要消耗较多的CPU和内存。当Facebook的访问量增长到了一定规模后，这个劣势就比较 突出了，于是从2007年起，Facebook就尝试多种方法来解决这个问题，最后诞生于Facebook Hackathon的HipHop产品成功地 脱颖而出。HipHop可以自动将PHP转化为C++代码，Facebook在使用HipHop后，同等配置的机器，可支撑的请求量是之前的6倍，CPU 的使用率平均下降了50%，从而为Facebook节省了大量主机。将来Facebook还会对HipHop进行再次改进，通过HipHop将PHP编译 为bytecode，放入HipHop VM中执行，再由HipHop VM来编译为机器代码，方式与JIT类似。

2009年，Facebook研发了BigPipe，借助此系统，Facebook成功让网站的速度提升了两倍。随着Facebook访问量的上 涨，收集众多服务器上的执行日志也开始面临挑战，于是Facebook研发了Scribe来解决此问题。对于存储在MySQL中的数据，Facebook 采用垂直拆分库和水平拆分表的方式来支撑不断增长的数据量。作为Facebook技术体系中重要的一环，Facebook也对MySQL进行了很多优化和 改进，例如Online Schema Change等，更多信息可见http://www.facebook.com/MySQLAtFacebook。

发展之初的Facebook采用了高端的存储设备（例如NetApp、Akamai）来存图片，随着图片不断增加，成本也大幅提高，于是2009年 Facebook开发了Haystack来存储图片。Haystack可采用廉价的PC Server进行存储，大幅度降低了成本。

Facebook除了使用MySQL存储数据外，近几年也开始摸索采用新的方式。在2008年Facebook开发了Cassandra，在 Message Inbox Search中作为新的存储方式。不过在2010年，Facebook又放弃了Cassandra，转为采用HBase作为 其Messages的存储，并在2011年将HBase应用在了Facebook更多的项目上（例如Puma、ODS）。据说，现在Facebook更是 在尝试将其用户以及关系数据从MySQL迁移到HBase。

从2009年开始，Facebook尝试自行设计DataCenter以及服务器，以降低其运行成本，并对外开放了其构建的PUE仅1.07的 DataCenter的相关技术。Facebook在技术方面的基本原则是：“在能用开源产品的情况下就用开源，根据情况对其进行优化并反馈给社区”。从 Facebook的技术发展历程上可以看到这个原则贯彻始终，Facebook的技术改造也主要是围绕在可伸缩、性能、成本和可用性4个方面。

Twitter目前Alexa排名第8。在2006年诞生之时是采用Ruby On Rails+ MySQL构建的，2007年增加了 Memcached作为Cache层，以提升响应速度。基于Ruby on Rails让Twitter享受到了快速的开发能力，但随着访问量的增长，其 对CPU和内存的消耗也让Twitter痛苦不堪，于是Twitter做了不少改造和努力，例如编写了一个优化版的Ruby GC。

2008年Twitter决定逐步往Java迁移，选择了Scala作为主力的开发语言（理由是“难以向一屋子的Ruby程序员推 销Java”），采用Thrift作为其主要的通信框架，开发了Finagle作为其Service Framework，可将后端各种功能暴露为 Service提供给前端系统使用，使得前端系统无需关心各种不同的通信协议（例如对于使用者可以用同样的调用服务的方式去访问Memcache、 Redis、Thrift服务端），开发了Kestrel作为其消息中间件（替代之前用Ruby写的Starling）。

Twitter的数据存储一直采用MySQL，发展过程中出现的小插曲是，当Facebook开源了Cassandra时，Twitter本计划使用，但最终还是放弃，仍然保持了使用MySQL，Twitter的MySQL版本已开源（https://github.com/twitter/mysql）。Twitter也是采用分库分表的方式来支撑大数据量，使用Memcached来Cache tweet，timeline的信息则迁移为用Redis来Cache。

2010年，Twitter在盐湖城拥有了第一个自建的DataCenter，主要是为了增加可控性。从Twitter的发展过程看，6年来它的技术改造主要围绕可伸缩以及可用性。

作为一家电子商务网站的员工，请允许我在此介绍这个Alexa排名21的著名电子商务网站的技术演变。

1995年，eBay诞生，当时采用CGI编写，数据库采用的是GDBM，最多只能支撑5万件在线商品。1997年，eBay将操作系统从 FreeBSD迁移到Windows NT，另外将数据库从GDBM迁移为Oracle。1999年，eBay将前端系统改造为Cluster（之前只有 一台主机），采用Resonate作为负载均衡，后端的Oracle机器升级为Sun E1000小型机，同年给数据库增加了一台机器作为备库，提升可用 性。前端机器随着访问量不断增加还可以应付，但数据库机器在1999年11月时已经达到了瓶颈（已经不能再加CPU和内存了），于是在11月开始将数据库 按业务拆分为多个库。2001-2002年，eBay将数据表进行了水平拆分，例如按类目存储商品，同时部署Oracle的小型机换为 Sun A3500。2002年，将整个网站迁移为用Java构建，在这个阶段，做了DAL框架来屏蔽数据库分库分表带来的影响，同时还设计了一个开发框 架以供开发人员更好地上手进行功能开发。从eBay的整个发展过程来看，技术改造主要围绕在可伸缩性和可用性两点。

腾讯目前Alexa排名第9。最初QQ IM采用的是单台接入服务器来处理用户的登录和状态保持，但在发展到一百万用户同时在线时，这台服务器已经 无法支撑。于是QQ IM将所有单台服务器改造为了集群，并增加了状态同步服务器，由其完成集群内状态的同步，用户的信息存储在MySQL中，做了分库分 表，好友关系存储在自行实现的文件存储中。为了提升进程间通信的效率，腾讯自行实现了用户态IPC。之后腾讯将状态同步服务器也改造为同步集群，以支撑越 来越多的在线用户。在经历了前面几次改造后，已基本能支撑千万级别的用户同时在线，但可用性比较差，于是腾讯对QQ IM再次进行改造，实现了同城跨 IDC的容灾，加强了监控和运维系统的建设。此后腾讯决定对QQ IM架构完全重写（大概是2009年持续到现在），主要是为了增强灵活性、支持跨城市的 IDC、支撑千万级的好友。在这次大的技术改造过程中，腾讯的数据都不再存储于MySQL中，而是全部存储在了自己设计的系统里。

从QQ  IM的技术演变来看，其技术改造主要是围绕在可伸缩性和可用性上。

2003年，淘宝诞生，直接购买了一个商业的phpAuction的软件，在此基础上改造产生了淘宝。2004年，将系统由PHP迁移到 Java，MySQL迁移为Oracle（小型机、高端存储设备），应用服务器采用了WebLogic。2005-2007年的发展过程中，用JBoss 替代了WebLogic，对数据库进行了分库，基于BDB做了分布式缓存，自行开发了分布式文件系统TFS以支持小文件的存储，并建设了自己的CDN。 2007-2009年对应用系统进行垂直拆分，拆分后的系统都以Service的方式对外提供功能，对数据采用了垂直和水平拆分。

在进行了数据的垂直和水平拆分后，Oracle产生的成本越来越高，于是在之后的几年，淘宝又开始将数据逐渐从Oracle迁移到MySQL，同时 开始尝试新型的数据存储方案，例如采用HBase来支撑历史交易订单的存储和检索等。近几年淘宝开始进行Linux内核、JVM、Nginx等软件的修改 定制工作，同时也自行设计了低能耗服务器，同时在软硬件上进行优化，以更好地降低成本。

从淘宝的整个发展过程来看，技术改造主要围绕在可伸缩性和可用性两点，现在也开始逐渐将精力投入在了性能和成本上。目前淘宝的Alexa排名为第14。

总结

从上面这些Alexa排名靠前网站的技术发展过程来看，每家网站由于其所承担的业务不同、团队人员组成不同、做事风格相异，在技术的不同发展阶段中 会采用不同的方法来支撑业务的发展，但基本都会围绕在可伸缩性、可用性、性能以及成本这4点上，在发展到比较大规模后，各网站在技术结构上有了很多的相似 点，并且这些结构还将继续进行演变。

作者林昊，目前就职于淘宝，2007-2010年负责设计和实现淘宝的服务框架，此服务框架在淘宝大面积使用，每天承担了150亿+的请求；2011年开始负责HBase在淘宝的落地，目前淘宝已有20个以上的在线项目在使用HBase。

新闻来源:《程序员》

我很吃惊在Hacker News的头版头条上竟然出现了一篇叫做《别学编程》的文章，而更让我吃惊的是文章的作者竟然是CodingHorror的创办人、StackOverflow上大名鼎鼎的Jeff Atwood。

Jeff认为，并不是每个人都需要知道编程知识，事实上，这世界上不需要更多的水平一般的程序员。所以，他对最近兴起的像CodeYear这样的旨在全民编程知识普及的运动并不热心。

因为Jeff 使用了我设计的CodeYear网站来说明他的观点，我想有必要对此做些反驳。

我认为每个人都应该学习编程，有一个简单的理由；知道如何编程是一种强大的能力。

我并不认为这世界上还存在有很多的其它的知识技能可以像知道如何搭建一个网站那样让你从无到有创建出一个东西并以此接触到如此多的人。

就像上周，我冒出来一个想法，然后用2天时间建起了一个网站。仅在几个小时内就有1万多人访问它。

想想吧：我做的东西触及到了1万多个活生生的人，而且对他们的生活产生了影响(或多或少)。如果不知道编程，一个人可能永远做不到这样。

什么是编程？

也许你会争辩：我并非一定要知道如何去开发一个网站。你也许还会认为用WordPress搭建一个网站不能算是“编程”。

但是，从一个不懂技术的人的角度上看，用Wordpress搭建一个网站和用Ruby on Rails创建一个网站具有相同的复杂度。

“学习编程”并不是说要你成为下一个托马斯.李纳斯(Linus Torvalds)那样的人，就像是“学会做饭”并不是意味着你要开一个3星级的餐馆。

它只是简单的表示你对计算机的工作原理有一些基本的掌握，而不是让一个会说话的回形针告诉你怎么做(也许你最终能学会如何编程开发自己会说话的回形针)。

我们首先要做的是告诉人们学会编程不是那么难，在他们的脑子里输入这样一种观点能让他们更容易学成。我相信这才是像CodeYear这样的网站想要做的事，我认为这是一个非常有意义而且能实现目标。

[本文英文原文链接：Please Learn to Code ]