注：本文是根據(jù)網(wǎng)上資料整理而成

1概述

首先給大家介紹一下新浪微博架構(gòu)發(fā)展的歷程涉兽，新浪微博在短短一年時(shí)間內(nèi)從零發(fā)展到五千萬用戶播瞳，我們的基層架構(gòu)也發(fā)展了3個(gè)大的版本。

2架構(gòu)演變

2.1第一版LAMP架構(gòu)

第 一版就 LAMP架構(gòu)堰氓，優(yōu)點(diǎn)是可以非嘲乐龋快的實(shí)現(xiàn)我們的系統(tǒng)。我們看一下技術(shù)特點(diǎn)裆赵，微博這個(gè)產(chǎn)品從架構(gòu)上來分析令境，它需要解決的是發(fā)表和訂閱的問題。我們第一版采用的 是推消息模式顾瞪，假如說我們一個(gè)明星用戶他有10萬個(gè)粉絲舔庶，那就是說用戶發(fā)表一條微博的時(shí)候，我們把這個(gè)微博消息存成10萬份陈醒，這樣就是很簡單了惕橙，第一版的 架構(gòu)實(shí)際上就是這兩行字。

2.1.1結(jié)構(gòu)

l微博的本質(zhì)是解決發(fā)表/訂閱問題

l第1版采用推消息模式钉跷，將發(fā)表/訂閱簡化成insert/select問題

第一版的技術(shù)細(xì)節(jié)弥鹦，典型的LAMP架構(gòu)，是使用MyISAM搜索引擎爷辙，它的優(yōu)點(diǎn)就是速度非潮蚧担快。

另外一個(gè)是MPSS（Multi-Port Single Server）膝晾， 就是多個(gè)端口可以布置在同一服務(wù)器上栓始。為什么使用MPSS？假如說我們做一個(gè)互聯(lián)網(wǎng)應(yīng)用血当，這個(gè)應(yīng)用里面有三個(gè)單元幻赚，我們可以由2種部署方式。我們可以把三 個(gè)單元分別部署在三臺服務(wù)器上臊旭，另外一種部署模式就是這三個(gè)單元部署在每個(gè)服務(wù)器上都有落恼。我推薦第2種方法。這個(gè)方法解決了兩個(gè)問題离熏，一個(gè)是負(fù)載均衡佳谦，因 為每一個(gè)單 元都有多個(gè)節(jié)點(diǎn)處理，另外一個(gè)是可以防止單點(diǎn)故障滋戳。如果我們按照模式1來做的話钻蔑，任何一個(gè)節(jié)點(diǎn)有故障就會影響我們系統(tǒng)服務(wù)，如果模式二的話胧瓜，任何一個(gè)結(jié)點(diǎn) 發(fā)生故障我們的整體都不會受到影響的矢棚。

2.1.2問題和架構(gòu)演變

l用戶快速增長

l出現(xiàn)發(fā)表延遲現(xiàn)象，尤其是明星用戶

2.2第二版架構(gòu)

我們微博第一版上線之后府喳，用戶非常喜歡這個(gè)產(chǎn)品蒲肋，用戶數(shù)增長非常迅速。我們技術(shù)上碰到幾個(gè)問題。

第一個(gè)問題是發(fā)表會出現(xiàn)延遲現(xiàn)象兜粘，尤其是明星用戶他的粉絲多系統(tǒng)需要處理很長時(shí)間申窘。另外系統(tǒng)在處理明星用戶發(fā)表時(shí)系統(tǒng)繁忙可能會影響到其他的用戶，因?yàn)槠渌挠脩敉粫r(shí)間發(fā)表的話孔轴，也會受到這個(gè)系統(tǒng)的影響剃法。

解決思路：

l分發(fā)推送是造成發(fā)表延遲的主要原因

n模式改進(jìn)

l數(shù)據(jù)規(guī)模增大也帶來一定延遲

n規(guī)模增大：數(shù)據(jù)拆分

n鎖表問題：更改引擎

我 們就考慮這個(gè)系統(tǒng)怎么改進(jìn)。首先是推模式路鹰，這肯定是延遲的首要原因贷洲，我們要把這個(gè)問題解決掉。其次我們的用戶越來越多晋柱，這個(gè)數(shù)據(jù)庫表從一百萬到一億优构，數(shù)據(jù) 規(guī)模不一樣處理方式是有差別的。我們第一版單庫單表的模式雁竞，當(dāng)用戶數(shù)量增多的時(shí)候钦椭，它不能滿足就需要進(jìn)行拆分。第二個(gè)是鎖表的問題碑诉，我們考慮的是更改引 擎彪腔。另外一個(gè)是發(fā)表過慢，我們考慮的是異步模式进栽。

第二版我們進(jìn)行了模塊化：

