听说 FaceBook 开放其网站的代码了 ，期前也算是了解过 FaceBook 的架构，所以重点就是看其代码的质量。

可以毫不夸张的说，FaceBook 的代码质量、风格都不亚于某个开放源代码的项目（当然，并不是每个开源的项目代码都很友好）。我可以用「教科书式」的代码，来形容我眼前所看到的 FaceBook 的源代码。

有点离题了，开发语言（或者工具）的本身，并不能说明系统会有多么的优秀。目前的网络上所能找到的、开源的工具，只要稍加都能很好的提升性能。

锦上添花的就是加上良好的 Cache（缓存）机制。在「上古时代」，人们对于性能上的考虑，还处在程序也算法的优化上。随着 Web2.0 的到来（什么是 Web2.0？）、Ajax 这样的技术的出现，造成服务器处理的请求比平时多得多，此时就需要从宏观上改进整个系统的机制。

很快就出现了大量的相应工具，首先是 Squid 、然后是 Memcached ，最后是具体到 某个语言（比如 PHP）的扩展 。 正如期前所说的 ，Ajax 等前端技术的流行，Cache 技术逐渐从「后台」的点心，转成了「正餐」。

重新回到上述的 FaceBook 中，从上往下看（似乎这图不是完整的逻辑，搞不清楚为什么 Database 会在这个位置），所涉及到的 Cache 技术就有 APC、Memcached、 CDN 以及 浏览器的缓存 。基于这点就能够充分的表明，FaceBook 能够应对如此高的负载的因素之一就是合理的使用 Cache 机制。

Cache 的确是个好东西，但是有时候也带来了不少的麻烦。比如在前端开发过程中，往往就会碰到用户反应样式、脚本无法执行的情况，此时本人就会很机械的告诉他 Ctrl + F5 刷新。

坦白的说，本人认为使用 Cache 在项目中，不应该过分的乐观。Cache 所带来的用户重复刷新（虽然在良好的 Cache 机制下这种情况很少），空间上的逐渐增大（真的是用空间换取时间，想想 FaceBook TB 级别的 Cache 容量吧），这是使用 Cache 所带来的负面效果（但这往往有些技术人员会将此拿来当作炫耀的资本）。

不要将 Cache 作为提升性能的救命稻草。前段时间 Twitter 间歇性的罢工 ，虽然找到瓶颈是数据库。但本人同时也听到某些观点，诸如「如果 Twitter 有良好的 Cache 机制也许就不会这样」，在这里本人保留意见。

请容我胆大的猜想，也许 Cache 会和 Ajax 一样，最终有一天会消失。技术这玩意也就是这样，没有更好的只有最合适的。退一步讲真的到了那一天，Cache 的替代方案也会造成另外的问题也说不准 -- 以后的事情谁知道呢？

想起了一句话，就是

「计算机原先是为了解决麻烦才搞出来的，但是后来它本身就成了麻烦」。

wiLdGoose 兄 在他的 Blog 上 真情流露 ，不免让我有些许的感动。wiLdGoose 的陈述让我不免勾起了些许的回忆。

在 Lierda 的日子是非常值得怀念的 -- 这是我第一份工作，我在那里认识了包括 wiLdGoose、 Ppeng 、 Leftleg 以及 Badbuild 老大等在内的兄弟，还有（利用职务之便）遇到了 小妮子 。

在进 Lierda 之前，我和 Web 无关，同时对于 Web 也是毫无概念。当时作为学生的我，还沉浸在去如何使用 Python 和 C 去 Hack 我心爱的 Slackware Linux 的阶段。

当时 Foolkaka 老大需要个人去使用 PHP 开发个项目，于是硬着头皮研究了段时间（少于一个月时间），然后作为实习生加入了公司 -- 当时我刚上大四。当时的想法很幼稚，一来是能找到兼职赚点外快；二来是因为公司离学校很近，来回方便。

就这样，我开始了以编程为职业的生涯。记得刚开始的时候，我的水平非常的烂（现在恐怕也好不到哪里去）。典型的例子就是，我编写的某个类包含了 权限管理、用户组管理、用户管理 等等所有的功能，加上「完善」的注释，这个 PHP 文件竟然将近 4000 多行！这在当时被称为一段「佳话」。

可以说，wiLdGoose 兄和 Ppeng 兄给予了我 最大的帮助 。从 wiLdGoose 这里我学到了很多有关 PHP 方面的技术，从 Ppeng 这里我也「偷」到了很多前端代码。

