本文整理自美團(tuán)點(diǎn)評(píng)技術(shù)沙龍第14期：美團(tuán)背后的故事－你不知道的美團(tuán)云。

美團(tuán)點(diǎn)評(píng)技術(shù)沙龍由美團(tuán)點(diǎn)評(píng)技術(shù)團(tuán)隊(duì)主辦，每月一期祝峻。每期沙龍邀請(qǐng)美團(tuán)點(diǎn)評(píng)及其他互聯(lián)網(wǎng)公司的技術(shù)專家分享來(lái)自一線的實(shí)踐經(jīng)驗(yàn)，覆蓋各主要技術(shù)領(lǐng)域次坡。

目前沙龍會(huì)分別在北京呼猪、上海和廈門等地舉行，要參加下一次最新沙龍活動(dòng)砸琅？趕快關(guān)注微信公眾號(hào)“美團(tuán)點(diǎn)評(píng)技術(shù)團(tuán)隊(duì)”宋距。

本期沙龍包括三場(chǎng)講座：美團(tuán)云Docker平臺(tái)、美團(tuán)云對(duì)象存儲(chǔ)系統(tǒng)症脂、美團(tuán)四層負(fù)載均衡網(wǎng)關(guān)MGW谚赎。其他幾場(chǎng)講座的圖文實(shí)錄會(huì)陸續(xù)發(fā)表，請(qǐng)繼續(xù)關(guān)注诱篷。

前言

在高速發(fā)展的移動(dòng)互聯(lián)網(wǎng)時(shí)代壶唤，負(fù)載均衡有著舉足輕重的地位，它是應(yīng)用流量的入口棕所，對(duì)應(yīng)用的可靠性和性能起著決定性的作用闸盔，因此負(fù)載均衡需要滿足高性能、高可靠?jī)蓚€(gè)特點(diǎn)琳省。MGW是美團(tuán)點(diǎn)評(píng)自研的一款四層負(fù)載均衡迎吵，主要用于替代原有環(huán)境的四層負(fù)載均衡LVS，目前處理著美團(tuán)點(diǎn)評(píng)數(shù)十 Gbps的流量针贬、上千萬(wàn)的并發(fā)連接击费。本文主要介紹MGW是如何實(shí)現(xiàn)高性能、高可靠的桦他。

什么是負(fù)載均衡蔫巩？

互聯(lián)網(wǎng)早期，業(yè)務(wù)流量比較小并且業(yè)務(wù)邏輯比較簡(jiǎn)單，單臺(tái)服務(wù)器便可以滿足基本的需求圆仔；但隨著互聯(lián)網(wǎng)的發(fā)展垃瞧，業(yè)務(wù)流量越來(lái)越大并且業(yè)務(wù)邏輯也越來(lái)越復(fù)雜，單臺(tái)機(jī)器的性能問(wèn)題以及單點(diǎn)問(wèn)題凸顯了出來(lái)荧缘，因此需要多臺(tái)機(jī)器來(lái)進(jìn)行性能的水平擴(kuò)展以及避免單點(diǎn)故障皆警。但是要如何將不同的用戶的流量分發(fā)到不同的服務(wù)器上面呢拦宣？

image.png

早期的方法是使用DNS做負(fù)載截粗，通過(guò)給客戶端解析不同的IP地址，讓客戶端的流量直接到達(dá)各個(gè)服務(wù)器鸵隧。但是這種方法有一個(gè)很大的缺點(diǎn)就是延時(shí)性問(wèn)題绸罗，在做出調(diào)度策略改變以后，由于DNS各級(jí)節(jié)點(diǎn)的緩存并不會(huì)及時(shí)的在客戶端生效豆瘫，而且DNS負(fù)載的調(diào)度策略比較簡(jiǎn)單珊蟀，無(wú)法滿足業(yè)務(wù)需求，因此就出現(xiàn)了負(fù)載均衡外驱。

image.png

客戶端的流量首先會(huì)到達(dá)負(fù)載均衡服務(wù)器育灸，由負(fù)載均衡服務(wù)器通過(guò)一定的調(diào)度算法將流量分發(fā)到不同的應(yīng)用服務(wù)器上面，同時(shí)負(fù)載均衡服務(wù)器也會(huì)對(duì)應(yīng)用服務(wù)器做周期性的健康檢查昵宇，當(dāng)發(fā)現(xiàn)故障節(jié)點(diǎn)時(shí)便動(dòng)態(tài)的將節(jié)點(diǎn)從應(yīng)用服務(wù)器集群中剔除瓦哎，以此來(lái)保證應(yīng)用的高可用。

