阿里妹導(dǎo)讀：雙十一的零點(diǎn)，整個(gè)電商系統(tǒng)的請(qǐng)求速率到達(dá)峰值。如果將這些請(qǐng)求流量只分配給少部分 server，這些機(jī)器接收到的請(qǐng)求速率會(huì)遠(yuǎn)超過處理速率，新來的任務(wù)來不及處理，就會(huì)產(chǎn)生請(qǐng)求任務(wù)堆積。

今年的中間件性能挑戰(zhàn)賽就圍繞“挑戰(zhàn)雙11零點(diǎn)流量洪峰”展開。自2015年開始，中間件性能挑戰(zhàn)賽已經(jīng)成功舉辦了四屆，被歷年大賽選手稱為“中間件技術(shù)的風(fēng)向標(biāo)”。接下來，跟隨阿里巴巴中間件團(tuán)隊(duì)的郭浩，一起來圍觀賽題，解讀賽題。

在現(xiàn)代分布式應(yīng)用中，服務(wù)請(qǐng)求是由物理機(jī)或虛擬機(jī)組成的 server 池進(jìn)行處理的。 通常，server 池規(guī)模巨大且服務(wù)容量各不相同，受網(wǎng)絡(luò)、內(nèi)存、CPU、下游服務(wù)等各種因素影響，一個(gè) server 的服務(wù)容量始終處于動(dòng)態(tài)變動(dòng)和趨于穩(wěn)定的狀態(tài)，如何設(shè)計(jì)和實(shí)現(xiàn)這種系統(tǒng)的負(fù)載均衡算法是一個(gè)極具挑戰(zhàn)的難題。

自適應(yīng)負(fù)載均衡的需求背景

負(fù)載均衡有兩個(gè)主要目標(biāo)：

• 保持較短的請(qǐng)求響應(yīng)時(shí)間和較小的請(qǐng)求阻塞概率；
• 負(fù)載均衡算法的 overhead 在可控級(jí)別，不占用過多的 CPU 、網(wǎng)絡(luò)等資源。

自適應(yīng)負(fù)載均衡是指無論系統(tǒng)處于空閑、穩(wěn)定還是繁忙狀態(tài)，負(fù)載均衡算法都會(huì)自動(dòng)評(píng)估系統(tǒng)的服務(wù)能力，進(jìn)行合理的流量分配，使整個(gè)系統(tǒng)始終保持較好的性能，不產(chǎn)生饑餓或者過載、宕機(jī)。

這種算法對(duì)于現(xiàn)在的電商系統(tǒng)、數(shù)據(jù)中心、云計(jì)算等領(lǐng)域都很有必要，使用自適應(yīng)負(fù)載均衡能夠更合理的利用資源，提高性能。

對(duì)用戶而言，一旦產(chǎn)生任務(wù)堆積，請(qǐng)求會(huì)變慢甚至超時(shí)，體驗(yàn)嚴(yán)重下降，甚至導(dǎo)致服務(wù)不可用。而處理請(qǐng)求的機(jī)器也會(huì)由于堆積的任務(wù)越來越多而發(fā)生嚴(yán)重過載，直到被打垮。剩余的尚未宕機(jī)的其它機(jī)器會(huì)逐漸重復(fù)這個(gè)過程，直至整個(gè)應(yīng)用不可用，發(fā)生系統(tǒng)故障。

為了避免這種情況發(fā)生，我們可能會(huì)想到一種常用的辦法：在服務(wù)上線前提前進(jìn)行壓測(cè)，使用壓測(cè)的容量作為限流值，當(dāng)線上服務(wù)的請(qǐng)求速率大于限流值的時(shí)候，服務(wù)拒絕新到的服務(wù)，從而保障服務(wù)始終可用。但是這種方式也存在問題：壓測(cè)時(shí)測(cè)試的容量進(jìn)行限流通常會(huì)趨于保守，不能充分發(fā)揮異構(gòu)系統(tǒng)的全部性能；也無法智能地應(yīng)對(duì)由于網(wǎng)絡(luò)、下游服務(wù)變化而導(dǎo)致的容量下降等問題，系統(tǒng)仍然存在宕機(jī)風(fēng)險(xiǎn)。

因此，我們需要具備自適應(yīng)能力的負(fù)載均衡算法，來更好地進(jìn)行流量分配調(diào)度以及穩(wěn)定性保障，追求極致性能，挑戰(zhàn)大促等場(chǎng)景下的流量洪峰。

結(jié)合中間件性能挑戰(zhàn)賽的賽題

我們結(jié)合「第五屆中間件性能挑戰(zhàn)賽」中的初賽場(chǎng)景，來一起探討一下設(shè)計(jì)和實(shí)現(xiàn)一個(gè)自適應(yīng)的負(fù)載均衡的基本思路。

本次挑戰(zhàn)賽的場(chǎng)景由施壓程序(阿里云性能測(cè)試PTS)、服務(wù)調(diào)用方(Consumer)和三個(gè)規(guī)格不同的服務(wù)提供方(Provider) 組成。在評(píng)測(cè)過程中，每個(gè)程序都部署在不同的物理機(jī)上，以避免因 CPU、網(wǎng)絡(luò)資源的競(jìng)爭(zhēng)，導(dǎo)致評(píng)測(cè)程序抖動(dòng)，影響最終評(píng)測(cè)成績(jī)。