我們首先做了一個(gè)分層德挣，最底層叫基礎(chǔ)層，首先對數(shù)據(jù)做了拆分泪幌，圖上最右邊是發(fā)表做了異步模式盲厌。

2.2.1投遞模式優(yōu)化

第 二個(gè)服務(wù)層，我們把微博基礎(chǔ)的單元設(shè)計(jì)成服務(wù)層一個(gè)一個(gè)模塊祸泪，最大改進(jìn)是對推模式進(jìn)行了改進(jìn)。首先看一下投遞模式的優(yōu)化建芙，首先我們要思考推模式没隘，如果我們 做一下改進(jìn)把用戶分成有效和無效的用戶。我們一個(gè)用戶比如說有一百個(gè)粉絲禁荸，我發(fā)一條微博的時(shí)候不需要推給一百個(gè)粉絲右蒲，因?yàn)榭赡苡?0個(gè)粉絲不會馬上來看， 這樣同步推送給他們赶熟，相當(dāng)于做無用功瑰妄。我們把用戶分成有效和無效之后，我們把他們做一下區(qū)分映砖，比如說當(dāng)天登陸過的人我們分成有效用戶的話间坐，只需要發(fā)送給當(dāng) 天登陸過的粉絲，這樣壓力馬上就減輕了，另外投遞的延遲也減小了竹宋。

總結(jié)：

l推模式改進(jìn)劳澄，不需要推送到所有用戶

l存儲和發(fā)表峰值壓力減輕

l投遞延遲減小

2.2.2數(shù)據(jù)拆分

我們再看數(shù)據(jù)的拆分，數(shù)據(jù)拆分有很多方式蜈七，很多互聯(lián)網(wǎng)產(chǎn)品最常用的方法秒拔，比如說如可以按照用戶的UID來拆分。但是微博用戶的一個(gè)特點(diǎn)就是說大家訪問的都是最近的數(shù)據(jù)飒硅，所以我們考慮微博的數(shù)據(jù)我們按照時(shí)間拆分砂缩， 比如說一個(gè)月放一張表，這樣就解決了我們不同時(shí)間的維度可以有不同的拆分方式三娩。第二個(gè)考慮就是要把內(nèi)容和索引分開存放梯轻。假如說一條微博發(fā)表的uid,微 博id是索引數(shù)據(jù)，140個(gè)字的內(nèi)容是內(nèi)容數(shù)據(jù)尽棕。假如我們分開的話喳挑，內(nèi)容就簡單的變成了一種key-value的方式，key-value是最容易擴(kuò)展的 一種數(shù)據(jù)滔悉。索引數(shù)據(jù)的拆分具有挑戰(zhàn)伊诵，比如說一個(gè)用戶發(fā)表了一千條微博，這一千條微博我們接口前端要分頁訪問回官，比如說用戶需要訪問第五頁曹宴，那我們需要迅速定 位到這個(gè)記錄。假如說我們把這個(gè)索引拆分成一個(gè)月一張表歉提，我們記錄上很難判斷第五頁在 哪張表里笛坦，我們需要加載所有的索引表。如果這個(gè)地方不能拆分苔巨，那我們系統(tǒng)上就會有一個(gè)非常大的瓶頸版扩。最后我們想了一個(gè)方法，就是索引上做了一個(gè)二次索引侄泽， 把每個(gè)月記錄的偏移記下來礁芦，就是一個(gè)月這個(gè)用戶發(fā)表了多少條，ID是哪里悼尾，就是按照這些數(shù)據(jù)迅速把記錄找出來柿扣。

總結(jié)：

l優(yōu)先按時(shí)間維度拆分

l內(nèi)容和索引分開存放

l內(nèi)容使用key-value方式存儲（NoSQL）

l索引由于有分頁，拆分有挑戰(zhàn)

2.2.3異步處理

異步處理闺魏，發(fā)表是一個(gè)非常繁重的操作未状，它要入庫、統(tǒng)計(jì)索引析桥、進(jìn)入后臺司草，如果我們要把所有的索引都做完用戶需要前端等待很長的時(shí)間艰垂，如果有一個(gè)環(huán) 節(jié)失敗的話，用戶得到的提示是發(fā)表失敗翻伺，但是入庫已經(jīng)成功材泄，這樣會帶來數(shù)據(jù)不一致問題。所以我們做了一個(gè)異步操作吨岭，就是發(fā)表成功我們就提示成功拉宗，然后在后 臺慢慢的消息隊(duì)列慢慢的做完。另外新浪發(fā)表了一個(gè)很重要的產(chǎn)品叫做MemcacheQ辣辫，我們?nèi)ツ曜隽艘粋€(gè)對大規(guī)模部署非常有利的指令旦事，就是 statsqueue，適合大規(guī)模運(yùn)維急灭。

