第一次在生產(chǎn)環(huán)境同時面對LVS、Keepalived、HAProxy這三兄弟時很多人第一反應(yīng)是這仨不都是做負載均衡的嗎為什么一臺機器上要裝兩三個這個問題我當年也糾結(jié)了很久直到某個凌晨被線上告警炸醒——兩臺后端同時宕機Keepalived沒把VIP切走流量全部打到一臺半死的機器上我才真正明白它們根本不是競爭關(guān)系而是完全不同的三個角色。這篇文章就用我踩過的坑和實際在跑的生產(chǎn)配置把這幾個組件的分工、選型和避坑一次性說透。不管你是剛?cè)腴T要搭第一套高可用架構(gòu)還是已經(jīng)在維護線上環(huán)境想排查疑難問題這里面的內(nèi)容都應(yīng)該能幫到你。1. 先把三兄弟的分工一次說清楚1.1 用物流分揀中心理解三個角色先忘掉技術(shù)名詞想象一個大型物流分揀中心。貨車到了園區(qū)門口保安先看車牌和貨物類型能放行的直接放行到對應(yīng)月臺這是四層轉(zhuǎn)發(fā)只認網(wǎng)絡(luò)層和傳輸層的信息速度快到幾乎沒有存在感——這就是LVS的角色。園區(qū)里邊有個調(diào)度臺值班人員不僅看貨物類型還要看收件人地址、偏好甚至指定日期再決定送哪個倉庫這是七層分發(fā)功能強、能感知應(yīng)用層內(nèi)容——這就是HAProxy的角色。而保安和調(diào)度臺背后還有一套考勤和輪崗制度主值班員倒班時副值班員要無縫頂上這個保證“關(guān)鍵時刻有人管事”的機制——就是Keepalived。把這三個角色放到同一套架構(gòu)里分工就很清楚了LVS負責(zé)在數(shù)據(jù)鏈路層/網(wǎng)絡(luò)層把海量連接快速分散到多臺機器HAProxy負責(zé)在七層做精細化流量調(diào)度Keepalived則負責(zé)監(jiān)控并保證入口VIP不因為單點故障而失效。理解了這層關(guān)系你就不會糾結(jié)“能不能只用HAProxy不用LVS”這種問題了——當然能取決于你的規(guī)模和需求但你也得知道大流量場景下LVS那層“無狀態(tài)轉(zhuǎn)發(fā)”的動作HAProxy無論如何也替代不了。1.2 LVS四層轉(zhuǎn)發(fā)的效率之王LVS的全稱是Linux Virtual Server工作在四層支持TCP/UDP的負載均衡。它最核心的產(chǎn)品力是“快”。因為不需要解析HTTP頭部不需要維護復(fù)雜的會話狀態(tài)多數(shù)模式下LVS的轉(zhuǎn)發(fā)吞吐量可以做到逼近網(wǎng)卡物理上限。生產(chǎn)中最常用的是DR模式Direct Routing它的原理是客戶端請求到達LVS的VIP后LVS通過MAC地址把報文原封不動地發(fā)給選中的后端真實服務(wù)器后端處理完以后直接把響應(yīng)回給客戶端回程流量根本不再經(jīng)過LVS。這種“請求經(jīng)過、響應(yīng)不走”的方式讓LVS在巨大流量面前依然從容。DR模式雖然高效代價是配置有門檻。需要調(diào)整的不僅LVS本身還有后端兩臺真實服務(wù)器的內(nèi)核參數(shù)和回程路由壞消息是這部分網(wǎng)上資料很多都含糊其辭。我在生產(chǎn)里見過最典型的翻車現(xiàn)場realserver沒有抑制ARP導(dǎo)致VIP在局域網(wǎng)內(nèi)被真實服務(wù)器“搶答”客戶端訪問VIP時請求走到了其中一臺后端但LVS的轉(zhuǎn)發(fā)規(guī)則也好、健康檢查也好全部失效看起來就是集群時好時壞。所以提到LVS千萬不要只把它當一條ipvsadm命令來記它背后是一套需要配合內(nèi)核網(wǎng)絡(luò)策略的完整鏈路。1.3 Keepalived不是為了負載均衡是為了不宕機Keepalived這個命名本身就點出了它的核心任務(wù)讓服務(wù)“一直活著”。它基于VRRP協(xié)議實現(xiàn)高可用常見形態(tài)是一主一備兩臺機器綁定同一個VIP正常情況下VIP掛在主節(jié)點上主節(jié)點掛掉后備節(jié)點通過優(yōu)先級競選把VIP和對應(yīng)服務(wù)接管過來。它本身不做負載均衡決策只做一件事故障時保證VIP不丟、服務(wù)不中斷。理解Keepalived的關(guān)鍵在于“虛擬”二字。VIP不是物理網(wǎng)卡上的固定地址而是通過VRRP協(xié)議在兩臺機器之間“飄”的;客戶端感知不到這個漂移過程只知道自己訪問的IP一直有人在響應(yīng)。Keepalived除了漂移VIP還承擔(dān)對后端真實服務(wù)器的健康檢查任務(wù)在LVS場景下它會把多個real_server配置到一起哪個掛了就把它從轉(zhuǎn)發(fā)列表里摘掉恢復(fù)后自動加回。也就是說Keepalived其實干了兩件事管VIP漂移同時管后端狀態(tài)同步到轉(zhuǎn)發(fā)規(guī)則。1.4 HAProxy七層世界的規(guī)則處理器HAProxy是目前最流行的開源七層負載均衡器支持HTTP和TCP協(xié)議配置靈活內(nèi)置豐富的ACL規(guī)則、健康檢查和會話保持能力。很多中小團隊第一套高可用架構(gòu)就是“Keepalived HAProxy”前面Keepalived?；詈竺鍴AProxy把請求按域名、URI、Header甚至Cookie規(guī)則分發(fā)到后端。和LVS相比HAProxy能感知應(yīng)用層內(nèi)容可以做更細粒度的灰度發(fā)布、路徑路由、請求改寫這是四層轉(zhuǎn)發(fā)做不到的。HAProxy的快不僅體現(xiàn)在吞吐上還體現(xiàn)在它對連接的生命周期管理上。它把連接分成前端和后端來維護可以緩存空閑連接、限制慢客戶端占用資源降低“慢請求拖垮正常服務(wù)”的概率。但也正因為工作在七層HAProxy需要做更多的報文解析內(nèi)存占用和CPU開銷都要高于LVS。生產(chǎn)上很多團隊會在HAProxy前面再擋一層LVS就是為了讓七層機器盡量只干“精細活”海量連接交給四層去扛。到這里三者的位置基本清楚了Keepalived負責(zé)“活著”LVS負責(zé)“快”HAProxy負責(zé)“懂規(guī)則”。接下來真正的核心問題是這三者怎么排列組合才合理2. 架構(gòu)選型到底該用哪種組合2.1 雙節(jié)點起步Keepalived HAProxy 的高可用入口如果你的業(yè)務(wù)量目標是每日百萬級別以內(nèi)后端服務(wù)是HTTP接口且需要細粒度路由那么最經(jīng)典的組合就是兩臺HAProxy節(jié)點前面掛一個Keepalived漂移VIP后面接若干個應(yīng)用服務(wù)器。這個架構(gòu)的好處是簡單、直觀、好排查Keepalived配置只管VIP和健康檢查HAProxy只管轉(zhuǎn)發(fā)規(guī)則兩層互不干擾。出了問題無非就是看“是VIP沒飄成功”還是“轉(zhuǎn)發(fā)規(guī)則有問題”一條日志追到底。但這套架構(gòu)有一個容易被忽視的瓶頸——HAProxy本身的狀態(tài)。即使Keepalived健康檢查手段再豐富它也只能知道HAProxy進程還活著無法感知進程是否處于半死狀態(tài)比如處理線程卡死、accept隊列堆積、后端連接全滿。遇到這種“進程沒死但干活越來越慢”的情況Keepalived不會觸發(fā)切換用戶實際感受到的依然是故障。我以前就碰到過HAProxy的連接數(shù)被慢客戶端吃光進程還在但新請求全部排隊超時?；顧C制完全沒有反應(yīng)。所以用Keepalived做HAProxy的?；顣r健康檢查必須設(shè)計成“業(yè)務(wù)探活”不能只做進程級檢查。2.2 大流量入口雙LVS在前HAProxy在后當流量再往上走單靠HAProxy扛不住需要引入LVS做入口卸載。典型架構(gòu)是最前面兩臺LVS服務(wù)器跑Keepalived綁定VIP后面掛一組HAProxy集群也是兩臺或更多各自再接KeepalivedHAProxy再把流量分發(fā)給后端的應(yīng)用服務(wù)器?？蛻舳酥徽JVIPLVS把流量轉(zhuǎn)發(fā)到HAProxy節(jié)點HAProxy做完七層路由后再往后拋——兩層負載均衡各司其職HAProxy不會再被海量并發(fā)連接壓垮。很多朋友會問既然LVS都能扛住大量并發(fā)為什么HAProxy這層不干脆去掉答案在于“精細化”和“規(guī)模化”是兩條線。LVS的DR模式轉(zhuǎn)發(fā)效率極高但它只認IP和端口做不了“根據(jù)URI把流量切到不同版本的后端”這種需求。而HAProxy的ACL和調(diào)度策略非常成熟在七層灰度、多域名共存的環(huán)境下幾乎不可替代。所以這個組合不是冗余而是讓每層都只做自己擅長的事。如果你有跨機房容災(zāi)需求LVS在前也能更方便地和交換機策略聯(lián)動比如宣告VIP路由調(diào)試起來比HAProxy要平滑。2.3 選型決策的四個核心考量點第一看規(guī)模。日請求量在千萬級以內(nèi)QPS峰值幾千到幾萬單層HAProxy足夠不必硬上LVS。第二看流量特征。如果業(yè)務(wù)是長連接數(shù)據(jù)庫代理、WebSocket、TCP隧道四層負載更合適LVS或HAProxy的tcp模式都可以如果是HTTP短連接且要按域名和路徑分流必須上七層。第三看團隊運維水平。LVS的DR模式對網(wǎng)絡(luò)參數(shù)、后端系統(tǒng)配置的要求更高排錯時涉及tcpdump、ARP表、ipvs內(nèi)核表新手團隊貿(mào)然上LVS容易在細節(jié)上踩坑。第四看業(yè)務(wù)對故障恢復(fù)的要求。Keepalived能做到的切換時間通常2秒以內(nèi)LVSKeepalivedHAProxy這套架構(gòu)可以將切換做到秒級且?guī)缀鯚o感知但配置和測試成本也相應(yīng)增加。2.4 演進路線從小規(guī)模到大規(guī)模的平滑升級我的建議是不要一上來就上最重的方案而是隨著流量增長逐步演進出層次。初期使用單臺HAProxy做反代過段時間加一臺做Keepalived高可用業(yè)務(wù)快速增長、HAProxy成為瓶頸時在前面插入LVS卸載連接再往后如果有多活需求再在DNS或全局負載層引入多機房調(diào)度。每一次演進都應(yīng)該單一變更可回滾不追求一步到位。我見過團隊一開始就搭了三層負載均衡結(jié)果線上排故障時排查鏈路太長性能沒成為問題人的認知先成了瓶頸——架構(gòu)演進要跟著業(yè)務(wù)節(jié)奏走不是越復(fù)雜越好。3. 核心實操雙LVS Keepalived HAProxy架構(gòu)完整落地3.1 整體拓撲與角色分配為了講清楚落地細節(jié)我給出一個對應(yīng)章節(jié)2.2的參考拓撲生產(chǎn)完全可以照抄改IP。前面的兩臺LVS節(jié)點一臺MASTER一臺BACKUP跑VRRP綁定VIP后面兩臺HAProxy節(jié)點也組成一個VRRP組綁定后端VIP組再往后是兩臺Nginx應(yīng)用服務(wù)器。LVS通過DR模式把VIP上的80端口流量轉(zhuǎn)發(fā)給兩臺HAProxyHAProxy再按域名規(guī)則把請求分給Nginx。這樣任意一臺LVS或HAProxy宕機業(yè)務(wù)都不會中斷——LVS層面由Keepalived切換HAProxy層面由它自己的Keepalived切換。具體IP規(guī)劃如下VIP為192.168.1.100LVS主節(jié)點192.168.1.11LVS備節(jié)點192.168.1.12HAProxy節(jié)點分別192.168.1.21和192.168.1.22后端Nginx分別為192.168.1.31和192.168.1.32。所有機器在同一個二層網(wǎng)絡(luò)這是DR模式能工作的前提。生產(chǎn)環(huán)境如果跨VLANDR模式的廣播和ARP策略會變得很麻煩這也是為什么有些場景會改用NAT模式的原因。3.2 配置LVS節(jié)點上的Keepalived安裝Keepalived的過程這里不贅述yum或apt直接裝就行重點看keepalived.conf的寫法。以下是我的生產(chǎn)實例vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass yourpassword } virtual_ipaddress { 192.168.1.100/24 dev eth0 label eth0:0 } } virtual_server 192.168.1.100 80 { delay_loop 5 lb_algo wrr lb_kind DR protocol TCP # LVS會轉(zhuǎn)發(fā)流量到這組真實服務(wù)器也就是后面的HAProxy節(jié)點 real_server 192.168.1.21 80 { weight 1 HTTP_GET { url { path /healthz status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } real_server 192.168.1.22 80 { weight 1 HTTP_GET { url { path /healthz status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } }backup節(jié)點的配置只需要把state改成BACKUP、priority改成90其他保持一致。這里有兩個關(guān)鍵點lb_kind一定要寫DR否則LVS會走NAT模式轉(zhuǎn)發(fā)邏輯完全不同real_server的健康檢查建議用HTTP_GET而不要用TCP_CHECK因為TCP能連通不代表HAProxy真的能返回正常的業(yè)務(wù)響應(yīng)尤其要確保HAProxy上有/healthz這個探活地址并且該接口不依賴后端的數(shù)據(jù)庫或緩存否則容易出現(xiàn)“健康檢查跟著后端一起抖動”的連鎖問題。注意vrrp_instance中virtual_router_id必須兩機一致keepalived才能互相認出彼此是同一個VRRP組的成員不一致會導(dǎo)致兩邊都認為自己該持有VIP直接造成腦裂。authentication_pass這個參數(shù)也是寫錯了日志里會出現(xiàn)不斷的VRRP包校驗失敗。3.3 配置后端HAProxy節(jié)點的內(nèi)核網(wǎng)絡(luò)參數(shù)這一節(jié)是最容易翻車的也是LVS的DR模式之所以勸退很多新手的地方。DR模式下LVS轉(zhuǎn)發(fā)給后端的數(shù)據(jù)包目標MAC地址是后端網(wǎng)卡但目標IP依然是VIP192.168.1.100。后端收到這個包后如果按照正常工作流程本機網(wǎng)卡發(fā)現(xiàn)目標IP不是自己的IP比如本機只有192.168.1.21會直接把包丟棄——所以必須在每臺HAProxy節(jié)點上把VIP綁定到lo這塊虛擬網(wǎng)卡上ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up這里用了32位掩碼而不是常見的24位。原因很微妙如果掩碼是24位系統(tǒng)會認為整個192.168.1.0/24網(wǎng)段的流量都應(yīng)該通過lo轉(zhuǎn)發(fā)反而會干擾正常的東西向流量甚至路由決策用32位掩碼則只宣告VIP本身屬于本機精準且安全。光綁定地址還不夠必須抑制ARP響應(yīng)。如果不做后端節(jié)點會響應(yīng)客戶端發(fā)往VIP的ARP請求告訴“VIP在這臺機器上”流量就被引流到了某一臺后端LVS完全失去意義。需要在sysctl.conf中修改四個參數(shù)net.ipv4.conf.lo.arp_ignore 1 net.ipv4.conf.lo.arp_announce 2 net.ipv4.conf.all.arp_ignore 1 net.ipv4.conf.all.arp_announce 2執(zhí)行sysctl -p后再用arping或ip neigh看一遍VIP對應(yīng)的MAC地址確認它只在LVS主節(jié)點上。還有一個坑是回程路由。DR模式要求后端響應(yīng)直接返回給客戶端但后端本身并沒有VIP它響應(yīng)的源地址應(yīng)該是VIP所以必須添加一個路由確保發(fā)送給VIP所在網(wǎng)段的包通過本機lo處理route add -host 192.168.1.100 dev lo這三個步驟做完后端節(jié)點才算真正能接住LVS丟過來的流量。我當年遺漏了route add這一步結(jié)果是LVS不斷轉(zhuǎn)發(fā)、后端不斷丟包健康檢查還顯示正常因為健康檢查走的是單獨IP線上故障全靠用戶來報告狼狽極了。3.4 配置HAProxy的關(guān)鍵性能參數(shù)HAProxy的核心配置分成global、defaults、frontend、backend幾個塊。為了保證在高并發(fā)下不拖后腿我習(xí)慣在生產(chǎn)里這樣寫global maxconn 100000 nbproc 2 nbthread 4 pidfile /var/run/haproxy.pid defaults mode http timeout connect 5s timeout client 30s timeout server 30s timeout http-keep-alive 2s option httplog option forwardfor frontend main bind *:80 # 簡單按域名分流的例子 acl is_payment hdr_dom(host) -i pay.example.com use_backend payment_servers if is_payment default_backend web_servers backend payment_servers balance roundrobin option httpchk GET /healthz server web1 192.168.1.31:80 check inter 3s fall 3 rise 2 server web2 192.168.1.32:80 check inter 3s fall 3 rise 2 backend web_servers balance leastconn option httpchk GET /healthz server web1 192.168.1.31:80 check inter 3s fall 3 rise 2 server web2 192.168.1.32:80 check inter 3s fall 3 rise 2這里值得展開的是timeout與maxconn設(shè)置。前端和后端的timeout決不能照抄默認值必須結(jié)合業(yè)務(wù)特征設(shè)置。比如你的頁面偶爾有慢查詢超過30秒那server timeout設(shè)30s就太短會造成正常請求被斷開、用戶看到502但timeout設(shè)得過長又會導(dǎo)致大量慢連接占住進程資源。一個比較接地氣的做法是先看后端P99響應(yīng)時間再在這個基礎(chǔ)上加一倍作為server timeout參考值。maxconn同理100000這個值如果你們機器只有2C4G很可能內(nèi)存先爆掉實際應(yīng)該壓測后根據(jù)內(nèi)存使用率來反推。option forwardfor這行很容易被忽略但沒有它后端Nginx拿不到客戶端真實IP日志里全是HAProxy節(jié)點的地址排查訪問來源會非常痛苦。3.5 驗證與切換演練架構(gòu)搭完不是能通就收工一定要做幾輪故障演練。第一步在LVS主節(jié)點上執(zhí)行ip addr show確認VIP掛在eth0:0上在LVS備節(jié)點上執(zhí)行ipvsadm -L -n確認內(nèi)核轉(zhuǎn)發(fā)規(guī)則已經(jīng)從主節(jié)點同步過來。第二步模擬主節(jié)點宕機可以執(zhí)行systemctl stop keepalived來驗證VIP是否在3秒內(nèi)漂移到備份節(jié)點。第三步做真實流量測試用ab或wrk打壓力同時kill掉一臺HAProxy觀察業(yè)務(wù)中斷時間。我建議把這套演練寫成固定腳本每次架構(gòu)變更后都自動跑一遍。不要過度相信Keepalived本身任何VIP漂移機制的可靠性都必須在實際演練中驗證因為你不知道交換機上有沒有開啟STP、ARP緩存老化時間是多久等外部因素。生產(chǎn)中很多“Keepalived沒起作用”的案例并不是Keepalived的問題而是二層環(huán)境的變化導(dǎo)致VRRP報文或VIP的ARP廣播被交換機策略攔截了這些只有演練才能暴露。4. 生產(chǎn)環(huán)境避坑指南那些文檔里不會寫的坑4.1 最隱蔽的坑ARP表緩存和VIP位置漂移DR模式下客戶端訪問VIP時需要解析VIP的MAC地址。正常情況下VIP在LVS主節(jié)點上客戶端ARP表里記錄的就是LVS主節(jié)點網(wǎng)卡的MAC。主節(jié)點宕機后備節(jié)點廣播VRRP報文并接管VIP備節(jié)點會發(fā)送免費的ARP廣播來刷新客戶端的ARP表。但有些交換機或云網(wǎng)絡(luò)環(huán)境會把這種免費ARP包過濾掉客戶端依然往老MAC發(fā)請求結(jié)果就是VIP明明已經(jīng)漂移到備機線上還是大面積超時直到客戶的ARP表老化。這個問題在物理機之間可以用ping一個廣播地址來強制刷新但更穩(wěn)妥的做法是在Keepalived的配置里加上vrrp_skip_check_adv_addr和vrrp_strict參數(shù)的理解同時確認交換機的組播和未知單播洪泛策略放行了VRRP報文。云環(huán)境則更復(fù)雜因為很多云廠商的虛擬網(wǎng)絡(luò)不標準支持VRRP這也是我后來在云上更傾向用SLB而不是自建LVS的原因。4.2 Keepalived腦裂主備同時持有VIP腦裂是指主備兩臺機器同時認為自己是MASTER、同時持有VIP造成網(wǎng)絡(luò)上出現(xiàn)兩個相同IP的設(shè)備ARP混亂流量時好時壞非常隱蔽。誘發(fā)腦裂最常見的原因是VRRP組播報文被防火墻或安全組攔掉了主備之間收不到對方的hello包各自都認為對方掛了于是各自搶占VIP。解決思路有三個維度網(wǎng)絡(luò)層面放行VRRP協(xié)議Keepalived內(nèi)部增加對端檢查腳本外部用仲裁機制兜底。我目前在生產(chǎn)里比較務(wù)實的方案是給Keepalived加一個自定義的smtp或script告警一旦檢測到本機持有VIP但VIP無法正常提供服務(wù)比如調(diào)用本地健康檢查腳本失敗就主動降低本機優(yōu)先級并釋放VIP。這比指望防火墻規(guī)則永遠正確要可靠得多。4.3 HAProxy后端的連接堆積與排隊七層負載均衡還有一個獨特的坑連接隊列堆積。HAProxy的maxconn設(shè)得再大后端應(yīng)用服務(wù)器也有自己的TCP連接上限。當后端響應(yīng)變慢后端隊列滿了之后HAProxy會持續(xù)把新連接掛在自己的隊列里等待用戶感覺就像頁面卡死。這種現(xiàn)象在監(jiān)控圖上表現(xiàn)為HAProxy的qcur值一直往上爬。排查時先看HAProxy的統(tǒng)計頁通過stats socket或web界面找到qcur高、qmax大的實例和后臺server。生產(chǎn)上的處理手段一般分三步第一步臨時調(diào)低對應(yīng)后端的maxconn或調(diào)高后端的timeout server給后端喘息空間第二步定位后端變慢的原因通常是數(shù)據(jù)庫慢查詢、緩存穿透第三步在HAProxy上啟用排隊策略比如限制單IP最大連接數(shù)給慢客戶端單獨的池子避免正常請求被拖死。4.4 常見問題速查表故障現(xiàn)象可能原因排查命令/思路VIP通的但業(yè)務(wù)時好時壞ARP表緩存沖突VIP被多臺機器響應(yīng)ip neigh、arping 檢查VIP對應(yīng)MAC是否始終在LVS主節(jié)點LVS轉(zhuǎn)發(fā)但后端總丟棄請求realserver未綁定VIP或未加回程路由ifconfig lo:0、route -n 確認VIP綁定和路由Keepalived主備同時持有VIP組播被防火墻隔離vrid不一致tcpdump抓VRRP報文(224.0.0.18)檢查防火墻規(guī)則HAProxy健康檢查正常但轉(zhuǎn)發(fā)502后端超時或隊列滿看stats頁面的qcur/scur排查后端日志交換機斷網(wǎng)后VIP漂移失敗交換機STP收斂太慢或ARP緩存過大調(diào)整交換機端口fastport、恒定性ARP配置連接數(shù)增長但CPU不高負載不平衡未配置leastconn檢查backend的balance策略改為leastconn試試上面這個表是我自己實際排障記錄改寫的基本覆蓋了新手到中級運維最常遇到的問題。排查思路有個共同點先確認VIP在哪再確認轉(zhuǎn)發(fā)規(guī)則有沒有生效最后再往后端追不要一開始就在應(yīng)用日志里翻來翻去。這種分層排查的習(xí)慣比任何腳本都能更快幫你定位問題。5. 性能評估與架構(gòu)演進建議5.1 壓測思路與指標預(yù)期整套架構(gòu)落地后必須壓測拿到真實數(shù)據(jù)否則你根本不知道它在什么時候會崩。壓測我建議分三層做。第一層只壓LVS用tcpreplay或pktgen生成純TCP包觀察LVS節(jié)點的CPU和丟包率這一層的重點不是QPS而是吞吐bps和ppsLVS在純轉(zhuǎn)發(fā)時瓶頸通常是物理網(wǎng)卡和內(nèi)核協(xié)議棧而不是軟件本身。第二層壓LVSHAProxy用wrk或ab打HTTP請求觀察HAProxy節(jié)點的CPU、內(nèi)存、連接隊列重點指標是QPS、延遲和錯誤率。第三層全鏈路壓到后端Nginx拉上數(shù)據(jù)庫或緩存一起壓看整個架構(gòu)的瓶頸到底在哪一層。壓測過程中我發(fā)現(xiàn)一個很有意思的現(xiàn)象很多時候瓶頸不在LVS也不在HAProxy而是后端Nginx的keepalive連接數(shù)和單個進程的fd上限沒調(diào)好。用wrk測試時并發(fā)一上去后端日志馬上出現(xiàn)too many open files聯(lián)合創(chuàng)始人一晚上都在改ulimit——類似的坑現(xiàn)在如果你提前知道完全可以避免。5.2 流量再大之后從單集群到多活當單集群的容量逼近極限或者有跨機房容災(zāi)需求時架構(gòu)還得繼續(xù)進化。LVSKeepalived雖然能在單個集群內(nèi)做到秒級切換但跨機房就無能為力了。這時你會需要上層DNS、GSLB、云負載均衡或自建邊界集群來分流多個IDC。到了這個階段LVS和HAProxy仍然在單個機房內(nèi)部起到重要作用但全局調(diào)度已經(jīng)不屬于它們的職責(zé)范圍。我在規(guī)模增長過程中還發(fā)現(xiàn)LVS的VIP在單一集群里雖然好使但多機房場景下IP就變成了稀缺資源而且不同運維團隊對LVS的理解不一致也容易造成配置漂移。后期如果條件允許我會優(yōu)先考慮讓負載均衡團隊統(tǒng)一維護一套IaC模板用terraform或ansible把LVS、Keepalived、HAProxy的配置全部代碼化減少人為修改帶來的不可控風(fēng)險。這一點越早做越好別等到三十臺以上的機器再回頭改。5.3 架構(gòu)演進中值得保留的細節(jié)演進歸演進有三個基礎(chǔ)細節(jié)是我無論架構(gòu)怎么變都一直保留的一是所有健康檢查都必須走“業(yè)務(wù)探活”絕不能只看進程在不在二是所有VIP相關(guān)的ARP和路由變更都必須在變更前先宿主機演練不能被生產(chǎn)環(huán)境打臉三是壓測指標和監(jiān)控報警要一直保留原始版本的對比數(shù)據(jù)方便快速判斷流量模式是否發(fā)生了變化。這些習(xí)慣看似瑣碎但在故障面前它們比任何想象中的“架構(gòu)先進”都更能救你命。6. 寫在最后的一點個人體會負載均衡這套東西資料雖然多但真正能在生產(chǎn)里跑得穩(wěn)的組合往往是團隊對每一層職責(zé)邊界理解最透徹的組合。我自己踩過不少坑有的坑是因為配置參數(shù)少寫了一行有的坑是因為架構(gòu)順序沒想清楚有的坑則是被網(wǎng)上各種千篇一律的教程誤導(dǎo)照著抄卻沒驗證。如果你讀完這篇能記住三句話我會很滿足LVS解決并發(fā)吞吐問題HAProxy解決業(yè)務(wù)分發(fā)問題Keepalived解決故障高可用問題。搞清楚每一層解決什么問題選型就不會偏排障也不會手忙腳亂。最后再分享一個小技巧每次做架構(gòu)變更前先在本地用虛擬機關(guān)閉所有防火墻把LVS的轉(zhuǎn)發(fā)鏈路、Keepalived的VIP漂移、HAProxy的健康檢查全部實測一遍再復(fù)現(xiàn)一次故障切換確認無誤后再上生產(chǎn)——這套流程看上去麻煩但相比線上出一次故障的成本劃算太多了。