由于 PHP 方面的薄弱，加上本人天生喜欢「折腾」，后来就认识了 Javascript 这门传说中的语言。坦白的讲，开始我很不屑于这种所谓的「浏览器脚本」。但后来对于那些「复制粘贴」的代码修修改改，逐渐的才对其产生了兴趣，这是后话了。

对于 Badbuild 老大，在本人的印象中一直都是个大孩子。记得第一天来 Lierda 上班时，我称 BigHead 大姐为「大姐」（这个称呼可能改变不了了）。后来才得知她是 Badbuild 的「原装」压寨夫人，要早知道就不会这么称呼她了，因为 Badbuild 老大他可是有权利定我每个月工资的，对此我曾经懊恼不已。

Badbulid 老大没有任何领导的架子，我甚至会向他开些玩笑。本人的移动硬盘中，经常会有很多好玩的东西（大家不要误解），Badbuild 老大总是会好奇得去打探究竟。于是我就经常拿这些去「勾引」此人，以达到加工资的目的。

和 Leftleg 兄谈论得最多的还是系统方面的问题。他在 Lierda 的时候是系统管理员兼 DBA ，在系统维护方面有非常丰富的经验。

那时的公司，总会有个非常经典的镜头，就是我、wiLdGoose 以及 Leftleg 兄拿着根烟在讨论问题，搞得公司门总是烟雾缭绕。Leftleg 兄是非常务实的人，碰到我们提到的问题总会先试验下，然后再给出结论。

当然还有 妮子 ，她总是给我们部门的人提出些「无理要求」。于是经过「本人的努力」，她现在可以在本人下班以后提出「无理要求」了（Badbuild 老大称之为「吃完了打包」）。

而最后正如 wiLdGoose 所言，上述的挚友逐一的离开，我发现在这里已经找不到一起抽烟、BT 的人了。加上本人从开始就不喜欢穿西装 Coding，最后选择黯淡离开。

总计我在 Lierda 的日子， 502 天。

有关 Web 字符编码的问题，已经是老生常谈。今天看到 一峰 兄弟和 Lunatic Sun 不谋而合的谈到有关 UTF-8 的使用现状，也谈谈我的看法。

上图是 Google 根据近年 Web 页面编码趋势的一个总结 。我很欣喜的看到 UTF-8 编码已经成为了主流，而犹如 一峰 兄弟所言，让人堪忧的是中文字符编码还是呈现很平稳的趋势，这说明目前 UTF-8 编码并没有在中文网站中推广开来。

究其原因，本人认为会有如下几点：

第一，中文编码（无论是 GBK、GB2312、GB18030 等）都变成了「传统」，毕竟这是 中文 的编码。开发者不愿意在字符编码这块花太多的心思。

第二，由于早期项目的原因，不得不继续使用 GBK 等中文编码。

我曾经就遇到过这样的一个项目，当时我很奇怪他们为什么不用 UTF-8，因为他们面对的客户不仅仅是国内用户。而解决这一方案的办法就只能是 使用非常劳累的手段 ，但这是指标不治本的办法。虽然最后，在本人的一再坚持下，最后还是转成了 UTF-8 编码，但相信国内还有很多项目都会碰到类似的问题。

第三，开发工具方面的支持，尤其是国内的一些产品。从根本上说，除了基本的思想意识以外，还有就是开发工具的问题。或许有一天，开发者相关的开发工具都默认的就是 Unicode 的话，这样转换的成本就会非常的低。

第四（感谢小马补充），流量大、文字多的中文站点通常都会使用 GB2312，原因很简单，页面下载量会比 UTF-8 小（GBK 编码只需要两个字节，而 Unicode 需要三个或者以上）。

那么，我经常使用的些主要的中文站点，目前在使用什么编码呢？下面是一个不完全的列表，供大家参考一下（以页面 meta 标签的 Content-type 为准）。

1. 淘宝 - GB2312
2. 支付宝 - GB2312
3. 口碑 - GBK
4. 中国雅虎 - GB2312
5. 163 - GB2312
6. 新浪 - GB2312
7. 搜狐 - GB2312
8. 豆瓣 - UTF-8
9. Yupoo - UTF-8
10. 谷歌 - UTF-8
11. ...

从上述的站点看来，目前国内一般门户类型的站点基本上都是 GBK 等编码，而类似 豆瓣 、 Yupoo 这样的新兴 「Web2.0 式站点」已经开始尝试 UTF-8 。在我看来，Unicode 在中文站点的推广，任重而道远。

那么接下来，在您以后的项目中，您会选择什么字符编码？

另，有关字符编码方面的知识，一峰 兄弟的 相关文章 ，很受用。