image.png

負(fù)載均衡又分為四層負(fù)載均衡和七層負(fù)載均衡蒋譬。四層負(fù)載均衡工作在OSI模型的傳輸層，主要工作是轉(zhuǎn)發(fā)犯助，它在接收到客戶端的流量以后通過(guò)修改數(shù)據(jù)包的地址信息將流量轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器。

七層負(fù)載均衡工作在OSI模型的應(yīng)用層剂买，因?yàn)樗枰馕鰬?yīng)用層流量惠爽，所以七層負(fù)載均衡在接到客戶端的流量以后雷恃，還需要一個(gè)完整的TCP/IP協(xié)議棧倒槐。七層負(fù)載均衡會(huì)與客戶端建立一條完整的連接并將應(yīng)用層的請(qǐng)求流量解析出來(lái)，再按照調(diào)度算法選擇一個(gè)應(yīng)用服務(wù)器两残，并與應(yīng)用服務(wù)器建立另外一條連接將請(qǐng)求發(fā)送過(guò)去人弓，因此七層負(fù)載均衡的主要工作就是代理崔赌。

既然四層負(fù)載均衡做的主要工作是轉(zhuǎn)發(fā)，那就存在一個(gè)轉(zhuǎn)發(fā)模式的問(wèn)題县钥，目前主要有四層轉(zhuǎn)發(fā)模式：DR模式若贮、NAT模式谴麦、TUNNEL模式伸头、FULLNAT模式熊锭。

image.png

DR模式也叫作三角傳輸碗殷，通過(guò)修改數(shù)據(jù)包的目的MAC地址來(lái)讓流量經(jīng)過(guò)二層轉(zhuǎn)發(fā)到達(dá)應(yīng)用服務(wù)器，這樣應(yīng)用服務(wù)器就可以直接將應(yīng)答發(fā)給應(yīng)用服務(wù)器代乃，性能比較好搁吓。由于這種模式需要依賴二層轉(zhuǎn)發(fā)吭历，因此它要求負(fù)載均衡服務(wù)器和應(yīng)用服務(wù)器必須在一個(gè)二層可達(dá)的環(huán)境內(nèi)晌区，并且需要在應(yīng)用服務(wù)器上配置VIP。

NAT模式通過(guò)修改數(shù)據(jù)包的目的IP地址恼五，讓流量到達(dá)應(yīng)用服務(wù)器灾馒，這樣做的好處是數(shù)據(jù)包的目的IP就是應(yīng)用服務(wù)器的IP睬罗，因此不需要再在應(yīng)用服務(wù)器上配置VIP了傅物。缺點(diǎn)是由于這種模式修改了目的IP地址，這樣如果應(yīng)用服務(wù)器直接將應(yīng)答包發(fā)給客戶端的話，其源IP是應(yīng)用服務(wù)器的IP卒暂，客戶端就不會(huì)正常接收這個(gè)應(yīng)答也祠，因此我們需要讓流量繼續(xù)回到負(fù)載均衡诈嘿，負(fù)載均衡將應(yīng)答包的源IP改回VIP再發(fā)到客戶端奖亚，這樣才可以保證正常通信昔字，所以NAT模式要求負(fù)載均衡需要以網(wǎng)關(guān)的形式存在于網(wǎng)絡(luò)中首繁。

TUNNEL模式的優(yōu)缺點(diǎn)和DR是一樣的弦疮，并且TUNNEL模式要求應(yīng)用服務(wù)器必須支持TUNNEL功能胁塞。

FULLNAT模式是在NAT模式的基礎(chǔ)上做一次源地址轉(zhuǎn)換（即SNAT），做SNAT的好處是可以讓應(yīng)答流量經(jīng)過(guò)正常的三層路由回到負(fù)載均衡上无蜂，這樣負(fù)載均衡就不需要以網(wǎng)關(guān)的形式存在于網(wǎng)絡(luò)中了斥季，對(duì)網(wǎng)絡(luò)環(huán)境要求比較低累驮，缺點(diǎn)是由于做了SNAT，應(yīng)用服務(wù)器會(huì)丟失客戶端的真實(shí)IP地址躁锡。

image.png