第二版我們做了這些改進(jìn)之后姐浮，微博的用戶和訪問量并沒有停止，還有很多新的問題出現(xiàn)葬馋。比如說系統(tǒng) 問題卖鲤，單點(diǎn)故障導(dǎo)致的雪崩，第二個(gè)是訪問速度問題因?yàn)閲鴥?nèi)網(wǎng)絡(luò)環(huán)境復(fù)雜畴嘶，會有用戶反映說在不同地區(qū)訪問圖片蛋逾、js這些速度會有問題。另外一個(gè)是數(shù)據(jù)壓力以 及峰值窗悯，MySql復(fù)制延遲区匣、慢查詢，另外就是熱門事件蒋院，比如說世界杯亏钩，可能會導(dǎo)致用戶每秒發(fā)表的內(nèi)容達(dá)到幾千條。我們考慮如何改進(jìn)欺旧，首先系統(tǒng)方面允許任 意模塊失敗姑丑。另外靜態(tài)內(nèi)容，第一步我們用CDN 來加速切端，另外數(shù)據(jù)的壓力以及峰值彻坛，我們需要將數(shù)據(jù)、功能踏枣、部署盡可能的拆分，然后提前進(jìn)行容量規(guī)劃钙蒙。

總結(jié)：

l發(fā)表異步化

l發(fā)表速度和可靠性得到提高

l使用MemcacheQ

n增加stats queue,適合大規(guī)模運(yùn)維

技術(shù)細(xì)節(jié)：

lInnoDB引進(jìn)茵瀑，避免鎖表煩惱

lPHP中l(wèi)ibmemcached代替memecache

n在高并發(fā)下穩(wěn)定性極大提高

2.2.4高速發(fā)展

l系統(tǒng)問題

n單點(diǎn)故障

n訪問速度，國內(nèi)復(fù)雜網(wǎng)絡(luò)環(huán)境

l數(shù)據(jù)壓力和峰值

nMySQL復(fù)制延遲躬厌、慢查詢

n熱門事件微博發(fā)表量马昨，明星評論及粉絲

2.2.5如何改進(jìn)

l系統(tǒng)方面

n允許任意模塊失敗

n靜態(tài)內(nèi)容CDN加速

l數(shù)據(jù)壓力和峰值

n將數(shù)據(jù)竞帽、功能、部署盡可能拆分

2.3第三版平臺化

2.3.1平臺化需求

另一方面我們還有平臺化的需求鸿捧，去年11月我們就說要做開放平臺屹篓，開放平臺的需求是有差異的，Web系統(tǒng)它有用戶行為才有請求匙奴，但是API系統(tǒng)特別是客戶端的應(yīng)用堆巧，只要用戶一開機(jī)就會有請求，直到他關(guān)閉電腦這種請求一直會不間斷的過來泼菌，另外用戶行為很難預(yù)測谍肤。

系 統(tǒng)規(guī)模在持續(xù)的增大，另外也有平臺化的需求哗伯，我們新架構(gòu)應(yīng)該怎么做才能滿足這些需要荒揣？我們看一下同行，比如說Google怎么樣考慮這個(gè)問題 的焊刹？Google首席科學(xué)家講過一句話系任，就是一個(gè)大的復(fù)雜的系統(tǒng)，應(yīng)該要分解成很多小的服務(wù)虐块。比如說我們在Google.com執(zhí)行一個(gè)搜索查詢的話俩滥，實(shí) 際上這個(gè)操作會調(diào)動內(nèi)部一百多個(gè)服務(wù)。因此非凌，我們第三版的考慮就是先有服務(wù)才有接口最后才有應(yīng)用举农，我們才能把這個(gè)系統(tǒng)做大。

平臺化需求：

lWeb系統(tǒng)

n有用戶行為才有請求

lAPI系統(tǒng)

n輪詢請求

n峰值不明顯

n用戶行為很難預(yù)測

2.3.2架構(gòu)如何設(shè)計(jì)

