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

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

成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),邵陽企業(yè)網(wǎng)站建設(shè),邵陽品牌網(wǎng)站建設(shè),網(wǎng)站定制,邵陽網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,邵陽網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

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

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

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

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

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

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

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

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

 

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

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

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

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

新聞名稱：node主要應(yīng)用場景是在大前端
本文路徑：http://bm7419.com/article4/gejhoe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、營銷型網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航、關(guān)鍵詞優(yōu)化、品牌網(wǎng)站設(shè)計、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)