下面詳細(xì)介紹一下FULLNAT模式。首先負(fù)載均衡上需要存在一個(gè)localip池蜡坊，在做SNAT時(shí)的源IP就是從localip池中選擇的秕衙。當(dāng)客戶端流量到達(dá)負(fù)載均衡設(shè)備以后据忘，負(fù)載均衡會(huì)根據(jù)調(diào)度策略在應(yīng)用服務(wù)器池中選擇一個(gè)應(yīng)用服務(wù)器勇吊，然后將數(shù)據(jù)包的目的IP改為應(yīng)用服務(wù)器的IP萧福。同時(shí)從localip池中選擇一個(gè)localip將數(shù)據(jù)包的源IP改為localip鲫忍，這樣應(yīng)用服務(wù)器在應(yīng)答時(shí)悟民，目的IP是localip，而localip是真實(shí)存在于負(fù)載均衡上的IP地址近忙，因此可以經(jīng)過(guò)正常的三層路由到達(dá)負(fù)載均衡及舍。由于FULLNAT比NAT模式多做了一次SNAT锯玛，并且SNAT中有選端口的操作攘残，因此其性能要遜色于NAT模式歼郭，但是由于其較強(qiáng)的網(wǎng)絡(luò)環(huán)境適應(yīng)性病曾，我們選擇了FULLNAT作為MGW的轉(zhuǎn)發(fā)模式知态。

為什么選擇自研四層負(fù)載均衡负敏？

選擇自研四層負(fù)載均衡的原因主要有兩個(gè)：第一個(gè)是考慮到硬件負(fù)載均衡成本比較高其做；第二個(gè)赁还，隨著美團(tuán)點(diǎn)評(píng)業(yè)務(wù)流量越來(lái)越大艘策，LVS出現(xiàn)了性能瓶頸以及運(yùn)維成本的上升問(wèn)題朋蔫。

硬件負(fù)載均衡成本問(wèn)題

1. 硬件成本：中低端硬件負(fù)載均衡價(jià)格在數(shù)十萬(wàn)驯妄，高端的上百萬(wàn)青扔，價(jià)格非常昂貴。當(dāng)我們需要組成一個(gè)高可用集群時(shí)缘屹，需要數(shù)臺(tái)機(jī)器轻姿，成本異常高踢代。
2. 人力成本：硬件負(fù)載均衡功能比較強(qiáng)大胳挎，配置比較靈活慕爬，這也導(dǎo)致在維護(hù)上医窿，我們需要一些經(jīng)過(guò)專業(yè)培訓(xùn)的人員姥卢，就增加了人力成本独榴。
3. 時(shí)間成本：當(dāng)使用的過(guò)程中遇到bug或者新需求需要廠商提供新版本的時(shí)候棺榔，我們需要經(jīng)過(guò)繁瑣的流程向廠商上報(bào)症歇，然后廠商再發(fā)布新版本供我們升級(jí)忘晤，時(shí)間周期非常長(zhǎng)德频，在高速發(fā)展的互聯(lián)網(wǎng)行業(yè)缩幸，這種周期是無(wú)法接受的。

LVS的性能問(wèn)題

最初美團(tuán)點(diǎn)評(píng)使用的是LVS+Nginx組成的負(fù)載均衡結(jié)構(gòu)，LVS做四層負(fù)載均衡课梳，Nginx做七層負(fù)載均衡暮刃，但是隨著美團(tuán)點(diǎn)評(píng)流量的高速增長(zhǎng)（幾個(gè)月內(nèi)無(wú)論新建連接數(shù)還是吞吐量都有三倍的增長(zhǎng)）椭懊，LVS故障頻發(fā)氧猬，性能上出現(xiàn)瓶頸盅抚，因此我們自研了一款高性能妄均、高可靠的四層負(fù)載均衡MGW來(lái)替換LVS丛晦。

MGW如何實(shí)現(xiàn)高性能

下面通過(guò)對(duì)比LVS的一些性能瓶頸來(lái)介紹MGW是如何實(shí)現(xiàn)高性能的。

中斷問(wèn)題以及協(xié)議棧路徑性能過(guò)長(zhǎng)問(wèn)題

中斷是影響LVS性能最重要的一個(gè)因素隙笆，假如我們一秒需要處理600萬(wàn)的數(shù)據(jù)包撑柔，每6個(gè)數(shù)據(jù)包產(chǎn)生一個(gè)硬件中斷的話铅忿，那一秒就會(huì)產(chǎn)生100萬(wàn)個(gè)硬件中斷檀训，每一次產(chǎn)生硬件中斷都會(huì)打斷正在進(jìn)行密集計(jì)算的負(fù)載均衡程序峻凫，中間產(chǎn)生大量的cache miss荧琼，對(duì)性能的影響異常大命锄。