“Break large complex systems down into many services… google.com search touches 100s of service(ads, web search, books, news, spelling correction…”

--Jeff Dean, Google Fellow

2.3.3第三版結(jié)構(gòu)

服務(wù)化：

服務(wù)-〉接口-〉應(yīng)用

現(xiàn)在我們看一下第三版：

l首先我們把底層的東西分成基礎(chǔ)服務(wù)敞嗡，基礎(chǔ)服務(wù)里面有分布式的存儲颁糟，我們做了一些去中心化、自動化的操作喉悴。在基礎(chǔ)服務(wù)之上有平臺服務(wù)棱貌，我們把微博常用的應(yīng)用做成各種小的服務(wù)。

l然后我們還有應(yīng)用服務(wù)箕肃，這個(gè)是專門考慮平臺各種應(yīng)用的需求婚脱。最上面我們有API，API就是新浪微博 各種第三方應(yīng)用都在上面跑勺像。

l平臺服務(wù)和應(yīng)用服務(wù)是分開的障贸，這樣實(shí)現(xiàn)了模塊隔離，即使應(yīng)用服務(wù)訪問量過大的話吟宦，平臺服務(wù)不會首先影響篮洁。另外我們把微博的引擎進(jìn)行了改進(jìn)，實(shí)現(xiàn)了一個(gè)分層關(guān)系殃姓。用戶的關(guān)注關(guān)系袁波，我們改成一個(gè)多惟度的索引結(jié)構(gòu)瓦阐，性能極大的提高。

l第四個(gè)層面就是計(jì)數(shù)器的改進(jìn)篷牌，新版我們改成了基于偏移的思路睡蟋，就是一個(gè) 用戶他原來讀的一個(gè)ID比如說是10000，系統(tǒng)最系的ID是10002的話枷颊，我們很清楚他有兩條未讀戳杀。原來的版本是采用絕對計(jì)數(shù)的，這個(gè)用戶有幾條未讀 都是用一個(gè)存儲結(jié)構(gòu)的話偷卧，就容易產(chǎn)生一致性的問題豺瘤，采用這種偏移的技術(shù)基本上不會出錯(cuò)。

l另外基礎(chǔ)服務(wù)DB冷熱分離多維度拆分听诸，在微博里面我們是按照時(shí)間拆分的坐求，但是一個(gè)大型的系統(tǒng)里面有很多業(yè)務(wù)需要有不同的考慮。比如說私信這個(gè)就不能按照時(shí) 間來拆分晌梨，這個(gè)按照UID來拆分可能更簡單桥嗤。然后我們突出存儲還做了一個(gè)去中心化，就是用戶上傳圖片的速度會極大的提高仔蝌，另外察看其他用戶的圖片速度也會 極大的提高泛领。另外是動態(tài)內(nèi)容支持多IDC同時(shí)更新，這個(gè)是在國內(nèi)比較新穎的敛惊。

2.3.4平臺服務(wù)

l平臺服務(wù)和應(yīng)用服務(wù)分開渊鞋，模塊隔離

l新微博引擎，實(shí)現(xiàn)feed cache分層

l關(guān)系多維度索引結(jié)構(gòu)瞧挤，性能極大提高

l計(jì)數(shù)服務(wù)改成基于偏移锡宋，更高的一致性、低延遲

2.3.5基礎(chǔ)服務(wù)

lDB冷熱分離等多維度拆分

l圖片等存儲去中心化

l動態(tài)內(nèi)容支持多IDC同時(shí)更新

3如何打造高性能架構(gòu)

高性能架構(gòu)：

l50,000,000用戶使用新浪微博

l最高發(fā)表3000條微博/秒

l姚晨發(fā)表一條微博特恬，會被6,689,713粉絲讀到(11/10/2010)

下 面給大家介紹一下新浪微博怎么樣打造一個(gè)高性能架構(gòu)执俩。到目前為止有五千萬用戶使用新浪微博，最高發(fā)表3000條以上每秒癌刽，然后一個(gè)明星用戶發(fā)表的話役首，會被 幾百萬用戶同時(shí)讀到。這些問題的本質(zhì)是我們架構(gòu)需要考慮高訪問量显拜、海量數(shù)據(jù)的情況下三個(gè)問題衡奥。易于擴(kuò)展、低延遲远荠、高可用和異地分布杰赛。

3.1問題本質(zhì)和思路

l解決高訪問量、海量數(shù)據(jù)規(guī)模下：

n易于擴(kuò)展矮台、低延遲

n高可用

n異地分布能力

我 們每天有數(shù)十億次外部網(wǎng)頁以及API接口的需求乏屯，我們知道微博的特點(diǎn)是用戶請求是無法cache的。因此面對這個(gè)需求我們怎么樣擴(kuò)展瘦赫？幾點(diǎn)思路辰晕。第一我們 的模塊設(shè)計(jì)上要去狀態(tài)，我們?nèi)我庖粋€(gè)單元可以支持任意節(jié)點(diǎn)确虱。另外是去中心化含友，避免單點(diǎn)及瓶頸。另外是可線性擴(kuò)展校辩。最后一個(gè)是減少模塊窘问。

3.1.1思路：

l去狀態(tài)，可請求服務(wù)單元中任意節(jié)點(diǎn)

l去中心化宜咒，避免單點(diǎn)及瓶頸

l可線形擴(kuò)展惠赫，如

n100萬用戶，10臺服務(wù)器

n1000萬用戶故黑，100臺服務(wù)器

l減少模塊耦合

3.1.2實(shí)時(shí)性

l高性能系統(tǒng)具備低延遲儿咱、高實(shí)時(shí)性

l實(shí)時(shí)性的核心是讓數(shù)據(jù)離CPU最近，避免磁盤IO

