前文我們聊了下nginx作為反向代理服務器，代理后端動態應用服務器的配置，回顧請參考https://www.cnblogs.com/qiuhom-1874/p/12430543.html；今天我們來聊一聊nginx作為反向代理服務器，代理一組服務器的配置（負載均衡）；前邊我們只說到了nginx怎么去代理后端服務器響應客戶端的請求，它在響應客戶端請求的流程是這樣的，用戶請求發送到nginx代理服務器上，此時nginx服務器扮演的就是服務端的角色，客戶端是無法感知后端服務器的存在，而用戶的報文被nginx接收后，nginx代理服務器它會把用戶的請求報文拆開看，用戶請求的資源，然后把用戶的請求資源，拿到自己的location中進行匹配，如果匹配到了，就按照匹配到的location中定義的代理規則進行代理，在這之前nginx首先會看自己的緩存是否存在用戶請求的資源，如果有，它就從緩存中響應用戶，如果沒有，它就扮演客戶端的角色，重新對用戶請求重新封裝請求報文，發送給后端服務器，后端服務器收到請求后，把對應資源響應給nginx代理服務器，nginx會把后端服務器響應的資源，先緩存一份（如果允許緩存的話），然后在封裝響應報文，響應客戶端；從這樣一個過程來看，nginx它既當服務器角色，又當客戶端角色，而且nginx是可以把用戶的報文拆開，然后再封裝；這是nginx作為代理服務器代理后端服務器響應客戶端請求的一個過程（后端服務器是一個的情況）；如果后端服務器有多個，都是提供者相同的服務，此時我們該怎么把客戶端的請求代理到后端多台服務器呢？
首先我們來了解下nginx的upstream模塊，nginx的upstream模塊有兩個，一個是基於http協議的upstream，它主要是基於http協議定義后端服務器組，還有一個就是基於tcp協議的upstream，它主要是基於tcp協議定義后端服務器組；我們先說nginx的http里的upstream模塊吧！！！
一、ngx_http_upstream_module：此模塊用於定義一組服務器，然后被proxy_pass、fastcgi_pass、uwsgi_pass、scgi_pass和memcached_pass指令引用的服務器組。意思很簡單，就是把相同的多台服務器歸並成一組服務器，然后nginx基於各種協議的代理，把請求代理到該組上，從而實現把用戶請求代理到后端多台服務器上
1、upstream name {……}：此指令只能用於http配置段中，意思是定義一組后端服務器組；
2、server address [parameters]:此指令用於upstream配置段中，表示定義upstream配置段中的server成員，以及相關的參數；其中地址的格式支持IP地址加端口的形式，支持unix path路徑，也支持主機名或域名加端口的形式；parameters表示參數，常用的參數有weight=number權重，默認是1，max_fails=number表示失敗嘗試最大次數；超出此處指定的次數，nginx將失敗的server標記為不可用；fail_timeout=time表示設置將服務器標記為不可用狀態的超時時長；max_conns表示當前的服務器的最大並發連接數；backup表示將服務器標記為“備用”，既所有服務器均不可用時，此服務器才會被啟用，有點類似LVS里的sorry server的角色；down表示將服務器標記為“不可用”
3、least_conn：此指令表示最少連接調度算法，當server擁有不同的權重時表示wlc算法
4、ip_hash：此指令類似lvs里的sh算法（源地址哈希算法），同一客戶端地址始終調度到同一台服務器上；
5、hash key [consistent]：基於指定的key的hash表示實現對請求的調度，此處的key可以是文本、變量、或者二者的組合；作用是將請求分類，將同一類請求發往同一個upstream的server進行響應；
6、keepalive connections：為每個worker進程保留的空閑的長連接數量；
示例：
定義一組服務器名為webserver
提示：upstream 只能用於定義在http配置段中，它表示定義一組服務器，名為webserver ，后續調度直接將用戶請求代理到該組上即可；
提示：以上配置表示將用戶訪問www.proxy.com時將用戶請求代理到webserver這個組上的服務器，默認情況下是輪詢的；
提示：可以看到客戶端的請求是可以通過nginx把請求代理到后端一組服務器上，從上面的響應結果來看，我們不配置任何權重，它默認就是輪詢的（當然上面的結果也有重復的，這個還不太清楚為什么會重復，可能是每個報文的響應速度不一樣吧，但總的響應是一樣的每個后端服務器各占一半）；當然我們也是可以給不同的服務器加上不同的權重，此時nginx作為調度器就是使用的加權輪詢，如下配置
提示：以上配置表示 192.168.0.20這台服務器的權重是5，0.22的權重是2，意思就是7個請求中，0.20處理5個請求，0.22處理2個請求；
假如我們后端服務器有一台服務出現故障，nginx會不會把用戶的請求調度到出現故障的服務器上呢？我們知道在lvs做調度器時，前端lvs會把用戶的請求調度到出現故障的服務器上，我們需要借助keepalived或者其他輔助服務去實現對后端服務器做健康狀態監測，才能把用戶的請求不調度到有故障的后端服務器上，nginx會不會呢？
提示：可以看到nginx不會把用戶的請求調度到有故障的服務器上，這是因為nginx自身就有對后端服務器做健康狀態監測的機制，能夠及時的發現后端服務器的健康狀態，及時的將服務不可用的后端主機從集群中下線，當然這種下線是當服務不可用時，自動觸發的動作，我們也可以人為的把后端服務器標記為不可用狀態，通常在做灰度發布時可能用到，直接在服務器后面明確用down來標記該服務器，不接受任何請求；
提示：以上配置表示把0.22這台主機從webserver組中下線，下線的意思就是不再往上調度請求；當然此時的組中服務器就只用0.20這一台主機，用戶請求也只能調度到這台上，所以用戶不管怎么請求，nginx都只會把請求調度到0.20這台后端主機上；
假如后面的兩台主機都宕機了，此時用戶訪問我們的網站會不會像lvs那樣，有sorry server 來給用戶說sorry 呢？
提示：可以看到當后端主機全部宕機后，沒有像lvs里的有sorry server出來給用戶說sorry 或者響應客戶端請求的；在nginx里sorry server里的配置很簡單，只需要在服務器的后面打上backup的標簽即可
提示：以上配置表示把127.0.0.1:80作為sorry server ,意思是組里的正常被代理的主機全部宕機后，這台主機才會被調度，當組里主機有一台恢復正常，這台主機就不被調度，用戶請求將調度到正常的那一台主機上；
提示：可以看到當后端主機全部宕機后，sorry server就會被調度；
提示：當后端主機恢復時，sorry server 就不會被調度，用戶的請求將會被代理至恢復的那台主機上；
以上就是nginx作為負載均衡的常用配置，接下來我們在說說調度算法
基於源地址hash算法
提示：以上配置表示同一源地址的客戶端請求將會調度到后端某一台server上進行響應
提示：可以看到同一客戶段始終被調度到一台server上進行響應，這種就叫做源地址綁定；除了以上ip_hash;來指定綁定源地址，還可以通過hash key來指定，以上配置等同hash $remote_addr;
基於用戶請求的uri進行綁定，用戶請求同一uri始終調度到某一server上響應，這樣做的好處可以使緩存命中提高；
提示：以上配置表示綁定用戶請求的rui，不同的用戶請求同一rui時，nginx會始終把同一rui的請求調度到同一台server上進行響應；
提示：可以看到同一客戶端請求不同的uri時，會根據請求的uri隨機調度到某一台server上進行響應；從上面的配置實例我們可以知道我們把什么當作key來hash，就可以實現基於什么來綁定后端服務器，比如基於用戶請求的uri當作hash對象，那么用戶請求同一uri就會被調度到同一server上進行響應，如果基於用戶源ip地址當作hash對象，那么同一源IP地址的用戶，不論請求什么uri都會被調度到同一server進行響應；按這個邏輯我們可以綁定用戶的信息來做調度；
以上就是nginx作為七層代理http請求的負載均衡的常用配置；總結一點nginx作為負載均衡使用其中核心的思想就是把同類服務的服務器先歸並到一個組里，然后基於不同協議的代理來把用戶的請求反代到該組上，然后基於某種調度算法來實現把用戶請求調度到某一台server進行響應；