負載均衡續：萬億流量場景下的負載均衡實踐

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

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

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

實現原理

1）優良性能依賴 DPDK

阿里的新一代負載均衡器是基於 DPDK[2] 來實現的。其優勢總結如下 *[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

[1] 支撐雙十一的高性能負載均衡: http://www.aliyunhn.com/Home/Article/detail/id/1643.html

[2] 一文讀懂 DPDK: https://cloud.tencent.com/developer/article/1198333

[3] DPDK 技術簡介: https://www.jianshu.com/p/86af81a10195

[4] 12306 互聯網售票系統的架構優化及演進: 鐵路計算機應用期刊

[5] 百億級微信紅包系統設計方案: https://www.infoq.cn/article/2017hongbao-weixin

[6] 抖音春晚幕後: https://www.volcengine.cn/docs/6360/67383

[7] 抖音春晚紅包百億互動量級背後: https://www.163.com/dy/article/G5N0AFOF0511FQO9.html

[8] 什麼是 Service Mesh: https://zhuanlan.zhihu.com/p/61901608

[9] Service Mesh Istio 架構解析: https://developer.aliyun.com/article/759790

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/KM686VV1KJgmsRoaTNgJ6w

猜你喜歡