為什麼node.js不適合大型項目

前言

首先要明確什麼是大型應用,其實這是仁者見仁、智者見智的問題,並且它是一個哲學問題,不是一個技術問題。假如有人問你,一個可以進行線上銷售的網站,比如優衣庫,大不大?你可能會說大,因為這與你平常所見的博客、企業官網等邏輯相比較確實復雜很多。或者說小,那麼說明你開發過比它還復雜的系統。那麼相比較淘寶而言呢?大和小的對比是要有參照物的。

1. 應用的組成

一個完備的 Web 應用可能隻由一門語言或者一種技術構成嗎?不可能。因為一個完備的 Web 應用其實是多門技術的綜合體,解決某個問題有非常多的解決方案,比如後端的邏輯解決方案就非常多,Java、php、Python、Ruby 等都可以。

簡單地概述,應用的組成內容可能包括:

Web 界面顯示邏輯;後端業務邏輯;緩存;數據庫;消息隊列。

其實還可以加入日志分析、數據分析等,隻是上面幾個最廣為人知而已。

2. 應用的種類

I/O 密集型;CPU 密集型。

就常見的互聯網產品而言,它的瓶頸並非在後端業務的邏輯上,而是在 I/O 上,即返回給用戶看的數據的讀入與輸出。相對於應用程序而言,讀入指的是從數據庫裡獲取數據,而輸出指的是將這些數據經過一定的處理輸出到用戶的瀏覽器,那麼這就是 I/O 密集型。

而CPU密集型是指做頻繁計算任務的應用,Node.js在這方面確實是短板。

3. 應用服務的過程

如圖所示,用戶通過瀏覽器發送請求,由網卡接收TCP 連接,通知內核,內核再去調用相對應的服務端程序。

Request 請求過程

Response 返回過程

如下圖,Web 應用要返回數據,首先要獲取數據,通過內核調用磁盤的驅動程序,把數據讀入緩存,這樣就可以在 Web 應用程序中獲取數據並進行數據處理,最終調用內核,將數據通過網卡發送給客戶端。

4. 應用的瓶頸

通常 I/O 密集型的瓶頸會在磁盤的讀寫上,所以在購買雲服務器的時候可以購買 SSD 的磁盤來提升性能,一般數據庫軟件的數據都是存儲在文件上面的。首先考慮添加內存型緩存來解決這個瓶頸,緩存經常訪問的數據,看能否解決當前場景的問題,比如使用 Redis。其次才考慮搭建或擴充數據庫集群來提高並發。

而 CPU 密集型的應用瓶頸則在 CPU 上,隻能增加 CPU 處理核心來解決瓶頸。

5. 分佈式應用

大型的普通應用與分佈式應用其實是不同的概念。讀者可以把分佈式應用簡單地理解為一個團隊,每一個成員都是一個節點,一個大的項目要讓成員合作完成,那麼成員與成員之間就存在一些溝通成本,甚至有的成員與成員之間勾心鬥角,說話陽奉陰違、推脫責任,也有可能成員生病在傢休養,無法工作,等等。在面對這些問題的時候,Node.js的優勢並不能很好地顯現出來(並非不可以做,隻是沒有完善的基礎設施)。

分佈式的真正定義是,在多臺不同的服務器中部署不同的服務模塊,以進程為基本單位,派發到服務器上,通過遠程調用(RPC)通信並協同工作,最終對外提供服務。

相比較Node.js目前的分佈式基礎設施,Go 語言的基礎設施則完善多瞭,特別是在 Docker 這個項目上,充分證明瞭 Go 語言的優勢,這也是為什麼 Node.js 社區“大牛”TJ Holowaychuk 轉向 Go 語言,因為他要開發分佈式應用。

其實沒必要過分地關心分佈式的問題,畢竟JavaScript最初隻是一個運行在瀏覽器端的腳本語言而已,JavaScript不是萬能的,為什麼一定要把它用在操作系統級別的開發上呢?尋找一個更合適的語言不是更好嗎?就像此刻我們選擇 JavaScript 構建 Web 應用一樣。

6. 多進程的 Node.js

瞭解瞭以上的一些知識點,現在讀者應該知道,Node.js 跟大型應用關系不大。大多數學習 Node.js 的開發者是前端開發者,所以對後端的基礎知識並不瞭解,在網絡上搜尋一些資料的時候發現 Node.js 隻能利用單核,而又聽說 TJ Holowaychuk 轉向 Go 的陣營,所以有的開發者就產生瞭Node.js不適合開發大型應用的疑問。

Node.js 隻能利用單核的問題已經被解決瞭,後面使用的 Egg.js框架中的 Egg-Cluster 模塊就利用多進程非常好地解決瞭這個問題。

以上就是為什麼node.js不適合大型項目的詳細內容,更多關於node.js的資料請關註WalkonNet其它相關文章!