日常生活中，我們免不了要去一些比較擁擠的地方，比如地鐵站、火車站、銀行等。這些地點都有一個特徵，都會設置多個服務點或者入口，大多數情況下，最近的入口會擠滿人，而那些距離較遠的服務點或者入口來說，人流密度一般會少很多。
其實，網站的建設也是一樣的，一般公司網站或者系統都是有好幾臺甚至更多服務器一起支撐起來的。當用戶集中訪問網站的時候，如果沒有任何機制來疏導用戶的訪問，完全隨機或者就近原則的話，那麼就會導致某些服務器的流量很大，而另外的服務器的訪問量很小。這不僅嚴重的浪費了資源，而且還會導致拉長用戶訪問網站的 RT（響應時間），影響用戶體驗，更嚴重的可能直接拖垮那些流量大的服務器。
這時候，我們就需要一個協調者，讓這些用戶的請求可以均勻的分派到不同的服務器上。這個協調者有很多，今天我們要說的這個協調者就是 Nginx。
目前三大主流“協調者”：LVS、Nginx、HAproxy
什麼是Nginx
Nginx（發音同engine x）是一個高性能且輕量級的WEB服務器，其特點是佔有內存少，併發能力強。
Nginx 它能做什麼？
— 反向代理
— 負載均衡
— HTTP服務器
— 虛擬主機
— ......
靜態HTTP服務器
使用 Nginx 充當一個靜態的WEB服務器，可以將服務器上的靜態文件（如HTML文檔、CSS樣式、JS腳本、圖片）通過 HTTP 協議展現給客戶端。
虛擬主機
有的網站，比如自己的個人博客之類的，由於訪問量太小，爲了節省成本，可以將多個網站部署在同一臺服務器上。例如將 www.a.com 和 www.b.com 兩個網站部署在同一臺服務器上，兩個域名解析到同一個IP地址，但是用戶通過兩個域名卻可以打開兩個完全不同的網站，互相不影響，就像訪問兩個服務器一樣，這樣 Nginx 就將一臺服務器變成了兩臺虛擬主機。
反向代理與負載均衡
反向代理與負載均衡是 Nginx 功能中使用率最高的兩個功能，可以說是它的靈魂所在。
作爲前端，要了解的 Nginx 用法其實不多，簡單看看就好，因爲這兩個功能在工作當中就夠用了。當我們瞭解完這兩個功能之後，我們就可以做很多事情了。
那我們就開始今天的主題吧~
什麼是反向代理
有反必有正，在說反向代理之前，我們先來看看什麼是正向代理。
正向代理
正向代理是一個位於客戶端和原始服務器之間的服務器，爲了從原始服務器取得內容，客戶端向代理髮送一個請求並指定目標(原始服務器)，然後代理向原始服務器轉交請求並將獲得的內容返回給客戶端。
正向代理是客戶端知道目的服務器在哪裏，然後通過代理服務器去訪問目標服務器，而目標服務器並不知道客戶端通過什麼來訪問的，也不知道是該請求是源於哪個客戶端。
在正向代理中，客戶端是被代理者 。如果以生產者、消費者模式來區分的話，客戶端屬於消費者，它不對外提供服務，反而是對外消費服務。
用租房爲例，
A(客戶端) 想租 C(服務端) 的房子,但是 A(客戶端) 由於某些情況不能直接找到 C(服務端) ，而恰恰 B (代理) 認識 C(服務端) ，所以 A(客戶端) 找了 B(代理) 幫忙，讓 B(代理) 去找 C(服務端) 租了這個房子，然後再把房子給 A(客戶端) 使用。
這個過程中 C(服務端) 不認識 A(客戶端) 只認識 B(代理) ，而 C(服務端) 並不知道 A(客戶端) 租了房子，只知道房子租給了 B(代理)。
反向代理
反向代理是架設在服務端的，以代理服務器來接受 Internet 上的連接請求，然後將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給 Internet 上請求的客戶端。
在反向代理中，服務端是被代理者，對外提供服務，屬於服務提供者。
反向代理的原理也可以用租房的例子來解釋：
A(客戶端) 想租一個房子，然後通過某些渠道找到了B(代理) ，然後 B(代理) 就把這個房子租給了他。而實際上 C(服務端) 纔是房東。B(代理) 是中介，把這個房子租給了 A(客戶端)。這個過程中 A(客戶端) 並不知道這個房子到底誰纔是房東，他都有可能認爲這個房子就是 B(代理) 的。
正向代理和反向代理的區別
位置不同
正向代理：架設在客戶機和目標主機之間
反向代理：架設在服務器端
代理對象不同
正向代理：代理客戶端，服務端不知道實際發起請求的客戶端
反向代理：代理服務端，客戶端不知道實際提供服務的服務端
安全性不同
正向代理：允許客戶端通過它訪問任意網站並且隱藏客戶端自身，因此必須採取安全措施以確保僅爲授權的客戶端提供服務
反向代理：對外都是透明的，訪問者並不知道自己訪問的是哪一個代理
什麼是負載均衡
其實前面我們在講排隊的例子的時候，說到將排隊的人較平均的分散到各個入口，從而縮短排隊時間，提高顧客的體驗。這其實就是負載均衡的通俗解釋了。
負載均衡（Load Balance），意思是將負載（工作任務，訪問請求）進行平衡、分攤到多個操作單元（服務器，組件）上進行執行。是解決高性能，單點故障（高可用），擴展性（水平伸縮）的終極解決方案。
先看一個沒有負載均衡機制的Web架構：
用戶的請求直接通過 Internet 發送到了指定服務器，這種架構在用戶量集中訪問的時候就可能出現問題，例如響應時間長而影響用戶的體驗，最嚴重的可能是導致服務器掛掉。這對於個人網站或者小型網站來說，可能影響不是很大，但是對於一直都是大流量的網站來說，這是致命的，哪怕是隻掛了幾分鐘，影響到的也是成千上萬的用戶。
所以，爲了提升網站的各方面能力，大型網站一般會把多臺服務器組成一個集羣對外提供服務。然而，我們訪問網站的入口都是一個的，比如 www.a.com。那麼當用戶在瀏覽器輸入 www.a.com 的時候如何將用戶的請求分發到集羣中不同的機器上呢，這就是負載均衡在做的事情。
用戶每次訪問，都會保證服務器集羣中的每個服務器壓力趨於平衡，分擔了服務器壓力，避免了服務器崩潰的情況。簡言之：哪裏“人”少就往哪裏去。
即便某個服務器因爲某些其他原因掛了，負載均衡策略也會把用戶轉發到正常工作的服務器上去，從而不影響用戶訪問。
通常情況下，所有的後端服務器會保證提供相同的內容，以便用戶無論哪個服務器響應，都能收到一致的內容。
負載均衡算法
負載均衡服務器在決定將請求轉發到具體哪臺真實服務器的時候，是通過負載均衡算法來實現的。它是一個負載均衡服務器的核心。
下面是幾個常用的算法，這裏做個簡單介紹：
輪詢：爲第一個請求選擇健康池中的第一個後端服務器，然後按順序往後依次選擇，即第二個請求就發給第二個後端服務器，以此類推，直到最後一個，然後循環。
最小連接：優先選擇連接數最少，也就是壓力最小的後端服務器，在會話較長的情況下可以考慮採取這種方式。
散列：根據請求源的 IP 的散列（hash）來選擇要轉發的服務器。這種方式可以一定程度上保證特定用戶能連接到相同的服務器。如果你的應用需要處理狀態而要求用戶能連接到和之前相同的服務器，可以考慮採取這種方式。
不同的負載均衡服務器會個根據自身的業務需要選擇不同的算法，就像電影院和火車站可能會選用不同的引導策略一樣。火車站可能會把行李少的旅客分配到一個專門的入口，可能給即將發車的旅客分派到快捷入口，手持可掃描車票的用戶單獨分配到特殊入口等。
今天所講的大多都是概念性的東西，具體如何在服務端配置 Nginx，請看下回分享~