Becnhmarker 負(fù)責(zé)請(qǐng)求 Consumer, Consumer 收到請(qǐng)求后，從三臺(tái)物理規(guī)格不同、服務(wù)響應(yīng)時(shí)間和最大并發(fā)都不同的 Provider 中選擇一個(gè)進(jìn)行調(diào)用并返回結(jié)果。選擇哪一個(gè) Provider 進(jìn)行調(diào)用的流程就是本次挑戰(zhàn)賽需要實(shí)現(xiàn)的負(fù)載均衡算法。

為了簡(jiǎn)化環(huán)境部署和提升性能，本次挑戰(zhàn)賽沒有使用服務(wù)注冊(cè)和發(fā)現(xiàn)機(jī)制。三個(gè) Provider 對(duì)應(yīng)的 URL 都已經(jīng)被直接配置在了 Consumer 中，選手在開發(fā)和測(cè)試時(shí)可直接通過 Provider-small 等 hostname 訪問相應(yīng)的 Provider。

賽題分析

題目描述很簡(jiǎn)單，不考慮 Consumer 直接拒絕的情況下，場(chǎng)景可以簡(jiǎn)化為 3 選 1 的問題，但如何進(jìn)行這個(gè)決策則是本次挑戰(zhàn)賽考察的難點(diǎn)和重點(diǎn)。

官方題目組提供了 Random 算法作為默認(rèn)實(shí)現(xiàn)：從 3 個(gè) Provider 中隨機(jī)取任意一個(gè)。對(duì)于單 dispatcher （在本次賽題中是 Consumer) 同構(gòu)系統(tǒng)的場(chǎng)景，Random可以達(dá)到漸近負(fù)載均衡， 每個(gè) Provider 接收到的總請(qǐng)求數(shù)接近。但是對(duì)于多 dispatcher 或異構(gòu)系統(tǒng)而言，Random 算法由于缺少全局狀態(tài)，無法保證全局隨機(jī)，極端條件下，多個(gè) dispatcher 可能將請(qǐng)求同時(shí)分配到一臺(tái) Provider 上，導(dǎo)致系統(tǒng)存在服務(wù)過載和宕機(jī)的風(fēng)險(xiǎn)；異構(gòu)系統(tǒng)中，不同 Provider 服務(wù)容量實(shí)際是不同的，即使每個(gè) Provider 請(qǐng)求速率相同也會(huì)產(chǎn)生空閑、穩(wěn)定、過載等不同的服務(wù)狀態(tài)，無法實(shí)現(xiàn)最優(yōu)流量分配，更不能做到響應(yīng)時(shí)間最小。顯而易見，Random 并不是符合賽題要求的自適應(yīng)算法。

那么，如何實(shí)現(xiàn)自適應(yīng)負(fù)載均衡呢？接下來我們將利用題目給出的條件由淺入深的描述這個(gè)算法的設(shè)計(jì)過程。

自適應(yīng)算法首先要解決如何對(duì)服務(wù)進(jìn)行容量評(píng)估的問題。

本次比賽按照硬件規(guī)格不同，Provider 被分為 small、medium、和 large 三種，CPU 和內(nèi)存對(duì)應(yīng)的比例為 1:2:3 。在評(píng)測(cè)過程中，每個(gè) Provider 的處理能力都會(huì)動(dòng)態(tài)變化，主要體現(xiàn)在單次響應(yīng)時(shí)間的變化和允許的最大的并發(fā)數(shù)上。來自 Consumer 的請(qǐng)求速率過快時(shí)， Provider 端新到的請(qǐng)求會(huì)排隊(duì)等待處理，當(dāng)排隊(duì)線程數(shù)和工作線程數(shù)量之和達(dá)到最大線程數(shù)時(shí)，Provider 返回線程池用盡異常。在算法的實(shí)現(xiàn)和調(diào)優(yōu)過程中，應(yīng)該盡量避免產(chǎn)生線程池異常，減少排隊(duì)。如何結(jié)合好程序和硬件的限制，區(qū)分出不同階段的瓶頸，做出符合實(shí)際的容量評(píng)估是賽題的第一個(gè)難點(diǎn)。對(duì)于本次題目所采用的參數(shù)和變化過程，僅憑現(xiàn)有的理論和實(shí)踐很難達(dá)到最優(yōu)，所以需要選手充分理解題意和各參數(shù)配置，設(shè)計(jì)出更適合實(shí)際場(chǎng)景的算法。

第二個(gè)需要考慮的問題是如何應(yīng)用容量評(píng)估結(jié)果，即如何維護(hù)代表 Provider 服務(wù)能力的狀態(tài)，又如何在選擇 Provider 階段根據(jù)這些狀態(tài)進(jìn)行決策？

