第一次知道 鲜果阅读器 是在今年五月底的时候。那个时候我并不怎么在意，因为我一直是 Google Reader 的忠实用户。我一直以为鲜果是 抓虾 的 Copy 而已，并没有怎么的在意它。而近期无意间关注了下鲜果阅读器，我发现发的界面有很多的改变，功能也比刚上线的时候增强了不少。

这下有好戏看了，我要看看抓虾怎么对于这个用户群完全一样的对手了。我当初在选择在线阅读器的时候在抓虾和 Google Reader 之间犹豫不决。虽然我最后选择了当初只有英文版本的 Google Reader，但是我一直很期待 Google Reader 能像抓虾一样有一个 RSS Feed 的共享社区。

曾经有一段时间我每天上抓虾看下是否有其他「更精彩」的 Blog，然后将其拉回 Google Reader。我之所以那么「执着」的使用 Google Reader 是因为它出色的兼容性和易用性。从兼容性方面来说，Google Reader 几乎可以在任何的浏览器上使用（甚至包括了移动版本的 Opera Mini）；其次从易用性方面来说，Google Reader 几乎可以不用设置，你直接将 Rss 的链接加入 Google Reader 以后就可以了。之所以依赖 Google Reader 也部分其他的原因，就是 Firefox 能直接将 Rss 扔到 Google Reader 中。要知道，使用 Google Reader 的大部分用户同时也是 Firefox 的使用者。

说道这里似乎有点离题了，我所以看好鲜果是因为它清楚的市场定位。鲜果近期推出了「博客认领」的功能，它可以将博客和其作者对应起来。这个功能意义是非常巨大的，它摆脱了以前单一的 读者 - 读者 共享方式，使 Blog 的作者 - 读者 之间有了一个直接的交流。

鲜果的「热榜」功能则能直接的给出相应分类下订阅量最多的博客。订阅者的「羊群效应」是明显的。设想一下，刚了解怎么使用 Rss 的用户保证会满天下的寻找 Rss Feed，最终他们往往「相信」的是订阅最多的 Blog。

鲜果的「雷达」软件是在线阅读器的衍生。它可以让用户在桌面端随时知道自己的 OPML （Rss 订阅列表）更新。这是一个非常不错的功能，鲜果的确是想用户所想。

说了那么多，但是我目前还是处于观望状态。对于我「这些」原本就使用某阅读器的用户来说，适应也一种过程。Rss 阅读器本身就是一种粘性非常强的产品。

目前的鲜果已经可以用「优越」两个字来形容了，但是我个人认为还有一些细节可以考虑一下。比如用户的自身的阅读趋势。这点在 Google Reader 中本人使用的非常的频繁，因为它可以迅速知道哪些频道是许久未更新哦，哪些频道是自己最常看的。其次，将推荐或收藏（Google Reader 中称为「加注星标」和「共享」）自身生成一个 Rss Feed，这样可以被 Feedsky 等进行 Rss 合烧，让更多的读者知道我们（Blogger，内容的产生者）每天在阅读那些条目。

最后，发布一张我的 Rss 订阅比例，虽然 Google Reader 还是是以「压倒性」的优势占据了大部分的 Rss 阅读器市场。不过我有理由相信，依据目前鲜果的发展态势，完全可以有更好的作为。

清早忽闻 Angelived 团队解散了，这对我来说是莫大的遗憾，因为 Angelived 中文翻译 Blog 是我每天必读的 Blog 之一。

根据 官方所言 ，解散的原因是因为「制度不健全是导致团队越来越没有积极性」。我本人对此也深有感触。回想即将过去的 2007 年，我已经听闻不少的团队要么停滞、要么就是解散。七月份的 fcitx 事件 至今都没有恢复回来。

这使我陷入深深考虑中，为什么一切开始都是激情的团队在一段时间以后就会逐渐的冷却，甚至是冻结。我想正如 Angelived 所说「制度不全」是原因之一。从微观上讲，开源或者是公益的项目本身也是项目的一种，但其比传统的公司式项目开发要灵活很多。成员可以随时选择加入，也可以随时选择离开。这就需要一定的制度来健全人员的分工合作等等问题。

其次，基于网络的项目往往自身是没有任何报酬的。这点可能会涉及到成员的个人利益问题。刚加入时是一种激情，而长期以往无论精力还是时间上，没有任何人有义务去做这些无谓的花销。这就是理想和现实之间的差距。

再次，每天重复的劳动也会产生一种疲劳感。项目成员除了牺牲自己的业余时间、自身的精力和时间外，还需要处理各种不同的问题，比如成员之间的沟通合作等等。可以想象 Angelived 的成员每天都会「机械」的翻译国外的文章然后相互校对，我以前所参与的 fcitx 项目 也会在编写代码的同时，每天都要处理使用者反馈的 bug 、改进意见等等。

要改变这种情况，不是一朝一夕的，健全制度是一种可行的办法。同时对于团队的成员来说，保持激情的同时，有目标乃至有一定的报酬（无论是精神上还是物质上的）也是同等重要的。国外对此就做得非常的好，开源和公益项目除了有各大公司支持以外，他自身也有一整套自我盈利的系统。比如 Mozilla 基金会 、 Linux Kernel 团队 等等，这都是我们国内相关团队可以值得借鉴的地方。

最后， Angelived 所言「博客暂时停止更新一段时间，不过我不会放弃它的」，这也让我感到深深的触动。作为其团队的受益者之一，我看见他们还是执着着自己的理想和激情。我认为这样的团队是不可能被暂时的困难所击倒的，我期待 Angelived 回来的那天。

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

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

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

网络链路层

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

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

应用服务层

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

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

数据存储层

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

其他

相对的后期扩展性问题

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

预算问题

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

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