?

喬幫主

讀完需要

21

分鐘

速讀僅需 5 分鐘

導讀：本文摘自于阿里云 MVP、“喬幫主”喬銳杰所撰寫的《阿里云運維架構實踐秘籍》一書，我們發現常見負載均衡 LVS、Nginx、HAProxy、阿里云 SLB 及硬件負載均衡等，不同的負載均衡應用場景和功能上有很大區別，這取決于負載均衡底層的原理，原理不同導致了不同負載均衡應用場景、功能、性能的巨大差異。但萬變不離其宗，這些常見負載均衡可以按照底層原理進行歸類，相信通過本文內容會讓你有很大收獲。

作者簡介

? ?

喬銳杰 阿里云 MVP，江湖人稱“喬幫主”，阿里云資深架構師/技術專家。國內云端架構與運維實踐開拓者，曾主導過電商、金融、政府、視頻、游戲等領域千萬級云端架構，在云端分布式集群架構、云端運維、云端安全等方面有著豐富的實戰經驗。擔任黑客講師/Java 高級講師/Python 講師/運維高級講師/阿里云講師，從事過安全、研發、高級運維、架構師等大半個互聯網相關技術職位，現擔任駐云科技運維總監兼阿里云架構師。

1

? ?

常見負載均衡的分類

說到常見負載均衡的分類，我們先來看看什么是 OSI 七層模型。我們常說的二層/三層/四層交換機，就是基于 OSI 七層模型所對應的層來命名的。我剛開始接觸網絡設備的時候，第一次聽說二層交換機、三層交換機時，還以為交換機的硬件厚度有二層、有三層，后來才知道，其實是按照 OSI 七層模型來區別不同交換機的原理功能。OSI 七層模型主要作為一個通用模型來做理論分析，它是一個理論模型。而 TCP/IP 通信協議模型（四層）是互聯網的實際通信協議，兩者一般做映射對比及分析。

OSI 七層模型及對應的傳輸協議

而常見的負載均衡有很多，有出名的硬件負載均衡，如 F5、Netscaler；還有常見開源的負載均衡，比如 LVS、HAProxy、Nginx，甚至 Apache 也能做負載均衡（不推薦）。我們常說的七層負載均衡、四層負載均衡，也是基于 OSI 七層模型的。基于 OSI 七層模型的底層原理，我們把常見的負載均衡具體劃分為以下幾個類型：二層、三層、四層、七層。最后再加上一個除 OSI 七層模型以外的 DNS，通過 DNS 做負載均衡的場景也是非常常見的。

負載均衡的分類

當前二層、三層負載均衡的實現只有 LVS 能做到。而相比在四層、七層的負載均衡應用得要更為廣泛，比如硬件負載均衡、Nginx、HAProxy 熱門的中間件都支持四層、七層的負載均衡。

2

? ?

負載均衡開山鼻祖—LVS 的工作原理

前面已介紹了 LVS 的應用場景及特性，但在介紹二層/三層/四層/七層負載均衡對比之前，有必要說一下 LVS 的原理。在運維領域，相信大家對 LVS 并不陌生，幾乎提到負載均衡，提到運維，都會提到 LVS。在實際負載均衡實踐應用中，我看到了一些有意思的現象，接下來跟大家詳細分享一下相關的技術實踐。在此之前，先來看看負載均衡技術相關術語縮寫。

負載均衡技術相關術語縮寫

LVS 負載均衡技術的實現，主要由 IPVS 和 Ipvsadm 實現。

• IPVS：是 LVS 集群系統的核心部分，是基于 Linux Netfilter 框架實現的一個內核模塊，主要工作于內核空間的 INPUT 鏈上。其鉤子函數分別 HOOK 在 LOCAL_IN 和 FORWARD 兩個 HOOK 點。

需要特別注意的是，IPVS 是直接作用在內核空間進行數據包的修改及轉發的。而 Nginx/HAProxy 作用在用戶空間，這使得 LVS 的性能更為強悍（能夠趕上硬件負載均衡的性能），而 Nginx/HAProxy 根本不是一個量級。并且現在 IPVS 已經是 Linux 內核標準的一部分，在早期的 Linux 系統版本中，安裝 LVS 還需要重新編譯內核，當然現在已經不需要了。

內核LVS數據包流向

