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引起了大量争议,欢迎纠错、评论。

你可能感兴趣的:(JavaScript)