同時(shí)由于LVS是基于內(nèi)核netfilter開發(fā)的一個(gè)應(yīng)用程序脐恩，而netfilter是運(yùn)行在內(nèi)核協(xié)議棧的一個(gè)鉤子框架被盈。這就意味著當(dāng)數(shù)據(jù)包到達(dá)LVS時(shí)只怎，已經(jīng)經(jīng)過(guò)了一段很長(zhǎng)的協(xié)議棧處理邓尤，但是這段處理對(duì)于LVS來(lái)說(shuō)都不是必需的汞扎，這也造成了一部分不必要的性能損耗澈魄。

image.png

針對(duì)這兩個(gè)問(wèn)題痹扇，解決方法是使用輪詢模式的驅(qū)動(dòng)以及做kernel bypass鲫构，而DPDK提供的用戶態(tài)PMD驅(qū)動(dòng)恰好可以解決這兩個(gè)問(wèn)題。DPDK在設(shè)計(jì)時(shí)使用了大量硬件相關(guān)特性比如numa炕吸、 memory channel算途、 DDIO等嘴瓤，對(duì)性能優(yōu)化非常大廓脆，同時(shí)提供了比較多網(wǎng)絡(luò)方面的庫(kù)停忿，可以大大減小開發(fā)難度席赂，提高開發(fā)效率颅停。因此選擇DPDK作為MGW的開發(fā)框架癞揉。

鎖

由于內(nèi)核是一個(gè)比較通用的應(yīng)用程序柏肪，因此它并沒(méi)有對(duì)一些特定場(chǎng)景做一些定制設(shè)計(jì)烦味，這就導(dǎo)致一些公共的數(shù)據(jù)結(jié)構(gòu)需要鎖的保護(hù)拐叉。下面介紹一下出現(xiàn)鎖的原因和MGW的解決方法。

image.png

首先介紹一下RSS（Receive Side Scaling），RSS是一個(gè)通過(guò)數(shù)據(jù)包的元組信息將數(shù)據(jù)包散列到不同網(wǎng)卡隊(duì)列的功能控汉，這時(shí)候不同的CPU再去對(duì)應(yīng)的網(wǎng)卡隊(duì)列讀取數(shù)據(jù)進(jìn)行處理姑子，就可以充分利用CPU資源谢翎。之前介紹MGW使用FULLNAT的模式森逮，F(xiàn)ULLNAT會(huì)將數(shù)據(jù)包的元組信息全部改變褒侧，這樣同一個(gè)連接闷供，請(qǐng)求和應(yīng)答方向的數(shù)據(jù)包有可能會(huì)被RSS散列到不同的網(wǎng)卡隊(duì)列中歪脏，在不同的網(wǎng)卡隊(duì)列也就意味著在被不同的CPU進(jìn)行處理硕糊，這時(shí)候在訪問(wèn)session結(jié)構(gòu)的時(shí)候就需要對(duì)這個(gè)結(jié)構(gòu)進(jìn)行加鎖保護(hù)。

解決這個(gè)問(wèn)題的方法有兩種舟误，一種就是在做SNAT選端口的時(shí)候姻乓，通過(guò)選擇一個(gè)端口lport0讓RSS(cip0, cport0, vip0, vport0) = RSS(dip0, dport0, lip0, lport0)相等嵌溢；另外一種方法就是我們?yōu)槊總€(gè)CPU分配一個(gè)localip，在做SNAT選IP的時(shí)候蹋岩，不同的CPU選擇自己的localip赖草，等應(yīng)答回來(lái)以后，再通過(guò)lip和CPU的映射關(guān)系剪个，將指定目的IP的數(shù)據(jù)包送到指定隊(duì)列上秧骑。

由于第二種方法恰好可以被網(wǎng)卡的flow director特性支持，因此我們選擇了第二種方法來(lái)去掉session結(jié)構(gòu)的鎖乎折。

image.png