• Ipvsadm：而 Ipvsadm 是工作在用戶空間，主要用于用戶定義和管理集群服務的工具。所以實際在安裝配置 LVS 時，主要是安裝配置 Ipvsadm。比如在 Redhat 中安裝一條簡單命令來實現：

yum install ipvsadm

LVS 原理架構

在 Director Server 上，IPVS 虛擬出一個對外提供訪問的 IP 地址，用戶必須通過這個虛擬的 VIP 地址訪問服務器。由于 LVS 是采用 VIP（三層 IP 地址）作為請求入口的，這也是很多人喜歡把 LVS 統稱為 IP 負載均衡的原因，即也是三層負載均衡。但 LVS 有 DR/IP TUN/NAT3 種模式，每種模式的核心原理分別作用在二層/三層/四層，所以把 LVS 稱為二層/三層/四層負載均衡更為恰當些。

具體數據包的走向如下：

訪問請求首先經過 VIP 到達負載調度器的內核空間。

PREROUTING 鏈在接收到用戶請求后，會判斷目標 IP，確定是本機 IP，將數據包發往 INPUT 鏈。

當用戶請求到達 INPUT 時，IPVS 會將用戶請求和 Ipvsadm 定義好的規則進行對比。如果用戶請求的就是定義的集群服務，那么此時 IPVS 會強行修改數據包，并將新的數據包發往 POSTROUTING 鏈。

POSTROUTING 鏈接收數據包后發現目標 IP 地址剛好是自己的后端服務器，最終將數據包發送給后端的服務器。對于數據包的修改，基于修改方式的不同，形成了 LVS 的 3 種模式。

LVS 三種模式

3

? ?

二層負載均衡

當前的負載均衡界，只有 LVS 實現了二層負載均衡。所以二層負載均衡實踐主要為 LVS 的 DR 模式實踐。

二層負載均衡數據包走向原理

以下是對二層負載均衡數據包走向原理的詳細說明：

客戶端請求數據包報文的源地址是 CIP，目標地址是 VIP。

負載均衡會將客戶端請求數據包報文的源 MAC 地址改為自己 DIP 的 MAC 地址，目標 MAC 改為了 RIP 的 MAC 地址，并將此包發送給后端服務器。這里要求所有后端服務器和負載均衡所在服務器只能在一個 VLAN（局域網）里面，即不能跨 VLAN。根據二層原理我們可以看到，在后端服務器中能直接獲取客戶端的源 IP 地址，netstat -n 能直接查看客戶端請求通信的源 IP。示例代碼如下：># netstat -nActive Internet connections (w/o servers)Proto Recv-Q Send-Q Local Address Foreign Address Statetcp 0 0 192.168.3.33:80 47.100.187.71:13537 ESTABLISHEDtcp 0 0 192.168.3.33:80 115.29.209.104:49435 ESTABLISHEDtcp 0 0 192.168.3.33:80 115.19.244.124:45418 TIME_WAITtcp 0 0 192.168.3.33:80 115.29.233.224:59310 ESTABLISHED

后端服務器發現請求數據包報文中的目的 MAC 是自己，會將數據包報文接收下來。由于數據包的 MAC 地址被修改，因此后端服務器需要在 lo 網口綁定 VIP，這樣數據包才會有“歸屬感”。處理完請求報文后，將響應報文通過 lo 接口送給 eth0 網卡直接發送給客戶端。由于數據包由后端服務器直接返回給客戶端，因此也會要求后端服務器必須綁定公網 IP。

4

? ?

三層負載均衡

同樣，在當前負載均衡界，只有 LVS 實現了三層負載均衡。所以三層負載均衡實踐主要為 LVS 的 IP-TUN 模式實踐。

三層負載均衡數據包走向原理

以下是對三層負載均衡數據包走向原理的詳細說明：

客戶端請求數據包報文的源地址是 CIP，目標地址是 VIP。

