node.js不適合大型項目的原因是什么

這期內容當中小編將會給大家帶來有關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不適合大型項目的原因是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。