[[394760]]

在實際場景下，特別是萬億流量場景下，真實的負(fù)載均衡方案又是怎么做的呢。

本篇分別就淘寶雙11、春運(yùn)12306、微信紅包和抖音春晚紅包等場景在負(fù)載均衡方面的運(yùn)用進(jìn)行一些介紹和討論。

阿里雙11流量下的負(fù)載均衡^[1]

雙十一流量特點(diǎn)請求量巨大，脈沖式的。是對阿里生態(tài)鏈路上所有服務(wù)的考驗對負(fù)載均衡器的要求：

• 性能優(yōu)良：應(yīng)對雙11當(dāng)晚脈沖式的流量沖擊
• 服務(wù)穩(wěn)定：可用性高，以應(yīng)對設(shè)備和網(wǎng)絡(luò)的抖動
• 業(yè)務(wù)無感：順滑的自身升級和容災(zāi)切換 

實現(xiàn)原理

1）優(yōu)良性能依賴DPDK

阿里的新一代負(fù)載均衡器是基于DPDK^[3]

正是由于這些專門針對數(shù)據(jù)包的高性能支持，才得以實現(xiàn)性能優(yōu)良的負(fù)載均衡器來支撐多年雙11場景下的脈沖流量的壓力。

2）應(yīng)對ECMP重選導(dǎo)致的連接中斷

ECPM(Equal-CostMultipathRouting) 是一種最大限度利用最短路徑的等價多路徑路由算法。 

如上圖，SLB采用水平擴(kuò)展的集群部署，多臺服務(wù)器發(fā)布相同路由，在交換機(jī)處形成ECPM路由。以達(dá)到高可用的目的。但，在連接沒有同步之前，遇到服務(wù)器硬件或網(wǎng)絡(luò)異常，會使該服務(wù)器不可用，ECPM重選路由，會使連接到達(dá)其他服務(wù)器，導(dǎo)致已有連接中斷，造成用戶訪問異常。SLB使用了會話同步的機(jī)制來解決了升級與容災(zāi)場景下長連接中斷的問題。用組播技術(shù)解決會話同步機(jī)制中的機(jī)器上下線問題。詳細(xì)解釋參見文獻(xiàn)[1]。 

鐵路12306的負(fù)載均衡^[4]

12306大名鼎鼎，無需多介紹。其中很多的場景和技術(shù)都可以給我們做一些很好的參考。但只找到了16年發(fā)表的論文，沒有能了解到最新的架構(gòu)部署。

12306的業(yè)務(wù)難點(diǎn)

• 動態(tài)庫存，余票可以按站點(diǎn)拆分
• 事務(wù)強(qiáng)一致，下單交易性質(zhì)
• 多維度數(shù)據(jù)一致性，線上線下售票渠道
• 流量洪峰，遇節(jié)假日有流量洪峰

這里對前幾個問題就暫不討論，單說負(fù)載均衡在應(yīng)對流量洪峰時的作用。

12306架構(gòu)的發(fā)展歷程如下： 

由上圖可以看到，第一次優(yōu)化之前，幾乎全鏈路服務(wù)都出現(xiàn)了性能瓶頸，因為并發(fā)查詢導(dǎo)致查詢系統(tǒng)負(fù)載過高，用戶重試引發(fā)AS過載；AS阻塞導(dǎo)致響應(yīng)增加，引發(fā)WEB負(fù)載問題，線上壓力導(dǎo)致整個票務(wù)系統(tǒng)異常，進(jìn)而影響了線下購票渠道正常運(yùn)轉(zhuǎn)，直至鏈路雪崩。

第一次優(yōu)化后，引入排隊系統(tǒng)，不同車次使用不同隊列，已達(dá)到請求分流；且排隊系統(tǒng)采用了動態(tài)流量控制，根據(jù)各鐵路局客票中心處理速度，進(jìn)行控速請求下發(fā)；并進(jìn)行了客票網(wǎng)服務(wù)拆分，根據(jù)不同規(guī)則，使流量負(fù)載均衡。此次優(yōu)化讓12306順利度過了13年春運(yùn)。但隨著互聯(lián)網(wǎng)的高速發(fā)展，網(wǎng)上訂票人數(shù)不斷增加，目前的架構(gòu)已經(jīng)達(dá)到了帶寬、性能、穩(wěn)定性的瓶頸。因此第二次優(yōu)化如下：

本篇重點(diǎn)還是看負(fù)載均衡在業(yè)務(wù)場景下的實際作用，因此，其他優(yōu)化點(diǎn)就不做討論了。正是因為多維度，多層次的負(fù)載均衡，才使得12306能夠承載更高的流量沖擊（如果哪些同學(xué)有12306最新的部署架構(gòu)，希望能私信交流學(xué)習(xí)~）

微信紅包背后的負(fù)載均衡^[5]

2017年正月，微信公布用戶在除夕當(dāng)天收發(fā)微信紅包的數(shù)量——142億個，收發(fā)峰值已達(dá)到76萬每秒。

百億紅包業(yè)務(wù)特點(diǎn)：