負載均衡將客戶端請求數據包報文首部再封裝一層 IP 報文，將源地址改為 DIP，目標地址改為 RIP，并將此數據包發送給后端服務器。與二層負載均衡不同的是，包通信通過 TUNNEL 模式實現，因此不管是內網還是外網都能通信，所以不需要 LVS VIP 與后端服務器在同一個網段內，即能跨 VLAN。但三層負載均衡原理導致在后端服務器中不能直接獲取客戶端的源 IP 地址，netstat -n 能查看到的是和負載均衡的通信 IP。示例代碼如下：># netstat -nActive Internet connections (w/o servers)Proto Recv-Q Send-Q Local Address Foreign Address Statetcp 0 0 192.168.3.33:80 172.16.2.2:13537 ESTABLISHEDtcp 0 0 192.168.3.33:80 172.16.2.2:49435 ESTABLISHEDtcp 0 0 192.168.3.33:80 172.16.2.2:45418 TIME_WAITtcp 0 0 192.168.3.33:80 172.16.2.2:59310 ESTABLISHED

云訣竅?

TUNNEL 模式走的隧道模式，運維起來比較困難，在實際應用中不常用。

后端服務器收到請求報文后，會首先拆開第一層封裝，然后發現里面還有一層 IP 首部的目標地址是自己 lo 接口上的 VIP，所以會處理次請求報文，并將響應報文通過 lo 接口發送給 eth0 網卡直接發送給客戶端。

5

? ?

四層負載均衡

LVS 的 NAT 模式、阿里云的四層 SLB、Nginx/HAProxy 的四層，雖然都是四層負載均衡，但是它們的底層原理有很大差異，這就導致它們的功能特性也有很大區別。

5.2

? ?

LVS-NAT 下的四層負載均衡

四層負載均衡 LVS-NAT 數據包走向原理如下圖所示。以下是對四層負載均衡 LVS-NAT 數據包走向原理的詳細說明。

客戶端請求數據包報文的源地址是 CIP，目標地址是 VIP。

負載均衡將客戶端請求數據包報文的目標地址改為 RIP 地址，并將此數據包發送給后端服務器。同樣要求所有的后端服務器和負載均衡所在服務器只能在一個 VLAN（局域網）里面，即不能跨 VLAN。同樣，根據 LVS 的 NAT 模式修改數據包報文的原理，在后端服務器中能直接獲取客戶端的源 IP 地址，netstat -n 能直接查看客戶端請求通信的源 IP。

報文送到后端服務器后，目標服務器會響應該請求，并將響應數據包報文返還給負載均衡。每臺內部的后端服務器的網關地址必須是負載均衡所在服務器的內網地址，即要配置 SNAT，這樣數據包才能經過 LVS 返回給客戶端。

然后負載均衡將此數據包報文的源地址修改為本機并發送給客戶端。

四層負載均衡 LVS-NAT 數據包走向原理

云訣竅

我們可以看到，目標服務器處理完數據包返回給客戶端的時候，會經過 LVS，然后再把數據包回給客戶端。由此可以看到，LVS NAT 模式存在很大的性能瓶頸（就是在于 LVS 這一端），而相比于 DR 及 IP-TUN 模式，數據包后端服務器直接返回給客戶端就不存在這個問題。在實際運用中，我也遇到過這個真實的性能瓶頸案例。之前工作過的一家公司主要從事電商領域，在一年一度的雙十一備戰中，流量高峰期客戶端出現嚴重的卡頓、丟包和延時。當時負載均衡采用的就是 LVS 的 NAT 模式，我們發現高并發高流量模式下，內網的流量可達到千兆。那時緊急切換到 LVS DR 模式，故障很快消除了。

5.3

? ?

阿里云 SLB 下的四層負載均衡

阿里云四層負載均衡針對 LVS 的一些問題進行了定制和優化，新增轉發模式 FULLNAT。

阿里云四層負載均衡對 LVS 的優化

由此可見基于 LVS，阿里云四層負載均衡實現了跨 VLAN、具備防 DDoS 攻擊的能力、采用集群方式部署。這 3 個方面相比原生態的 LVS，功能上做了很大的改進。

云訣竅

實踐應用中，我們發現使用阿里云的四層負載均衡，數據包的走向跟后端的 ECS 有沒有綁定公網 IP 有直接關系（僅限經典網絡）。

• 當后端 ECS 不綁定公網的時候，負載均衡轉發數據包給后端 ECS。后端 ECS 處理完將返回數據包給負載均衡，負載均衡再返回數據包給客戶端。這種方式類似 LVS 的 NAT 模式。

