你是一個程序員，你在電腦上編輯了一段文本，將它保存為 txt 文件。將它拖到瀏覽器打開，就能看到文件里的內容。

但這看起來太過單調，為了讓畫面更豐富，我們定個規則，在文本邊上加個兩個h1符號，文本就以標題形式展示。

加入ul和li就能變成列表，加入img還能讓url文本直接變成對應的圖片。

圖片

這些帶尖括號的特殊符號，我們叫它標簽。只要瀏覽器識別到這些標簽，就展示對應的樣式。

為了將這個自帶標簽的文本跟 txt 純文本區分開來，我們給了它新的后綴名, html。

瀏覽器只要識別到文件是 html，就會解析里面的標簽，這樣我們就有了標題、輸入框等各種豐富的內容了。這其實就是我們平時在瀏覽器中看到的網頁。

但不同的是，這個 html 文件是瀏覽器從我們本地電腦文件中打開的。

本地瀏覽器打開html

而我們平時訪問的網頁，則是從某臺遠端服務器，將文件傳到我們電腦的瀏覽器后打開的。

從遠端服務器得到html打開

那么問題就來了，我們是怎么獲得這個遠端服務器上的 html 文件的？

沒有什么是加一層中間層不能解決的，如果有，那就再加一層，這次我們要加的中間層是 Nginx.

nginx中間層

假設我們完全不了解 nginx，來看下它是怎么設計出來的。

HTTP 服務器是什么？

想要讓本地的瀏覽器，獲取到放在遠端服務器上的 html 文件。

那很簡單，我們可以在遠端服務器啟動一個進程，這個進程對外提供 http 服務，說白了就是提供了個 url。

用戶在瀏覽器中輸入這個 url， 回車，瀏覽器就會向 這個進程發起 http 請求，

進程收到瀏覽器的請求后，就將 html 文件發給瀏覽器，瀏覽器完成解析和展示，完美。

而像這種根據瀏覽器請求，返回 html 文件的服務進程，其實就叫 http 服務器。

有了它，前端開發老哥寫的各種 html 文件就能部署到遠端服務器上，對外提供網頁服務了。

http服務器是什么

反向代理是什么？

但一個完整產品往往不止有前端頁面，還有后端服務，比如某寶，前端商城頁面需要從后端服務那獲取最新的商品數據。

前后端分離

假設現在前端頁面已經被加載到瀏覽器中，瀏覽器會按頁面里寫好的代碼邏輯，向后端商品服務發起請求，獲取數據，流量小的時候沒什么問題，流量變大后，后端服務器扛不住的話，就需要增加商品服務的個數，服務變多后，每個都有對應的 ip 和端口，瀏覽器就不知道該訪問哪個服務了。

所以我們還需要在這幾個后端服務前面加一個進程，對外提供一個 url 域名，請求來了，由這個進程均勻轉發給背后的幾個服務，讓每個服務都能處理上請求，也就實現了所謂的負載均衡。

像這種，屏蔽掉背后具體有哪些服務器的代理方式，就是我們常說的反向代理。

反向代理

有了反向代理，我們對外就可以只提供一個url域名，背后根據需要, 隨時擴縮容服務。

這個反向代理的功能，正好可以加到前面放 html 文件的進程上。

那現在這個進程就很靈性了，既可以為 前端 html 文件提供 http 服務器的功能，當 html 文件被加載到瀏覽器，并向后端發起請求的時候，這個進程還能為后端服務器提供反向代理的功能。

http服務器+反向代理

模塊化網關能力

既然是中間層，所有網絡流量都要經過進程，那它高低也算個網關了。

網關

于是我們就可以順理成章的在它上面加入一些通用網關能力，比如加個日志，記錄每次調用的結果，方便后續排查問題，又比如加個對輸入輸出的內容進行壓縮的功能，減小網絡帶寬消耗，又或者是對某個 IP 進行限流或封禁，甚至還可以修改輸入輸出的內容。能實現的功能實在太多，想象空間很大，于是將這部分功能設計為開放接口，讓用戶通過自定義模塊來實現特定功能。

這還不夠，現在這個網關只支持http，我們其實還能擴展下，讓它支持tcp，udp，http2和websocket，你能想到的我都要支持，我本來不支持的，自會有人通過自定義模塊幫我支持。

支持多種通用能力和協議

配置能力

前面提到那么多種能力，用戶肯定不會全用上，所以需要有個地方讓人選擇用哪些能力，于是我們可以加個配置文件，也就是nginx.conf，用戶想用什么能力，就在配置文件上聲明清楚就行，非常方便。

