最新一期《程序员》杂志上有篇《Web 2.0 构建要素》的文章，里面描述了一些 Web 2.0 的扩展性问题，这可能也是 Web 2.0 站点从小到大必须承受的苦恼。该文简单介绍了有些站点通过 Amazon S3 服务来解决存储扩展带来的压力。有些站点则必须自己动手构建最适合自身业务的技术方案。
很多比较成功的站点，有的时候会透露出一些关于站点扩展性的技术信息，像我收集的 Flickr 的开发者的 Web 应用优化技巧、Technorati 的后台数据库架构、Craigslist 的数据库架构等，往往是蜻蜓点水，看过之后让人心痒难当，可是更细节的东西又很难获取。尽管这些站点基本都是构建在 OpenSource 软件上，但这一点上看，似乎不够 Open ，唯一一个做的比较好的倒是要算 LiveJournal ，他们通过 Danga 站点贡献了几个经典的软件与一些很有参考价值的文档(如这篇对LiveJournal扩展性的介绍)，是为很多后起 Web 2.0 站点必备的参考信息。
在国内，很多 Web 2.0 站点也同样面临着这样的问题，象豆瓣，阿北还需要身兼 DBA, 而抓虾，虽然数据库已经有上亿级别的记录量，就上次我在北京和谌振宇聊天，感觉抓虾在扩展性上也是还有很多细节需要完善，在杭州，Yupoo 也因为日益增长的数据量而不得不着手考虑如何更为成功的实现分布式存储解决方案……
这些似乎表明，Web 2.0 站点扩展性问题越来越突出，已经成为制约 Web 2.0 发展的一个障碍，”多、快、好、省”的构建新型互联网应用，不知道正在让多少人犯愁。
在传统互联网领域，很多技术解决方案往往是软硬件厂商提出来，类似自上而下的推动，而 Web 2.0 站点变化太快，到现在为止，似乎只有 MySQL 一家公司是比较大的赢家，可是因为面对的客户情况各异，解决方案似乎无从说起(比较简略的实现案例倒是能找到几个)，再者，这些站点基本上是把 MySQL 这样的产品当作基本工具，和其他软硬件相互结合，然后在这个上面灵活构建出很多具有创新性的应用。这是一种自下而上的变化。
另一方便，Web 2.0 架构方面的人才还是稀缺，这个架构不是指某一方面(比如Java)的架构，而是整个产品环境的架构，象 Flickr 技术大牛 Cal Henderson 这样的人几乎是可遇不可求。操作系统、网络、数据库、开发语言每样都能那起来并且能够涉及足够灵活的技术方案，这要求，也的确高了一些。或许有人说，一个人不行，那么多几个人分别负责某几个环节不就成了? 这又带来另外一个问题：人力成本。
上一篇 Blog 我提到五月份的”侠客行“大会，我倒是希望能有一群网络技术人才能够就 “Web 站点可扩展性” 这个话题作一番探讨，每个站点如果都说说自己的心得，那么汇集在一起参考价值会对整个 Web 2.0 环境起到很大的促进作用。
最后，还拿 MySQL 说事儿，去年网志年会上，就有人感叹，国内 MySQL 好手太少了，考虑到物以稀为贵，有的 Oracle DBA 已经开始学习 MySQL 啦.
–EOF–