• 當后端經典網絡的 ECS 綁定公網的時候（只有經典網絡的 ECS 綁定的公網 IP 會單獨分配公網網卡 eth1），負載均衡轉發數據包給后端 ECS。后端 ECS 處理完將數據包直接通過公網網卡返回給客戶端。這種方式類似 LVS 的 DR 模式。在 ECS 的公網網卡監控中看不到這塊的流量明細，這塊流量內容直接歸并到 SLB 中計算了。但我們通過 Zabbix 相關監控，可以看到 eth1 公網網卡流量，并能抓到相應明細。有時候實際公網網卡流量甚至遠遠超過公網帶寬峰值，由此可以看到，這部分返回給客戶端的數據包走公網網卡，不受后端 ECS 綁定的公網帶寬限制，且不納入 ECS 的流量計費，單獨放在 SLB 流量計費中了。

如果 ECS 有公網 IP 和私網 IP，禁用公網網卡就會影響負載均衡服務，因為在有公網網卡的情況下，默認路由會走公網，如禁用就無法回包，因此負載均衡服務會受影響。建議不要禁止，如一定要這么做，需要修改默認路由為私網才會不影響服務。但需要考慮業務是否對公網有依賴，如通過公網訪問 RDS 等。

7.1

? ?

Nginx/HAProxy 下的四層負載均衡

四層負載均衡 Nginx/HAProxy 數據包走向原理如下圖所示。以下是對四層負載均衡 Nginx/HAProxy 數據包走向原理的詳細說明。

四層負載均衡 Nginx/HAProxy 數據包走向原理

云訣竅

需要重點注意的是，這里已經跟 LVS 有本質的區別。LVS 的 NAT 模式對外是以虛擬 VIP 作為請求入口（IP 層為三層），然后在三層負載均衡的基礎之上用 IP+PORT 接收請求，再轉發到對應后端服務器，所以 LVS 的 NAT 模式是三層負載均衡+四層負載均衡。而 Nginx/HAProxy 的四層對外直接暴露的是 DIP+TCP/UDP IP 端口服務。

客戶端請求數據包報文的源地址是 CIP，訪問目標地址是 DIP+IP 端口。

負載均衡在用戶空間接收數據包，并且負載均衡和后端服務器發起新的 TCP 三次握手，建立新的 TCP 連接。所以這時候是負載均衡代替客戶端與后端發起新的 TCP 請求連接。請求數據包為一個新的請求數據包，報文的源地址是 DIP，目標地址是 RIP。所以在后端服務器中，netstat -n 查看到的是和負載均衡的通信 IP。但負載均衡和后端服務器是建立新的 TCP 連接，所以后端服務器和負載均衡所在服務器可以進行跨 VLAN（局域網）通信。

報文發送到后端服務器后，服務器響應該請求，并將響應數據包報文返還給負載均衡。相比 LVS 的 NAT 模式，Nginx/HAProxy 下的四層負載均衡無須將每臺內部的后端服務器的網關地址設為負載均衡所在服務器的內網地址，即無須配置 SNAT。因為是負載均衡和后端服務器建立了新的 TCP 連接，不必擔心數據包不會返回給負載均衡。

然后負載均衡將此數據包報文的響應內容進行重新打包并返回給客戶端。

6

? ?

七層負載均衡

在常見負載均衡分類中，其實應用最為廣泛的還是七層和四層負載均衡。而七層和四層負載均衡最主要的區別是，在七層負載均衡中能獲取用戶請求的 HTTP 頭信息。具體什么是 HTTP 頭信息，我們以 nginx.conf 配置中定義的 Nginx 日志文件的格式內容從側面進行說明：

log_format '$remote_addr - $remote_user [$time_local] "$request" ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent" "$http_x_forwarded_for"';

然后我們在對應的日志文件中可以看到具體客戶端的請求頭內容信息，如下：

45.127.220.171 - - [02/Dec/2018:14:10:17 +0800] "GET https://qiaobangzhu.cn ( https://qiaobangzhu.cn ) HTTP/1.1" 301 184 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"

可以看到在七層負載均衡中，我們能獲取客戶端訪問的 IP、HTTP 請求類型（GET/POST）、訪問的域名主機地址及請求的 URL 明細、瀏覽器的類型等，這便是 HTTP 請求頭信息。而七層負載均衡的原理就是根據 HTTP 請求頭來做判斷轉發，在七層負載均衡中應用最為廣泛的當數虛擬主機功能。其實虛擬主機功能的核心就是獲取 HTTP 請求頭中的 HOST 字段來對應匹配轉發。