nginx.conf配置

單線程

現在這個網關進程的主要任務就是跟上下游建立網絡連接，順便內部做下處理。多個客戶端請求通過網絡進入到一個進程，如果用多線程并發處理，那就需要考慮并發問題，同時影響性能。怎么辦呢？

多線程

很簡單！外部不管有多少有個網絡連接，網關進程收到客戶端請求后，都統一塞到一個線程上，在一個線程上處理客戶端請求，什么并發問題和線程切換開銷，完全不存在！

單線程

多 worker 進程

但單個進程要單線程處理那么多流量，哪怕再快，壓力也不小，萬一這里面有美羊羊發的流量，你覬覦那么久？怎么忍心讓她久等？沸羊羊你說話！

怎么辦呢？既然多線程不行，那我們就上多進程。

于是可以將單個進程改成多個進程，我們管它們叫 worker 進程。進程之間互相獨立，一個 worker 跪了不影響另外一個 worker 進程。

多worker進程

讓多個 worker 進程同時監聽一個 ip 地址+端口。只要一有流量進來，操作系統就會隨機給到其中一個進程處理。將進程數量設置為跟操作系統cpu核數一致，那每個進程都能得到一個核，開足馬力猛猛干。

worker數與核數一致

看到這里，問題就來了，為什么多個進程同時監聽一個端口不會出現端口沖突（port is already in use），評論區告訴我答案。

共享內存

但多 worker 進程的情況下，同一個客戶端的多個請求會隨機打到某個 worker ，對于限流這種需要計數的場景，就會被分散到多個 worker 上單獨計數，那還怎么限流，所以還需要給這些 worker 進程 分配一個共享內存區域，方便多個進程之間共用同一份數據做邏輯，確保系統數據一致性。

共享內存

proxy cache

作為網關，它在收到前端網頁請求后，會轉發給后端，并將后端處理結果中轉給前端。如果它能將響應結果緩存起來，這樣下次收到同樣的請求，直接將緩存里的數據返回給前端，從而減少響應時間和網絡負載。

那這個數據是放在共享內存里嗎？內存貴，不合適，我們可以維護些磁盤文件，用于在前端請求后端的過程中，暫存后端響應的結果，后面再有相同請求，就可以將磁盤里的數據返回。

這又是經典的空間換時間，用廉價的磁盤空間換取網絡傳輸和cpu計算耗時。對于后端響應較慢或重復請求較多的場景，讀寫磁盤總歸比直接將請求打到后端來得快。這些用于緩存響應數據的磁盤文件，就是 所謂的proxy cache 。

proxy cache

加入 master 進程

但這還不夠，現在每個 worker 都會分走一部分流量，如果功能更新，所有 worker 同時一起重啟，上面的網絡連接就會全部斷掉。更好的方式是創建 worker 和關閉 worker 挨個陸續執行，這樣前端網頁連接斷開后還能去連另外一個worker，保證任意時間一直有worker在工作。也就是所謂的滾動升級。因此還需要一個新的進程協調各個 worker 誰先誰后，這個協調進程，就是所謂的 master 進程。讓master讀取前面提到的nginx.conf配置，統一管理多個worker。

master進程

nginx 是什么

好啦，到這里，當初那個簡陋的單進程網關服務，就變成了一個支持動態配置多種通用網關能力和多種網絡協議，單 master 多 worker 架構、多個worker進程之間共享內存和proxy cache，對外提供一個IP+端口，支持 http 服務器和反向代理的高性能網關服務。

它就是所謂的 nginx。

nginx是什么

它不僅支持日志、限流等各種通用能力、還支持自定義網關能力，只要你寫好配置，就能讓它給你當牛做馬。性能上 5w qps 非常輕松，應付你那只有幾十 qps 的服務更是綽綽有余了。

現在大家通了嗎？好啦，如果你覺得這個視頻對你有幫助，記得點贊并轉發給你那不成器的兄弟，文字版的筆記見評論區。

最后遺留一個問題，想必大家也發現了，聊到現在它其實也只是某臺服務器上的多個進程，一旦服務器跪了，nginx 也就跪了，存在單點問題。

nginx單點問題

那怎么解決 nginx 的單點問題呢？nginx 有集群模式嗎？評論區告訴我答案。

最后的最后再遺留一個問題，你聽說過大數據嗎？你知道大家是怎么解決大數據問題的嗎？