在 LinkedIn 的 Ruby on Rails 和 Node.js 对决

  • Abel Avram
  • 张卫滨

2012 年 10 月 10 日

话题:RubyRuby on RailsJavaScriptDevOps架构

鉴于性能和可扩展性方面的原因,LinkedIn 前段时间将其移动设施的后台从 Ruby on Rails 替换成了 Node.js。LinkedIn 团队的一位前成员根据其自身的认识, 对此做出了回应并解释了问题的原委。

LinkedIn 移动工程部门的总监Kiran Prasad对 ArsTechnica 说,他们必须重新考虑为 LinkedIn 客户移动设备提供服务的后台设施,原因在于尽管只有 7-8% 的用户使用他们提供的移动应用程序,但 Ruby on Rails 的后台就已经陷入可扩展性问题了。

LinkedIn 评估了三种可行的解决方案:Rails/Event Machine,Python/Twisted 以及 Node.js。按照 Prasad 的说法,Node.js 之所以最后被选中,是因为它提供了一些好处:

  • 更高的性能,在特定场景下 Node.js 能比 Rails 快 20 倍
  • 使用 3 个服务器而不是 30 个就能应对 10 倍的流量增长
  • 前端工程师能够进行后端代码的开发,两个团队实际上合二为一了。

LinkedIn 因为可扩展性舍弃 Rails 的事情在网络上引起了一些反响。LinkedIn 移动团队的一位成员 Ikai Lan 分享了在技术选择方面以及所面临的问题上的一些个人经历

我们选择的是 Ruby on Rails 1.2 版本而部署技术是Mongrel。别忘了,这是 2008 年。Mongrel 是 Ruby 的前沿技术。Phusion Passenger还没有发布(在此很久才发布的)而 Mongrel 比 FastCGI 早了很多很多年。Mongrel 的问题是什么?它是单线程的。它认为传输速度比 CPU 的效率更重要,这一点我认同。…我们使用Capistrano部署,并且是较早使用nginx的。…

(后来)我们升级到了 Rails 2.x+ … 并且使用 OAuth 来对 iPhone 客户端进行认证。基于 3-Legged OAuth,我们将 Rails 服务器转化成了 OAuth provider。为什么使用 3-legged OAuth?很简单:我们并不知道自己在做什么。我必须承认这一点。

为移动设备提供服务的服务器托管在 Joyent 上。所以按照 Lan 的说法,当移动应用需要信息时,请求要先发到 Joyent 上,然后再连接提供主 API 服务的 LinkedIn 数据中心:

伙计们,这是一个跨数据中心的请求。运行在单线程的 Rails 的服务器上(每个请求都会阻塞主程序),运行 Mongrel,内存泄露得像筛子(这主要是 gettext 的问题)。Rails 也做过一些事情,像翻译、将 XML 转换成 JSON,我们还在它上面测试了一些针对于移动设备的特性,但除此以外,它并没有做太多的事情。它仅仅比代理强一点。这个代理的最大并发数取决于我们运行了多少了单线程的 Mongrel 服务器。每个 Mongrel 经常要膨胀到 300Mb 的 RAM,所以我们不能大量运行它。

在指出了一系列问题后,Lan 最终承认“v8 确实相当快”但是他还说:“不要认为在构建下一项技术方案的时候必须用 node.js。在移动应用的服务器端,它确实是比 Ruby on Rails 更适合,但是它并不是性能的灵丹妙药。你正在比较的是一种较低级别的服务器和一种一站式的 web 框架。”

关于这个使用 Node.js 取代 Rails 的决定,Hacker News 上有很长的反响讨论

查看英文原文:Ruby on Rails vs. Node.js at LinkedIn

RubyRuby on RailsJavaScriptDevOps架构