文章目錄
一、什麼是負載均衡
當一臺服務器的單位時間內的訪問量越大時,服務器壓力就越大,大到超過自身承受能力時,服務器就會崩潰。爲了避免服務器崩潰,讓用戶有更好的體驗,我們通過負載均衡的方式來分擔服務器壓力。
我們可以建立很多很多服務器,組成一個服務器集羣,當用戶訪問網站時,先訪問一箇中間服務器,在讓這個中間服務器在服務器集羣中選擇一個壓力較小的服務器,然後將該訪問請求引入該服務器。如此以來,用戶的每次訪問,都會保證服務器集羣中的每個服務器壓力趨於平衡,分擔了服務器壓力,避免了服務器崩潰的情況。
負載均衡器的管理員能主要爲下面四種主要類型的請求設置轉發規則:
- HTTP
- HTTPS
- TCP
- UDP
二、負載均衡器如何選擇要轉發的後端服務器?
負載均衡器應當只選擇能正常做出響應的後端服務器,因此就需要有一種判斷後端服務器是否「健康」的方法。爲了監視後臺服務器的運行狀況,**運行狀態檢查服務會定期嘗試使用轉發規則定義的協議和端口去連接後端服務器。**如果,服務器無法通過健康檢查,就會從池中剔除,保證流量不會被轉發到該服務器,直到其再次通過健康檢查爲止。
三、Nginx作爲負載均衡的優點
常見負載均衡的優點和缺點對比(Nginx、HAProxy、LVS)
參考URL: https://www.cnblogs.com/Tang-Yuan/p/10442447.html
- 工作在網絡的7層之上,可以針對http應用做一些分流的策略,比如針對域名、目錄結構,它的正則規則比HAProxy更爲強大和靈活,這也是它目前廣泛流行的主要原因之一,Nginx單憑這點可利用的場合就遠多於LVS了。
- Nginx對網絡穩定性的依賴非常小,理論上能ping通就能進行負載功能,這個也是它的優勢之一;相反LVS對網絡穩定性依賴比較大。
- Nginx安裝與配置比較簡單,測試也比較方便,基本能把錯誤日誌打印出來。
- 可以承擔高負載壓力且穩定,在硬件不差的情況下一般能支撐幾萬次的併發量,負載度比LVS相對小些。
- Nginx可以通過端口檢測到服務器內部的故障,如根據服務器處理網頁返回的狀態碼、超時等,並會把返回錯誤的請求重新提交到另一個節點。
- Nginx社區活躍,第三方模塊非常多。
四、Nginx的缺點
- Nginx僅能支持http、https和Email協議,這樣就在適用範圍上面小些,這個是它的缺點。
- 對後端服務器的健康檢查,只支持通過端口來檢測,不支持通過url來檢測。不支持Session的直接保持,但能通過ip_hash來解決。
五、nginx配置http負載均衡
nginx 實現負載均衡用到了 proxy_pass 代理模塊核心配置, 將客戶端請求代理轉發至一組 upstream 虛擬服務池。
a、使用upstream定義web服務器池,包含web1、web2節點。
b、proxy_pass把訪問請求轉發給之前定義的web服務器池。
-
編輯nginx的配置文件
vi nginx/conf/nginx.conf
http { upstream upstream_name{ server 192.168.0.28:8001; server 192.168.0.28:8002; } #定義服務池 upstream apollo-configservice-pools-dev { server 192.168.0.100:8080 weight=1; server 192.168.0.101:8080 weight=1; } server { listen 8080; server_name localhost; location / { proxy_pass http://apollo-configservice-pools-dev; } location /test { proxy_pass http://upstream_name; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } }
在http下添加 upstream upstream_name {} 來配置要映射的服務器。
其中的upstream_name大家可以指定爲服務的域名或者項目的代號。
nginx upstream 名稱下劃線問題
nginx upstream 中帶下劃線bug,前端會報400錯誤
參考URL: https://blog.csdn.net/u010953880/article/details/103484967
經過測試,發現nginx 在配置upstream的時候,
如果名字帶有下劃線,會導致前端返回400錯誤。
原因分析:
帶有下劃線的Host的http請求,tomcat認爲是有問題
那爲什麼之前版本的tomcat是正常的呢?
新版本的tomcat對這個頭部進行了校驗,舊版本沒有校驗。
好了,到這裏我們就知道了,其實對於帶有下劃線的Host,tomcat是遵循的RFC1-1034的規範的,所以tomcat的處理是正確的。
但是tomcat在處理某些其他合法的Host的時候歷史上出現過bug,但是對於下劃線的處理一直是正確的。
所以,以後nginx在配置upstream的時候不能使用帶有下劃線的名稱
nginx在沒有配置proxy_set_header HOST $host 的時候,在轉發http請求的時候會默認把upstream的名稱作爲Host頭部的內容。
也就是說新版的tomcat在接收Host爲sc_java(帶有下劃線)的http請求報了400錯誤
proxy_set_header HOST $host
這個配置是啥意思?
這個配置的主要是在nginx在轉發htp請求的時候會加上實際的Host請求頭。如http請求是 http://abc.com/hello,那麼nginx在轉發http請求的時候會原封不動的把host請求頭(Host:abc.com)轉發給後臺服務。對於nginx而言,如果沒有配置proxy_set_header HOST $host的時候會默認修改Host爲upstream的名稱。
六、參考
Nginx 負載均衡(簡單配置)
參考URL: https://blog.51cto.com/bilibili/2059677
使用 Nginx 配置負載均衡
參考URL: https://www.jianshu.com/p/19b1fdc3a469