一、微博的業(yè)務(wù)場(chǎng)景和挑戰(zhàn)

微博是2009年上線的一款社交媒體平臺(tái)。剛開始微博的功能比較簡(jiǎn)單，就是用戶關(guān)注了一些其他微博賬號(hào)，就可以在自己的信息流里看到相關(guān)用戶的動(dòng)態(tài)微博。

圖片

為了滿足不同用戶的實(shí)際需求，微博的功能也變得越來(lái)越豐富，出現(xiàn)了多種信息流機(jī)制，比如基于關(guān)注關(guān)系進(jìn)行信息分發(fā)的關(guān)注流、基于用戶興趣進(jìn)行信息分發(fā)的推薦流，還有發(fā)現(xiàn)頁(yè)中大家都很關(guān)注的熱搜板塊等。

圖片

有人把微博比喻為一個(gè)大廣場(chǎng)，每當(dāng)有社會(huì)熱點(diǎn)事件出現(xiàn)，首先都會(huì)在微博上發(fā)酵，然后用戶都集中來(lái)微博上關(guān)注事情進(jìn)展，進(jìn)行相關(guān)的熱議，因此也給技術(shù)架構(gòu)帶來(lái)巨大的挑戰(zhàn)。

圖片

2023年第一季度財(cái)報(bào)顯示：微博活躍用戶MAU5.93億，DAU2.55億。如此大的用戶量，對(duì)技術(shù)架構(gòu)就是一個(gè)不小的挑戰(zhàn)，微博用戶每天發(fā)布微博、評(píng)論、點(diǎn)贊等可以達(dá)到億級(jí)規(guī)模，每天新增的訂閱關(guān)注也在千萬(wàn)級(jí)規(guī)模。

用戶規(guī)模大，首先要具備海量數(shù)據(jù)存儲(chǔ)能力，同時(shí)作為用戶日常的高頻應(yīng)用，也要求具備一定的容災(zāi)能力。所以在談到微博的高可用挑戰(zhàn)的時(shí)候，首先要關(guān)注的就是微博在什么情況下流量高、挑戰(zhàn)大。總結(jié)下來(lái)，微博有4個(gè)典型的流量場(chǎng)景：

圖片

• 日常業(yè)務(wù)場(chǎng)景：微博用戶一般在中午和晚上比較活躍，所以從流量上看微博會(huì)有午高峰和晚高峰；
• 重大節(jié)假日?qǐng)鼍埃罕热缭⒋汗?jié)時(shí)期，微博也會(huì)有一個(gè)非常大的流量高峰；
• 運(yùn)營(yíng)活動(dòng)場(chǎng)景：特別的一些運(yùn)營(yíng)活動(dòng)，流量也會(huì)比較高；
• 突發(fā)熱點(diǎn)場(chǎng)景：這是對(duì)微博技術(shù)架構(gòu)最大的挑戰(zhàn)。

前三個(gè)場(chǎng)景是可以預(yù)期的，可以提前準(zhǔn)備，而突發(fā)熱點(diǎn)場(chǎng)景是不可預(yù)知的，且往往流量峰值非常高。

因此，從微博的業(yè)務(wù)情況和場(chǎng)景上看，高可用架構(gòu)的挑戰(zhàn)可以歸納出四個(gè)主要問(wèn)題：

圖片

• 容量問(wèn)題：數(shù)據(jù)存儲(chǔ)不下，請(qǐng)求量扛不住

微博從剛上線時(shí)的幾百萬(wàn)用戶到現(xiàn)在幾億用戶量，博文內(nèi)容數(shù)據(jù)也在不斷累積，數(shù)據(jù)量和存儲(chǔ)壓力越來(lái)越大；同時(shí)，隨著用戶規(guī)模增大，并發(fā)用戶請(qǐng)求量也會(huì)增大。

• 性能問(wèn)題：服務(wù)響應(yīng)太慢，資源成本太高

接口性能問(wèn)題，不僅會(huì)影響用戶消費(fèi)微博信息流的體驗(yàn)，還會(huì)增加資源成本。

• 依賴問(wèn)題：個(gè)別非核心資源拖死整個(gè)服務(wù)