• 不同于普通電商場景，一個群紅包就相當(dāng)于一個秒殺活動，并發(fā)要求更高
• 金融屬性，不允許數(shù)據(jù)出現(xiàn)一致性，安全級別要求更高。

那么微信的紅包方案是怎么設(shè)計的

垂直SET化，分而治之

如果采用普通的服務(wù)拆分和部署方式，由于需要鎖庫存來防止超發(fā)，海量的鎖競爭將對DB造成不可估量的壓力。及時是使用外部存儲的分布式鎖進(jìn)行前置壓力緩解，只是對壓力的轉(zhuǎn)移，而無法減少。

采用SET化部署的好處，就是同一個紅包只會被路由到同一個的SET內(nèi)，相當(dāng)于對龐大的洪流，進(jìn)行了reduce似的細(xì)小拆分，不同的SET之間互不影響，極大的減少了不同SET之間的資源壓力。(其實和阿里的RGCzone單元化部署原理差不多)

server層請求排隊

產(chǎn)生并發(fā)搶鎖的原因，是因為到達(dá)DB的請求可能是并發(fā)，如果可以保證到達(dá)DB的請求穿行，那就不存在并發(fā)了。 

首先，通過IDhash確保同一紅包的請求被分配到同一臺Server，然后再進(jìn)行單機(jī)紅包排隊，這樣，就可以保證同一紅包的請求順序的達(dá)到DB，從而減少DB搶鎖并發(fā)。

雙維度庫表設(shè)計

因為紅包數(shù)量巨大，單表數(shù)據(jù)達(dá)到一定程度就會出現(xiàn)性能問題；因此除了按紅包ID分庫分表，還按天進(jìn)行冷熱數(shù)據(jù)拆分，在保障數(shù)據(jù)可以優(yōu)雅遷移的前提下，保證了當(dāng)天的DB性能。而在查詢時，通過數(shù)據(jù)庫中間件，進(jìn)行庫表路由。

總結(jié)

從負(fù)載均衡的角度看紅包的架構(gòu)設(shè)計，可以看到，整個架構(gòu)設(shè)計可以理解為使用了三層負(fù)載均衡，首先是入口層，將流量進(jìn)行set拆分，達(dá)到整體SET集群的負(fù)載均衡；然后是server層，對紅包ID進(jìn)行業(yè)務(wù)邏輯Hash ,ID穿行的同時，達(dá)到server集群內(nèi)部的負(fù)載均衡；再有是DB層，通過雙維度庫表設(shè)計，在保障DB性能的同時達(dá)到數(shù)據(jù)訪問的負(fù)載均衡。 

抖音春晚紅包背后的負(fù)載均衡^[6][7]

前幾部分分別從網(wǎng)絡(luò)層、架構(gòu)層、內(nèi)部設(shè)計等角度闡述了負(fù)載均衡的實際運(yùn)用。而這里會著重介紹下抖音架構(gòu)中涉及到的下一代微服務(wù)技術(shù)Service Mesh在負(fù)載均衡上的優(yōu)勢。

什么是Service Mesh^[8]

為了解決端到端的字節(jié)碼通信問題，TCP協(xié)議誕生，讓多機(jī)通信變得簡單可靠；微服務(wù)時代，Service Mesh誕生，屏蔽了分布式系統(tǒng)的諸多復(fù)雜性，讓開發(fā)者可以回歸業(yè)務(wù)。 

Service Mesh下Istio的負(fù)載均衡^[9]

Istio 服務(wù)網(wǎng)格在邏輯上分為控制平面和數(shù)據(jù)平面兩部分。其中，數(shù)據(jù)平面由一組以Sidecar方式部署的智能代理(Envoy)組成，這些代理可以調(diào)節(jié)和控制微服務(wù)及Mixer之間所有的網(wǎng)絡(luò)通信。

Envoy 代理可以發(fā)出很多指標(biāo)和遙測數(shù)據(jù)，這些遙測數(shù)據(jù)發(fā)送到何處，取決于 Envoy 的配置.

Envoy作為代理，在網(wǎng)絡(luò)體系中扮演著中介的角色，可以為網(wǎng)絡(luò)中的流量管理添加額外的功能，包括提供安全性、隱私保護(hù)或負(fù)載策略等。在服務(wù)間調(diào)用的場景中，代理可以為客戶端隱藏服務(wù)后端的拓?fù)浼?xì)節(jié)，簡化交互的復(fù)雜性，并保護(hù)后端服務(wù)不會過載。并能發(fā)現(xiàn)集群中的所有成員，然后通過主動健康檢查來確定集群成員的健康狀態(tài)，并根據(jù)健康狀態(tài)，通過負(fù)載均衡策略決定將請求路由到哪個集群成員。

結(jié)束語

本篇從實踐的角度出發(fā)，挑選了四個最典型的案例，分別從網(wǎng)絡(luò)層、架構(gòu)層、微服務(wù)發(fā)展等方面闡述了負(fù)載均衡的實際運(yùn)用，希望能對大家的工作和學(xué)醫(yī)有所幫助~ 

Reference