分布式 - 集群與負(fù)載均衡的算法與實(shí)現(xiàn)

學(xué)習(xí)完整課程請(qǐng)移步 互聯(lián)網(wǎng) Java 全棧工程師

負(fù)載均衡

什么是負(fù)載均衡呢?用戶輸入的流量通過負(fù)載均衡器按照某種負(fù)載均衡算法把流量均勻的分散到后端的多個(gè)服務(wù)器上,接收到請(qǐng)求的服務(wù)器可以獨(dú)立的響應(yīng)請(qǐng)求,達(dá)到負(fù)載分擔(dān)的目的。從應(yīng)用場(chǎng)景上來說,常見的負(fù)載均衡模型有全局負(fù)載均衡和集群內(nèi)負(fù)載均衡,從產(chǎn)品形態(tài)角度來說,又可以分為硬件負(fù)載均衡和軟件負(fù)載均衡。全局負(fù)載均衡一般通過DNS實(shí)現(xiàn),通過將一個(gè)域名解析到不同VIP,來實(shí)現(xiàn)不同的region調(diào)度能力;硬件負(fù)載均衡器常見的有F5、A10、Array,它們的優(yōu)缺點(diǎn)都比較明顯,優(yōu)點(diǎn)是功能強(qiáng)大,有專門的售后服務(wù)團(tuán)隊(duì),性能比較好,缺點(diǎn)是缺少定制的靈活性,維護(hù)成本較高;現(xiàn)在的互聯(lián)網(wǎng)更多的思路是通過軟件負(fù)載均衡來實(shí)現(xiàn),這樣可以滿足各種定制化需求,常見的軟件負(fù)載均衡有 LVS、Nginx、Haproxy。

image

阿里云高性能負(fù)載均衡使用 LVS 和 Tengine,我們?cè)谝粋€(gè) region 區(qū)分不同的機(jī)房,每個(gè)機(jī)房都有 LVS 集群和 Tengine 集群,對(duì)于用戶配置的四層監(jiān)聽,LVS 后面會(huì)直接掛載用戶 ECS,七層用戶監(jiān)聽 ECS 則掛載在 Tengine 上,四層監(jiān)聽的流量直接由 LVS 轉(zhuǎn)發(fā)到 ECS,而 7 層監(jiān)聽的流量會(huì)經(jīng)過 LVS 到 Tenigine 再到用戶 ECS。每一個(gè) region 里都會(huì)有多個(gè)可用區(qū),達(dá)到主備容災(zāi)目的,每一個(gè)集群里都有多臺(tái)設(shè)備,第一是為了提升性能,第二也是基于容災(zāi)考慮。

image

圖為高性能負(fù)載均衡控制管理概要圖,SLB 產(chǎn)品也有 SDN 概念,轉(zhuǎn)發(fā)和控制是分離的,用戶所有配置通過控制臺(tái)先到控制器,通過集中控制器轉(zhuǎn)換將用戶配置推送到不同設(shè)備上,每臺(tái)設(shè)備上都有 Agent 接收控制器下發(fā)的需求,通過本地轉(zhuǎn)換成 LVS 和 Tengine 能夠識(shí)別的配置,這個(gè)過程支持熱配置,不影響用戶轉(zhuǎn)發(fā),不需要 reload 才能使新配置生效。

LVS

LVS 支持的三種模式

image

早期 LVS 支持三種模式,DR 模式、TUN 模式NAT 模式。

DR 模式

DR 模式經(jīng)過 LVS 之后,LVS 會(huì)將 MAC 地址更改、封裝 MAC 頭,內(nèi)層 IP 報(bào)文不動(dòng),報(bào)文經(jīng)過 LVS 負(fù)載均衡查找到 RS 之后,將源 MAC 頭改成自己的,目的 MAC 改成 RS 地址,MAC 尋址是在二層網(wǎng)絡(luò)里,對(duì)網(wǎng)絡(luò)部署有一定的限定,在大規(guī)模分布式集群部署里,這種模式的靈活性沒有辦法滿足需求;

TUN 模式

TUN 模式走在 LVS 之后,LVS 會(huì)在原有報(bào)文基礎(chǔ)上封裝 IP 頭,到了后端 RS 之后,RS 需要解開 IP 報(bào)文封裝,才能拿到原始報(bào)文,不管是 DR 模式還是 TUN 模式,后端 RS 都可以看到真實(shí)客戶源 IP,目的 IP 是自己的 VIP,VIP 在 RS 設(shè)備上需要配置,這樣可以直接繞過 LVS 返回給用戶,TUN 模式問題在于需要在后端 ECS 上配置解封裝模塊,在 Linux 上已經(jīng)支持這種模塊,但是 Windows 上還沒有提供支持,所以會(huì)對(duì)用戶系統(tǒng)鏡像選擇有限定。

