柚子快報邀請碼778899分享：聊聊系統(tǒng)架構(gòu)之負載均衡優(yōu)化實踐

http://yzkb.51969.com/

一、寫在前面

最近在進行線上監(jiān)控檢查時，我遇到了兩個超出預(yù)期的案例。首先，網(wǎng)關(guān)層的監(jiān)控數(shù)據(jù)與應(yīng)用實際監(jiān)控數(shù)據(jù)存在不一致性，尤其是max有較大的差異，詳見如下圖。其次在某個應(yīng)用中，通過httpclient請求某域名時發(fā)現(xiàn)只有一臺機器持續(xù)出現(xiàn)"Read timed out"的異常錯誤。

鑒于這種情況，我分析了客戶端請求到應(yīng)用集群之間的完整鏈路。用戶發(fā)起域名請求時，客戶端通過本地DNS（沒有解析記錄粥查詢，如權(quán)威DNS）發(fā)起查詢請求獲取域名關(guān)聯(lián)的VIP，接著發(fā)起到負載均衡LB的請求，LB接收到請求后，根據(jù)配置的LB策略（如輪詢、最小連接、IP源hash等）決定將請求轉(zhuǎn)發(fā)給后端的服務(wù)實例。后端服務(wù)器接收到請求后，應(yīng)用服務(wù)器處理請求并生成響應(yīng)數(shù)據(jù)，然后再逆向傳遞。

??

二、負載均衡

首先聊聊什么是負載均衡。負載均衡（LB，Load Balance)是一種技術(shù)解決方案，用來在多個資源（一般是服務(wù)器）中分配負載達到最優(yōu)資源使用，避免過載。最常見的LB是四層TCP負載和7層HTTP負載。四層負載均衡是基于IP+Port實現(xiàn)，通過網(wǎng)絡(luò)層的IP地址（VIP)，然后加上運輸層的端口號來決定哪些流量需要做負載均衡，主要工作是轉(zhuǎn)發(fā)，在接收到客戶端的流量以后通過修改數(shù)據(jù)包的地址信息將流量轉(zhuǎn)發(fā)到應(yīng)用服務(wù)呂。七層負載均衡器除了支持四層負載均衡以外，還要分析應(yīng)用層的信息，如HTTP協(xié)議URI或Cookie信息，可以理解應(yīng)用協(xié)議，七層負載均衡會與客戶端建立一條完整的連接并將應(yīng)用層的請求流量解析出來，再按照調(diào)度算法選擇一個應(yīng)用服務(wù)器，并與應(yīng)用服務(wù)器建立另外一條連接將請求發(fā)送過去，因此它主要工作是代理 。

?四層負載均衡：在傳輸層（即網(wǎng)絡(luò)層）對網(wǎng)絡(luò)流量進行負載均衡的一種手段

??

以常見的TCP為例，負載均衡設(shè)備在接收到第一個來自客戶端的SYN請求時，通過報文中的IP+Port根據(jù)預(yù)設(shè)的負載均衡算法（如輪詢、加權(quán)輪詢、最小連接等）選擇一個最佳的服務(wù)器，當(dāng)然在轉(zhuǎn)發(fā)時會修改報文中目標IP地址直接轉(zhuǎn)發(fā)給后端服務(wù)器。TCP的建連，是客戶端與服務(wù)器直接建立的，LB只是起到一個類似路由器轉(zhuǎn)發(fā)動作。

4層負載均衡主要通過檢查傳輸層的相關(guān)信息來源請求流量的轉(zhuǎn)發(fā)，性能較高，適應(yīng)于TCP/UDP等傳輸協(xié)議。然而，由于不了解應(yīng)用層信息，因此無法做到智能化的請求分發(fā)，只能基于基本信息進行轉(zhuǎn)發(fā)決策。

?七層負載均衡：在應(yīng)用層對網(wǎng)絡(luò)流量進行負載均衡的一種方案