就是邊緣業(yè)務(wù)功能有問(wèn)題，影響了核心功能，這是不能接受的。

• 容災(zāi)問(wèn)題：機(jī)房、專線故障導(dǎo)致服務(wù)不可用

近幾年也經(jīng)常聽(tīng)說(shuō)機(jī)房或?qū)＞€故障導(dǎo)致某些服務(wù)不可用情況，作為用戶高頻使用的APP，需要有一定的容災(zāi)能力。

二、構(gòu)建高可用架構(gòu)體系

針對(duì)上面提到的問(wèn)題和挑戰(zhàn)，對(duì)應(yīng)的解決方案如下：

圖片

當(dāng)然，解決問(wèn)題最重要的一步是能夠提前感知和發(fā)現(xiàn)問(wèn)題，因此需要有比較完備的監(jiān)控體系，這就組成了我們的高可用架構(gòu)體系（如下圖所示）。

圖片

下面我們談?wù)劯鱾€(gè)模塊的具體技術(shù)架構(gòu)方案：

1、容量問(wèn)題

建設(shè)海量數(shù)據(jù)存儲(chǔ)架構(gòu)要關(guān)注四個(gè)方面：首先是容量評(píng)估，根據(jù)業(yè)務(wù)規(guī)模和場(chǎng)景確定存儲(chǔ)容量和請(qǐng)求的讀寫比例和規(guī)模，接著就可以進(jìn)行存儲(chǔ)組件選型（MySQL、Redis等），然后就需要根據(jù)實(shí)際壓測(cè)數(shù)據(jù)，確定相關(guān)的容量安全閾值和請(qǐng)求量安全閾值，同時(shí)增加相關(guān)監(jiān)控和報(bào)警，最后還要做好容量的可擴(kuò)展預(yù)案，一旦存儲(chǔ)容量或請(qǐng)求容量達(dá)到安全閾值，能從容按照預(yù)案應(yīng)對(duì)。

圖片

存儲(chǔ)容量的可擴(kuò)展預(yù)案，需要提前做好三方面的準(zhǔn)備：

• 讀寫分離：特別適合讀寫比例失衡的業(yè)務(wù)場(chǎng)景，方便將來(lái)針對(duì)性地進(jìn)行容量擴(kuò)展；
• 水平拆分：能夠把數(shù)據(jù)按hash存儲(chǔ)到多個(gè)存儲(chǔ)實(shí)例中，解決單機(jī)存儲(chǔ)容量的瓶頸問(wèn)題；
• 垂直拆分：針對(duì)隨著時(shí)間會(huì)累積增加的內(nèi)容存儲(chǔ)場(chǎng)景，提前按時(shí)間維度做好分庫(kù)或分表，應(yīng)對(duì)隨著時(shí)間累積引起的存儲(chǔ)容量問(wèn)題。

圖片

微博場(chǎng)景已經(jīng)有十幾年的歷程，博文內(nèi)容存儲(chǔ)量會(huì)隨著時(shí)間不斷增多，因?yàn)閮?nèi)容存儲(chǔ)按時(shí)間維度進(jìn)行垂直拆分，每隔一段時(shí)間，就可以自然地增加新的數(shù)據(jù)庫(kù)實(shí)例，不斷擴(kuò)展整體存儲(chǔ)容量。

2、性能問(wèn)題

性能問(wèn)題的主要應(yīng)對(duì)方式是建設(shè)分布式緩存架構(gòu)，也包含四個(gè)方面的建設(shè)。首先是容量評(píng)估（對(duì)應(yīng)緩存要緩存什么數(shù)據(jù)，緩存數(shù)據(jù)有多大規(guī)模，增長(zhǎng)趨勢(shì)如何等），有了這些評(píng)估情況，就可以進(jìn)行緩存組件選型（本地緩存LocalCache還是分布式緩存，分布式緩存常見(jiàn)的還有memcached或redis等），原則上，如果緩存數(shù)據(jù)不多，能使用LocalCache搞定的就盡量用LocalCache，會(huì)相對(duì)簡(jiǎn)單。