flow director可以根據(jù)一定策略將指定的數(shù)據(jù)包送到指定網(wǎng)卡隊(duì)列绒疗，其在網(wǎng)卡中的優(yōu)先級(jí)要比RSS高，因此我們?cè)谧龀跏蓟臅r(shí)候就為每個(gè)CPU分配一個(gè)localip骂澄，比如為cpu0分配lip0吓蘑，為cpu1分配lip1，為cpu2分配lip2坟冲，為cpu3分配lip3磨镶。 當(dāng)一個(gè)請(qǐng)求包（cip0, cport0, vip0, vport0）到達(dá)負(fù)載均衡后，被RSS散列到了隊(duì)列0上樱衷，這時(shí)這個(gè)包被cpu0處理棋嘲。cpu0在對(duì)其做fullnat時(shí)，選擇cpu0自己的localip lip0矩桂，然后將數(shù)據(jù)包（lip0, lport0, dip0, dport0）發(fā)到應(yīng)用服務(wù)器沸移，在應(yīng)用服務(wù)器應(yīng)答后，應(yīng)答數(shù)據(jù)包（dip0, dport0, lip0,
lport0）被發(fā)到了負(fù)載均衡服務(wù)器侄榴。此時(shí)我們就可以在flow director下一條將目的IP為lip0的數(shù)據(jù)包送到隊(duì)列0的規(guī)則雹锣，這樣應(yīng)答數(shù)據(jù)包就會(huì)被送到隊(duì)列0讓cpu0處理。這時(shí)候CPU在對(duì)同一個(gè)連接兩個(gè)方向的數(shù)據(jù)包進(jìn)行處理的時(shí)候就是完全串行的一個(gè)操作癞蚕，也就不要再對(duì)session結(jié)構(gòu)進(jìn)行加鎖保護(hù)了蕊爵。

上下文切換

image.png

在設(shè)計(jì)時(shí)，希望控制平面與數(shù)據(jù)平面完全分離桦山，數(shù)據(jù)平面專心做自己的處理攒射，不被任事件打斷。因此將CPU分成兩組恒水，一組用作數(shù)據(jù)平面一組用做控制平面会放。同時(shí)，對(duì)數(shù)據(jù)平面的CPU進(jìn)行CPU隔離钉凌，這樣控制平面的進(jìn)程就不會(huì)調(diào)度到數(shù)據(jù)平面的這組CPU上面了咧最；對(duì)數(shù)據(jù)平面的線程進(jìn)行CPU綁定，這樣就可以讓每個(gè)數(shù)據(jù)線程獨(dú)占一個(gè)CPU御雕。 其他的控制平面的程序比如Linux kernel矢沿、 SSH等都跑在控制平面的這組CPU上。

MGW如何做到高可靠

下面從MGW集群酸纲、MGW單機(jī)以及應(yīng)用服務(wù)器層這三個(gè)層介紹MGW如何在每一層實(shí)現(xiàn)高可靠捣鲸。

集群的高可靠

image.png

MGW使用OSPF+ECMP的模式組成集群，通過(guò)ECMP將數(shù)據(jù)包散列到集群中各個(gè)節(jié)點(diǎn)上闽坡，再通過(guò)OSPF保證單臺(tái)機(jī)器故障以后將這臺(tái)機(jī)器的路由動(dòng)態(tài)的剔除出去摄狱，這樣ecmp就不會(huì)再給這臺(tái)機(jī)器分發(fā)流量脓诡，也就做到了動(dòng)態(tài)的failover。

image.png

傳統(tǒng)的ecmp算法有一個(gè)很嚴(yán)重的問(wèn)題媒役，當(dāng)集群中節(jié)點(diǎn)數(shù)量發(fā)生變化以后，會(huì)導(dǎo)致大部分流量的路徑發(fā)生改變宪迟，發(fā)生改變的流量到達(dá)其他MGW節(jié)點(diǎn)上時(shí)是找不到自己的session結(jié)構(gòu)的酣衷，這就會(huì)導(dǎo)致大量的連接出現(xiàn)異常，對(duì)業(yè)務(wù)影響很大次泽，并且當(dāng)我們?cè)趯?duì)集群做升級(jí)操作時(shí)會(huì)將每個(gè)節(jié)點(diǎn)都進(jìn)行一次下線操作穿仪，這樣就加重了這個(gè)問(wèn)題的影響。

一種解決方式是使用支持一致性hash的交換機(jī)意荤，這樣在節(jié)點(diǎn)發(fā)生變化的時(shí)候啊片，只有發(fā)生變化的節(jié)點(diǎn)上面的連接會(huì)有影響，其他連接都會(huì)保持正常玖像，但是支持這種算法的交換機(jī)比較少紫谷，并且也沒(méi)有完全實(shí)現(xiàn)高可用，因此我們做了集群間的session同步功能捐寥。

image.png

集群中每個(gè)節(jié)點(diǎn)都會(huì)全量的將自己的session同步出去笤昨，使集群中每個(gè)節(jié)點(diǎn)都維護(hù)一份全局的session表，因此無(wú)論節(jié)點(diǎn)變化以后流量的路徑以任何形式改變握恳，這些流量都可以找到自己的session結(jié)構(gòu)瞒窒，也就是說(shuō)可以被正常的轉(zhuǎn)發(fā)，這樣就可以在集群中節(jié)點(diǎn)數(shù)量發(fā)生變化時(shí)保證所有連接正常乡洼。

