鉴于性能和可扩展性方面的原因，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 上有很长的反响讨论。
注册/登录 InfoQ 发表评论