你用 Node.js 寫過哪些大型/複雜的應用？碰到什麼難點?

相關問題

node.js能開發大型網站嗎？?

www.zhihu.com

這個問題有是幾年前知乎的問題,當然我看到了許多回答,node確實參與到了很多大型應用中,但是node的定位絕大部分屬於輔助(渲染層),主力後端語言還是java/c#,甚至php/Python都有獨立作為主力的大型應用,nodejs目前有嗎?

Nodejs已經出現近十年了,例如語法、類型檢測等被詬病的問題基本都解決的差不多了,成熟的庫例如koa/express也出現很久了,企業級框架如thinkjs/eggjs也橫空出世,但是node依然處於渲染層語言或者中小項目語言的定位,我想知道大家有沒有用node寫出(或參與)過複雜or大型項目的?哪些地方讓你感覺得存在語言瓶頸或者非語言類的挑戰?

大型 Web 系統不可能只依賴一類編程語言和環境。

如果系統架構設計得好，業務邏輯用什麼語言就變得次要了。

這幾年經常用 NodeJS 寫複雜的 Web 系統（十個以上子服務），只要服務介面拆分合理就能很好的融入系統。

語言不是瓶頸。

在瀏覽器和 NodeJS 環境中，雖然都是在寫 JavaScript，但運用的工具和思路不一樣，涉及的技術差別還是很大。

從人才儲備上來看 NodeJS 後端，招人上要難些。

1. 有參與過大型/複雜項目

列舉幾個我參與過的，店鋪裝修(海量商家), Lazada(東南亞第一大電商), 釘釘(超1億用戶)等都是阿里的重要業務，都有涉及到Node.js開發。 還有我所在團隊的前端監控系統Retcode(5 - 10 W QPS)，已經在阿里雲對外開放。這些應用，有的是直面用戶請求，有的提供API供java應用調用。從某種程度上來說都稱得上複雜應用。

至於阿里內部，有大量的Node.js應用(超過1500個)。不可否認的一個事實是： Node.js應用大部分情況是輕量級應用或者只負責渲染層。 造成這樣一個情況，我的觀點是：

2. 語言不是瓶頸, 往往是由於人員能力欠缺

從人員和應用兩個角度來闡述我的觀點：

A. 為什麼Node開發人員很少開發大型/複雜應用？

其實大部分Node.js使用者是前端出身，缺乏服務端方面的經驗。比如應用分層、分散式架構、海量並發、擴容縮容、計算與存儲分離、服務端容災以及業務模型的抽象等。把鍋甩給語言是有失公允的。相信隨著經驗的累積，會有越來越多的Node開發者具備駕馭大型/複雜應用的能力

B. 為什麼很少有大型/複雜應用採用Node.js開發？

Node作為後來者, 相比java，以下幾點很關鍵：

Node.js是否具備顛覆式優勢： 雖然具備非同步IO等優勢，但也存在劣勢，比如不擅於處理CPU計算密集型業務。只能說各有優劣，談不上顛覆式優勢。

人才儲備： 真正在服務端領域具備深功底的Node.js開發者鳳毛麟角，要招一個同等服務端能力的Node.js開發比Java開發要難很多，把大型/複雜業務交給不專業的人，誰敢這麼做？

歷史積累： 以阿里為例，在技術上和業務上都有深厚的積累，而承載這些能力的核心系統基本上都是基於Java去搭建的，要重構這些系統或者從零搭建都會帶來巨大的成本和風險。很多時候都是從技術架構方面去重構以滿足更加複雜的業務需求，要從語言層面去發起重構可能性非常小。技術架構和業務抽象才是這些系統的核心，至於用的是什麼語言遠沒那麼重要。

3. 碰到了什麼問題？

從最近我們一個Java + Node.js混用的一個大型項目來看，很多問題(分散式一致性、命中率低難以緩存等)，Node.js側碰到的問題，放到Java側來完成問題同樣複雜，本質上和語言無關。Java側和Node側最大的差別是： Java側有有更多處理類似問題的經驗 以及 更多能夠應對這些挑戰的人員。

