Node.js應用場景及發展趨勢

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已經在改變，就是步子太過婉約，他必須兼容過去的大量回調代碼，但也必需要解決形式同步的問題。說這是生死問題，一點也不誇張，程序員會用腳投票，回調山真不是必須的。