與此同時(shí)，因?yàn)榛ヂ?lián)網(wǎng)產(chǎn)品用戶規(guī)模大，需要緩存的數(shù)據(jù)多，大部分情況都要用分布式緩存就來(lái)解決，所以緩存組件也需要建立性能基準(zhǔn)，確定請(qǐng)求安全閾值，建立監(jiān)控和報(bào)警機(jī)制，最后也要提前做好緩存容量可擴(kuò)展預(yù)案。

圖片

緩存容量的可擴(kuò)展和保障預(yù)案主要從下面三個(gè)方面準(zhǔn)備：

因本地緩存機(jī)制簡(jiǎn)單高效、性能好，所以要優(yōu)先使用本地緩存LocalCache；如果本地緩存放不下，就要使用分布式緩存，使用sharding分片把數(shù)據(jù)按指定hash規(guī)則放到對(duì)應(yīng)緩存實(shí)例中；同時(shí)還需要考慮緩存高可用的問(wèn)題，因?yàn)橐坏┚彺娉隽斯收希蜁?huì)有大量請(qǐng)求直接穿透數(shù)據(jù)庫(kù)，可能會(huì)直接把對(duì)應(yīng)數(shù)據(jù)庫(kù)實(shí)例打掛，造成服務(wù)雪崩，一般預(yù)防措施是采用Master/Slave的主從模式。

圖片

3、依賴問(wèn)題

系統(tǒng)一般都會(huì)有核心和非核心功能，它們之間會(huì)有調(diào)用關(guān)系，也就是有依賴關(guān)系。通常情況下，這種調(diào)用依賴會(huì)加上超時(shí)控制和重試機(jī)制，盡量降低依賴的影響。

同時(shí)，在核心功能內(nèi)部，也會(huì)有核心服務(wù)模塊和非核心服務(wù)模塊、核心資源和非核心資源；因?yàn)檫@些服務(wù)模塊在一個(gè)JVM（以java環(huán)境為例）或容器里，在運(yùn)行環(huán)境中共享cpu、內(nèi)存、磁盤，所以它們之間的很難避免互相影響。

圖片

基于這種情況，我們通常會(huì)想到微服務(wù)架構(gòu)。微服務(wù)架構(gòu)在2012、2013年的時(shí)候就非常火，好的微服務(wù)架構(gòu)要求實(shí)現(xiàn)松耦合、高內(nèi)聚。

通過(guò)微服務(wù)的理念，把服務(wù)模塊拆得足夠細(xì)，再加上超時(shí)控制和容錯(cuò)機(jī)制，相互之間的依賴會(huì)變輕量，但同時(shí)會(huì)帶來(lái)另一個(gè)問(wèn)題——服務(wù)性能會(huì)變差。

通常HTTP調(diào)用相比JVM內(nèi)部的進(jìn)程調(diào)用耗時(shí)會(huì)慢很多，所以我們又引入了RPC調(diào)用方式來(lái)解決服務(wù)性能的問(wèn)題。RPC的調(diào)用方式是在調(diào)用方和被調(diào)用方之間建立長(zhǎng)連接通道，相比HTTP調(diào)用，省去了域名解析、握手建連流程，調(diào)用效率會(huì)高很多。

微博內(nèi)部服務(wù)使用了PHP、GO、Java等不同的開發(fā)語(yǔ)言，為了能讓這些服務(wù)間實(shí)現(xiàn)高效的RPC調(diào)用，我們?cè)?014年自研了跨語(yǔ)言RPC服務(wù)Motan，并于內(nèi)部廣泛使用。目前這個(gè)RPC框架是已開源，已有5000+ star，感興趣的同學(xué)可以去了解和共同建設(shè)。Github地址：https://github.com/weibocom/motan

圖片

2017年左右出現(xiàn)了ServiceMesh技術(shù)，這是對(duì)微服務(wù)和RPC技術(shù)的一次理念升級(jí)。

因微博場(chǎng)景需要解決跨語(yǔ)言的問(wèn)題，所以很早就在motan RPC框架基礎(chǔ)上，把服務(wù)治理能力抽象到一個(gè)Agent中，然后部署上下層成為基礎(chǔ)設(shè)施組件的一部分，這和業(yè)界ServiceMesh的部分理念不謀而合。

