我的架構夢：（十九）Nginx搭建、反向代理、負載均衡、動靜分離以及底層進程機制詳解

一、前言

1、什麼是Nginx?

Nginx 是一個高性能的HTTP和反向代理web服務器，核心特點是佔有內存少，併發能力強。

2、Nginx的應用場景

• Http服務器(Web服務器)

  性能非常高，非常注重效率，能夠經受高負載的考驗。
  支持50000個併發連接數，不僅如此，CPU和內存的佔用也非常的低，10000個沒有活動的連 接才佔用2.5M的內存。

• 反向代理服務器

  正向代理
  在瀏覽器中配置代理服務器的相關信息，通過代理服務器訪問目標網站，代理服務器收到目標網站的響應之後，會把響應信息返回給我們自己的瀏覽器客戶端。

  反向代理
  瀏覽器客戶端發送請求到反向代理服務器(比如Nginx)，由反向代理服務器選擇原始服務器提供服務獲取結果響應，最終再返回給客戶端瀏覽器。

• 負載均衡服務器

  負載均衡，當一個請求到來的時候(結合上圖)，Nginx反向代理服務器根據請求去找到一個 原始服務器來處理當前請求，那麼這叫做反向代理。那麼，如果目標服務器有多臺，找哪一個目標服務器來處理當前請求呢，這樣一 個尋找確定的過程就叫做負載均衡。

  生活中也有很多這樣的例子，比如，我們去銀行，可以處理業務的窗口有多個，那麼我們會 被分配到哪個窗口呢到底，這樣的一個過程就叫做負載均衡。

  負載均衡就是爲了解決高負載的問題。

• 動靜分離

3、Nginx的特點

• 跨平臺:Nginx可以在大多數類unix操作系統上編譯運行，而且也有windows版本。
• Nginx的上手非常容易，配置也比較簡單。
• 高併發，性能好。
• 穩定性也特別好，宕機概率很低。

二、Nginx搭建

1、安裝Nginx依賴，pcre、openssl、gcc、zlib(推薦使用yum源自動安裝)

yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel

2、下載Nginx

wget http://nginx.org/download/nginx-1.17.8.tar.gz

3、解包Nginx軟件包

tar -zxvf nginx-1.17.8.tar.gz

4、進入解壓之後的目錄 nginx-1.17.8

cd nginx-1.17.8

5、命令行執行./configure

6、make

7、命令行執行 make install，完畢之後在/usr/local/下會產生一個nginx目錄

8、進入sbin目錄中，執行啓動nginx命令

cd nginx/sbin 
./nginx

9、然後訪問服務器的80端口(nginx默認監聽80端口)

10、訪問自己的雲服務器不成功的話

阿里雲服務器需要設置安全組規則，配置下面的http規則就行了。

11、Nginx主要命令

• ./nginx 啓動nginx
• ./nginx -s stop 終止nginx(當然也可以找到nginx進程號，然後使用kill -9 殺掉nginx進程)
• ./nginx -s reload (重新加載nginx.conf配置文件)

三、Nginx核心配置文件解讀

Nginx的核心配置文件conf/nginx.conf包含三塊內容:全局塊、events塊、http塊

1、全局塊

從配置文件開始到events塊之間的內容，此處的配置影響nginx服務器整體的運行，比如worker進程的數量、錯誤日誌的位置等。

2、events塊

events塊主要影響nginx服務器與用戶的網絡連接，比如worker_connections 1024，標識每個
workderprocess支持的最大連接數爲1024。

3、http塊

http塊是配置最頻繁的部分，虛擬主機的配置，監聽端口的配置，請求轉發、反向代理、負載均衡等。

四、Nginx應用場景之反向代理

1、反向代理需求一

瀏覽器請求nginx（http://47.113.82.141:9003），nginx將請求轉發給了目標服務器，我們看到的是目標服務器的響應頁面。在整個過程中，目標服務器相當於對客戶端是不可見的，服務端向外暴露的就是nginx的地址。

• 部署tomcat，保持默認監聽8080端口
• 修改nginx配置
• 重新加載nginx配置
  ./nginx -s reload
• 測試，訪問http://47.113.82.141:9003,返回tomcat的⻚面

2、反向代理需求二

在需求一的基礎上，目標服務器有兩個，分別是127.0.0.1:8080、127.0.0.1:8081。
當訪問http://47.113.82.141/9003/abc的時候，實際訪問目標服務器127.0.0.1:8080；
當訪問http://47.113.82.141/9003/def的時候，實際訪問目標服務器127.0.0.1:8081。

• 再部署一臺tomcat，保持默認監聽8081端口

• 修改nginx配置，並重新加載

