node主要應用場景是在大前端

node主要應用場景是在大前端，阿里的思路是比較合適的，但是必須要注意，絕對不能讓node做太多的業務邏輯，他只適合接受人家生成好的數據，然后或渲染后，或直接發送到客戶端。如果讓node做復雜的業務邏輯，那會得不償失的。這個阿里的人可以來說明一下，你們node主要應用的場景是不是都是比較簡單的邏輯。

回調模式下的異步是有明顯缺陷的，程序的執行順序必須依靠回調來保證，沒有層層回調，就沒有可以保障的邏輯順序，這也就注定了，node不能做復雜的業務邏輯。javascript語言本身也一直在和回調做斗爭，promise，generator都可以將回調包裝起來，在代碼的某個部分形成形式同步，但是這種模式進化的還不完全，還不能做到與回調完全割裂，做到完全的形式同步。但是形式同步肯定是發展的方向，這種模式即可以獲得異步的好處，又可以有效回避回調帶來的編程困難，在業務邏輯上可以更簡單的表達。

就現在的環境來說，大家的思路還沒轉過彎，對回調的批評認為都是不好的，這些人是不敢面對現實，javascript都在變，這些人的腦子卻不肯變，還以為回調就代表異步。

天貓這么干，主要出發點可能還在于讓前端工程師使用最擅長的javascript負責“全棧”javascript工作來提高團隊整體工作效率。至于后端接口，可能都是一些java寫的已經穩定的功能，誰也不可能決策再用Node.js去全部改造，因此在Node和java間才有了那一層接口層。這樣，用Node.js去實現一層完全配置化的適配HTTP/SOAP/…協議的具有緩存策略的接口路由，再通過配置或少量代碼實現接口調用聚合即可完成功能，這些工作前端工程師就能干了，完全不需要后端參與。前后端的交互就在”接口文檔”，不需要會議、語言、IM來溝通。

Node.js的業務邏輯應用，阿里的淘寶還是天貓里的收藏功能拒說已經在試水，這次改動應該也是一次大的變動，否則也不會把好好的java改成Node.js。如果阿里得出Node.js在性能和開發效率上超過java、在穩定性上不輸java之后，會不會有更多的業務邏輯使用Node.js去實現，這些可能會取決于前后端團隊的工作負荷。

Node.js的發展給javascript注入了新的生命力，試想一下，如果你是老板，你是愿意雇傭一個javascript全棧工程師搞定全部前后端工作開他30K，天天讓他加班成狗；還是愿意雇傭兩個工程師，每人開20K，讓他們倆天天有空坐下來擼兩把？

至于javascript的垢病，個人感覺，不在它的callback而在它的隨意性，隨意到想怎么寫都行，但正是這點給它帶來了驚人的開發效率，做好代碼規范和文檔工作可以減少javascript的隨意性帶來的負面影響。

WEB端、移動端、桌面端、甚至嵌入式，javascript已經無處不在。接下來，ES6的實現會讓眾多習慣同步或者不喜歡回調的開發人員能夠更快地上手javascript寫出符合他們思維習慣的代碼，這些開發人員會是更大的群體，那么也許javascript會橫掃應用開發也不一定。

所以，javascript很有前途，那Node.js自然就有前途。

但是，必須清楚的看到node的好是相對PHP，java的同步代碼而言的，是相對的好。node主體采用單線程回調異步模式，部分采用了線程池，文件系統，dns.lookup（）都是采用了線程池實現的。在關鍵的網絡通信上，node是異步的，所以在通信效率上，node就相對比同步代碼效率好。java也有異步接口，但是java不像javascript這樣回調函數可以比較簡單自然的實現，c也可以，c也存在同樣的問題。node這種模式曾經是比較先進的。

node跟nginx比在某些方面又相對不好， 尤其在靜態文件處理上，node用的是線程池模擬的異步，nginx則針對不同的文件類型提供了不同的策略，對大量的小文件，直接使用同步的系統調用sendfile，對大文件，使用AIO。而nginx也有自己不擅長的，處理動態的沒有node方便，雖然有openresty，但從實際使用中來看，還是沒有node方便。

曾經相對先進的回調模式下的異步現在也遇到了挑戰者，那就是協程（coroutine），或者叫纖程（fiber），不管叫什么名字，他們本質上都是在用戶空間模擬線程，這種線程是非常輕量的，調度完全由用戶自己控制（或者用戶不直接控制，而是由用戶態程序控制）。這種模式有兩大好處，一是避免了原生線程的大消耗，原生線程在一定程序上也能實現并行，也能實現異步，但他們的好處很快被線程的切換吞噬掉了。用戶空間模擬的線程切換消耗就小得多。fibjs用的是自己實現的ucontext，lua用的是longjmp。解決了切換消耗，接下來就是鎖，用戶空間模擬的線程本質上是單線程的函數調用，只不過這種函數調用是可控的，沒有了鎖開銷，性能上自然又獲得了不少提升。即便是node使用的鎖非常輕量，性能如果想再進一步，這也是實實在在的性能殺手。當然這不是node的問題，所有只要涉及多線程的，包括協程，都會面對這個問題。

協程相對原生的線程有很多好處，相對于回調有什么好處呢？首先，他們在異步編程領域的使命是一致的，那就是保證異步編程的執行順序，回調山大家都不陌生，為什么會出現回調山呢？回調山就是保證異步過程是按照我們所設想的步驟去執行，在需要并行的地方，我可以將異步請求一股腦兒的都發出去，這個時候我對返回的順序沒有要求。在需要順序執行的地方，我們則需要用一層套一層的回調來保證執行順序。回調模式下的異步避免了多線程條件下，鎖的競爭問題，編程模型跟多線程鎖相比簡化了，在思維上可以說更接近了人類思維模式。但是回調模式跟協程相比還是存在缺陷的，協程可以通過適當的處理，模擬出同步代碼的效果，但本質上還是異步的，fibjs，openresty的代碼都實現了這個效果。回調不行，回調是有傳染性的，要獲得異步的好處，所有異步代碼必須全部用回調，某段邏輯上如果存在大量的異步過程，就需要大量的回調來應對，如果正好回調內部關聯比較強烈，無法將回調拆分，那么寫出的代碼將是又長又難調試的，大家回想一下，自己是不是碰到過某些比較復雜的代碼，是自己寫的，過了一段時間后自己回過頭來看，幾乎都看不明白了，但是謝天謝地，那段代碼還能運行，但是就不知道什么時候會出問題，這種擔心大家有沒有？有的話，那是正常的。javascript為了應對這個問題，加入了一些類似協程的東西，generator，async/await這些東西都發展的方向。現在的node還在發育，還遠沒到成熟的階段，node的發展還是要看javascript的發展，現階段promise和generator還是太麻煩，回調模式朝形式同步的進化路上還是有坑，這些問題我們都必須要面對，javascript與lua等天生具備協程能力的語言相比，在這場競賽中誰能出頭，最關鍵的是看javascript能不能迅速的順應潮流，迅速的協程化，javascript已經在改變，就是步子太過婉約，他必須兼容過去的大量回調代碼，但也必須要解決形式同步的問題。說這是生死問題，一點也不夸張，程序員會用腳投票，回調山真不是必須的。