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

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實戰：使用Egg.js+Vue.js+Docker構建漸進式、可持續整合與交付應用》，作者yugo，電子工業出版社9月出版。

瞭解本書詳情：https://u.jd.com/e29Uft