[[394760]]

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

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

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

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

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

實現原理

1）優良性能依賴DPDK

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

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

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

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

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

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

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

12306的業務難點

• 動態庫存，余票可以按站點拆分
• 事務強一致，下單交易性質
• 多維度數據一致性，線上線下售票渠道
• 流量洪峰，遇節假日有流量洪峰

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

12306架構的發展歷程如下： 

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

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

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

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

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

百億紅包業務特點：

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

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

垂直SET化，分而治之

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

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

server層請求排隊

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

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

雙維度庫表設計

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

總結

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

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

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

什么是Service Mesh^[8]

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

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

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

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

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

結束語

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

Reference