本文從設(shè)計(jì)及服務(wù)可用性方面，詳細(xì)解析了微博短視頻高可用、高并發(fā)架構(gòu)設(shè)計(jì)中的問(wèn)題與解決方案。

今天與大家分享的是微博短視頻業(yè)務(wù)的高并發(fā)架構(gòu)，具體內(nèi)容分為如下三個(gè)方面：

• 團(tuán)隊(duì)介紹
• 微博視頻業(yè)務(wù)場(chǎng)景
• “微博故事”業(yè)務(wù)場(chǎng)景架構(gòu)設(shè)計(jì)

團(tuán)隊(duì)介紹

我們是隸屬于微博研發(fā)部視頻平臺(tái)研發(fā)部門(mén)的技術(shù)團(tuán)隊(duì)。平臺(tái)研發(fā)是微博的核心部門(mén)之一，包括大家熟知的微博視頻在內(nèi)的微博所有核心業(yè)務(wù)的基礎(chǔ)平臺(tái)架構(gòu)、用戶(hù)關(guān)系體系等都依賴(lài)微博平臺(tái)研發(fā)部門(mén)的技術(shù)支持。

我們的團(tuán)隊(duì)主要負(fù)責(zé)與視頻相關(guān)的上層業(yè)務(wù)也就是視頻微博、“微博故事”以及短視頻和直播，其中直播包括常規(guī)的直播與直播答題等新玩法。

同時(shí)我們還負(fù)責(zé)底層視頻平臺(tái)的架構(gòu)搭建，包括文件平臺(tái)、轉(zhuǎn)碼平臺(tái)、配置調(diào)度中心與媒體庫(kù)。

我們致力于用技術(shù)幫助微博從容應(yīng)對(duì)每天***的視頻增量與其背后多項(xiàng)業(yè)務(wù)的多種定制化需求。

微博視頻業(yè)務(wù)場(chǎng)景

我們的業(yè)務(wù)場(chǎng)景主要是應(yīng)對(duì)熱門(mén)事件的流量暴漲，例如明星緋聞、爆炸性新聞等勢(shì)必會(huì)讓流量在短時(shí)間內(nèi)急劇增長(zhǎng)的事件。

如何從架構(gòu)上保證流量暴漲時(shí)整體平臺(tái)的穩(wěn)定性?如果只是簡(jiǎn)單地通過(guò)調(diào)整服務(wù)器規(guī)模解決，流量較小時(shí)過(guò)多的服務(wù)器冗余帶來(lái)成本的浪費(fèi)，流量暴漲時(shí)過(guò)少的服務(wù)器又令平臺(tái)服務(wù)處于崩潰的邊緣。

比較特別的是，我們面臨的問(wèn)題與諸如“雙十一”這種在某一確定時(shí)間段內(nèi)流量的可預(yù)見(jiàn)式高并發(fā)有著本質(zhì)的不同，我們面臨的流量暴漲是不可預(yù)見(jiàn)的。因此通過(guò)哪些技術(shù)手段來(lái)妥善解決以上問(wèn)題，將是接下探討的重點(diǎn)。

以上是基于微博的過(guò)去已經(jīng)公開(kāi)數(shù)據(jù)量級(jí)，非近期內(nèi)部數(shù)據(jù)。微博視頻是一個(gè)多業(yè)務(wù)接入的綜合平臺(tái)，你可以在微博上看見(jiàn)現(xiàn)在市面上的各種玩法。

這就導(dǎo)致我們即將面臨的并不是某個(gè)垂直業(yè)務(wù)領(lǐng)域的***，而是一個(gè)構(gòu)建在龐大體量下的綜合性***，這就導(dǎo)致現(xiàn)有的通用技術(shù)框架無(wú)法妥善解決我們所面臨的難題。

因?yàn)橐恍╅_(kāi)源方案無(wú)法順利通過(guò)技術(shù)壓測(cè)，所以我們只能在開(kāi)源方案的基礎(chǔ)上進(jìn)行自研與優(yōu)化才能得到符合微博應(yīng)用場(chǎng)景需求的技術(shù)解決方案。

微博的短視頻業(yè)務(wù)被稱(chēng)為“微博故事”，上圖展示的是“微博故事”的展現(xiàn)形態(tài)。這是一個(gè)布置在微博首頁(yè)一級(jí)入口上的模塊，主要展示的是用戶(hù)關(guān)注的人所上傳的 15 秒內(nèi)的短視頻。

