从Ruby向Java的迁移帮助Twitter挺过了美国大选

在美国总统大选的日子&＃xff0c;根据负责Twitter基础架构运维工程的VP　Mazen Rawashdeh的说法&＃xff0c;服务器平均每分钟要处理327452条tweet&＃xff0c;即便在这种情况下&＃xff0c;Twitter声名狼藉的“失败鲸&＃xff08;Fail Whale&＃xff09;”画面也没有出现。在一天时间内&＃xff0c;大选相关的tweet总计有3100万条&＃xff0c;网站流量也继续阶段性飙升&＃xff0c;一度达到每秒15107条tweet的峰值。从历史上看&＃xff0c;2008年的大选之夜&＃xff0c;Twitter的峰值是每秒229条tweet。

Rawashdeh指出&＃xff0c;他们注意到在过去的一年中Twitter的使用模式有所变化&＃xff0c;原来峰值持续时间较短(比如新年之夜的钟声敲响或碧昂丝宣布怀孕这类事件时&＃xff09;&＃xff0c;而现在峰值持续时间动辄数小时。这种情况已经出现了多次&＃xff0c;比如奥运会闭幕式、NBA决赛以及现在的大选。

Twitter之所以能够支撑这种级别的流量&＃xff0c;部分原因是基础架构的改变&＃xff0c;其中包括InfoQ 之前曾经报道过的将架构从Ruby向运行于JVM之上的混用Java和Scala编写的服务逐步迁移。

最近的报道也提到了Twitter移动客户端的变化&＃xff0c;Rawashdeh写道

\u0026#xD;\n

作为从Ruby架构持续向外迁移的一部分&＃xff0c;我们重新配置了服务&＃xff0c;这样从移动客户端上到来的流量会交给Java虚拟机&＃xff08;JVM&＃xff09;软件栈&＃xff0c;因而完全避免了使用Ruby软件栈。

\u0026#xD;\n

Twitter一度被认为是世界上规模最大的Ruby on Rails用户&＃xff0c;而且在Ruby软件栈上也有大量投资&＃xff0c;该公司甚至开发了自己的名为Kiji的分代垃圾收集器&＃xff08;与标准的Ruby垃圾收集器不同&＃xff0c;这种收集器将对象划分到多个代中&＃xff0c;在大多数处理周期&＃xff0c;只需要将代中的对象子集放入初始的白色集中&＃xff0c;即作为垃圾回收的候选对象&＃xff09;。

然而在2010年&＃xff0c;Twitter宣布他们会改变开发的部分关注点。对于前端而言&＃xff0c;他们会跟随HTML5的趋势&＃xff0c;将渲染代码向基于浏览器的Javascript迁移&＃xff0c;这么做的同时&＃xff0c;也就无法再从Rails构建Web页面的模版模型中获益了。之后&＃xff0c;在性能和代码封装等因素驱动之下&＃xff0c;工程团队使用Scala重写了后端消息队列和Tweet存储引擎。

同样在2010年&＃xff0c;Twitter的搜索团队也开始重写搜索引擎&＃xff0c;将搜索的存储系统从MySQL修改为基于Lucene构建的系统。之后在2011年&＃xff0c;工程团队宣布将用于搜索的Ruby on Rails前端替换为Java服务器Blender。此举将搜索延迟降低了3倍。

作为这些改进的结果&＃xff0c;Twitter的系统一直处于无故障运行状态。“无论何时、何地或多少人使用&＃xff0c;Twitter在全世界范围内应该是7×24可用的&＃xff0c;这是我们的底限。”Rawashdeh写到&＃xff0c;“我们为实现这一愿景付出了很多努力。”

查看英文原文&＃xff1a;Twitter’s Shift from Ruby to Java Helps it Survive US Election

感谢侯伯薇对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作&＃xff0c;请邮件至editors&＃64;cn.infoq.com。也欢迎大家通过新浪微博&＃xff08;&＃64;InfoQ&＃xff09;或者腾讯微博&＃xff08;&＃64;InfoQ&＃xff09;关注我们&＃xff0c;并与我们的编辑和其他读者朋友交流。