Ryan Paul寫過一篇《深入觀察LinkedIn移動(dòng)端的設(shè)計(jì)》，在其中我們看到：有23%的移動(dòng)用戶；專注樸素、易用以及可靠性；30%原生代碼，70%使用HTML；嵌入輕量的HTTP服務(wù)；單一的客戶端應(yīng)用鏈接云服務(wù)器；后端服務(wù)從Rails轉(zhuǎn)換到Node.js。

曾經(jīng)在LinkedIn工作的工程師藍(lán)奕凱補(bǔ)充道：移動(dòng)促使產(chǎn)生了跨數(shù)據(jù)中心應(yīng)用。運(yùn)行在單線程的Rails服務(wù)器上（每一個(gè)請(qǐng)求都會(huì)降低整體性能），使用Mongrel，將會(huì)浪費(fèi)大量?jī)?nèi)存。這解釋了為什么任何沒有阻攔的方式會(huì)贏得青睞。

Node.js的優(yōu)勢(shì)在于：

• 更好的性能以及更少的內(nèi)存占用，在某型情景下性能提升20倍
• 程序員可以充分發(fā)揮他們JavaScript的技巧
• 前端與后端開發(fā)人員可以在一個(gè)小組內(nèi)協(xié)作
• 服務(wù)器從30臺(tái)減少到只有3臺(tái)，硬件資源利用率提升10倍，并且還有提升的空間。
• 開發(fā)工作可以更加專注在應(yīng)用開發(fā)，而不是到處去救火

很顯然，有大量的問題交織在一起。我們需要重寫代碼，改變服務(wù)器與客戶端的分布式邏輯，為了優(yōu)化我們有大量需要爭(zhēng)論的地方。但可以確信，LinkedIn選擇Node.js獲得了巨大成功。

在文章的評(píng)論部分看到一些有趣的分析，我特別喜歡oluseyi的評(píng)論：

不可避免的我們要重構(gòu)并重寫，我們積極的使用緩存，儲(chǔ)存客戶端的范本（并不可避免的從服務(wù)器更新數(shù)據(jù)）。這意味著一旦時(shí)間戳要求更新緩存，應(yīng)用程序就需要從服務(wù)器一致性過濾器更新數(shù)據(jù)，而不是通過打開又關(guān)閉若干個(gè)連接。我們希望建立一條長(zhǎng)壽命的連接，用來傳輸數(shù)據(jù)。（同樣的，原來的執(zhí)行將會(huì)返回HTML代碼，這意味著包括圖像的URI地址等在內(nèi)的鏈接都將指向服務(wù)器。同時(shí)，由于web瀏覽將會(huì)建立和銷毀導(dǎo)航，這些圖像并沒有有效的緩存。）

在長(zhǎng)壽命鏈接的方式下，在傳統(tǒng)的MVC（"Model-View-Controller"的縮寫，中文翻譯為"模式-視圖-控制器"。）web應(yīng)用程序不再有“查看”這一概念。最終的結(jié)果是，在服務(wù)器端的控制器將會(huì)聚集所有必要的數(shù)據(jù)，但這些數(shù)據(jù)并不會(huì)直接輸出，而是通過輸出二進(jìn)制對(duì)象，并被客戶端拆包提取所有有關(guān)的數(shù)據(jù)。

我注意到你很關(guān)心MVC被過度濫用，只在特定的web應(yīng)用程序相關(guān)環(huán)境才適合應(yīng)用。用戶的web端（標(biāo)記輸出，包括外部的URL等等，都需要重新處理）將提取拆包的數(shù)據(jù)和緩存數(shù)據(jù)產(chǎn)生。（CSDN 編譯/包研）