深入淺出搞懂 Nginx

除了 Apache,Nginx 也是一款很常用的輕量級的 Web 服務器、反向代理服務器,由於它的內存佔用少,啓動極快,高併發能力強,在互聯網項目中廣泛應用。

架構圖

上圖基本上說明了當下流行的技術架構,其中 Nginx 有點入口網關的味道。

反向代理服務器?

經常聽人說到一些術語,如反向代理,那麼什麼是反向代理,什麼又是正向代理呢?

正向代理:

正向代理示意圖

反向代理:

反向代理示意圖

由於防火牆的原因,我們並不能直接訪問谷歌,那麼我們可以藉助 VPN 來實現,這就是一個簡單的正向代理的例子。這裏你能夠發現,正向代理 “代理” 的是客戶端,而且客戶端是知道目標的,而目標是不知道客戶端是通過 VPN 訪問的。

當我們在外網訪問百度的時候,其實會進行一個轉發,代理到內網去,這就是所謂的反向代理,即反向代理 “代理” 的是服務器端,而且這一個過程對於客戶端而言是透明的。

Nginx 的 Master-Worker 模式

nginx 進程

啓動 Nginx 後,其實就是在 80 端口啓動了 Socket 服務進行監聽,如圖所示,Nginx 涉及 Master 進程和 Worker 進程。

Master-Worker 模式

nginx.conf

Master 進程的作用是?

讀取並驗證配置文件 nginx.conf;管理 worker 進程;

Worker 進程的作用是?

每一個 Worker 進程都維護一個線程(避免線程切換),處理連接和請求;注意 Worker 進程的個數由配置文件決定,一般和 CPU 個數相關(有利於進程切換),配置幾個就有幾個 Worker 進程。

思考:Nginx 如何做到熱部署?

所謂熱部署,就是配置文件 nginx.conf 修改後,不需要 stop Nginx,不需要中斷請求,就能讓配置文件生效!(nginx -s reload 重新加載 / nginx -t 檢查配置 / nginx -s stop)

通過上文我們已經知道 worker 進程負責處理具體的請求,那麼如果想達到熱部署的效果,可以想象:

方案一:

修改配置文件 nginx.conf 後,主進程 master 負責推送給 woker 進程更新配置信息,woker 進程收到信息後,更新進程內部的線程信息。(有點 valatile 的味道)

方案二:

修改配置文件 nginx.conf 後,重新生成新的 worker 進程,當然會以新的配置進行處理請求,而且新的請求必須都交給新的 worker 進程,至於老的 worker 進程,等把那些以前的請求處理完畢後,kill 掉即可。

Nginx 採用的就是方案二來達到熱部署的!

思考:Nginx 如何做到高併發下的高效處理?

上文已經提及 Nginx 的 worker 進程個數與 CPU 綁定、worker 進程內部包含一個線程高效迴環處理請求,這的確有助於效率,但這是不夠的。

作爲專業的程序員,我們可以開一下腦洞:BIO/NIO/AIO、異步 / 同步、阻塞 / 非阻塞...

要同時處理那麼多的請求,要知道,有的請求需要發生 IO,可能需要很長時間,如果等着它,就會拖慢 worker 的處理速度。

Nginx 採用了 Linux 的 epoll 模型,epoll 模型基於事件驅動機制,它可以監控多個事件是否準備完畢,如果 OK,那麼放入 epoll 隊列中,這個過程是異步的。worker 只需要從 epoll 隊列循環處理即可。

思考:Nginx 掛了怎麼辦?

Nginx 既然作爲入口網關,很重要,如果出現單點問題,顯然是不可接受的。

答案是:Keepalived+Nginx 實現高可用

Keepalived 是一個高可用解決方案,主要是用來防止服務器單點發生故障,可以通過和 Nginx 配合來實現 Web 服務的高可用。(其實,Keepalived 不僅僅可以和 Nginx 配合,還可以和很多其他服務配合)

Keepalived+Nginx 實現高可用的思路:

第一:請求不要直接打到 Nginx 上,應該先通過 Keepalived(這就是所謂虛擬 IP,VIP)

第二:Keepalived 應該能監控 Nginx 的生命狀態(提供一個用戶自定義的腳本,定期檢查 Nginx 進程狀態,進行權重變化,,從而實現 Nginx 故障切換)

Keepalived+Nginx

我們的主戰場:nginx.conf

很多時候,在開發、測試環境下,我們都得自己去配置 Nginx,就是去配置 nginx.conf。

nginx.conf 是典型的分段配置文件,下面我們來分析下。

虛擬主機

http 的 server 段

訪問結果

其實這是把 Nginx 作爲 web server 來處理靜態資源。

第一:location 可以進行正則匹配,應該注意正則的幾種形式以及優先級。(這裏不展開)

第二:Nginx 能夠提高速度的其中一個特性就是:動靜分離,就是把靜態資源放到 Nginx 上,由 Nginx 管理,動態請求轉發給後端。

第三:我們可以在 Nginx 下把靜態資源、日誌文件歸屬到不同域名下(也即是目錄),這樣方便管理維護。

第四:Nginx 可以進行 IP 訪問控制,有些電商平臺,就可以在 Nginx 這一層,做一下處理,內置一個黑名單模塊,那麼就不必等請求通過 Nginx 達到後端在進行攔截,而是直接在 Nginx 這一層就處理掉。

反向代理【proxy_pass】

所謂反向代理,很簡單,其實就是在 location 這一段配置中的 root 替換成 proxy_pass 即可。root 說明是靜態資源,可以由 Nginx 進行返回;而 proxy_pass 說明是動態請求,需要進行轉發,比如代理到 Tomcat 上。

反向代理,上面已經說了,過程是透明的,比如說 request -> Nginx -> Tomcat,那麼對於 Tomcat 而言,請求的 IP 地址就是 Nginx 的地址,而非真實的 request 地址,這一點需要注意。不過好在 Nginx 不僅僅可以反向代理請求,還可以由用戶自定義設置 HTTP HEADER

負載均衡【upstream】

上面的反向代理中,我們通過 proxy_pass 來指定 Tomcat 的地址,很顯然我們只能指定一臺 Tomcat 地址,那麼我們如果想指定多臺來達到負載均衡呢?

第一,通過 upstream 來定義一組 Tomcat,並指定負載策略(IPHASH、加權論調、最少連接),健康檢查策略(Nginx 可以監控這一組 Tomcat 的狀態)等。

第二,將 proxy_pass 替換成 upstream 指定的值即可。

負載均衡可能帶來的問題?

負載均衡所帶來的明顯的問題是,一個請求,可以到 A server,也可以到 B server,這完全不受我們的控制,當然這也不是什麼問題,只是我們得注意的是:用戶狀態的保存問題,如 Session 會話信息,不能在保存到服務器上。

緩存

緩存,是 Nginx 提供的,可以加快訪問速度的機制,說白了,在配置上就是一個開啓,同時指定目錄,讓緩存可以存儲到磁盤上。具體配置,大家可以參考 Nginx 官方文檔

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/W2vz_ipz0lGgxuDpsY7CXA