如何實現反向代理、負載均衡

這篇文章主要講解了“如何實現反向代理、負載均衡”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何實現反向代理、負載均衡”吧！

Nginx 的產生

Nginx 同 Apache 一樣都是一種 Web 服務器。基于 REST 架構風格，以統一資源描述符（Uniform Resources Identifier）URI 或者統一資源定位符（Uniform Resources Locator）URL 作為溝通依據，通過 HTTP 協議提供各種網絡服務。

然而，這些服務器在設計之初受到當時環境的局限，例如當時的用戶規模，網絡帶寬，產品特點等局限并且各自的定位和發展都不盡相同。這也使得各個 Web 服務器有著各自鮮明的特點。

Apache 的發展時期很長，而且是毫無爭議的世界第一大服務器。它有著很多優點：穩定、開源、跨平臺等等。

它出現的時間太長了，它興起的年代，互聯網產業遠遠比不上現在。所以它被設計為一個重量級的。

它不支持高并發的服務器。在 Apache 上運行數以萬計的并發訪問，會導致服務器消耗大量內存。

操作系統對其進行進程或線程間的切換也消耗了大量的 CPU 資源，導致 HTTP 請求的平均響應速度降低。

這些都決定了 Apache 不可能成為高性能 Web 服務器，輕量級高并發服務器 Nginx 就應運而生了。

俄羅斯的工程師 Igor Sysoev，他在為 Rambler Media 工作期間，使用 C 語言開發了 Nginx。

Nginx 作為 Web 服務器一直為 Rambler Media 提供出色而又穩定的服務。然后呢，Igor Sysoev 將 Nginx 代碼開源，并且賦予自由軟件許可證。

由于以下這幾點，所以，Nginx 火了：

• Nginx 使用基于事件驅動架構，使得其可以支持數以百萬級別的 TCP 連接。

• 高度的模塊化和自由軟件許可證使得第三方模塊層出不窮（這是個開源的時代啊）。

• Nginx 是一個跨平臺服務器，可以運行在 Linux、Windows、FreeBSD、Solaris、AIX、Mac OS 等操作系統上。

• 這些優秀的設計帶來的極大的穩定性。

Nginx 的用武之地

Nginx 是一款自由的、開源的、高性能的 HTTP 服務器和反向代理服務器；同時也是一個 IMAP、POP3、SMTP 代理服務器。

Nginx 可以作為一個 HTTP 服務器進行網站的發布處理，另外 Nginx 可以作為反向代理進行負載均衡的實現。

關于代理

說到代理，首先我們要明確一個概念，所謂代理就是一個代表、一個渠道；此時就涉及到兩個角色，一個是被代理角色，一個是目標角色。

被代理角色通過這個代理訪問目標角色完成一些任務的過程稱為代理操作過程；如同生活中的專賣店，客人到 adidas 專賣店買了一雙鞋，這個專賣店就是代理，被代理角色就是 adidas 廠家，目標角色就是用戶。

正向代理

說反向代理之前，我們先看看正向代理，正向代理也是大家最常接觸到的代理模式，我們會從兩個方面來說關于正向代理的處理模式，分別從軟件方面和生活方面來解釋一下什么叫正向代理。

在如今的網絡環境下，我們如果由于技術需要要去訪問國外的某些網站，此時你會發現位于國外的某網站我們通過瀏覽器是沒有辦法訪問的。

此時大家可能都會用一個操作 FQ 進行訪問，FQ 的方式主要是找到一個可以訪問國外網站的代理服務器，我們將請求發送給代理服務器，代理服務器去訪問國外的網站，然后將訪問到的數據傳遞給我們！

上述這樣的代理模式稱為正向代理，正向代理最大的特點是客戶端非常明確要訪問的服務器地址；服務器只清楚請求來自哪個代理服務器，而不清楚來自哪個具體的客戶端；正向代理模式屏蔽或者隱藏了真實客戶端信息。

來看個示意圖（我把客戶端和正向代理框在一塊，同屬于一個環境，后面我有介紹）：

客戶端必須設置正向代理服務器，當然前提是要知道正向代理服務器的 IP 地址，還有代理程序的端口。

如下圖：

通過上述的圖解大家就可以看清楚了，多個客戶端給服務器發送的請求，Nginx 服務器接收到之后，按照一定的規則分發給了后端的業務處理服務器進行處理了。

此時請求的來源也就是客戶端是明確的，但是請求具體由哪臺服務器處理的并不明確了，Nginx 扮演的就是一個反向代理角色。

客戶端是無感知代理的存在的，反向代理對外都是透明的，訪問者并不知道自己訪問的是一個代理。因為客戶端不需要任何配置就可以訪問。

反向代理，"它代理的是服務端"，主要用于服務器集群分布式部署的情況下，反向代理隱藏了服務器的信息。

反向代理的作用：

• 保證內網的安全，通常將反向代理作為公網訪問地址，Web 服務器是內網。

• 負載均衡，通過反向代理服務器來優化網站的負載。

項目場景

通常情況下，我們在實際項目操作時，正向代理和反向代理很有可能會存在同一個應用場景中，正向代理代理客戶端的請求去訪問目標服務器，目標服務器是一個反向單利服務器，反向代理了多臺真實的業務處理服務器。

具體的拓撲圖如下：

圖解：

• 在正向代理中，Proxy 和 Client 同屬于一個 LAN（圖中方框內），隱藏了客戶端信息。

• 在反向代理中，Proxy 和 Server 同屬于一個 LAN（圖中方框內），隱藏了服務端信息。

實際上，Proxy 在兩種代理中做的事情都是替服務器代為收發請求和響應，不過從結構上看正好左右互換了一下，所以把后出現的那種代理方式稱為反向代理了。

負載均衡

我們已經明確了所謂代理服務器的概念，那么接下來，Nginx 扮演了反向代理服務器的角色，它是依據什么樣的規則進行請求分發的呢？不用的項目應用場景，分發的規則是否可以控制呢？

這里提到的客戶端發送的、Nginx 反向代理服務器接收到的請求數量，就是我們說的負載量。

請求數量按照一定的規則進行分發，到不同的服務器處理的規則，就是一種均衡規則。

所以將服務器接收到的請求按照規則分發的過程，稱為負載均衡。

負載均衡在實際項目操作過程中，有硬件負載均衡和軟件負載均衡兩種，硬件負載均衡也稱為硬負載，如 F5 負載均衡，相對造價昂貴成本較高。

但是數據的穩定性安全性等等有非常好的保障，如中國移動中國聯通這樣的公司才會選擇硬負載進行操作。

更多的公司考慮到成本原因，會選擇使用軟件負載均衡，軟件負載均衡是利用現有的技術結合主機硬件實現的一種消息隊列分發機制。

感謝各位的閱讀，以上就是“如何實現反向代理、負載均衡”的內容了，經過本文的學習后，相信大家對如何實現反向代理、負載均衡這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！