-
1 # 寫程式設計師的程式碼
-
2 # warensoft
node之所以容易被接受,是應為js語言的普及性,但是考慮到全棧開發的話node並不是首選,傳統的.net core和java還是首選。
如果僅僅考慮到各種各樣的程式碼包,node確實有優勢,但是在高精度運算方面js語言就和java,c#沒法比了。
在伺服器效能層面,node和j2ee,.net core,go比起來效能相差的非常多(大家可自行google一下benchmarking),因此其並不適合對效能要求比較高的服務環境。
另外,所謂全棧,還要包括移動應用和桌面應用,在移動應用方面原生開發的主要還是java和c#和oc,swift。
桌面級的原生跨平臺應用主流的技術還得是c#,qt+c++等。mfc就不推薦了,估計近十年微軟也沒怎麼太更新了。
寫好服務程式,除了會crud以外,需要程式設計師在記憶體控制,資料結構,演算法過程控制等方面都要有更好的經驗,即便像java,c#這樣自動回收記憶體,內建資料結構的語言,也都要很小心記憶體開銷,否則你的Stack Overflow,就真的只能去Stack Overflow去查了。
-
3 # 橘子香蕉蘋果
其實這根本不是技術棧的問題,而是node工程師沒有後端經驗的問題。如果有的話,會僅限於node嗎?語言差距根本不是問題,語言本身就是工具,重點應該去考慮不要有太多異構,維護起來太麻煩。還要考慮開發者群體。node最適合的地方還是提供小型的工具服務,前端工程師不用去了解太多的後端知識,只要會基礎的資料庫讀寫,快取的使用就能解決的問題。
-
4 # 王聖元7
有些公司覺得node全棧很厲害,做伺服器小菜一碟。有些公司根本不認為node和伺服器開發有一毛錢關係,別說重要系統了,次級系統node都別想沾下邊。兩級分化嚴重,這就是node和傳統伺服器的區別。
-
5 # shermanz
我專業前端做了很多年了,對js不能說是感情淺。但是node做後端,我還是覺得寧可重學一門後端語言也不會冒這個險,除非我幹完專案拿錢走人別人去維護。我也知道一個大銀行不是國內的,前幾年被哪個頭腦發熱的技術牛人用js做了微服務,—後來專案用java重寫了。第一, node沒有多執行緒,以至於cpu-bound 任務是不可能的,如果沒有守護程式和 load balance 來做服務程式去響應微小的負荷也是冒險。第二,node 如果不用 async 寫出來的程式碼就是 callback hell, 如果再沒有typescript, 維護起來是個噩夢。callback 是解決阻塞問題,但氾濫了就噁心了。 第三,也別想著維護三四年了,npm還沒幹什麼就引用幾十萬個庫了,有的庫也就10行程式碼,庫質量差,壽命短,真用的複雜庫,幾年後依賴的庫有些已經不存在了。第三還是執行緒問題,別告訴我你多小的程式都配一個redis,部署和安全都是頭痛問題-沒有執行緒技術就無法共享資料緩衝資料。
總結:用nodejs做後端很作死。nodejs 在後端說白了只是一個高階的event bus, 一無是處。
回覆列表
我個人感覺node並不比傳統伺服器差,應該說各有各的優勢吧。
相關基本概念:
1. Node是一個Javascript執行環境,採用Google開發的V8引擎執行js程式碼。
2. 使用:事件驅動、非阻塞I/O模型等技術提高效能,可最佳化應用程式的傳輸量和規模。
3. 它是單程序,單執行緒的。
Node與傳統伺服器對比
傳統伺服器響應請求:傳統伺服器針對請求的處理是:每來一個請求,都會單獨建立一個程序,去處理這個請求,直到這個請求完成了全部的任務(包括耗時的I/O請求)這個程序才會釋放,並且執行很耗時的I/O請求時,執行緒一直處於掛起狀態,等待I/O操作結果。
2. Node伺服器單執行緒、單執行緒,對請求的處理是:每來一個請求,由統一的一個程序(暫時叫他A程序)去響應請求,看請求要操作什麼,然後轉交給相應的處理程式,例如要進行I/O操作,這時把請求交給I/O讀寫模組處理,隨後A程序再次去響應其他的請求,根據請求具體操作,再次分給相應模組處理,等到之前的I/O操作完成之後,I/O模組會通知A(以回撥的方式去通知),A將結果透過response返回給請求傳送者,也就是說Node的核心(優勢)就是非同步。
3 .Node適合如下場景(優點):
傾向於高併發的I/O密集型應用(最重要的優點)。
RESTful API(本身幾乎沒有邏輯,但是頻繁訪問API)。
不能建立快取,但瞬間有大量Ajax請求的應用。
在有限的硬體條件下,搭建一個能處理更多併發的伺服器。
4 .不適用Node的場景(缺點):
不適合CPU密集型應用;CPU密集型應用給Node帶來的挑戰主要是:由於JavaScript單執行緒的原因,如果有長時間執行的計算(比如大迴圈),將會導致CPU時間片不能釋放,使得後續I/O無法發起。
只支援單核CPU,不能充分利用CPU。
可靠性低,一旦程式碼某個環節崩潰,整個系統都崩潰,非同步遇到問題時,可追蹤性較差(原因:單程序,單執行緒)
綜上所述:
任何東西都有好壞的一面,不能籠統的說好說壞,只能看他的適用場景。看你具體要解決什麼問題,更看重哪個方面的效能,是穩定,還是速度。