緊接著，我們?cè)贛otan框架基礎(chǔ)上建設(shè)了WeiboMesh服務(wù)組件。區(qū)別于原來(lái)的微服務(wù)，我們無(wú)需業(yè)務(wù)關(guān)心通用服務(wù)治理能力下層的基礎(chǔ)設(shè)施層，只要用了WeiboMesh，自然就具備了相關(guān)的通用服務(wù)治理能力，業(yè)務(wù)在調(diào)用接口的時(shí)候，就感覺(jué)在調(diào)用本地服務(wù)接口一樣方便。

下圖所示為WeiboMesh架構(gòu)。我們把WeiboMesh服務(wù)直接打到基礎(chǔ)鏡像里，這樣在業(yè)務(wù)部署服務(wù)時(shí)，自然就有了服務(wù)網(wǎng)格的基礎(chǔ)通信能力、服務(wù)治理能力，業(yè)務(wù)間通過(guò)服務(wù)網(wǎng)格的通信基礎(chǔ)走長(zhǎng)連接通道，更加方便高效。

WeiboMesh的使用主要分成兩方面：一方面是服務(wù)間的調(diào)用（ServiceMesh）；另一方面是資源調(diào)用（DataMesh）。

資源調(diào)用DataMesh對(duì)性能要求會(huì)更高一些，有了服務(wù)網(wǎng)格模式后，我們就能更好地監(jiān)控到所有業(yè)務(wù)的資源調(diào)用情況，方便進(jìn)行相關(guān)調(diào)用管理，比如資源流量調(diào)用等。有了這些監(jiān)控?cái)?shù)據(jù)和調(diào)度手段，就能夠在全站建立聯(lián)動(dòng)策略和故障容災(zāi)體系。

目前為止，我們通過(guò)微服務(wù)架構(gòu)解決了服務(wù)依賴問(wèn)題、通過(guò)Motan RPC調(diào)用解決了調(diào)用性能問(wèn)題、通過(guò)ServiceMesh解決了服務(wù)治理通用化問(wèn)題。但微服務(wù)還帶來(lái)了一個(gè)問(wèn)題——運(yùn)維復(fù)雜度問(wèn)題。

圖片

如上圖所示，運(yùn)維復(fù)雜度取決于兩個(gè)因素：

• 服務(wù)規(guī)模：整個(gè)集群部署的服務(wù)器越多，運(yùn)維復(fù)雜度就會(huì)越大；
• 服務(wù)種類：集群中的服務(wù)類型越多，運(yùn)維復(fù)雜度也會(huì)隨之提升。

所以，微服務(wù)拆分之后，即使集群還是同樣的服務(wù)器規(guī)模，但是服務(wù)種類大幅增加了，運(yùn)維復(fù)雜度也大幅增加了。

在2014年左右，Docker容器化技術(shù)正好出現(xiàn)了，其可以實(shí)現(xiàn)用非常小的成本解決運(yùn)維復(fù)雜度的問(wèn)題，微博作為國(guó)內(nèi)最早一批大規(guī)模應(yīng)用容器化技術(shù)的團(tuán)隊(duì)，也享受著這一新技術(shù)的紅利。

圖片

Docker容器化技術(shù)的優(yōu)勢(shì)是可以隔離環(huán)境差異、實(shí)現(xiàn)統(tǒng)一的部署方式，同時(shí)還沒(méi)有太多額外消耗。統(tǒng)一部署方面，我們通過(guò)統(tǒng)一基礎(chǔ)鏡像的方式，解決組件和版本依賴問(wèn)題。

如微博春晚擴(kuò)容場(chǎng)景。因之前運(yùn)維復(fù)雜度高，春節(jié)需要提前一個(gè)月準(zhǔn)備采購(gòu)機(jī)器和版本環(huán)境，不同服務(wù)還要檢查相關(guān)差異，而在2014年春節(jié)的時(shí)候，我們首次大規(guī)模應(yīng)用容器化技術(shù)進(jìn)行春晚抗峰擴(kuò)容，利用容器化技術(shù)屏蔽系統(tǒng)環(huán)境和版本差異，擴(kuò)容準(zhǔn)備時(shí)間大幅縮短，很好地解決了微服務(wù)帶來(lái)的運(yùn)維復(fù)雜度問(wèn)題。