NAT 模式

NAT 模式用戶訪問的是 VIP,LVS 查找完后會(huì)將目的 IP 做 DNAT 轉(zhuǎn)換,選擇出 RS 地址,因?yàn)榭蛻舳说?IP 沒變,在回包的時(shí)候直接向公網(wǎng)真實(shí)客戶端 IP 去路由,NAT 的約束是因?yàn)?LVS 做了 DNAT 轉(zhuǎn)換,所以回包需要走 LVS,把報(bào)文頭轉(zhuǎn)換回去,由于 ECS 看到的是客戶端真實(shí)的源地址,我們需要在用戶 ECS 上配置路由,將到 ECS 的默認(rèn)路由指向 LVS 上,這對(duì)用戶場(chǎng)景也做了限制。

LVS 基于 NetFilter 框架實(shí)現(xiàn)

image

NetFilter 是 Linux 提供的網(wǎng)絡(luò)開放平臺(tái),基于平臺(tái)可以開發(fā)自己的業(yè)務(wù)功能模塊,早期好多安全廠商都是基于 NetFilter 做一些業(yè)務(wù)模型實(shí)現(xiàn),這種模型比較靈活,但通用模型里更多的是兼容性考慮,路徑會(huì)非常長;而且通用模型中沒辦法發(fā)揮多核特性,目前 CPU 的發(fā)展更多是向橫向擴(kuò)展,我們經(jīng)常見到多路服務(wù)器,每路上有多少核,早期通用模型對(duì)多核支持并不是特別友善,在多核設(shè)計(jì)上有些欠缺,導(dǎo)致我們?cè)谕ㄓ媚P蜕献鲆恍?yīng)用開發(fā)時(shí)的擴(kuò)展性是有限的,隨著核的數(shù)量越來越多,性能不增反降。

LVS 的改進(jìn)

image

早期模式的各種限制制約了我們的發(fā)展,所以我們首先做了 FullNAT,相比原來的 NAT 方式,F(xiàn)ullNAT 多了 SNAT 屬性,將客戶端的原 IP 地址作了轉(zhuǎn)換;其次,我們?cè)诓⑿谢献隽颂幚?,充分利用多核?shí)現(xiàn)性能線性提升;然后是快速路徑,我們?cè)谧鼍W(wǎng)絡(luò)轉(zhuǎn)發(fā)模型時(shí)很容易想到設(shè)計(jì)快速路徑和慢速路徑,慢速路徑更多是解決首包如何通過設(shè)備問題,可能需要查ACL或路由,需要判斷許多和策略相關(guān)的東西,后面所有報(bào)文都可以通過快速路徑轉(zhuǎn)發(fā)出去;還有指令相關(guān)優(yōu)化,利用因特爾特殊指令提升性能;另外針對(duì)多核架構(gòu),NUMA 多節(jié)點(diǎn)內(nèi)存訪問,通過訪問 Local 節(jié)點(diǎn)內(nèi)存可能獲得更好的延遲表現(xiàn)。

image

客戶端進(jìn)來 IP 首先訪問 LVS 的 VIP,原 IP 是客戶端的,目的 IP 是 LVS 的 VIP,經(jīng)過 FullNAT 轉(zhuǎn)換后,原 IP 變成 LVS 的 Local 地址,目的地址是 LVS 選擇出來的 RS 地址,這樣在 RS 回包時(shí)比較容易,只要路由可達(dá),報(bào)文一定會(huì)交到 LVS 上,不需要在 RS 上做特殊的配置。右面就是 DNAT + SNAT 轉(zhuǎn)換,報(bào)文就可以通過 LVS 轉(zhuǎn)發(fā)回客戶端,這種方式主要帶來應(yīng)用場(chǎng)景部署靈活性選擇。

image

通過并行化實(shí)現(xiàn)對(duì) LVS 性能的改善,性能沒有辦法得到線性提升更多的是因?yàn)槊織l路徑都需要訪問全局資源,就會(huì)不可避免引入鎖的開箱,另外,同一條鏈接上的報(bào)文可能分散在不同的核上,大家去訪問全局資源時(shí)也會(huì)導(dǎo)致 cache 的丟失。所以我們通過 RSS 技術(shù)把同一個(gè)五源組報(bào)文扔到同一個(gè) CPU 上處理,保證入方向的所有相同連接上的報(bào)文都能交給相同 CPU 處理,每個(gè)核在轉(zhuǎn)發(fā)出去時(shí)都用當(dāng)前 CPU 上的 Local 地址,通過設(shè)置一些 fdir 規(guī)則,報(bào)文回來時(shí)后端 RS 訪問的目的地址就是對(duì)應(yīng) CPU 上的 local 地址,可以交到指定的 CPU 上去處理,這樣一條連接上左右方向報(bào)文都可以交給同一個(gè) CPU 處理,將流在不同的 CPU 隔離開;另外,我們把所有配置資源包括動(dòng)態(tài)緩存資源在每個(gè) CPU 上作了拷貝,將資源局部化,這使整個(gè)流從進(jìn)入 LVS 到轉(zhuǎn)發(fā)出去訪問的資源都是固定在一個(gè)核上的本地資源,使性能達(dá)到最大化,實(shí)現(xiàn)線性提升。

