聊聊Node.js的一點開發體驗和應用場景

這幾天看見幾位業內人士在批Node.js，我也談一下自己的看法。我是堅持技術多元理念的人，就是從不過分鼓吹、貶低某項技術或相關體系，堅定認為，每項技術都應該用在合適的地方，不要老拿一把錘子包打天下。研發人員要善於學習，理解不同語言、技術的特色和適用場景，靈活選型。

去年我用Node.js為客戶做過一個服務。因為做了技術選型後，認為它適合這個應用場景。我有10多年開發經驗，常用的幾個語言都能自如切換，第一次用它並沒覺得Node.js有多難，但是仍然踩了一些坑。我覺得Node.js程式設計裡面，最難的或者說痛苦的地方在於業務邏輯控制。如果你的服務有很多順序性的要求：1-2-3-4-5…這種順序的操作鏈條很長，而且必須嚴格順序操作，就會面臨控制難題，而且特別容易出現bug。這對其它順序執行的語言來說，原本不是問題。但是Node全部是非同步回撥，它的特點和缺陷都在這裡。如果你能很熟練的控制順序執行問題，那麼其它的就沒啥了，不是事兒。

假如你的系統比較簡單，就是查詢資料庫，然後返回資料給客戶端，提供API介面，也可以考慮Node.js。開發速度真是很快的，而且效能也不錯。

另外有個應用場景是適合Node.js的，長連結+Web。PHP開發部署應用的模式，基本是Nginx+FPM，全是短連結，因為這就是Web的設計。可有應用場景，就是需要用Web控制長連結，這個時候用Node.js就很方便了。用Websocket就是很好的方案，它還支援瀏覽器。

為什麼可以這樣？這是部署模式的差異，其實用常駐記憶體的部署模型都能做到，比如Python。PHP的常用模式是：Nginx接受外部的瀏覽器請求，通過FastCGI協議發給PHP-FPM，PHP處理完畢後返回資料給Nginx，它再送給前面等著資料的瀏覽器。

這個應用模式裡面，PHP沒有辦法得到長連結，因為它前面是Nginx。如果要控制長連結請求，只能去請求另外的一個處理長連結的伺服器程式，協議自定。可是，這不是又多了一個服務程式嘛。Node.js就可以2合1，讓Web服務和其它應用服務結合著一起。

可能有人會問：這種需求有應用場景嗎？有的。舉個例子：你開發了一套服務系統，有各種客戶端或瀏覽器連結進來，但是你又想用Web介面去查詢、控制、管理，Node.js幹這種活也挺合適的。它可以同時支援Web服務和其它應用請求，相互操作。

有個同行指出，用Nginx也可以支援WebSocket的長連線，有對應的模組可以配置。這個其實我知道，文章在這裡：https://www.nginx.com/blog/websocket-nginx/

它跟我說的Node.js可以2合1不是一回事。如果使用Nginx，你還得單獨開一個WebSocket伺服器程式，比如這個PHP的實現：

Ratchet http://socketo.me/ 你必須單獨啟動一個程式，類似：

php bin/chat-server.php

你的Web服務與它完全是兩個程式，如何與它進行互動通訊？就需要額外的程式間通訊手段了。而Node.js就不用了，它可以讓Web的Http請求與WebSocket的實時資訊相互操作，因為它們是一體的。

還有朋友提到，可以採用基於PHP語言的Swoole – http://www.swoole.com 這是個可選項。不過，要麼把Swoole部署在Nginx後面，跟Ratchet類似，單起一個服務程式，要麼使用Swoole內建的Http Server。但Swoole內建的Server對Http協議的支援不完整。另外，Node.js有相當不錯的Web開發框架 – Express／Koa，Swoole只能靠手工了，跟框架的開發速度如何相比。

​沒有什麼技術十全十美，只要把它們的特色用的合適，解決了問題就是好技術。

作者部落格