同時(shí)，伴隨著現(xiàn)在公有云廠商的出現(xiàn)，我們又有了新的想法。回顧微博4種典型流量場(chǎng)景，微博的流量高峰和低谷都非常明顯，如果按照高峰來(lái)部署服務(wù)器，資源成本會(huì)非常高，因此在運(yùn)維效率得到一定的提升之后，我們只需部署基礎(chǔ)流量的服務(wù)器資源，出現(xiàn)流量高峰的時(shí)候再?gòu)墓性婆R時(shí)借用一部分服務(wù)器，流量高峰過(guò)去后再歸還，這樣的策略大幅降低服務(wù)器成本。

圖片

基于以上思路，我們通過(guò)容器化技術(shù)+公有云技術(shù)，并通過(guò)容器化技術(shù)屏蔽我們本地服務(wù)器和公有云服務(wù)器的環(huán)境差異，建設(shè)了微博的混合云架構(gòu)。

混合云架構(gòu)讓微博可以日常部署基礎(chǔ)的服務(wù)器資源，在各種流量高峰場(chǎng)景，還可以快速?gòu)墓性婆R時(shí)借服務(wù)器部署，極大地降低服務(wù)運(yùn)維資源成本。特別是在微博的突發(fā)熱點(diǎn)場(chǎng)景下，依托混合云技術(shù)的動(dòng)態(tài)擴(kuò)縮容能力，讓我們可以用相對(duì)較小的成本，很好地應(yīng)對(duì)微博突發(fā)熱點(diǎn)流量。

4、容災(zāi)問(wèn)題

多機(jī)房部署是大型服務(wù)必須考慮的事情，因此機(jī)房容災(zāi)的重要性在這幾年特別突出。有些公司因機(jī)房問(wèn)題導(dǎo)致的故障甚至還上了熱搜，還因此受到了處罰，所以基礎(chǔ)運(yùn)維負(fù)責(zé)人要尤為重視容災(zāi)問(wèn)題。

圖片

說(shuō)到多機(jī)房容災(zāi)架構(gòu)，我們一定首先要了解一個(gè)古老而重要的理論——CAP理論（就是一致性、可用性、分區(qū)容忍性，同一時(shí)間場(chǎng)景只能滿足其二），對(duì)于社交場(chǎng)景一般是舍棄一致性，把一致性從強(qiáng)一致性降為最終一致性。

圖片

上圖是微博的簡(jiǎn)化版多機(jī)房架構(gòu)，這個(gè)架構(gòu)主要解決三個(gè)問(wèn)題：

• 一是把數(shù)據(jù)的強(qiáng)一致性降為最終一致性，多個(gè)機(jī)房之間的最終數(shù)據(jù)是通過(guò)數(shù)據(jù)主從同步的方式實(shí)現(xiàn)的，以此來(lái)保障機(jī)房數(shù)據(jù)的最終一致性；
• 二是通過(guò)自研的WMB消息總線服務(wù)，快速把消息進(jìn)行機(jī)房間同步，保障機(jī)房間消息同步的高效、穩(wěn)定、完整；
• 三是通過(guò)緩存機(jī)制，保障用戶實(shí)施看到不同機(jī)房間的消息內(nèi)容，不過(guò)度依賴數(shù)據(jù)庫(kù)同步。

在這樣的架構(gòu)下 ，即使某一機(jī)房出現(xiàn)問(wèn)題，機(jī)房?jī)?nèi)部還能形成自運(yùn)行生態(tài)，從而保障服務(wù)可用。

微博的機(jī)房較為分散，把幾個(gè)相近的機(jī)房稱為一個(gè)可用區(qū)，最終微博形成的是：三可用區(qū)+公有云架構(gòu)。在可用區(qū)內(nèi)部，服務(wù)和資源依賴形成閉環(huán)，同時(shí)不能強(qiáng)依賴可用區(qū)外的服務(wù)和資源，核心服務(wù)采用多可用區(qū)部署；同時(shí)依托混合云架構(gòu)，讓每個(gè)可用區(qū)可獨(dú)立通過(guò)公有云隨時(shí)進(jìn)行快速擴(kuò)容；最終還要建立流量調(diào)用機(jī)制，并定期進(jìn)行相關(guān)場(chǎng)景的容災(zāi)演練。

