同时怀念 Ppeng 兄弟November 8, 2007

上次记得刚 纪念过 wiLdGoose 君 。而最近感情压力大、心里波动厉害，加之春心荡漾，不禁的想起我们亲爱的美工 Ppeng 兄弟。

在平常人的印象中 Ppeng 兄弟 是一位内向的人，当你和他熟悉了以后发现他也是一位非常有趣的人。我记得 Ppeng 兄弟最经典的就是「呵呵呵」三声的笑声，这让我永久难忘。

记得也是在去年的这个时候，也就是 wiLdGoose 远离了我们之后。因为工作的缘故，我们甚至连续吃了一个月的清真（但请千万不要怀疑我的信仰就变成了伊斯兰）。遥想当年 Ppeng 和 wiLdGoose 兄争争执到底是去吃盖浇饭还是清真的时候，我永远都是站在中立的位置。

记得 Ppeng 兄弟走的时候身体已略显的发福，不知许久不见会变得怎么样。但愿钻石的光芒没有掩盖你那傲人的身躯。当你在 Gtalk 签名挂起「2000 帅哥男女...」的时候，我就知道 Ppeng 兄弟现在一定很开心、很 happy。

嗯，开心比一切都重要。

Ppeng 兄弟不知还记得我在我们的网站上面开的那个彩蛋不。每当我有空的时候就打开这个页面，听着阿牛的「骚歌」、看着那碗拉面，对着显示器流口水……

下面是短信竞猜时间，请您右击上面图片，获取此图片的地址，保存并发送至 135******** 即可赢取本人初吻一个。* 时间有限，先到先得，晚到也得。*

让我们一起忽悠 Spam 机器人吧November 8, 2007

很多人的 Blog 都被 Spam 机器人骚扰，有的甚至已经到了无法容忍的地步。这是一种不幸，同时也是一种荣幸。不幸的是那些无聊的 Spam 尽是发一些广告消息，而荣幸的是它给我们带来了流量。

很庆幸我的 Gracecode.com 的流量还不足够引起 Spam 机器人的重视。但是防患于未然，毕竟不是每个 Blog 都是喜欢垃圾评论的。下面根据我看到的、学到的结合我自己的经验在不影响用户体验的前提下说说防止 Spam 的「小窍门」。

别和我谈论如何美化验证码图片，因为我想网站访问者和我本人都不喜欢那些图片的。

防止 Spam 垃圾评论

Spam 其实是很傻的，傻到它似乎无法去辨认 Javascript 和 CSS。防止它们我们只要在 from 中加入一个空的 textarea 就可以了。然后运用 Javascript 和 CSS 将这个 textarea 设置为隐藏就可以了（现在主流的浏览器都支持 CSS 和 Javascript）。

然后我们在服务器端测试这个 textarea 是否有输入，如果有输入那么就十有八九是 Spam 机器人。因为普通「人类」访问并提交这个 from 的时候他是无法看见这个 textarea 的。

防止 Trackback Spam

有时候道理一点就通。那么类似于 Trackback 这样的外部可写操作就非常的简单实现防止 Spam 了。比如我们设定一个 Trackback 的链接地址的 HTML 代码如下：

<a href="http://www.gracecode.com/trackback/blackhole" 
    id="trackback_id">Trackback</a>

然后根据当前的文章内容（比如 ID 等）运用 Javascript 将这个 trackback_id 的 href 值修改成正常的 Trackback 的地址就可以了。让 Trackback Spam 掉入无尽的黑洞里面吧！

总结

上面只是一点的「小窍门」而已，非到万不得已千万不要让用户输入那些该死的验证码。我个人认为这样在麻烦用户的同时，同时也麻烦了自己（很多人在花心思思考如何将自己验证码做得美观）。

最后，让我们一起对付 Spam 机器人吧，包括 Gracecode.com 在内的广大 Blogger 不怕你！

有关网站集群架构的一点点思考November 8, 2007

我目前所在的公司打算重新部署服务器集群架构。对于此，作为名项目开发人员本身对于 Linux 有点了解，想谈谈我的看法。

首先参看下面的网络和服务器架构图：

基本上此集群的架构可以分为三层：网络链路层、应用服务层和数据存储层。然后大体上再安排两台服务器分别作为数据备份服务器和监控服务器。

网络链路层

网络链路层主要分配请求的负载平衡。前端通过一个防火墙和交换机以后，再交由 LVS 处理。然后 LVS 决定相应的应用服务器处理请求并返回。

此端我部门里的某一成员计划采用脚本程序控制。但个人认为对于此我想一来是效率不高，二来的确对于高负载的要求来说，稳定性还是有待测试的。所以我们听从了我们的管理员的看法，采用网络层的动态分配。

应用服务层

应用服务器主要用作存放各种应用服务器，比如 Web 服务器、搜索服务器和文件服务器。Web 服务器可能要根据具体的流量来确定具体的服务器规模。

大体上按照服务器的性质来分， Web 服务器和搜索服务器对于 CPU 的要求是比较高的。而文件服务器则偏向于磁盘的吞吐性能。

数据存储层

数据存储层在这里我理解为数据库集群。按照现有的项目规划数据库的性能要求是当前的服务器集群中最高的，所以个人认为这块是重点。

其他

相对的后期扩展性问题

这点我们也已经意识到了。后期如果对于数据更新频率不是很高的应用，可以在各层之间中加入若干台缓存服务器，以提高响应速度并缓解应用服务器的压力。

预算问题

预算和现实总是有些差距的。此规模的服务器集群主要的预算基本上都应该在数据库服务器上面了。在不降低性能的前提下，可以适当的缩减服务器的规模和数量。

但是对于长期的项目规划来看，任何的付出都会获得一定的回报的。对于此，我想我的态度是乐观的。