“CPU訪問L1就像從書桌拿一本書场晶，L2是從書架拿一本書混埠，L3是從客廳的桌子上拿一本書，訪問主存就像騎車去社區(qū)圖書館拿一本書”

--淘寶系統(tǒng)專家余錚

3.2IO和緩存

我 們要做一個(gè)高性能的系統(tǒng)诗轻，要具備一個(gè)低延遲钳宪、高實(shí)時(shí)性，微博要做到高實(shí)時(shí)性這是核心的價(jià)值扳炬，實(shí)時(shí)性的核心就是讓數(shù)據(jù)離CPU最近吏颖，避免磁盤的 IO。我們看淘寶核心系統(tǒng)專家余鋒說過的一句話“CPU訪問L1就像從書桌拿一本書鞠柄，L2是從書架拿一本書侦高，L3是從客廳桌子上拿一本書，訪問主存就像騎 車去社區(qū)圖書館拿一書”厌杜。我們微博如果要做到非常實(shí)時(shí)的話奉呛，我們就需要把數(shù)據(jù)盡量離CPU節(jié)點(diǎn)最近。所以我們看一下cache設(shè)計(jì)里面怎么達(dá)到這個(gè)目標(biāo)夯尽。 首先INBOX瞧壮，這個(gè)數(shù)據(jù)我們需要放再一個(gè)最快的地方，因?yàn)橛脩綦S時(shí)訪問匙握。OutBOX里面的最近發(fā)表就是L1cache咆槽，還有一個(gè)是中期的，這個(gè)因?yàn)樵L 問少一點(diǎn)圈纺，它可以被踢秦忿。最后一部分內(nèi)容體有三部分麦射。L0是本地的，我們需要把一些經(jīng)常訪問的灯谣，比如說明星發(fā)表微博的內(nèi)容體本地化潜秋，因?yàn)樗辉L問的概率非常 大。然后L1里面存放著最近發(fā)表的胎许，還有一個(gè)是中期的峻呛。我們通常用L2就可以了，L1我們可以理解成它就是一個(gè)RAM存儲辜窑。

3.3高可用

一 個(gè)好的架構(gòu)還需要舉行高可用性钩述。我們看一下業(yè)界的指標(biāo)，S3是99.9%穆碎，EC2是99.5%牙勘，我們另外一個(gè)同行Facebook在這方面它是沒有承諾 的，就是接口可用寫惨远。微博平臺目前承諾的是99.95%谜悟，就是說一天365天故障率應(yīng)該小于9小時(shí)。這個(gè)怎么達(dá)到北秽？第一我們要做容量規(guī)劃葡幸，要做好監(jiān)控以及 入口的管理，就是說有些服務(wù)如果訪問量過了的話贺氓，我們要有一個(gè)開關(guān)可以攔住他蔚叨。我們通過這個(gè)圖表可以清楚的看到，比如說我們要做L1的 cache辙培，我們剩余空間有多少蔑水，比如說80%，就說明這個(gè)數(shù)據(jù)有可能會丟失扬蕊，有可能會對我們的系統(tǒng)造成影響搀别。

l好的架構(gòu)具有高可用性

l業(yè)界：

nAmazon S3：99.9%

nAmazon EC2：99.95%

nFacebook：n/a

如何達(dá)到高可用性：

l容量規(guī)劃

n圖表

l監(jiān)控

n接口及資源監(jiān)控，7X24

n業(yè)務(wù)回環(huán)測試尾抑，檢測業(yè)務(wù)邏輯有效性

3.3.1接口監(jiān)控

另外一個(gè)層面就是接口監(jiān)控歇父，我們目前有Google維度的接口監(jiān)控，包括訪問錯(cuò)誤失敗率再愈。然后要做架構(gòu)榜苫，給大家一個(gè)很重要的經(jīng)驗(yàn)分享，就是說監(jiān)控的指標(biāo) 盡量量化翎冲。比如說他延遲30秒是小問題垂睬，如果是延遲10分鐘我們就要立即采取措施了，就是所有可以量化的指標(biāo)都要量化。

然后我們看監(jiān)控怎么 樣更好的做驹饺？我們看亞馬遜的VP說過的一句話钳枕，就是說監(jiān)控系統(tǒng)確實(shí)特別好，可以立即告訴我們哪里有故障逻淌，但是有20%的概率 我們?nèi)耸菚鲥e(cuò)的么伯。所以我們一個(gè)大型系統(tǒng)就應(yīng)該要為自動化設(shè)計(jì)，就是說盡可能的將一些運(yùn)作自動化卡儒。比如說發(fā)布安裝、服務(wù)俐巴、啟用骨望、停止。我們再看另外一 句欣舵，Google的工程師是怎么做的擎鸠。他是這么做的，比如說第一周是處理線上的業(yè)務(wù)缘圈，這一周他處理了很多事情劣光，處理了很多系統(tǒng)的情況，剩下幾周時(shí)間沒有別 的工作糟把，他只要把這一周碰到的情況用程序的方法來解決绢涡，下次再碰到這種情況很簡單的一個(gè)按鈕就可以處理了。我們目前也在向自動化這方面努力遣疯，就是我們的工 具在持續(xù)增加雄可。