我們希望強(qiáng)調(diào)其“即時(shí)互動(dòng)”的屬性，視頻只有 24 小時(shí)的有效展示時(shí)間。不同用戶(hù)的視頻按照時(shí)間軸在上方排序，多個(gè)視頻可依次觀看、評(píng)論、點(diǎn)贊等。

“微博故事”業(yè)務(wù)場(chǎng)景架構(gòu)設(shè)計(jì)

微服務(wù)架構(gòu)

上圖展示的是這項(xiàng)業(yè)務(wù)的微服務(wù)架構(gòu)：在接口層我們混布了 Web API 與內(nèi)部的 RPC 請(qǐng)求。

在這里我們并未集成具有實(shí)際意義的門(mén)面層，而接下來(lái)的服務(wù)層集成了許多微服務(wù)，每個(gè)微服務(wù)集中在一個(gè)垂直功能上并可對(duì)外提供接口，這里的門(mén)面層主要作用是聚合一些微服務(wù)并對(duì)外提供綜合性接口。

除此之外還有一些依賴(lài)服務(wù)例如用戶(hù)關(guān)注、也需要依賴(lài)于其他部門(mén)的 RPC 服務(wù);***的存儲(chǔ)層則是集成了 Cache 與 db 的標(biāo)準(zhǔn)方案。

技術(shù)挑戰(zhàn)

有人曾問(wèn)到：微博短視頻業(yè)務(wù)的高并發(fā)有多高?假設(shè)我關(guān)注了 500 名好友，如果有好友發(fā)布一個(gè)視頻就會(huì)在“微博故事”頭像列表上顯示一個(gè)彩圈用以提示我去觀看。

如果我想知道自己所有關(guān)注的 500 個(gè)人所發(fā)的視頻內(nèi)容，假設(shè)首頁(yè)每秒刷新十萬(wàn)次，那么需要每秒鐘五千萬(wàn)的 QPS。

除此之外我們還需要確定視頻是否過(guò)期、視頻發(fā)送順序等，實(shí)際的資源層讀取量將遠(yuǎn)遠(yuǎn)高于五千萬(wàn)。

方案比較

在構(gòu)建解決方案時(shí)我們思考：可以借鑒微博之前的 Feed 解決方案，我們不會(huì)進(jìn)行無(wú)意義的重復(fù)性工作與思考。

即使短視頻與 Feed 都具有首頁(yè)刷新與關(guān)注人發(fā)布消息聚合的特點(diǎn)，但以用戶(hù)列表為形式，強(qiáng)調(diào)進(jìn)度續(xù)播與即時(shí)互動(dòng)的短視頻和以?xún)?nèi)容列表為形式，強(qiáng)調(diào)無(wú)閱讀狀態(tài)與***保存的微博具有本質(zhì)的區(qū)別。

面對(duì)一般的 Feed 應(yīng)用場(chǎng)景可以使用以下兩種模型：

• Feed 推模型
• Feed 拉模型

①Feed 推模型

Feed 推模型是指將用戶(hù)上傳發(fā)布的內(nèi)容推送至每一位粉絲，這種方案具有很大的弊端。由于用戶(hù)尚未達(dá)成一定規(guī)模，早期的微博以 Feed 推模型為主導(dǎo)。

而現(xiàn)在一個(gè)大 V 用戶(hù)的粉絲數(shù)量普遍都是***別，如果依舊使用 Feed 推模型則意味著千萬(wàn)量級(jí)的內(nèi)容推送，在難以保證千萬(wàn)份推送一致性的情況下，勢(shì)必會(huì)為服務(wù)器帶來(lái)巨大壓力。

微博的業(yè)務(wù)強(qiáng)調(diào)的就是強(qiáng)時(shí)效性下的內(nèi)容一致性，我們需要確保熱點(diǎn)事件推送的瞬時(shí)與一致。

除了從技術(shù)層面很難確保***別內(nèi)容推送的時(shí)效性與一致性，由于用戶(hù)上線(xiàn)狀態(tài)的不統(tǒng)一，為離線(xiàn)的用戶(hù)推送強(qiáng)時(shí)效性的內(nèi)容無(wú)疑是對(duì)服務(wù)器等資源的巨大浪費(fèi)，為了避免以上麻煩我們必須改變思路。

②Feed 拉模型