• 裏主要就是多location的使用，這裏的nginx中server/location就好比tomcat中的Host/Context

  location 語法如下:
  location [=|~|~*|^~] /uri/ { ... }

在nginx配置文件中，location主要有這幾種形式:

• 正則匹配 location ~ /riemann { }
• 不區分大小寫的正則匹配 location ~* /riemann { }
• 匹配路徑的前綴 location ^~ /riemann { }
• 精確匹配 location = /riemann { }
• 普通路徑前綴匹配 location /riemann { }

優先級 4>3>2>1>5

五、Nginx應用場景之負載均衡

負載均衡需求：

新增一個tomcat監聽8082端口，當訪問http://47.113.82.141/9003/abc，使用Nginx作爲負載均衡器，將請求分配到127.0.0.1:8080、127.0.0.1:8082。

1、輪詢

默認策略，每個請求按時間順序逐一分配到不同的服務器，如果某一個服務器下線，能自動剔除。

upstream riemannServer{
	server 47.113.82.141:8080; 
	server 47.113.82.141:8082;
}
location /abc {
	proxy_pass http://riemannServer/;
}

2、weight

weight代表權重，默認每一個負載的服務器都爲1，權重越高那麼被分配的請求越多(用於服務器
性能不均衡的場景)

upstream riemannServer{
	server 47.113.82.141:8080 weight=1; 
	server 47.113.82.141:8082 weight=2;
}

3、ip_hash

每個請求按照ip的hash結果分配，每一個客戶端的請求會固定分配到同一個目標服務器處理，可
以解決session問題。

upstream riemannServer{ 
	ip_hash;
	server 47.113.82.141:8080;
	server 47.113.82.141:8082; 
}

六、Nginx應用場景之動靜分離

動靜分離就是講動態資源和靜態資源的請求處理分配到不同的服務器上，比較經典的組合就是 Nginx+Tomcat架構(Nginx處理靜態資源請求，Tomcat處理動態資源請求)，那麼其實之前的講解 中，Nginx反向代理目標服務器Tomcat，我們能看到目標服務器ROOT項目的index.jsp，這本身就是 Tomcat在處理動態資源請求了。

所以，我們只需要配置靜態資源訪問即可。

動靜分離需求

主要是靜態資源的訪問，因爲我們之前Nginx反向代理到Tomcat能夠看到Tomcat ROOT項目的index.jsp頁面，這本身就是一個動態資源的請求過程。

我們希望在Nginx服務器上部署靜態資源，然後瀏覽器請求http://47.113.82.141/9003/static/abc.html,Nginx直接讀取的本地靜態資源。

Nginx配置

七、Nginx底層進程機制剖析

Nginx啓動後，以daemon多進程方式在後臺運行，包括一個Master進程和多個Worker進程，Master
進程是領導，是老大，Worker進程是幹活的小弟。

• master進程

  主要是管理worker進程，比如:
  接收外界信號向各worker進程發送信號(./nginx -s reload)
  監控worker進程的運行狀態，當worker進程異常退出後Master進程會自動重新啓動新的 worker進程等

• worker進程

  worker進程具體處理網絡請求。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程， 不可能處理其它進程的請求。worker進程的個數是可以設置的，一般設置與機器cpu核數一致。

1、Nginx進程模型示意圖如下

2、以 ./nginx -s reload 來說明nginx信號處理這部分

• master進程對配置文件進行語法檢查
• 嘗試配置(比如修改了監聽端口，那就嘗試分配新的監聽端口)
• 嘗試成功則使用新的配置，新建worker進程
• 新建成功，給舊的worker進程發送關閉消息
• 舊的worker進程收到信號會繼續服務，直到把當前進程接收到的請求處理完畢後關閉

所以reload之後worker進程pid是發生了變化的

3、worker進程處理請求部分的說明

例如，我們監聽9003端口，一個請求到來時，如果有多個worker進程，那麼每個worker進程都有
可能處理這個鏈接。

• master進程創建之後，會建立好需要監聽的的socket，然後從master進程再fork出多個
  worker進程。所以，所有worker進程的監聽描述符listened在新連接到來時都變得可讀。
• nginx使用互斥鎖來保證只有一個worker進程能夠處理請求，拿到互斥鎖的那個進程註冊 listenfd讀事件，在讀事件裏調用accept接受該連接，然後解析、處理、返回客戶端。

4、nginx多進程模型好處

• 每個worker進程都是獨立的，不需要加鎖，節省開銷
• 每個worker進程都是獨立的，互不影響，一個異常結束，其他的照樣能提供服務
• 多進程模型爲reload熱部署機制提供了支撐