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

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

圖片

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

圖片

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

圖片

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

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

圖片

• 日常業(yè)務(wù)場景：微博用戶一般在中午和晚上比較活躍，所以從流量上看微博會有午高峰和晚高峰；
• 重大節(jié)假日場景：比如元旦、春節(jié)時(shí)期，微博也會有一個(gè)非常大的流量高峰；
• 運(yùn)營活動場景：特別的一些運(yùn)營活動，流量也會比較高；
• 突發(fā)熱點(diǎn)場景：這是對微博技術(shù)架構(gòu)最大的挑戰(zhàn)。

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

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

圖片

• 容量問題：數(shù)據(jù)存儲不下，請求量扛不住

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

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

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

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

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

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

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

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

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

圖片

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

圖片

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

1、容量問題

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

圖片

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

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

圖片

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

2、性能問題

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

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

圖片

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

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

圖片

3、依賴問題

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

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

圖片

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

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

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

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

圖片

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

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

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

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

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

資源調(diào)用DataMesh對性能要求會更高一些，有了服務(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)動策略和故障容災(zāi)體系。

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

圖片

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

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

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

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

圖片

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

如微博春晚擴(kuò)容場景。因之前運(yùn)維復(fù)雜度高，春節(jié)需要提前一個(gè)月準(zhǔn)備采購機(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ù)帶來的運(yùn)維復(fù)雜度問題。

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

圖片

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

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

4、容災(zāi)問題

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

圖片

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

圖片

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

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

在這樣的架構(gòu)下 ，即使某一機(jī)房出現(xiàn)問題，機(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ú)立通過公有云隨時(shí)進(jìn)行快速擴(kuò)容；最終還要建立流量調(diào)用機(jī)制，并定期進(jìn)行相關(guān)場景的容災(zāi)演練。

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

圖片

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

圖片

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

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

三、新的探索與展望

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

圖片

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

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

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

作者介紹

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