Feed 拉模型：拉取關(guān)注的人并實(shí)時(shí)查詢(xún)狀態(tài)及內(nèi)容。綜合微博的龐大用戶(hù)體量、數(shù)據(jù)寫(xiě)入開(kāi)銷(xiāo)與確保一致性三方面，我們決定選擇 Feed 拉模型。

如何通過(guò) Feed 拉模型應(yīng)對(duì)如此規(guī)模龐大的 QPS?首先我們采用了分布式緩存架構(gòu)，在緩存層集成了數(shù)據(jù)分片并將緩存通過(guò)哈希算法合理分片，之后再把緩存去切片化并進(jìn)行存取。

分布式緩存架構(gòu)

其次我們使用了獨(dú)有的多級(jí)緩存方案也就是 L1、 Master 、Slave 三層緩存方案。

L1 是一個(gè)熱度極高容量極小的緩存，我們稱(chēng)其為“極熱緩存”，其特點(diǎn)是便于橫向擴(kuò)展。

假設(shè) L1 只有 200MB 緩存，我們使用 LRU 算法通過(guò)熱度分析把訪(fǎng)問(wèn)最熱的數(shù)據(jù)存儲(chǔ)在 L1 中;之后的 Master 與 Slave 的緩存空間則是 4GB、6GB，比 L1 大很多倍。

因?yàn)槲⒉┑牧髁勘容^集中于熱點(diǎn)事件中某幾位明星或某個(gè)新聞，小容量的 L1 可進(jìn)行快速擴(kuò)容;在發(fā)生熱門(mén)事件時(shí)利用云的彈性自動(dòng)擴(kuò)容從而分擔(dān)熱點(diǎn)事件短時(shí)間激增的流量壓力。

由于自動(dòng)擴(kuò)容時(shí) L1 僅占用每臺(tái)緩存中很小的空間，擴(kuò)容的速度就會(huì)非?？?，通過(guò)這種手動(dòng)或自動(dòng)的瞬間彈性擴(kuò)容來(lái)確保服務(wù)器穩(wěn)定承受熱點(diǎn)事件背后的數(shù)據(jù)激增量。

第二層的 Master 與 Slave 具有比 L1 大好多倍的緩存空間，主要用于防止數(shù)據(jù)冷穿。

雖然 L1 主要承擔(dān)的是熱點(diǎn)數(shù)據(jù)，但卻無(wú)法確保一些短時(shí)間內(nèi)不熱但在某個(gè)時(shí)間段熱度突然高漲所帶來(lái)的流量短時(shí)間爆發(fā)時(shí)服務(wù)器的穩(wěn)定性。

HA 多機(jī)房部署

而 Master 與 Slave 作為 L1 的邏輯分組可有效防止數(shù)據(jù)過(guò)冷，在這里我們采用的是 HA 多機(jī)房部署。

例如圖中的的兩臺(tái) IDC，我們稱(chēng)左邊為 IDC-A，右邊為 IDC-B。緩存層的 Master 與 Slave 是主從同步的關(guān)系，雙機(jī)房的緩存互相主從同步。

這里的“互相主從同步”是指 IDC-A 的 MC 與 IDC-B 的 MC 之間進(jìn)行雙向同步互為主從。

因?yàn)樵谶M(jìn)行雙機(jī)房部署時(shí)需要均衡兩個(gè)機(jī)房的流量負(fù)載，在緩存層需要使用 LRU 算法進(jìn)行熱度分析。

如果我們將流量分為兩份并傳輸至兩個(gè)機(jī)房，通過(guò)每個(gè)機(jī)房的 IRU 算法得到的熱度信息有一定失真。

如果我們?cè)诰彺鎸幼鱿嗷ネ胶竺總€(gè)機(jī)房的 MC 都是一個(gè)全量的熱度算法，那么兩個(gè)機(jī)房的 L1 基本可實(shí)現(xiàn)同步計(jì)算得出的熱度信息一定是準(zhǔn)確的，只有保證熱度信息的準(zhǔn)確無(wú)誤才能從容應(yīng)對(duì)流量激增與整個(gè)系統(tǒng)的高可用性。

在這里需要強(qiáng)調(diào)的是，實(shí)際上我們?cè)谶x型上使用的是 MC 而未使用 Redis。

MC 對(duì)于純簡(jiǎn)單數(shù)據(jù) Key，Value 的抗量遠(yuǎn)大于 Redis;MC 采用預(yù)分配內(nèi)存的形式放置 Key，Value，也就是把內(nèi)存分成若干組相同數(shù)據(jù)區(qū)域，實(shí)際上就是若干個(gè)數(shù)組。

