什麼是 Nginx？｜ExplainThis

在開發網路應用程式時，如果要處理數千個併發連線的狀況，傳統的網路伺服器會遇到效能瓶頸。這個限制又被稱為 C10K 問題 (處理 10,000 個併發連線的挑戰)，之所以會有這種瓶頸，是因為舊式的網路伺服器會為每個連線都建立新的進程或執行緒，消耗大量記憶體和 CPU 資源。

Nginx 透過事件驅動、非同步架構解決了這個問題，讓開發者能用最少的資源處理超過 10,000 個併發連線。Nginx 是由 Igor Sysoev 在 2004 年特別為了解決這些擴展性挑戰而開發的，現在已經成為許多科技公司、高流量網站的基礎架構。不過， Nginx 具體是什麼? 為什麼後端工程師需要知道它?

可以把 Nginx 想像成網路應用程式的終極交通控制器。就像熟練的交通警察能讓車輛順暢地通過繁忙的路口，Nginx 位於使用者和應用程式伺服器之間，智慧地管理請求，確保一切運作順暢。

從核心來看，Nginx 是一個網路伺服器，但它比一般的網路伺服器更強大——它可以同時作為反向代理、負載平衡器和 HTTP 快取。

Nginx 作為反向代理

先從反向代理開始說起，這個名詞聽起來可能有點複雜，但實際上很簡單。但為什麼稱為「反向」呢？一般的代理（或稱為正向代理）位於客戶端和網際網路之間，向伺服器隱藏客戶端的身份。反向代理則相反——它位於網際網路和伺服器之間，向客戶端隱藏伺服器的細節。

把 Nginx 想像成大型辦公大樓的接待員。當訪客到達時，他們不需要知道行銷部門在哪一層，或者執行長是在會議室 A 還是 B。他們只需要告訴接待員自己需要什麼，接待員就會指引他們到正確的地方。

同樣地，當使用者向你的網站發出請求時，他們不需要知道後端伺服器中的哪一台應該處理他們的請求——Nginx 會為他們解決這個問題。

這種設置提供了關鍵的好處：它向潛在的攻擊者隱藏了內部伺服器結構，在一個地方處理 SSL 加密，並且可以將不同類型的請求路由到專門的伺服器。

Nginx 反向代理流程

    客戶端                    Nginx               應用程式伺服器
      🌐     ────請求───>    🔶     ────請求───>    💾💾💾
             <───回應───          <───回應───

• 客戶端向 Nginx (網路伺服器) 發送請求
• Nginx 將請求轉發到適當的應用程式伺服器
• 應用程式伺服器處理並透過 Nginx 傳回回應
• 客戶端接收回應，但不知道後端詳細資訊

Nginx 作為負載平衡器

但是當你的網站流量增長到超過單一後端伺服器能夠處理的範圍時，會發生什麼情況呢？這時負載平衡就派上用場了。當你的應用程式成長，一台伺服器已經不足以處理所有流量時，你可以部署多台運行相同應用程式副本的伺服器。

接著 Nginx 可以使用各種演算法將傳入的請求分配到這些伺服器上。最常見的方法是循環配置（round-robin，輪流將請求分配給每台伺服器），但如果你的伺服器有不同的能力，你可能會選擇最少連線數（least-connections，將請求發送到處理最少活動連線的伺服器），或者如果你需要會話一致性，可以使用 IP 雜湊（IP hash，始終將同一個使用者發送到同一台伺服器）。

這種方法帶來了顯著的好處：你的應用程式可以處理更高的流量，提供更好的可靠性（如果一台伺服器故障，其他伺服器會繼續提供服務），並且透過防止任何單一伺服器過載來改善回應時間。

Nginx 負載平衡

多個客戶端                           Nginx                    多台伺服器
     🌐 ────────────────────┐                  ┌─────────────> 💾💾💾
                            │                  │
     🌐 ────────────────────┤─────> 🔶 ────────┼─────────────> 💾💾💾
                            │                  │
     🌐 ────────────────────┘                  └─────────────> 💾💾💾

• 多個客戶端向 Nginx 發送請求
• Nginx 將請求分配到多台後端伺服器
• 每台伺服器同時處理不同的請求
• 提供更高的容量和冗餘

Nginx 的 HTTP 快取

現在，這裡是最有趣的部分。如果我們告訴你 Nginx 可以在不更改任何後端程式碼的情況下，讓你的應用程式感覺快很多，會如何呢？這就是 HTTP 快取成為秘密武器的地方。

把它想像成一個聰明的服務生，記住你平常點的餐點。當你重複請求相同的資料時——比如你網站的標誌、CSS 檔案，甚至是不經常變更的 API 回應——Nginx 可以將這些回應儲存在記憶體中。

與其每次有人需要這些檔案時都去麻煩你的後端伺服器，Nginx 直接從它的快取中提供這些檔案。結果是什麼？回應時間可以從 500 毫秒降低到僅僅 50 毫秒，而你的後端伺服器可以專注於處理新的動態內容，而不是重複提供靜態檔案。

Nginx HTTP 快取

第一次請求：
🌐 ──請求──> 🔶 ──請求──> 💾💾💾
   <─回應──   <─回應──   (500ms)
                     │
                     ▼
                  📁 快取

後續請求：
🌐 ──請求──> 🔶 ──────────────> 💾💾💾
   <─回應──   ↑                (伺服器空閒)
                  │
                📁 快取 (50ms)

• 第一次請求：Nginx 從伺服器取得並快取回應
• 後續請求：Nginx 直接從快取提供（快 10 倍）

什麼時候使用 Nginx

那麼什麼時候應該考慮使用 Nginx 呢？如果你正在建構任何比簡單原型更複雜的東西，Nginx 從第一天開始就能幫助你。無論你是在建立需要處理併發使用者的 REST API，建構同時提供靜態檔案和動態內容的網路應用程式，或者為最終需要多台伺服器的成長做準備，Nginx 都為可擴展架構提供了基礎。

Nginx 的美妙之處在於它的靈活性——你可以從基本的反向代理功能開始，然後隨著需求增長逐漸加入負載平衡和快取。無論你是在建構小型個人專案還是為企業級流量做準備，Nginx 都提供了確保你的應用程式保持快速、可靠和可擴展的工具。

加入 E+ 成長計畫

如果你覺得這篇內容有幫助，喜歡我們的內容，歡迎加入 ExplainThis 籌辦的 E+ 成長計畫，透過每週的深度主題文，以及技術討論社群，讓讀者在前端、後端、軟體工程的領域上持續成長。