事實上, Node不僅有作為主力完成大型應用的案例，甚至有些大公司把Node用作主力開發語言，比如

Paypal

Walmart

LinkedIn

歡迎加入我們，一起成為能夠駕馭大型/複雜應用的Node開發者

郵箱： weichun.pwc@alibaba-inc.com

微信: EN_Holden

方向：

1. 基礎設施架構： Node雲容器
2. Node同構框架： Egg系同構框架Beidou
3. 應用： Lazada、前端監控系統Retcode等大量上層應用

之前創業公司，全部node，量不夠，這大概沒太有說服力。在阿里各種node量也很大，不是我做的，我說也不太合適。我在做的優酷的web站了採用node做中間層，已知數據提升6倍性能，播放起播時間提升一倍，下一步爭取秒開。數據不方便說，只能說相當可觀，大家可以猜猜主站和播放頁的量。目前pc和h5，小程序，播放器還有大量工作要做，想加入的同學歡迎郵件我langshu.ssl@alibaba-inc.com

校招，社招都要，我這邊是北京。其他團隊也可以幫推

其實最重要的是在你的公司，Nodejs 是前端團隊的工具還是服務端團隊的工具，如果你從一開始就是把它定位成前端團隊的補充，那它大抵就是渲染層或者前端工具，如果你就是把它定位成服務端工具，開發也都是專業的服務端開發，那就可以承擔大型項目開發沒問題。

生態和語言問題都不大了，更多還是定位問題 在我們團隊，有專門的團隊做 nodejs 服務端開發，而前端團隊內部也會用 node 做一些工具層面的事情，但是二者的工作和定位是完全分離的。

是的，語言不是問題，人才是問題。其實人也不是的，錢才是問題。

部分答案其實混淆了業務量和業務複雜度。

Node.js 的主要弊端不在性能，沒有什麼是開多幾台機子解決不了的。

但怕就怕在應用承載的業務太複雜。業務的同事自己也沒搞清楚所有業務流程，業務和技術的溝通存在天然的困難，不同技術團隊之間對業務的理解和建模又不一致，最後 JavaScript 本身又（相對）太過靈活，最後就是複雜性層層放大，代碼越寫越亂，嚴重拖累開發效率。

這件事用 Java 也避免不了，就不要用 JavaScript 來添亂了。

如果前端的同學覺得 JavaScript 的版本兼容性是個大問題，瀏覽器兼容性是個大問題，那麼大型項目的需求複雜度，大概是前兩者的10倍。

其他答案下的項目其實相對簡單，也相對面向技術服務。雖然東西性能需求很高，但是業務和開發、開發和其他開發都在同一個領域下，溝通成本很低。至少代碼層面，大家公用同一套專業術語。何況性能優化的方案其實說穿了也就那幾套，複雜不到哪裡去。

說到底做業務的程序員才是最苦逼。有些比較厲害的同學直接被招去專攻技術難關了，可能感覺不到什麼叫需求複雜。讓我來舉個例子：

你的公司需要跟全球各個國家的客戶進行交易。交易系統至少需要支持全球主流的11種貨幣。

每種貨幣的匯率時時刻刻動態變化，數據來源不一致，更新時間不一致，每種貨幣的可交易日期不一致，顯示的小數精度不一致。

各個國家的不同客戶可能有不同的優惠政策，而這優惠政策又跟匯率有關聯。

你還必須遵守各個國家的交易規則，法律法規。很多在某些國家特有的屬性欄位在其他國家並沒有卵用。

你公司在各個國家的網點都有自己特別的需求，又憑空多了一對 if else。

你會發現在代碼里，同一個東西有好幾種名稱；同一個名稱，又指代好幾種東西。

而這個系統，可能只是你需要維護的眾多系統之一...

所以當真的需要開發複雜的應用時，至少上個 TypeScript ...

不然...也挺好的，一天啥都沒做成還有工資拿。