這種特殊結(jié)構(gòu)使其在數(shù)據(jù)定位數(shù)組尋址與讀寫(xiě)上的速度非?？?這種結(jié)構(gòu)的缺點(diǎn)是：一旦緩存的數(shù)據(jù)出現(xiàn)變動(dòng)就會(huì)出現(xiàn)即使內(nèi)存留有空余但數(shù)據(jù)依舊無(wú)法存儲(chǔ)的現(xiàn)象。

由于這種問(wèn)題的存在，MC 不適用于存儲(chǔ)變動(dòng)大、Value 跨度大、業(yè)務(wù)多變的數(shù)據(jù)。

而 Redis 作為單線(xiàn)程方案，一致性更好，但在超大規(guī)模簡(jiǎn)單 Key，Value 讀取上速度比 MC 是要差很多的。

除了上述方案之外，我們還采用了彈性擴(kuò)縮容。實(shí)際應(yīng)用中，基于成本的考量我們無(wú)法部署大量的服務(wù)器，于是我們采用了自研的 DCP 彈性擴(kuò)縮容平臺(tái)。

首先，我們的自有機(jī)房有一些共享機(jī)器資源可在特殊情況下動(dòng)態(tài)彈性擴(kuò)充以應(yīng)對(duì)增加的流量壓力。

當(dāng)然，這部分機(jī)器的性能是有限的，當(dāng)數(shù)據(jù)量超過(guò)一定閾值后我們就會(huì)接入阿里云并利用我們與阿里云的混合云 DCP 方式構(gòu)建一層彈性軟平臺(tái)用于自動(dòng)擴(kuò)容承擔(dān)流量壓力。

除了彈性擴(kuò)容我們同時(shí)也采用了定時(shí)擴(kuò)容的邏輯，在每天晚高峰時(shí)段進(jìn)行擴(kuò)縮容從而確保整體服務(wù)的穩(wěn)定性。之所以這么做，主要是為了在保證用戶(hù)體驗(yàn)的前提下盡可能節(jié)約成本。

需要強(qiáng)調(diào)的是，擴(kuò)容對(duì)速度的要求十分嚴(yán)格。只有擴(kuò)容的速度越快，流量峰值來(lái)臨時(shí)可承受的數(shù)據(jù)量越大，才能確保整體服務(wù)的高可用，因而我們也在努力優(yōu)化擴(kuò)容的速度。

我們的 DCP 平臺(tái)上也有晚高峰固定時(shí)段擴(kuò)縮容與突發(fā)流量臨時(shí)擴(kuò)縮容，通過(guò)如流量監(jiān)控等的自動(dòng)化容量評(píng)估來(lái)判斷服務(wù)器荷載，并通過(guò)自動(dòng)化任務(wù)調(diào)度妥善解決突發(fā)流量對(duì)服務(wù)器的影響。

微服務(wù)熔斷機(jī)制

當(dāng)然，為了保證服務(wù)器整體的健康與穩(wěn)定，我們也在其中集成了微服務(wù)熔斷機(jī)制，其原理類(lèi)似于家用電表中的保險(xiǎn)絲，可在過(guò)載的情況下迅速自動(dòng)熔斷。

系統(tǒng)會(huì)定期進(jìn)行自我評(píng)估并確定每個(gè)服務(wù)的***荷載，假設(shè)將熔斷值定為 3000QPS，那么當(dāng) QPS 超過(guò) 3000、超時(shí)或異常時(shí)服務(wù)即會(huì)迅速熔斷并關(guān)閉，從而確保其他資源的安全穩(wěn)定。

通過(guò)這種框架級(jí)、細(xì)粒度的自動(dòng)降級(jí)機(jī)制，系統(tǒng)失敗隔離能力可被有效提高，避免了雪崩式的鏈?zhǔn)藉礄C(jī)事件的發(fā)生。在熔斷的同時(shí)，自動(dòng)擴(kuò)容也會(huì)同步運(yùn)行。

熔斷之后系統(tǒng)會(huì)不斷更新服務(wù)流量荷載，一旦擴(kuò)容完成或者服務(wù)還能繼續(xù)承受流量即可重新恢復(fù)工作，這種熔斷機(jī)制同樣也是為服務(wù)器擴(kuò)容爭(zhēng)取時(shí)間。