在設(shè)計(jì)的過(guò)程中主要考慮了兩個(gè)問(wèn)題：第一個(gè)是故障切換崇裁，第二個(gè)是故障恢復(fù)以及擴(kuò)容。

故障切換

image.png

在故障切換的問(wèn)題上束昵，我們希望在機(jī)器故障以后拔稳，交換機(jī)可以立刻將流量切到其他機(jī)器上，因?yàn)榱髁坎磺凶咂拊酰馕吨竭_(dá)這臺(tái)機(jī)器流量會(huì)被全部丟掉壳炎，產(chǎn)生大量丟包。經(jīng)過(guò)調(diào)研測(cè)試發(fā)現(xiàn)逼侦，當(dāng)交換機(jī)側(cè)全部使用物理接口并且服務(wù)器側(cè)對(duì)接口進(jìn)行斷電時(shí)匿辩，交換機(jī)會(huì)瞬間將流量切換到其他機(jī)器上。通過(guò)一個(gè)100ms發(fā)兩個(gè)包的測(cè)試（客戶端和服務(wù)端各發(fā)一個(gè)）榛丢，這種操作方法是0丟包的铲球。

由于故障切換主要依賴于交換機(jī)的感知，當(dāng)服務(wù)器上出現(xiàn)一些異常晰赞，交換機(jī)感知不到時(shí)稼病，交換機(jī)就無(wú)法進(jìn)行故障切換操作选侨，因此需要一個(gè)健康自檢程序，每半秒進(jìn)行一次健康自檢然走，當(dāng)發(fā)現(xiàn)服務(wù)器存在異常時(shí)就對(duì)服務(wù)器執(zhí)行網(wǎng)口斷電操作援制，從而讓流量立刻切走。

故障切換主要依賴于網(wǎng)口斷電操作并且網(wǎng)卡驅(qū)動(dòng)是跑在主程序里面的芍瑞，當(dāng)主程序掛掉以后晨仑，就無(wú)法再對(duì)網(wǎng)口執(zhí)行斷電操作了，因此為了解決這個(gè)問(wèn)題拆檬，主進(jìn)程會(huì)捕獲異常信號(hào)洪己，當(dāng)發(fā)現(xiàn)異常時(shí)就對(duì)網(wǎng)卡進(jìn)行斷電操作，在斷電操作結(jié)束以后再繼續(xù)將信號(hào)發(fā)給系統(tǒng)進(jìn)行處理竟贯。

經(jīng)過(guò)以上設(shè)計(jì)答捕，MGW可以做到升級(jí)操作0丟包，主程序故障0丟包屑那，其他異常（網(wǎng)線等）會(huì)有一個(gè)最長(zhǎng)500ms的丟包拱镐，因?yàn)檫@種異常需要靠自檢程序去檢測(cè)，而自檢程序的周期是500ms齐莲。

故障恢復(fù)與擴(kuò)容

image.png

無(wú)論是在進(jìn)行故障恢復(fù)還是擴(kuò)容操作痢站，都會(huì)導(dǎo)致集群節(jié)點(diǎn)數(shù)量發(fā)生變化，這樣也就會(huì)導(dǎo)致流量路徑發(fā)生變化选酗。當(dāng)變化的流量到達(dá)集群中原有的節(jié)點(diǎn)時(shí)阵难，因?yàn)樵泄?jié)點(diǎn)都維護(hù)著一個(gè)全局的session表，因此這些流量是可以被正常轉(zhuǎn)發(fā)的芒填；但是如果流量到達(dá)了新機(jī)器上呜叫，這個(gè)機(jī)器是沒(méi)有全局session表的，那么這部分流量就會(huì)全部被丟棄殿衰。為了解決這個(gè)問(wèn)題朱庆，MGW在上線以后會(huì)經(jīng)歷一個(gè)預(yù)上線的中間狀態(tài)，在這個(gè)狀態(tài)上闷祥，MGW不會(huì)讓交換機(jī)感知到自己上線了娱颊，這樣交換機(jī)也就不會(huì)把流量切過(guò)來(lái)。首先MGW會(huì)對(duì)集群中其他節(jié)點(diǎn)發(fā)送一個(gè)批量同步的請(qǐng)求凯砍，其他節(jié)點(diǎn)收到請(qǐng)求以后會(huì)將自己的session全量的同步到新上線的節(jié)點(diǎn)上箱硕，新上線節(jié)點(diǎn)在收到全部session以后才會(huì)讓交換機(jī)感知到自己上線，這時(shí)交換機(jī)再將流量切過(guò)來(lái)就可以正常被轉(zhuǎn)發(fā)出去了悟衩。