七層負載均衡數據包走向原理

以下是對七層負載均衡數據包走向原理的詳細說明。

和 Nginx/HAProxy 的四層一樣，客戶端請求數據包報文的源地址是 CIP。只不過在實際應用中，這里訪問的目標地址并不是 DIP+IP 端口，而是 URL。

同樣和 Nginx/HAProxy 的四層一樣，負載均衡在用戶空間接收數據包，并且負載均衡和后端服務器發起新的 TCP 三次握手，建立新的 TCP 連接。所以這時候是負載均衡代替客戶端與后端發起新的 TCP 請求連接。請求數據包是新的，報文的源地址是 DIP，目標地址是 RIP，并且還有客戶端請求的目標 URL（這里可以看到，對于七層負載均衡，目標地址可能一直在變，但訪問的目標 URL 始終不變，除非修改了客戶端請求內容）。

報文送到后端服務器后，服務器響應該請求，并將響應數據包報文返還給負載均衡。跟 Nginx/HAProxy 一樣，這里無須額外配置后端服務器的網關，即 SNAT 相關配置。

然后負載均衡將此數據包報文的響應內容進行重新打包并返回給客戶端。

綜上所述，因為七層中能獲取應用層 HTTP 的請求內容，所以七層負載均衡有如下常見應用場景：

• 七層作用在 HTTP 應用層，所以七層的負載均衡只能跟 Tomcat、PHP 等 Web 服務做負載均衡。

• 可以根據請求的域名來做轉發。比如請求者訪問 A 域名，轉發到后端 A 服務器；請求訪問 B 域名，轉發到后端 B 服務器。這個功能，在七層叫虛擬主機功能，是七層應用中最為熱門的應用實踐。

• 可以根據請求的 URL 來做轉發。比如請求者訪問的 URL 包含 A 目錄，就轉發到 A 服務器；請求訪問的 URL 包含 B 目錄，就轉發到 B 服務器。

• 可以根據請求的瀏覽器類型來做轉發。比如請求者使用的瀏覽器類型是 Chrome，就轉發到 A 服務器；請求者使用的瀏覽器類型是 Firefox，就轉發到 B 服務器。

而四層只能獲取訪問的目標/源 IP 地址和端口。所以四層的負載均衡，單純地是將請求輪詢轉發到后端目標服務器。并不能跟七層一樣，做相應的邏輯判斷，然后最終再轉發給符合要求的后端目標服務器。相比七層，四層的應用場景包括：

• 對 MySQL、LDAP、Redis、Memcache 等四層應用做負載均衡。

• 對七層 HTTP 的 Web 類應用做負載均衡，如 Tomcat、PHP。

• 對七層 Nginx、HAProxy 的負載均衡做負載均衡（具體在實踐中，四層和七層怎么來搭配使用，詳見第二篇中負載均衡的相關章節）。

但四層中沒辦法跟七層一樣，做虛擬主機的應用。我曾經在面試中問過這個問題，就是 LVS 能不能識別域名來做轉發。比如請求者訪問 A 域名，轉發到后端 A 服務器；請求訪問 B 域名，轉發到后端 B 服務器。有意思的是，有一些經驗豐富的運維人員對這個問題還回答不出來，這就需要好好看一下底層原理和對應負載均衡的應用場景了。答案肯定是不行的，因為 LVS 在四層和二層，沒辦法識別封裝在七層中的數據包內容。再舉個七層負載均衡實踐的例子，要訪問我們駐云內部的某個系統，要求客戶端必須使用 Chrome 瀏覽器，可參考以下核心配置：

