LinkedIn用Node替代Rails：减少了27台服务器 速度提升20倍

摘要：这不是代表孰优孰劣，但LinkIn从Node替换Rails取得了不俗的性能提升，硬件的利用率提升了10倍。客观的说，将2008年与2012年的产品进行对比本身就不公平，曾经在LinkedIn工作的工程师蓝奕凯发表了博文，对使用Rails那段历史进行了说明，他并不认为Node是提升性能的灵丹妙药。

Ryan Paul写过一篇《深入观察LinkedIn移动端的设计》，在其中我们看到：有23%的移动用户；专注朴素、易用以及可靠性；30%原生代码，70%使用HTML；嵌入轻量的HTTP服务；单一的客户端应用链接云服务器；后端服务从Rails转换到Node.js。

曾经在LinkedIn工作的工程师蓝奕凯补充道：移动促使产生了跨数据中心应用。运行在单线程的Rails服务器上（每一个请求都会降低整体性能），使用Mongrel，将会浪费大量内存。这解释了为什么任何没有阻拦的方式会赢得青睐。

Node.js的优势在于：

• 更好的性能以及更少的内存占用，在某型情景下性能提升20倍
• 程序员可以充分发挥他们JavaScript的技巧
• 前端与后端开发人员可以在一个小组内协作
• 服务器从30台减少到只有3台，硬件资源利用率提升10倍，并且还有提升的空间。
• 开发工作可以更加专注在应用开发，而不是到处去救火

很显然，有大量的问题交织在一起。我们需要重写代码，改变服务器与客户端的分布式逻辑，为了优化我们有大量需要争论的地方。但可以确信，LinkedIn选择Node.js获得了巨大成功。

在文章的评论部分看到一些有趣的分析，我特别喜欢oluseyi的评论：

不可避免的我们要重构并重写，我们积极的使用缓存，储存客户端的范本（并不可避免的从服务器更新数据）。这意味着一旦时间戳要求更新缓存，应用程序就需要从服务器一致性过滤器更新数据，而不是通过打开又关闭若干个连接。我们希望建立一条长寿命的连接，用来传输数据。（同样的，原来的执行将会返回HTML代码，这意味着包括图像的URI地址等在内的链接都将指向服务器。同时，由于web浏览将会建立和销毁导航，这些图像并没有有效的缓存。）

在长寿命链接的方式下，在传统的MVC（"Model-View-Controller"的缩写，中文翻译为"模式-视图-控制器"。）web应用程序不再有“查看”这一概念。最终的结果是，在服务器端的控制器将会聚集所有必要的数据，但这些数据并不会直接输出，而是通过输出二进制对象，并被客户端拆包提取所有有关的数据。

我注意到你很关心MVC被过度滥用，只在特定的web应用程序相关环境才适合应用。用户的web端（标记输出，包括外部的URL等等，都需要重新处理）将提取拆包的数据和缓存数据产生。

 

Update：本文在Hacker News引起了大量争议，欢迎纠错、评论。