?七層負載均衡，也稱為內(nèi)容交換，主要通過報文中真正有意義的應(yīng)用層內(nèi)容，加上負載均衡設(shè)備設(shè)置的服務(wù)器選擇方式，決定最終選擇的內(nèi)容服務(wù)器。以常見的TCP為例，LB設(shè)備如果要根據(jù)應(yīng)用層內(nèi)容選擇服務(wù)器，只能先代理最終的服務(wù)器和客戶端建立連接后才可能接受到客戶端發(fā)送的真正報文內(nèi)容，然后再根據(jù)報文中的特寫字段+LB設(shè)備設(shè)置的服務(wù)器選擇方式（如輪詢、加權(quán)輪詢、最小連接等），決定最終 選擇的內(nèi)部服務(wù)器。由此可見，LB和客戶端以及服務(wù)器會分別獨立建立TCP連接，與四層模式的LB相比 處理能力必然要低一些。

從技術(shù)原理上看，它可以對客戶端的請求和服務(wù)器的響應(yīng)進行任何意義上的修改，極大提高了應(yīng)用系統(tǒng)在網(wǎng)絡(luò)層的靈活性，另一方面就是安全性，特別是常見的SYN Flood攻擊，SYN攻擊可以在LB設(shè)備上截止，不會影響后臺服務(wù)器的正常運營；另外LB設(shè)備可以在七層層面設(shè)定多種策略，過濾特寫報文，例如SQL注入等應(yīng)用層面的特寫攻擊手段，從應(yīng)用層面進一步提高系統(tǒng)整體安全。由于深入到應(yīng)用層，對請求處理更加精細，但相應(yīng)地也會增加負載均衡的處理開銷。

下圖是經(jīng)典四層和七層架構(gòu)和解析包的關(guān)系。

??

三、LB模式

LB模式含義有：

?fullnat 代表dpdk+keepalive實現(xiàn)的4層tcp集群，負載均衡軟件為lvs

?nginx代表nginx實現(xiàn)的，可同時提供4層tcp和7層http服務(wù)，負載均衡軟件為jfe（基于nginx二次開發(fā)）

?ha代表haproxy實現(xiàn)的，可同時提供4層tcp和7層http服務(wù)，負載均衡軟件為haproxy.

這里強調(diào)一下實例冷備時，不同LB模式的影響。如果VIP的LB模式是fullnat，冷備時當(dāng)前已有的鏈接會立刻被斷開；其他模式如nginx、ha將不會轉(zhuǎn)發(fā)新的請求到冷備設(shè)備，但已建立的鏈接不影響，直至鏈接正常斷開為止。因此需要強調(diào)的，茵LB模式為fullnat，在冷備應(yīng)用實例后立即部署對業(yè)務(wù)會有短暫的影響，相反在fullnat模式下影響幾乎可以忽略不計。

??四層負載均衡（DR/FULLNAT）：基于DPDK的DLVS，DPDK全稱Data Plane Development Kit，是Intel提供的數(shù)據(jù)平面開發(fā)工具集，專注于網(wǎng)絡(luò)應(yīng)用中數(shù)據(jù)包的高性能處理，其提供基于TCP的應(yīng)用程序代理。

七層負載均衡（HA）： 基于HAProxy 二次開發(fā)，支持配置熱加載生效、單機QPS可達5w，其提供基于TCP和HTTP的應(yīng)用程序代理。

七層負載均衡（Nginx）：基于Nginx 二次開發(fā)，支持單元化、物理網(wǎng)關(guān)隔離、實例變更熱加載等功能，單機QPS可達3w，其提供基于TCP和HTTP的應(yīng)用程序代理。

對比項四層負載均衡（FULLNAT）七層負載均衡（HA）七層負載均衡（Nginx）產(chǎn)品定位·強大的四層處理能力 ·聚焦TCP協(xié)議 ·面向網(wǎng)絡(luò)層交付·強大的七層處理能力 ·聚焦HTTP應(yīng)用層協(xié)議 ·面向應(yīng)用層交付·強大的七層處理能力 ·聚焦HTTP、HTTPS應(yīng)用層協(xié)議 ·面向應(yīng)用層交付業(yè)務(wù)場景·低延遲（10ms）、高并發(fā)（1Wqps）、高帶寬（1Gbps）各類型業(yè)務(wù)·基于HTTP協(xié)議接口類業(yè)務(wù)（不適合需要HTTPS的WEB網(wǎng)頁類業(yè)務(wù)）·基于HTTP協(xié)議的WEB網(wǎng)頁類業(yè)務(wù)、尤其需要支持HTTPS訪問的業(yè)務(wù)

