柚子快報(bào)邀請(qǐng)碼778899分享：聊聊系統(tǒng)架構(gòu)之負(fù)載均衡優(yōu)化實(shí)踐

http://yzkb.51969.com/

一、寫(xiě)在前面

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

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

??

二、負(fù)載均衡

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

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

??

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

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

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

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

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

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

??

三、LB模式

LB模式含義有：

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

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

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

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

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

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

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

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

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

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

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

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

???

?場(chǎng)景二：?jiǎn)闻_(tái)機(jī)器HTTP請(qǐng)求域名時(shí)Read Timed Out異常

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

???

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

1) 、網(wǎng)絡(luò)問(wèn)題：首先，出現(xiàn)timeout的原因是因?yàn)檎?qǐng)求的域名下的某臺(tái)機(jī)器網(wǎng)絡(luò)存在問(wèn)題。

2)、長(zhǎng)連接機(jī)制：HttpClient默認(rèn)使用長(zhǎng)連接（Keep-Alive）的方式進(jìn)行通信。這種方式在大多數(shù)情況下可以提高性能，因?yàn)樗鼫p少了頻繁建立和斷開(kāi)連接的開(kāi)銷(xiāo)。然而，當(dāng)目標(biāo)服務(wù)器存在網(wǎng)絡(luò)問(wèn)題時(shí)，這種長(zhǎng)連接機(jī)制可能會(huì)導(dǎo)致持續(xù)的超時(shí)問(wèn)題。

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

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

五、寫(xiě)在最后

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

?

柚子快報(bào)邀請(qǐng)碼778899分享：聊聊系統(tǒng)架構(gòu)之負(fù)載均衡優(yōu)化實(shí)踐

http://yzkb.51969.com/

好文推薦