5、監(jiān)控體系、服務(wù)治理SLA體系

圖片

探討四大問(wèn)題后，還需要探討監(jiān)控體系、服務(wù)治理SLA體系問(wèn)題。服務(wù)監(jiān)控是整個(gè)高可用體系的眼睛，能夠及時(shí)發(fā)現(xiàn)問(wèn)題并制定預(yù)案，服務(wù)治理也已完全融入ServiceMesh中，SLA體系作為重要的量化指標(biāo)，對(duì)確保上下游建立良好默契、提高解決問(wèn)題的效率有著重要作用。

圖片

高可用架構(gòu)體系易于搭建，難在維護(hù)。隨著日常需求的不斷上線變更，系統(tǒng)架構(gòu)也在不斷變化，原來(lái)的容災(zāi)預(yù)案也可能會(huì)受影響而失效。因此，多機(jī)房架構(gòu)需要持續(xù)地積累和傳承，最終把這個(gè)技術(shù)經(jīng)驗(yàn)轉(zhuǎn)化為基礎(chǔ)組件，形成平臺(tái)的技術(shù)體系。

有了平臺(tái)的技術(shù)體系，系統(tǒng)的可用性就無(wú)需過(guò)度依賴人的因素，只需服務(wù)部署在這個(gè)技術(shù)體系上，海量數(shù)據(jù)存儲(chǔ)、分布式緩存架構(gòu)、混合云體系能力都可以渾然天成。

三、新的探索與展望

微博一直在建設(shè)PAAS平臺(tái)，未來(lái)，我們希望把平臺(tái)積累的技術(shù)經(jīng)驗(yàn)、技術(shù)組件集成到這個(gè)PAAS平臺(tái)上，業(yè)務(wù)開發(fā)同學(xué)把功能開發(fā)完成后，只要在git提交，就能自動(dòng)進(jìn)行CI/CD流程、進(jìn)行服務(wù)部署。

圖片

微博PAAS還以混合云技術(shù)為基礎(chǔ)，實(shí)現(xiàn)服務(wù)資源的動(dòng)態(tài)擴(kuò)縮容能力，通過(guò)容器化技術(shù)和K8s技術(shù)，管理并標(biāo)準(zhǔn)化服務(wù)Node節(jié)點(diǎn)，通過(guò)ServiceMesh和DataMesh組件，管理服務(wù)間調(diào)用和資源調(diào)用，包括繼承服務(wù)治理能力。通過(guò)Paaslet來(lái)進(jìn)行資源的隔離和優(yōu)先級(jí)調(diào)度，實(shí)現(xiàn)多類型服務(wù)混合部署，提升資源利用率。所有部署在PAAS平臺(tái)上的服務(wù)，都可以得到runtime的實(shí)時(shí)監(jiān)測(cè)，可以及時(shí)發(fā)現(xiàn)服務(wù)運(yùn)行時(shí)異常、保障服務(wù)穩(wěn)定。

隨著AIGC的興起，我們也在積極探索AIGC代碼生成和異常監(jiān)測(cè)方案，目前我們開發(fā)了WeCode組件，從代碼開發(fā)層面提升代碼質(zhì)量保障服務(wù)穩(wěn)定。

微博PAAS平臺(tái)建設(shè)方面已初具規(guī)模，也還在不斷完善，后續(xù)有機(jī)會(huì)再和大家分享。

作者介紹

李慶豐，新浪微博研發(fā)中心高級(jí)總監(jiān)。負(fù)責(zé)微博基礎(chǔ)架構(gòu)和流媒體等研發(fā)方向，在高可用架構(gòu)、視頻、直播等技術(shù)方向有豐富的研發(fā)實(shí)戰(zhàn)及管理經(jīng)驗(yàn)，同時(shí)作為微博技術(shù)新兵訓(xùn)練營(yíng)負(fù)責(zé)人，主導(dǎo)技術(shù)新人技術(shù)融入提升培訓(xùn)體系。技術(shù)社區(qū)的擁護(hù)者，多次擔(dān)任業(yè)界前沿技術(shù)大會(huì)的講師及出品人。