在這個(gè)過(guò)程中主要存在兩點(diǎn)問(wèn)題剧罩。
第一個(gè)問(wèn)題是，由于集群中并沒(méi)有一個(gè)主控節(jié)點(diǎn)來(lái)維護(hù)一個(gè)全局的狀態(tài)座泳，如果request報(bào)丟失或者session同步的數(shù)據(jù)丟失的話惠昔，那新上線節(jié)點(diǎn)就沒(méi)辦法維護(hù)一個(gè)全局的session狀態(tài)幕与。但是考慮到所有節(jié)點(diǎn)都維護(hù)著一個(gè)全局的session表，因此所有節(jié)點(diǎn)擁有的session數(shù)量都是相同的镇防，那么就可以在所有節(jié)點(diǎn)每次做完批量同步以后發(fā)送一個(gè)finish消息啦鸣，finish消息中帶著自己擁有的session數(shù)量。當(dāng)新上線節(jié)點(diǎn)收到finish消息以后来氧，便會(huì)以自己的session數(shù)量與finish中的數(shù)量做對(duì)比赏陵。當(dāng)達(dá)到數(shù)量要求以后，新上線節(jié)點(diǎn)就控制自己進(jìn)行上線操作饲漾。否則在等待一定的超時(shí)時(shí)間以后，重新進(jìn)行一次批量同步操作缕溉，直到達(dá)到要求為止考传。

另外一個(gè)問(wèn)題是在進(jìn)行批量同步操作時(shí)，如果出現(xiàn)了新建連接证鸥，那么新建連接就不會(huì)通過(guò)批量同步同步到新上線的機(jī)器上僚楞。如果新建連接特別多，就會(huì)導(dǎo)致新上線機(jī)器一直達(dá)不到要求枉层。因此泉褐，需要保證處于預(yù)上線狀態(tài)的機(jī)器能接收到增量同步數(shù)據(jù)，因?yàn)樾陆ㄟB接可以通過(guò)增量同步同步出來(lái)鸟蜡。通過(guò)增量同步和批量同步就可以保證新上線機(jī)器可以最終獲得一個(gè)全局的session表膜赃。

單機(jī)高可靠

image.png

在單機(jī)高可靠方面，MGW做了一個(gè)自動(dòng)化測(cè)試平臺(tái)揉忘，自動(dòng)化平臺(tái)通過(guò)連通性和配置的正確性來(lái)判斷一個(gè)測(cè)試用例是否執(zhí)行成功跳座，失敗的測(cè)試用例平臺(tái)可以通過(guò)郵件通知測(cè)試人員。在每次新功能迭代結(jié)束以后泣矛，都會(huì)將新功能的測(cè)試用例加到自動(dòng)化平臺(tái)里面疲眷，這樣在每次上線之前都進(jìn)行一次自動(dòng)化測(cè)試，可以大大避免改動(dòng)引發(fā)的問(wèn)題您朽。

在之前狂丝，每次上線之前都需要進(jìn)行一次手動(dòng)的回歸測(cè)試，回歸測(cè)試非常耗時(shí)并且很容易遺漏用例哗总，但是為了避免改動(dòng)引發(fā)新問(wèn)題又不得不做几颜，有了自動(dòng)化測(cè)試平臺(tái)以后，大大提高了回歸測(cè)試的效率和可靠性魂奥。

RS可靠性

節(jié)點(diǎn)平滑下線

image.png

在RS可靠性方面菠剩，MGW提供了節(jié)點(diǎn)平滑下線功能，主要是為了解決當(dāng)用戶需要對(duì)RS進(jìn)行升級(jí)操作時(shí)耻煤，如果直接將需要升級(jí)的RS下線具壮，那這個(gè)RS上存在的所有連接都會(huì)失敗准颓，影響到業(yè)務(wù)。此時(shí)如果調(diào)用MGW的平滑下線功能棺妓，MGW就可以保證此RS已有連接正常工作攘已，但不會(huì)往上面調(diào)度新的連接。當(dāng)所有已有連接結(jié)束以后怜跑，MGW會(huì)上報(bào)一個(gè)結(jié)束的狀態(tài)样勃，用戶就可以根據(jù)這個(gè)結(jié)束的狀態(tài)對(duì)RS進(jìn)行升級(jí)操作，升級(jí)后再調(diào)用上線接口讓這個(gè)RS器進(jìn)行正常的服務(wù)性芬。如果用戶平臺(tái)支持自動(dòng)化應(yīng)用部署峡眶，那就可以通過(guò)接入云平臺(tái)使用平滑下線功能，實(shí)現(xiàn)完全自動(dòng)化且對(duì)業(yè)務(wù)無(wú)影響的升級(jí)操作植锉。

