突破技术瓶颈

2007年 10月，Google完成了收购 Jaiku的企划案。但彼时

Twitter已经做好了应战的准备，技术的完善使它更有信心迎接其他

人的挑战。不过 Jaiku重新开放后并没有取得预想中的效果，尽管拥有相对稳定的客户流，但新用户数的增长速度并不理想，始终处于一种不温不火的状态之中，而 Google似乎也没有兴趣投入更多的人力、财力进一步开发这项服务。看起来，Jaiku与 Twitter正在并行不悖地发展着，Google的收购案并没有给 Twitter带来实质性的伤害，反倒是在一定程度上促成了人们对 Twitter的进一步关注。现在似乎可以暂时松一口气了。但很快，这种相对平静的局面就再次被打破了。

2008年春，Twitter又迎来了新一轮的挑战。而这次的挑战首先来自自身的技术瓶颈。由于用户数量的持续增多，Twitter的月独立用户访问量再创历史新高，达到了 50万。用户上传信息的爆炸式增长明显超出了 Twitter的承载限度。Twitter在最初的架构过程中，主要是面向内容的管理系统，因此在面对大量信息时显得有些力不从心，于是一个让人恼火的现象出现了——Twitter开始频繁宕机，并且很多时候是长时间宕机。在这个春季，很多 Twitter用户一登录就看见 Twitter停机维护的通告。

对于一个网站来说，频繁的宕机是非常致命的，它破坏了用户的网络体验，影响了用户的上网习惯，可能导致用户数量的下降。尽管此刻 Twitter已经拥有众多的粉丝，但这种弊端仍然非常严重。很多 Twitter使用者为此非常苦恼，在 Twitter宕机的时间里，他们的生活仿佛也受到了影响——没有心思做别的事情，情愿一而再再而三地不断尝试登录，但是迎接他们的总是不咸不淡的停机维护通知。推迷们抱怨说 Twitter应该及时改进服务质量，阻止宕机情况的一再发生，否则就要考虑寻找新的替代品。

苍蝇不叮无缝的蛋，你的漏洞往往就会成为敌人的突破口。正当 Twitter苦恼于频繁发生的宕机故障时，另一个微博客社交网站——Plurk问世了。

Plurk是由一个叫做 A-team的组织创建的支持多种语言的可视化微博客网站。与 Twitter类似，Plurk也主张极简主义，将消息的规模限定在 140个字符，用户同样可以在网站上设定自己关注的人，或者被人关注，并且可以随时查阅关注的人的更新信息。时间轴是 Plurk的最主要特色，用户自己和好友的信息都被整合在时间轴上，这样用户就可以通过拖动时间轴来方便地查阅信息。此外，为了鼓励用户更多地使用网站的服务，Plurk设定了一个特殊的热度计算系统——Karma，用户每天发表质量较高的 Plurk信息、保持活跃的状态、成功邀请好友加入或者发表的信息被回复等都可以使Karma值得到增长。当然，如果用户超过一定时间不活动，发表超过限量的 Plurk信息，或者发送的注册邀请被拒绝也会导致 Karma值的下降。Karma值对于用户来说不仅仅是一个活跃值或者贡献值，而且意味着一种资格——拥有高 Karma值的用户可以得到系统提供的更多附加服务，这使得用户愿意花费更长的时间在线使用 Plurk以获得更高的 Karma值。也许是考虑到系统数据处理的负荷问题，Plurk从一推出就做出了用户每天所发信息的数量限定，超出这个限定将以 Karma值的减少给予惩罚，这在一定程度上避免了因大量无用信息的堆积造成服务中断。

Plurk的出现再次向 Twitter提出了挑战。与 Jaiku不同，Plurk在产品的定位上更准确，在产品的营销上也更有经验。其人性化的设计，便捷的服务，独特的热度计算系统和时间轴服务吸引了大批用户，很快成为 Twitter的有力竞争对手，在某些地区受欢迎的程度甚至远远超过了Twitter。

面对系统宕机和竞争对手的双重挑战，Twitter感受到了前所未有的压力。为了扭转这一局面，Twitter决定放弃以前使用的 Rubyon Rails开发工具，尝试寻找新的支持可扩展性强的语言。大家在一起罗列了很多可供选择的语言，但都因为存在这样那样的问题而被一一否定了。这时有人想到了Scala。在 JVM平台上，Scala执行速度的表现是相当优秀的，几乎难以找到另一种语言能与之匹敌。经过反复的研究和讨论，Twitter决定采用 Scala进行开发。很快，数据处理的速度得到了明显改善，宕机的次数也逐渐减少。人们又开始重新陆陆续续地回到 Twitter了。