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

鉴于性能和可扩展性方面的原因,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上有很长的反响讨论

原文地址:https://www.cnblogs.com/shihao/p/2720837.html