接口監(jiān)控：

lcurl/各地請求情況及相應(yīng)時(shí)間

l流量異常/access log

lnon-200結(jié)果/失敗率/exceptions

l將監(jiān)控指標(biāo)量化

3.3.2自動化

l大規(guī)模互聯(lián)網(wǎng)系統(tǒng)運(yùn)作需要盡可能自動化

n發(fā)布及安裝

n服務(wù)啟用缠犀、停止

n故障處理

l前提数苫，去狀態(tài)化，允許故障及充啟

3.3.3分布式

另外一個(gè)異地分布辨液，在國內(nèi)網(wǎng)絡(luò)環(huán)境下虐急，比如說IDC災(zāi)難，機(jī)房檢修甚至是機(jī)房掉電滔迈，我們也碰到過中國最好的機(jī)房也會掉電止吁，所以要每個(gè)服務(wù)單元都能支持多 機(jī)房部署。另外做多機(jī)房部署有一個(gè)好處亡鼠，就是用戶的訪問速度會提高赏殃。多IDC分布靜態(tài)內(nèi)容就不說了，基本上大的互聯(lián)網(wǎng)公司都會做间涵，它非常成熟基本上沒有什 么問題仁热，比如說圖片等等的靜態(tài)內(nèi)容。動態(tài)內(nèi)容的CDN分布是業(yè)內(nèi)的難點(diǎn)，國內(nèi)很少有公司能夠做到非常成熟的多機(jī)房動態(tài)內(nèi)容發(fā)布的成熟方案抗蠢，它的核心就是分 布式存儲举哟。一款理想的分布式存儲產(chǎn)品它有哪些需求呢？首先它要支持海量規(guī)模迅矛、可擴(kuò)展妨猩、高性能、低延遲秽褒、高可用壶硅。第二個(gè)是需要多機(jī)房分布，能夠滿足 國內(nèi)負(fù)責(zé)的網(wǎng)絡(luò)環(huán)境销斟，還要具備異地容災(zāi)能力庐椒。第三個(gè)就是要調(diào)用簡單，具備豐富數(shù)據(jù)庫特性蚂踊。因此分布式存儲需要解決一個(gè)多對多的數(shù)據(jù)復(fù)制约谈。

如 果要做復(fù)制無非是三種策略，第一個(gè)是Master/Slave犁钟，但是它也兩個(gè)缺點(diǎn)棱诱，第一個(gè)是Master是中心化的，如果Master在北京 那廣州訪問就非常慢涝动。第二個(gè)缺點(diǎn)是有單點(diǎn)風(fēng)險(xiǎn)的迈勋，比如說Master在北京，能立即遷到廣州嗎捧存？這樣有個(gè)時(shí)間窗口的數(shù)據(jù)就丟失了粪躬，而且需要人工的干預(yù)，而 且日常廣州的用戶訪問北京的Master是有很大延遲問題的昔穴，所以一般來說要做的非常優(yōu)秀是不會考慮第一種方案的镰官。第二種就是Multi-Master方 案，它需要應(yīng)用避免沖突吗货，就是我們不能多處改變泳唠。這個(gè)對于微博來說不會特別難，我們的用戶通常只會再一個(gè)地方發(fā)表微博宙搬，用戶不會同時(shí)在廣州又在北京發(fā)表或 者是修改自己的資料笨腥，這樣的話我們應(yīng)用上就已經(jīng)避免了這種情況。第三個(gè)就是Paxos就是可以達(dá)到強(qiáng)一致寫勇垛，就是一條數(shù)據(jù)如果成功肯定是多個(gè)機(jī)房都成功 了脖母，這個(gè)也顯而易見就是延遲性非常大。因此總結(jié)一下Multi-Master是最成熟的策略闲孤，但是它現(xiàn)在沒有成熟的產(chǎn)品谆级，因?yàn)榇_實(shí)沒有。

Multi-Master：

lWeb應(yīng)用多地區(qū)同步的最佳策略

l沒有現(xiàn)成成熟的產(chǎn)品

通過消息廣播方式將數(shù)據(jù)多地分布，類似Yahoo肥照！Message Broker