傳統(tǒng)的單 Dispatcher 負(fù)載均衡模型由一個(gè) Dispatcher 維護(hù)所有 Provider 的狀態(tài)，在同構(gòu)系統(tǒng)中，這種方式能夠達(dá)到漸進(jìn)最優(yōu)負(fù)載均衡。但是它存在的問題也很明顯：單 Dispatcher 性能存在天然瓶頸，可擴(kuò)容性較差，當(dāng) Provider 數(shù)量成倍上升時(shí)，Dispatcher 需要維護(hù)的狀態(tài)也在成倍上升，通信成本也在上升。本次挑戰(zhàn)賽中為了降低難度，沒有基于多 Dispatcher 模型構(gòu)建題目，但多 Dispatcher 、多 Provider 才是 Dubbo 等微服務(wù)框架在實(shí)際生產(chǎn)環(huán)境中最常見的情況。因此，若能實(shí)現(xiàn)高性能且可擴(kuò)展性良好的均衡算法，會(huì)是一個(gè)不錯(cuò)的加分項(xiàng)。

第三點(diǎn)是輔助接口的使用。為了不限制算法設(shè)計(jì)思路，賽題提供了多個(gè)可能用到的輔助接口，包括雙向通信、Provider 限流等支持。但是這些接口都是非必選項(xiàng)，是否使用這些接口取決于算法實(shí)現(xiàn)的需要。

在評(píng)測(cè)環(huán)境中，任意一個(gè) Provider 服務(wù)處理速率都小于評(píng)測(cè)程序的請(qǐng)求速率。三個(gè) Provider 總的處理速率會(huì)在請(qǐng)求速率上下浮動(dòng)。最終成績(jī)由請(qǐng)求成功數(shù)和最大 TPS 組成，失敗的請(qǐng)求不計(jì)入成績(jī)。對(duì)于這個(gè)限制，可以有兩種解讀方式，一是為了保證服務(wù)不嚴(yán)重過載，可以適當(dāng)拒絕請(qǐng)求。第二點(diǎn)是需要充分利用每個(gè) Provider 的服務(wù)容量，保證性能最優(yōu)的 Provider 請(qǐng)求數(shù)合理，適當(dāng)?shù)倪^載也是允許的。

以上僅作為一個(gè)主要的算法設(shè)計(jì)思路，優(yōu)秀的負(fù)載均衡算法在工程上的實(shí)現(xiàn)也是很關(guān)鍵的一點(diǎn)，需要選取合適的數(shù)據(jù)結(jié)構(gòu)，充分利用好內(nèi)存和 CPU，壓榨出比賽環(huán)境的每一點(diǎn)性能。當(dāng)然，評(píng)測(cè)成績(jī)并不代表一切，良好的代碼結(jié)構(gòu)、編碼風(fēng)格以及通用性，也在最終初賽成績(jī)中占據(jù)很大比例。

關(guān)注“阿里技術(shù)”官方公眾號(hào)，并在對(duì)話框內(nèi)回復(fù)“中間件”，即可獲得初賽賽題。

賽題評(píng)測(cè)

評(píng)測(cè)環(huán)境由 1 臺(tái) 4 核 8G 的施壓機(jī)，1 臺(tái) 4 核 8G 的網(wǎng)關(guān)機(jī)和 3 臺(tái) 4 核 8G 的 Provider組成。Consumer 和 Provider 程序都會(huì)限制 CPU 和內(nèi)存使用，每個(gè)評(píng)測(cè)任務(wù)都會(huì)獨(dú)占五臺(tái)機(jī)器。

• 準(zhǔn)備跑分環(huán)境，創(chuàng)建并鎖定工作區(qū)；
• 根據(jù)提交的 Git 地址，從代碼倉(cāng)庫中拉取代碼；
• 構(gòu)建代碼，生成最終執(zhí)行的 fat JAR；
• 啟動(dòng)三個(gè) Provider ，并驗(yàn)證服務(wù)可用性；
• 啟動(dòng) Consumer ，并驗(yàn)證服務(wù)可用性；
• 對(duì)系統(tǒng)進(jìn)行預(yù)熱，持續(xù) 30 秒；
• 正式評(píng)測(cè) 1 分鐘；
• 取正式評(píng)測(cè)的總成功請(qǐng)求數(shù)和最大 TPS 作為最終成績(jī)，上報(bào)天池系統(tǒng)；
• 按順序依次停止 Consumer、三個(gè) Provider；
• 清理 Docker 實(shí)例及鏡像；
• 收集日志并上傳到 OSS；
• 解鎖工作區(qū)，清理環(huán)境。

總結(jié)

本文結(jié)合第五屆中間件性能挑戰(zhàn)賽的賽題背景、題目場(chǎng)景、題目分析和評(píng)測(cè)環(huán)境與過程的角度，介紹了自適應(yīng)負(fù)載均衡算法的基本設(shè)計(jì)思路，希望對(duì)即將參加比賽的同學(xué)們能有所幫助，也歡迎更多的技術(shù)同學(xué)報(bào)名參加我們的挑戰(zhàn)賽，分享你在算法方面的思考和實(shí)踐。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的同学，要不要来挑战双11零点流量洪峰？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。