一致性源IP Hash調(diào)度器

源IP Hash調(diào)度器主要是保證相同的客戶端的連接被調(diào)度到相同應(yīng)用服務(wù)器上辫樱，也就是說(shuō)建立一個(gè)客戶端與應(yīng)用服務(wù)器一對(duì)一的映射關(guān)系。普通的源IP Hash調(diào)度器在應(yīng)用服務(wù)器發(fā)生變化以后會(huì)導(dǎo)致映射關(guān)系發(fā)生改變俊庇，會(huì)對(duì)業(yè)務(wù)造成影響狮暑。

因此我們開發(fā)了一致性源IP Hash調(diào)度器，保證在應(yīng)用服務(wù)器集群發(fā)生變化時(shí)辉饱，只有發(fā)生變化的應(yīng)用服務(wù)器與客戶端的映射關(guān)系發(fā)生改變搬男，其他都是不變的。

image.png

為了保證流量的均衡彭沼，首先在hash環(huán)上分配固定數(shù)量的虛擬節(jié)點(diǎn)缔逛，然后將虛擬機(jī)節(jié)點(diǎn)均衡的重分布到物理節(jié)點(diǎn)上，重分布算法需要保證兩點(diǎn)：

1. 在物理節(jié)點(diǎn)發(fā)生變化時(shí)溜腐，只有少數(shù)虛擬節(jié)點(diǎn)映射關(guān)系發(fā)生變化译株，也就是要保證一致性Hash的基本原則。
2. 因?yàn)镸GW是以集群的形式存在的挺益，當(dāng)多個(gè)應(yīng)用服務(wù)器發(fā)生上線下線操作時(shí)歉糜，反饋到不同的MGW節(jié)點(diǎn)上就有可能會(huì)出現(xiàn)順序不一致的問(wèn)題，因此無(wú)論不同的MGW節(jié)點(diǎn)產(chǎn)生何種應(yīng)用服務(wù)器上下線順序望众，都需要保證最終的映射關(guān)系一致匪补，因?yàn)槿绻灰恢戮蛯?dǎo)致相同客戶端的連接會(huì)被不同的MGW節(jié)點(diǎn)調(diào)度到不同的應(yīng)用服務(wù)器上，也就違背了源IP Hash調(diào)度器的原則烂翰。

綜合以上兩點(diǎn)夯缺，Google Maglev負(fù)載均衡的一致性Hash算法是一個(gè)很好的例子，在paper中有詳細(xì)的介紹甘耿，這里就不過(guò)多討論了踊兜。

總結(jié)

經(jīng)過(guò)美團(tuán)點(diǎn)評(píng)以及美團(tuán)云的流量驗(yàn)證，MGW無(wú)論在傳統(tǒng)網(wǎng)絡(luò)環(huán)境還是overlay的大二層環(huán)境下都有出色的性能和穩(wěn)定性表現(xiàn)佳恬。在業(yè)務(wù)場(chǎng)景方面涵蓋數(shù)據(jù)庫(kù)業(yè)務(wù)捏境，千萬(wàn)級(jí)別的長(zhǎng)連接業(yè)務(wù)于游，嵌入式業(yè)務(wù)，存儲(chǔ)業(yè)務(wù)以及酒店垫言、外賣贰剥、團(tuán)購(gòu)等Web應(yīng)用業(yè)務(wù)。在業(yè)務(wù)需求快速變化的環(huán)境下筷频，MGW在不斷完善自身功能蚌成，在各種業(yè)務(wù)場(chǎng)景下都有良好的表現(xiàn)。 在未來(lái)的一段時(shí)間內(nèi)凛捏，MGW除了會(huì)完善四層的功能需求外担忧，也會(huì)考慮向七層方向發(fā)展。

參考資料

1. DPDK.
2. LVS.
3. Eisenbud D E, Yi C, Contavalli C, et al. Maglev: A Fast and Reliable Software Network Load Balancer.

個(gè)人介紹：

高廣超：多年一線互聯(lián)網(wǎng)研發(fā)與架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)坯癣，擅長(zhǎng)設(shè)計(jì)與落地高可用涵妥、高性能、可擴(kuò)展的互聯(lián)網(wǎng)架構(gòu)坡锡。

本文首發(fā)在 高廣超的簡(jiǎn)書博客 轉(zhuǎn)載請(qǐng)注明！