location / {if ( $http_user_agent !~ ^.Chrome/5|6. ){rewrite ^(.)$ https://qiaobangzhu.cn/error.html ( https://qiaobangzhu.cn/error.html ) permanent;}proxy_pass http://192.168.2.2:81/ ( http://192.168.2.2:81/ );proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}

實現的核心配置就是獲取七層頭信息里面的數據來做對比判斷，如果符合，執行對應的操作即可。這個是四層/二層負載均衡無法實現的功能。

7

? ?

負載均衡的“一次連接”和“兩次連接”核心總結

7.2

? ?

LVS 二層/四層的“一次連接”

LVS 的 DR 模式、NAT 模式對數據包的處理都僅做“一次連接”，即負載均衡對數據包僅做轉發。

LVS 的三次握手數據包走向

LVS 能夠做到“一次連接”的本質原因是 LVS 工作在內核空間。LVS3 種模式都是工作在內核空間，數據包的處理也僅在內核空間，這也是 LVS 輕量高效、高性能的最為本質的原因。

云訣竅?

LVS 能夠做到“一次連接”，所以通過四層 SLB，我們能直接在后端服務器 ECS 中 netstat -n 查看到客戶端通信的源 IP 地址。

LVS 請求數據包走向

7.3

? ?

Nginx/HAProxy 四層的“二次連接”

相比于 LVS，Nginx/HAProxy 四層要建立“二次連接”。

Nginx/HAProxy 四層三次握手數據包走向

客戶端在向負載均衡進行 TCP 三次握手后，負載均衡會馬上發起新的 TCP 連接，即為“二次連接”。由于是負載均衡與后端建立新的 TCP 三次握手及轉發客戶端請求的數據，所以在后端服務器 netstat -n 查看到的請求通信的 IP 是負載均衡的 IP。而相比于 LVS，Nginx/HAProxy 四層工作在用戶空間，對數據包的處理是在用戶空間完成的，數據包的流轉及處理過程增多，這也是 Nginx/HAProxy 的性能和達不到 LVS 這個量級的本質原因。

Nginx/HAProxy 請求數據包走向

? ?

Nginx/HAProxy 七層的“二次連接”

相比于 Nginx/HAProxy 四層的二次連接，而 Nginx/HAProxy 七層的二次連接有些不一樣。Nginx/HAProxy 四層的二次連接，是客戶端和負載均衡進行 TCP 三次握手后，負載均衡和后端服務器馬上進行新的 TCP 三次握手。而 Nginx/HAProxy 七層的二次連接，在客戶端和負載均衡進行 TCP 三次握手后，還需要等客戶端 Pushdata 傳輸數據，之后負載均衡和后端服務器才會建立新的 TCP 三次握手。由此可見，Nginx/HAProxy 四層的二次連接轉發效率會更高。加上 Nginx/HAProxy 七層會進行一些 Rewrite 規則的判斷，會損耗一些 CPU 和內存的性能。所以相較而言，Nginx/HAProxy 四層的性能要高許多。同樣，由于是負載均衡跟后端建立新的 TCP 三次握手及轉發客戶端請求的數據，所以在后端服務器 netstat -n 查看到的請求通信的 IP 是負載均衡的 IP。所以在后端服務器中，HTTP 頭的 remote_addr 雖然代表客戶端的 IP，但實際值是負載均衡的 IP。為了避免這個情況，七層負載均衡通常會增加一個叫作 x_forwarded_for 的頭信息，把連接它的客戶端 IP（上網機器 IP）加到這個頭信息里，這樣就能保障后端服務器可以獲取到客戶端真實的 IP。但實際上，我們會遇到后端服務器再把請求轉發給到下一個目標服務器的情況，即：“客戶端請求>>> Nginx >>> Nginx1 >>> Nginx2”的結構，我們在 Nginx1 服務器上通過 x_forwarded_for 的頭信息獲取到了客戶端的真實源 IP，那如何在 Nginx2 上進一步獲取客戶端的源 IP 呢？在 Nginx1 上的轉發規則中，配置如下代碼：

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

這樣會讓 Nginx1 轉發給后端 HTTP 頭中的 x_forwarded_for 信息中保存客戶的真實源 IP。

Nginx/HAProxy 七層三次握手數據包走向

云訣竅?

Nginx 七層能夠進行“二次連接”，所以通過七層 SLB，我們在后端服務器 ECS 中 netstat -n 查看到和后端服務器通信的 IP 為 SLB 的 IP 地址，而不能直接獲取客戶端通信的源 IP。

8

? ?

DNS 負載均衡

從 OSI 七層模型來看，DNS 的域名解析其實作用在第七層應用層。

DNS 請求流向

在圖中，本質上 DNS 的負載均衡還算不上七層負載均衡，因為 DNS 解析是在 TCP/IP 通信之前進行的。即如果在應用中用到了域名，需要先去請求 DNS 服務器獲得目標 IP 地址，才能建立 TCP/IP 通信。相較于應用廣泛的四層和七層的負載均衡，DNS 做負載均衡的場景就沒那么常見了。DNS 做負載均衡會帶來兩個很大的問題，兩個問題分別如下：

實踐中，通過 DNS 解析配置多個 A 記錄地址。不同的客戶端來請求 DNS，返回 A 記錄配置的不同的源 IP（也可以是負載均衡的 VIP 地址），從而達到負載均衡的效果。但我們發現，設置 DNS 的負載均衡，落到不同源 IP（也可以是負載均衡的 VIP 地址）的請求流量往往分布得很不均勻。有可能是某個后端地址的請求量很大，而另一個后端地址的請求量卻很小。

由于客戶端往往有 DNS 相應緩存，如若 DNS 解析的某個源 IP 服務異常，一般它不會主動剔除這個有異常的源 IP 解析。這可能會導致部分客戶的解析訪問還是這個有異常的服務地址。雖然現在 DNS 有智能解析的高級功能，能主動監測后端服務的可用性。但是我們唯一不能把控的就是客戶端的 DNS 緩存，大部分客戶端的電腦 DNS 都有緩存。有可能是 DNS 已經解析到最新的 IP，但這時候客戶端的 DNS 緩存還是會獲取解析到的舊的 IP，這會導致這個客戶端可能一段時間內一直解析訪問到那個有異常服務的 IP。

DNS 的負載均衡，一般在超大規模的應用中，特別是跨地域的分布式應用中運用得非常廣泛，常規的中小型、中大型應用，不是特別推薦嘗試 DNS 的負載均衡。DNS 作為負載均衡的應用場景將會在第二篇中詳細介紹。

9

? ?

總結

不同負載均衡的類型的功能特性匯總。

本文摘自于《阿里云運維架構實踐秘籍》，經出版方授權發布。

10

? ?

福利時間

推薦語：本書由阿里云 MVP、“喬幫主”喬銳杰所撰寫，是不可多得的運維架構技術實踐類書籍，集結了作者多年一線工作實踐經驗，也是目前市面上少有的在常見熱門開源技術的基礎之上，結合云平臺、云產品，系統性地講解云端網絡、云端負載均衡、云端存儲、云端緩存、云端數據庫、云端運維、云端監控、云端容器、云端自動化運維/云端 DevOps、云端安全、云端架構等技術的實踐圖書。書中總結及歸納了將近三十種實踐的云秘訣，為讀者在風起“云”涌的時代，提供過關斬將的“尚方寶劍”。

中生代技術聯合機械工業華章圖書給大家帶來福利。

《阿里云運維架構實踐秘籍》

推薦語：

送書規則：截止2020年5月15日13:30前在留言區，分享你在云技術方面的心得與踩坑經驗、或者對新技術的更新、迭代有何獨特的個人見解，精選留言點贊1-5名各送出此書一本。

注：獲得贈書資格的讀者須于8小時內聯系小編發送詳細收貨信息，逾期則視為主動放棄。

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

? ?END ? ?? #接力技術，鏈接價值#精彩推薦1.?GitHub在線開發工具上線，是時候卸載IDE了2.?阿里高級技術專家邱小俠：微服務架構的理論基礎 - 康威定律 3.?導致微服務失敗的 11 個原因 4.?Facebook和Google應該向新聞媒體付費？漫畫推薦1.?漫畫：程序員和產品經理撕得真是太太太太厲害了 2.?漫畫：程序員真的是太太太太太太太太難了！3.?漫畫：普通程序員 vs 優秀程序員 4.?漫畫：35歲的IT何去何從？ 5.?漫畫：從修燈泡來看各種 IT 崗位，你是哪一種？ 6. 漫畫：一批90后已經30歲了，更扎心的是…7. 圖解：這才是程序員加班的真正原因！8.?漫畫：中國互聯網往事(2000-2020)好文點個在看吧！

點擊閱讀原文可以薅當當羊毛哦

總結

以上是生活随笔為你收集整理的阿里云MVP乔帮主：五大类型负载均衡的原理场景详解（文末赠书）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。