四、解決方案與調(diào)優(yōu)實踐

在之前的討論中，我已經(jīng)探討了負載均衡的核心概念、四層與七層LB的差異，以及LB模式。基于這些討論，本節(jié)重點關(guān)注如何通過具體的解決方案和調(diào)優(yōu)實踐來應(yīng)對線上監(jiān)控檢查中遇到的問題，包括風(fēng)關(guān)層與應(yīng)用層監(jiān)控數(shù)據(jù)不一致以及"Read timed out"異常。

?場景一：網(wǎng)關(guān)層的監(jiān)控數(shù)據(jù)與應(yīng)用實際監(jiān)控數(shù)據(jù)存在不一致性

前面已經(jīng)詳細分析了四層LB與七層LB的差異。對于不同的協(xié)議，在性能上TCP比HTTP快，畢竟7層監(jiān)聽經(jīng)過LVS后，還需要更長的鏈路，但不會達到max1kms的影響。那影響性能的另一個因素就是：運營商到集群的跨機房調(diào)用?？鐧C房調(diào)用會導(dǎo)致網(wǎng)絡(luò)延遲和穩(wěn)定性，由于物理距離的增加，數(shù)據(jù)在傳輸過程中經(jīng)過路由器和交換機數(shù)量增多，網(wǎng)絡(luò)RTT會顯著增加。上圖中的經(jīng)色箭頭就是調(diào)整同機房調(diào)用后的時刻，可以看到max性能顯著提升。

???

?場景二：單臺機器HTTP請求域名時Read Timed Out異常

在線上應(yīng)用環(huán)境中，通過HttpClient請求某個域名時，發(fā)現(xiàn)只有一臺機器持續(xù)出現(xiàn)“Read Timed Out”的異常錯誤。這種情況首先讓人疑惑的是，為什么只有一臺機器會遇到這個問題，而其他機器卻能正常工作？

???

經(jīng)過詳細的排查和分析，我發(fā)現(xiàn)了幾個關(guān)鍵因素導(dǎo)致了這個問題的出現(xiàn)：

1) 、網(wǎng)絡(luò)問題：首先，出現(xiàn)timeout的原因是因為請求的域名下的某臺機器網(wǎng)絡(luò)存在問題。

2)、長連接機制：HttpClient默認使用長連接（Keep-Alive）的方式進行通信。這種方式在大多數(shù)情況下可以提高性能，因為它減少了頻繁建立和斷開連接的開銷。然而，當(dāng)目標服務(wù)器存在網(wǎng)絡(luò)問題時，這種長連接機制可能會導(dǎo)致持續(xù)的超時問題。

3）、源地址Hash策略：根本原因在于集群負載均衡算法采用了源地址Hash策略。這種策略根據(jù)請求的源地址來分配請求到后端服務(wù)器，旨在保持客戶端與特定服務(wù)器的會話連續(xù)性。因此，如果某臺后端機器遇到了網(wǎng)絡(luò)問題，那么所有被路由到這臺機器的請求都會受到影響。（業(yè)務(wù)ip的數(shù)量小于或接近域名對應(yīng)的ip數(shù)量）

當(dāng)然解決方案很簡單。一方面設(shè)置合理的超時時間，調(diào)整負載均衡策略如輪詢最小連接等。

五、寫在最后

線上監(jiān)控當(dāng)發(fā)現(xiàn)問題解決問題后，追根溯源也是非常重要的。不能忽視線上的任何問題，無論它們是多少微小。每一個異常都有可能是更深層次問題的征兆。通過建立一套完善的監(jiān)控體系，實時捕捉異常數(shù)據(jù)，結(jié)合深入的技術(shù)分析和理解，就能夠及時定位問題并采取相應(yīng)措施。這不僅僅是為了解決眼前的問題，更是為了系統(tǒng)的長期健康和可持續(xù)發(fā)展。追蹤溯源的過程，雖然可能耗時費力，但它是確保我們服務(wù)可靠、穩(wěn)定和高效的基石。

?

柚子快報邀請碼778899分享：聊聊系統(tǒng)架構(gòu)之負載均衡優(yōu)化實踐

http://yzkb.51969.com/

好文推薦