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

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

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

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

最近的报道也提到了 Twitter 移动客户端的变化，Rawashdeh 写道

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

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

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

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

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

查看英文原文： Twitter’s Shift from Ruby to Java Helps it Survive US Election

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

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