我 們再來看微博的方案脚仔，所以我們自己實(shí)現(xiàn)了一個(gè)多機(jī)房同步的方案。就是我們前端應(yīng)用將數(shù)據(jù)寫到數(shù)據(jù)庫舆绎，再通過一個(gè)消息代理鲤脏，相當(dāng)于通過我們自己 開發(fā)的一個(gè)技術(shù)，將數(shù)據(jù)廣播到多個(gè)機(jī)房吕朵。這個(gè)不但可以做到兩個(gè)機(jī)房猎醇，而且可以做到三個(gè)、四個(gè)边锁。具體的方式就是通過消息廣播方式將數(shù)據(jù)多點(diǎn)分布姑食，就是說我們 的數(shù)據(jù)提交給一個(gè)代理，這個(gè)代理幫我們把這些數(shù)據(jù)同步到多個(gè)機(jī)房茅坛，那我們應(yīng)用不需要關(guān)心這個(gè)數(shù)據(jù)是怎么樣同步過去的。

用這種消息代理方 式有什么好處呢则拷？可以看一下Yahoo是怎么來做的贡蓖？第一個(gè)是數(shù)據(jù)提供之后沒有寫到db之后是不會消失的，我只要把數(shù)據(jù)提交成 功就可以了煌茬，不需要關(guān)心數(shù)據(jù)怎么到達(dá)機(jī)房斥铺。第二個(gè)特點(diǎn)YMB是一款消息代理的產(chǎn)品，但是它唯一神奇的地方是為廣域網(wǎng)設(shè)計(jì)的坛善，它可以把多機(jī)房應(yīng)用歸到內(nèi)部晾蜘， 我們應(yīng)用不需要關(guān)注這個(gè)問題。這個(gè)原理跟我們目前自己開發(fā)的技術(shù)相似眠屎。

然后我們再看一下目前即將推出的微博平臺的新架構(gòu)剔交。我們知道 API大部分的請求都為了獲取最新的數(shù)據(jù)。API請求有一個(gè)特點(diǎn)改衩，它大目前調(diào)用都是 空返回的岖常，比如說一款手機(jī)的客戶端每隔一分鐘它都要調(diào)用服務(wù)器一下，就是有沒有新數(shù)據(jù)葫督，大目前的調(diào)用都是空返回竭鞍，就是說不管服務(wù)器有沒有數(shù)據(jù)都要調(diào)用一 次。這次詢問到下一次詢問中間橄镜，如果有新的數(shù)據(jù)來了偎快，你是不會馬上知道的。因此我們想API能不能改用推的方式洽胶，就是客戶端不需要持續(xù)的調(diào)用晒夹，如果有新數(shù) 據(jù)就會推過去。技術(shù)特點(diǎn)，顯而易見低延遲惋戏，就是從發(fā)表到接受1秒內(nèi)完成领追，實(shí)際上可能用不了1秒。然后服務(wù)端的連接就是高并發(fā)長連接服務(wù)响逢，就是多點(diǎn)都連接在 我們的服務(wù)器上绒窑，這個(gè)比傳統(tǒng)的API要大很多。

我們看一下推送架構(gòu)怎么從架構(gòu)底層做到實(shí)時(shí)性的舔亭。從左上角的一條微博在我們系統(tǒng)發(fā)布之 后些膨，我們把它放在一個(gè)消息隊(duì)列里面，然后會有一個(gè)消息隊(duì)列 的處理程序把它拿過來钦铺，處理以后放到db里面订雾。假如說我們不做持久化，因?yàn)槲覀兺扑蛿?shù)據(jù)也不能丟失矛洞，我們就要寫一個(gè)很復(fù)雜的程序洼哎，將數(shù)據(jù)異步去存，這樣就 會非常復(fù)雜沼本，而且系統(tǒng)也會有不穩(wěn)定的因素噩峦。從另外一個(gè)角度來說，我們做持久化也是做過測試的抽兆。我們推送整個(gè)流程可以做到100毫秒和200毫秒之間识补，就是 說我們在這個(gè)時(shí)間能把數(shù)據(jù)推送出去。

我們再看一下內(nèi)部細(xì)節(jié)辫红，就是我們收到數(shù)據(jù)之后首先要經(jīng)過最上面RECEIVER凭涂。然后推到我們的引擎 里面，這個(gè)引擎會做兩個(gè)事情贴妻，首先會把用戶的關(guān)系拿過來切油，然后按照用戶關(guān)系馬上推送給他相應(yīng)的粉絲。所以我們調(diào)用方已經(jīng)在那兒等待了揍瑟，我們需要有一個(gè)喚醒 操作白翻，就是說在接口這兒把它喚醒，然后把它 發(fā)送過去绢片。最后是一個(gè)高并發(fā)的長連服務(wù)器滤馍，就是一臺服務(wù)器支持10萬以上的并發(fā)連接。最右邊中間有一個(gè)圓圈叫做StreamBuffer底循，我們需要 StreamBuffer是要保存用戶最近的數(shù)據(jù)巢株。因?yàn)橛脩艨赡軙袛嗑€的，比如說他發(fā)送數(shù)據(jù)的時(shí)候斷線半分鐘熙涤，我們需要把這半分鐘補(bǔ)給他阁苞。這就是我們的 推送架構(gòu)困檩。

