node主要應(yīng)用場(chǎng)景是在大前端

node主要應(yīng)用場(chǎng)景是在大前端，阿里的思路是比較合適的，但是必須要注意，絕對(duì)不能讓node做太多的業(yè)務(wù)邏輯，他只適合接受人家生成好的數(shù)據(jù)，然后或渲染后，或直接發(fā)送到客戶端。如果讓node做復(fù)雜的業(yè)務(wù)邏輯，那會(huì)得不償失的。這個(gè)阿里的人可以來(lái)說(shuō)明一下，你們node主要應(yīng)用的場(chǎng)景是不是都是比較簡(jiǎn)單的邏輯。

回調(diào)模式下的異步是有明顯缺陷的，程序的執(zhí)行順序必須依靠回調(diào)來(lái)保證，沒(méi)有層層回調(diào)，就沒(méi)有可以保障的邏輯順序，這也就注定了，node不能做復(fù)雜的業(yè)務(wù)邏輯。javascript語(yǔ)言本身也一直在和回調(diào)做斗爭(zhēng)，promise，generator都可以將回調(diào)包裝起來(lái)，在代碼的某個(gè)部分形成形式同步，但是這種模式進(jìn)化的還不完全，還不能做到與回調(diào)完全割裂，做到完全的形式同步。但是形式同步肯定是發(fā)展的方向，這種模式即可以獲得異步的好處，又可以有效回避回調(diào)帶來(lái)的編程困難，在業(yè)務(wù)邏輯上可以更簡(jiǎn)單的表達(dá)。

就現(xiàn)在的環(huán)境來(lái)說(shuō)，大家的思路還沒(méi)轉(zhuǎn)過(guò)彎，對(duì)回調(diào)的批評(píng)認(rèn)為都是不好的，這些人是不敢面對(duì)現(xiàn)實(shí)，javascript都在變，這些人的腦子卻不肯變，還以為回調(diào)就代表異步。

天貓這么干，主要出發(fā)點(diǎn)可能還在于讓前端工程師使用最擅長(zhǎng)的javascript負(fù)責(zé)“全?！眏avascript工作來(lái)提高團(tuán)隊(duì)整體工作效率。至于后端接口，可能都是一些java寫的已經(jīng)穩(wěn)定的功能，誰(shuí)也不可能決策再用Node.js去全部改造，因此在Node和java間才有了那一層接口層。這樣，用Node.js去實(shí)現(xiàn)一層完全配置化的適配HTTP/SOAP/…協(xié)議的具有緩存策略的接口路由，再通過(guò)配置或少量代碼實(shí)現(xiàn)接口調(diào)用聚合即可完成功能，這些工作前端工程師就能干了，完全不需要后端參與。前后端的交互就在”接口文檔”，不需要會(huì)議、語(yǔ)言、IM來(lái)溝通。

Node.js的業(yè)務(wù)邏輯應(yīng)用，阿里的淘寶還是天貓里的收藏功能拒說(shuō)已經(jīng)在試水，這次改動(dòng)應(yīng)該也是一次大的變動(dòng)，否則也不會(huì)把好好的java改成Node.js。如果阿里得出Node.js在性能和開發(fā)效率上超過(guò)java、在穩(wěn)定性上不輸java之后，會(huì)不會(huì)有更多的業(yè)務(wù)邏輯使用Node.js去實(shí)現(xiàn)，這些可能會(huì)取決于前后端團(tuán)隊(duì)的工作負(fù)荷。

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

至于javascript的垢病，個(gè)人感覺(jué)，不在它的callback而在它的隨意性，隨意到想怎么寫都行，但正是這點(diǎn)給它帶來(lái)了驚人的開發(fā)效率，做好代碼規(guī)范和文檔工作可以減少javascript的隨意性帶來(lái)的負(fù)面影響。

WEB端、移動(dòng)端、桌面端、甚至嵌入式，javascript已經(jīng)無(wú)處不在。接下來(lái)，ES6的實(shí)現(xiàn)會(huì)讓眾多習(xí)慣同步或者不喜歡回調(diào)的開發(fā)人員能夠更快地上手javascript寫出符合他們思維習(xí)慣的代碼，這些開發(fā)人員會(huì)是更大的群體，那么也許javascript會(huì)橫掃應(yīng)用開發(fā)也不一定。

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

但是，必須清楚的看到node的好是相對(duì)PHP，java的同步代碼而言的，是相對(duì)的好。node主體采用單線程回調(diào)異步模式，部分采用了線程池，文件系統(tǒng)，dns.lookup（）都是采用了線程池實(shí)現(xiàn)的。在關(guān)鍵的網(wǎng)絡(luò)通信上，node是異步的，所以在通信效率上，node就相對(duì)比同步代碼效率好。java也有異步接口，但是java不像javascript這樣回調(diào)函數(shù)可以比較簡(jiǎn)單自然的實(shí)現(xiàn)，c也可以，c也存在同樣的問(wèn)題。node這種模式曾經(jīng)是比較先進(jìn)的。

node跟nginx比在某些方面又相對(duì)不好， 尤其在靜態(tài)文件處理上，node用的是線程池模擬的異步，nginx則針對(duì)不同的文件類型提供了不同的策略，對(duì)大量的小文件，直接使用同步的系統(tǒng)調(diào)用sendfile，對(duì)大文件，使用AIO。而nginx也有自己不擅長(zhǎng)的，處理動(dòng)態(tài)的沒(méi)有node方便，雖然有openresty，但從實(shí)際使用中來(lái)看，還是沒(méi)有node方便。

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

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