改進(jìn)后的 LVS 表現(xiàn)如下:

  • 出于對(duì)容災(zāi)和性能提升的考慮,我們做了集群化部署,每個(gè) region 有不同機(jī)房,每個(gè)機(jī)房有多個(gè)調(diào)度單元,每個(gè)單元有多臺(tái) LVS 設(shè)備;
  • 每臺(tái) LVS 經(jīng)過優(yōu)化后,都能達(dá)到更高性能,大容量,單臺(tái) LVS 可以達(dá)到 4000W PPS600W CPS、單個(gè) group 可以到達(dá) 1億 并發(fā);
  • 支持 region、IDC、集群和應(yīng)用級(jí)的高可用;
  • 實(shí)現(xiàn)了防攻擊功能,并在原版 LVS 上提供了更豐富的功能,可以基于各個(gè)維度做管理控制,精確的統(tǒng)計(jì),流量的分析等。

Tengine

image

Tengine 在應(yīng)用過程中也遇到了各種問題,最嚴(yán)重的就是性能問題,我們發(fā)現(xiàn)隨著 CPU 數(shù)量越來越多,QPS 值并沒有線性提升;Nginx 本身是多 worker 模型,每個(gè) worker 是單進(jìn)程模式,多 worker 架構(gòu)做 CPU 親和,內(nèi)部基于事件驅(qū)動(dòng)的模型,其本身已經(jīng)提供了很高的性能,單核 Nginx 可以跑到 1W5~2W QPS。Nginx 往下第一層是 socket API,socket 往下有一層 VFS,再往下是 TCP、IP,socket 層比較薄,經(jīng)過量化的分析和評(píng)估,性能開銷最大的是 TCP 協(xié)議棧和 VFS 部分,因?yàn)橥介_銷大,我們發(fā)現(xiàn)橫向擴(kuò)展不行,對(duì)此,我們做了一些優(yōu)化。

七層反向代理的路徑更長,處理更復(fù)雜,所以它的性能比 LVS 低很多,我們比較關(guān)注單機(jī)和集群的性能,集群性能可以靠堆設(shè)備去解決,單機(jī)如果不提升,成本會(huì)一直增加,從性能角度來看,有以下的優(yōu)化思路和方向:

  • 基于 Kernel 做開發(fā),比如優(yōu)化協(xié)議棧;
  • 基于 AliSocket 的優(yōu)化,AliSocket 是阿里研發(fā)的高性能 TCP 協(xié)議棧平臺(tái),底層是 DPDK,它將資源做了局部化處理,報(bào)文分發(fā)不同核處理,性能非常出色;
  • HTTPS 業(yè)務(wù)越來越多,流量逐步遞增,我們采用硬件加速卡方式做一些加解密的性能提升,還有 HTTPS 的會(huì)話復(fù)用;
  • 基于 Web 傳輸層的性能優(yōu)化
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 摘要:2017阿里云網(wǎng)絡(luò)技術(shù)高峰論壇在線技術(shù)峰會(huì),阿里云衛(wèi)崢帶來題為高性能負(fù)載均衡設(shè)計(jì)與實(shí)現(xiàn)的演講。本文主要從早期...
    肆虐的悲傷閱讀 405評(píng)論 0 2
  • 轉(zhuǎn):http://kb.cnblogs.com/page/188170/ (一) 簡單理解四層和七層負(fù)載...
    菜鳥小玄閱讀 1,142評(píng)論 0 3
  • 本文部分觀點(diǎn)圖片采用于:http://chenx1242.blog.51cto.com 隨著智能機(jī)的逐漸普及,大量...
    BossHuang閱讀 3,399評(píng)論 0 16
  • 背負(fù)罵名與榮光,一生戎馬與輝煌,“兔死狗烹,鳥盡弓藏”,咸陽城內(nèi)收秦疆,烏江岸邊逼霸王,長安建漢統(tǒng)中華!一個(gè)不被父...
    回眸微笑閱讀 321評(píng)論 0 0
  • 14.1 基本概念 重載運(yùn)算符:至少含有一個(gè)類類型參數(shù),除函數(shù)調(diào)用運(yùn)算符外都不能含有默認(rèn)實(shí)參;優(yōu)先級(jí)、結(jié)合律、運(yùn)算...
    咸魚翻身ing閱讀 486評(píng)論 0 0

友情鏈接更多精彩內(nèi)容