[[394760]]

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

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

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

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

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

實現(xiàn)原理

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

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

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

2）應對ECMP重選導致的連接中斷

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

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

鐵路12306的負載均衡^[4]

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

12306的業(yè)務難點

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

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

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

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

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

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

微信紅包背后的負載均衡^[5]

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

百億紅包業(yè)務特點：

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

那么微信的紅包方案是怎么設計的

垂直SET化，分而治之

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

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

server層請求排隊

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

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

雙維度庫表設計

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

總結

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

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

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

什么是Service Mesh^[8]

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

Service Mesh下Istio的負載均衡^[9]

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

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

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

結束語

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

Reference