3.4新推送架構(gòu)

3.4.1現(xiàn)狀

lAPI大部分請求都是為了獲取最新的數(shù)據(jù)

l重新思考Rest API

n大部分調(diào)用都是空返回

n大部分時(shí)間都在處理不必要的詢問

3.4.2如何解決

l新一代推送接口（Stream API）

l采用推送的方式

n有新數(shù)據(jù)服務(wù)器立即推送給調(diào)用方

n無數(shù)據(jù)則不消耗流量

n客戶端實(shí)現(xiàn)更簡單

3.4.3技術(shù)特點(diǎn)

l低延遲，從發(fā)表到客戶端接收1秒內(nèi)完成

l高并發(fā)長連接服務(wù)器

3.4.4推送架構(gòu)

l為什么先持久化

nKISS那槽，Keep It Simple and Stupid

n測試表明持久幾乎不增加延遲開銷

uBatch insert

uCursor read

lStream Buffer

n保存用戶最近數(shù)據(jù)

n保存客戶端斷線重連之間下行數(shù)據(jù)

3.5平臺安全

l由于接口開放悼沿，需要防范各類惡意行為：

n垃圾內(nèi)容

n垃圾粉絲

n惡意行為

下面介紹一下平臺安全部分。由于我們的接口是完全開放的骚灸，所以我們要防范很多惡意行為糟趾，有很多人擔(dān)心我們接口是開放的，是不是有人通過這個(gè)接口發(fā)垃圾廣告甚牲，或者是刷粉絲义郑，我們技術(shù)架構(gòu)怎么來防范這一點(diǎn)呢袍嬉？

這是我們的安全架構(gòu)嘉熊，做了三個(gè)層面的事情。

1.最上面是我們有一個(gè)實(shí)時(shí)處理担扑，比如說根據(jù)頻度雏赦、內(nèi) 容的相似性來進(jìn)行判斷劫笙，判斷發(fā)的是不是廣告或者是垃圾內(nèi)容。

2.中間這個(gè)是一個(gè)日志處理器星岗，我們會根據(jù)一些行為進(jìn)行判斷邀摆，比如說如果我們只是實(shí)時(shí)攔截的話，有 些行為很難防止伍茄，我們做了個(gè)離線糾正的模塊，比如說他潛伏的幾個(gè)月開始發(fā)廣告了施逾，我們可以事后把這些人清除掉敷矫，以保證我們平臺的健康。

3.最后是通過監(jiān)控的維 度來保證內(nèi)容的安全汉额。目前內(nèi)容安全的架構(gòu)大概是541的體系曹仗，就是說我們的實(shí)時(shí)攔截可以做到50%的防止，離線分析大概可以做到40%的防止蠕搜。

微博平臺需要為用戶提供安全及良好的體驗(yàn)應(yīng)用怎茫，以及為開發(fā)者營造一個(gè)公平的環(huán)境，所以我們的接口需要清晰安全的規(guī)則妓灌。從一個(gè)APP調(diào)用我們的接 口轨蛤，需要幾個(gè)階層，需要劃分不同的業(yè)務(wù)模塊虫埂。第二個(gè)是安全層祥山。第三個(gè)是權(quán)限層。這是我們平臺安全的兩個(gè)維度掉伏，一個(gè)接口安全缝呕，一個(gè)是內(nèi)容安全澳窑。

我今天講的是架構(gòu)方面的問題，在座大部分是開發(fā)者供常，可能大家都在處理不同的架構(gòu)問題摊聋，架構(gòu)很多地方是相通的。我們需要做一個(gè)軟件系統(tǒng)需要解決的 本質(zhì)問題是什么栈暇？微博第一版解決發(fā)布規(guī)模問題麻裁，第二版是解決數(shù)據(jù)規(guī)模的問題，第三版是解決服務(wù)化的問題瞻鹏。將復(fù)雜的問題簡單化之后悲立，我們才可以設(shè)計(jì)出一個(gè)容 易擴(kuò)展的大規(guī)模架構(gòu)。我今天介紹就這么多新博，我們微博實(shí)際上是很需要各方面的技術(shù)人員薪夕，大家對我們的架構(gòu)如果感興趣的話、對我們的系統(tǒng)感興趣的話赫悄，也希望各 方面的技術(shù)人員參與我們微博的團(tuán)隊(duì)原献，隨時(shí)可以給我微博上發(fā)私信。

3.5.1接口安全

lAuth層

n訪問需要AppKey

n需要OAuth授權(quán)

l權(quán)限層

n流量控制埂淮，權(quán)限控制