序言新浪微博在2014年3月公布的月活躍用戶（MAU）已經(jīng)達(dá)到1.43億，2014年新年第一分鐘發(fā)送的微博達(dá)808298條，如此巨大的用戶規(guī)模和業(yè)務(wù)量，需要高可用（HA）、高并發(fā)訪問、低延時(shí)的強(qiáng)大后臺(tái)系統(tǒng)支撐。 微博平臺(tái)第一代架構(gòu)為L(zhǎng)AMP架構(gòu)，數(shù)據(jù)庫使用的是MyIsam，后臺(tái)用的是php，緩存為Memcache。 隨著應(yīng)用規(guī)模的增長(zhǎng)，衍生出的第二代架構(gòu)對(duì)業(yè)務(wù)功能進(jìn)行了模塊化、服務(wù)化和組件化，后臺(tái)系統(tǒng)從php替換為Java，逐漸形成SOA架構(gòu)，在很長(zhǎng)一段時(shí)間支撐了微博平臺(tái)的業(yè)務(wù)發(fā)展。 在此基礎(chǔ)上又經(jīng)過長(zhǎng)時(shí)間的重構(gòu)、線上運(yùn)行、思索與沉淀，平臺(tái)形成了第三代架構(gòu)體系。 我們先看一張微博的核心業(yè)務(wù)圖（如下），是不是非常復(fù)雜？但這已經(jīng)是一個(gè)簡(jiǎn)化的不能再簡(jiǎn)化的業(yè)務(wù)圖了，第三代技術(shù)體系就是為了保障在微博核心業(yè)務(wù)上快速、高效、可靠地發(fā)布新產(chǎn)品新功能。
第三代技術(shù)體系微博平臺(tái)的第三代技術(shù)體系，使用正交分解法建立模型：在水平方向，采用典型的三級(jí)分層模型，即接口層、服務(wù)層與資源層；在垂直方向，進(jìn)一步細(xì)分為業(yè)務(wù)架構(gòu)、技術(shù)架構(gòu)、監(jiān)控平臺(tái)與服務(wù)治理平臺(tái)。下面是平臺(tái)的整體架構(gòu)圖：
如上圖所示，正交分解法將整個(gè)圖分解為3*4=12個(gè)區(qū)域，每個(gè)區(qū)域代表一個(gè)水平維度與一個(gè)垂直維度的交點(diǎn)，相應(yīng)的定義這個(gè)區(qū)域的核心功能點(diǎn)，比如區(qū)域5主要完成服務(wù)層的技術(shù)架構(gòu)。 下面詳細(xì)介紹水平方向與垂直方向的設(shè)計(jì)原則，尤其會(huì)重點(diǎn)介紹4、5、6中的技術(shù)組件及其在整個(gè)架構(gòu)體系中的作用。 水平分層水平維度的劃分，在大中型互聯(lián)網(wǎng)后臺(tái)業(yè)務(wù)系統(tǒng)的設(shè)計(jì)中非?；A(chǔ)，在平臺(tái)的每一代技術(shù)體系中都有體現(xiàn)。這里還是簡(jiǎn)單介紹一下，為后續(xù)垂直維度的延伸講解做鋪墊：
水平分層有一個(gè)特點(diǎn)，依賴關(guān)系都是從上往下，上層的服務(wù)依賴下層，下層的服務(wù)不會(huì)依賴上層，構(gòu)建了一種簡(jiǎn)單直接的依賴關(guān)系。 與分層模型相對(duì)應(yīng)，微博系統(tǒng)中的服務(wù)器主要包括三種類型：前端機(jī)（提供 API 接口服務(wù)）、隊(duì)列機(jī)（處理上行業(yè)務(wù)邏輯，主要是數(shù)據(jù)寫入）和存儲(chǔ)（mc、mysql、mcq、redis 、HBase等）。 垂直延伸技術(shù)架構(gòu)隨著業(yè)務(wù)架構(gòu)的發(fā)展和優(yōu)化，平臺(tái)研發(fā)實(shí)現(xiàn)了許多卓越的中間件產(chǎn)品，用來支撐核心業(yè)務(wù)，這些中間件由業(yè)務(wù)驅(qū)動(dòng)產(chǎn)生，隨著技術(shù)組件越來越豐富，形成完備的平臺(tái)技術(shù)框架，大大提升了平臺(tái)的產(chǎn)品研發(fā)效率和業(yè)務(wù)運(yùn)行穩(wěn)定性。 區(qū)別于水平方向上層依賴下層的關(guān)系，垂直方向以技術(shù)框架為地基支撐點(diǎn)，向兩側(cè)驅(qū)動(dòng)影響業(yè)務(wù)架構(gòu)、監(jiān)控平臺(tái)、服務(wù)治理平臺(tái)，下面介紹一下其中的核心組件。 接口層Web V4框架接口框架簡(jiǎn)化和規(guī)范了業(yè)務(wù)接口開發(fā)工作，將通用的接口層功能打包到框架中，采用了Spring的面向切面（AOP）設(shè)計(jì)理念。接口框架基于Jersey 進(jìn)行二次開發(fā)，基于annotation定義接口(url, 參數(shù))，內(nèi)置Auth、頻次控制、訪問日志、降級(jí)功能，支撐接口層監(jiān)控平臺(tái)與服務(wù)治理，同時(shí)還有自動(dòng)化的Bean-json/xml序列化。 服務(wù)層框架服務(wù)層主要涉及RPC遠(yuǎn)程調(diào)用框架以及消息隊(duì)列框架，這是微博平臺(tái)在服務(wù)層使用最為廣泛的兩個(gè)框架。 MCQ消息隊(duì)列消息隊(duì)列提供一種先入先出的通訊機(jī)制，在平臺(tái)內(nèi)部，最常見的場(chǎng)景是將數(shù)據(jù)的落地操作異步寫入隊(duì)列，隊(duì)列處理程序批量讀取并寫入DB，消息隊(duì)列提供的異步機(jī)制加快了前端機(jī)的響應(yīng)時(shí)間，其次，批量的DB操作也間接提高了DB操作性能，另外一個(gè)應(yīng)用場(chǎng)景，平臺(tái)通過消息隊(duì)列，向搜索、大數(shù)據(jù)、商業(yè)運(yùn)營部門提供實(shí)時(shí)數(shù)據(jù)。 微博平臺(tái)內(nèi)部大量使用的MCQ(SimpleQueue Service Over Memcache)消息隊(duì)列服務(wù)，基于MemCache協(xié)議，消息數(shù)據(jù)持久化寫入BerkeleyDB，只有g(shù)et/set兩個(gè)命令，同時(shí)也非常容易做監(jiān)控（stats queue），有豐富的client library，線上運(yùn)行多年，性能比通用的MQ高很多倍。 Motan RPC框架微博的Motan RPC服務(wù)，底層通訊引擎采用了Netty網(wǎng)絡(luò)框架，序列化協(xié)議支持Hessian和Java序列化，通訊協(xié)議支持Motan、http、tcp、mc等，Motan框架在內(nèi)部大量使用，在系統(tǒng)的健壯性和服務(wù)治理方面，有較為成熟的技術(shù)解決方案，健壯性上，基于Config配置管理服務(wù)實(shí)現(xiàn)了High Availability與Load Balance策略（支持靈活的FailOver和FailFast HA策略，以及Round Robin、LRU、Consistent Hash等Load Balance策略），服務(wù)治理方面，生成完整的服務(wù)調(diào)用鏈數(shù)據(jù)，服務(wù)請(qǐng)求性能數(shù)據(jù)，響應(yīng)時(shí)間（Response Time）、QPS以及標(biāo)準(zhǔn)化Error、Exception日志信息。 資源層框架資源層的框架非常多，有封裝MySQL與HBase的Key-List DAL中間件、有定制化的計(jì)數(shù)組件，有支持分布式MC與Redis的Proxy，在這些方面業(yè)界有較多的經(jīng)驗(yàn)分享，我在這里分享一下平臺(tái)架構(gòu)的對(duì)象庫與SSD Cache組件。 對(duì)象庫對(duì)象庫支持便捷的序列化與反序列化微博中的對(duì)象數(shù)據(jù)：序列化時(shí)，將JVM內(nèi)存中的對(duì)象序列化寫入在HBase中并生成唯一的ObjectID，當(dāng)需要訪問該對(duì)象時(shí)，通過ObjectID讀取，對(duì)象庫支持任意類型的對(duì)象，支持PB、JSON、二進(jìn)制序列化協(xié)議，微博中最大的應(yīng)用場(chǎng)景將微博中引用的視頻、圖片、文章統(tǒng)一定義為對(duì)象，一共定義了幾十種對(duì)象類型，并抽象出標(biāo)準(zhǔn)的對(duì)象元數(shù)據(jù)Schema，對(duì)象的內(nèi)容上傳到對(duì)象存儲(chǔ)系統(tǒng)（Sina S3）中，對(duì)象元數(shù)據(jù)中保存Sina S3的下載地址。 SSDCache隨著SSD硬盤的普及，優(yōu)越的IO性能使其被越來越多地用于替換傳統(tǒng)的SATA和SAS磁盤，常見的應(yīng)用場(chǎng)景有三種：1）替換MySQL數(shù)據(jù)庫的硬盤，目前社區(qū)還沒有針對(duì)SSD優(yōu)化的MySQL版本，即使這樣，直接升級(jí)SSD硬盤也能帶來8倍左右的IOPS提升；2）替換Redis的硬盤，提升其性能；3）用在CDN中，加快靜態(tài)資源加載速度。 微博平臺(tái)將SSD應(yīng)用在分布式緩存場(chǎng)景中，將傳統(tǒng)的Redis/MC + Mysql方式，擴(kuò)展為 Redis/MC + SSD Cache + Mysql方式，SSD Cache作為L(zhǎng)2緩存使用，第一降低了MC/Redis成本過高，容量小的問題，也解決了穿透DB帶來的數(shù)據(jù)庫訪問壓力。 垂直的監(jiān)控與服務(wù)治理隨著服務(wù)規(guī)模和業(yè)務(wù)變得越來越復(fù)雜，即使業(yè)務(wù)架構(gòu)師也很難準(zhǔn)確地描述服務(wù)之間的依賴關(guān)系，服務(wù)的管理運(yùn)維變得越來難，在這個(gè)背景下，參考google的dapper和twitter的zipkin，平臺(tái)實(shí)現(xiàn)了自己的大型分布式追蹤系統(tǒng)WatchMan。 WatchMan大型分布式追蹤系統(tǒng)如其他大中型互聯(lián)網(wǎng)應(yīng)用一樣，微博平臺(tái)由眾多的分布式組件構(gòu)成，用戶通過瀏覽器或移動(dòng)客戶端的每一個(gè)HTTP請(qǐng)求到達(dá)應(yīng)用服務(wù)器后，會(huì)經(jīng)過很多個(gè)業(yè)務(wù)系統(tǒng)或系統(tǒng)組件，并留下足跡（footprint）。但是這些分散的數(shù)據(jù)對(duì)于問題排查，或是流程優(yōu)化都幫助有限。對(duì)于這樣一種典型的跨進(jìn)程/跨線程的場(chǎng)景，匯總收集并分析這類日志就顯得尤為重要。另一方面，收集每一處足跡的性能數(shù)據(jù)，并根據(jù)策略對(duì)各子系統(tǒng)做流控或降級(jí)，也是確保微博平臺(tái)高可用的重要因素。要能做到追蹤每個(gè)請(qǐng)求的完整調(diào)用鏈路；收集調(diào)用鏈路上每個(gè)服務(wù)的性能數(shù)據(jù)；能追蹤系統(tǒng)中所有的Error和Exception；通過計(jì)算性能數(shù)據(jù)和比對(duì)性能指標(biāo)（SLA）再回饋到控制流程（control flow）中，基于這些目標(biāo)就誕生了微博的Watchman系統(tǒng)。 該系統(tǒng)設(shè)計(jì)的一個(gè)核心原則就是低侵入性（non-invasivenss）：作為非業(yè)務(wù)組件，應(yīng)當(dāng)盡可能少侵入或者不侵入其他業(yè)務(wù)系統(tǒng)，保持對(duì)使用方的透明性，可以大大減少開發(fā)人員的負(fù)擔(dān)和接入門檻?；诖丝紤]，所有的日志采集點(diǎn)都分布在技術(shù)框架中間件中，包括接口框架、RPC框架以及其他資源中間件。 WatchMan由技術(shù)團(tuán)隊(duì)搭建框架，應(yīng)用在所有業(yè)務(wù)場(chǎng)景中，運(yùn)維基于此系統(tǒng)完善監(jiān)控平臺(tái)，業(yè)務(wù)和運(yùn)維共同使用此系統(tǒng)，完成分布式服務(wù)治理，包括服務(wù)擴(kuò)容與縮容、服務(wù)降級(jí)、流量切換、服務(wù)發(fā)布與灰度。 結(jié)尾現(xiàn)在，技術(shù)框架在平臺(tái)發(fā)揮著越來越重要的作用，驅(qū)動(dòng)著平臺(tái)的技術(shù)升級(jí)、業(yè)務(wù)開發(fā)、系統(tǒng)運(yùn)維服務(wù)，本文限于篇幅限制，沒有展開介紹，后續(xù)會(huì)不斷地介紹核心中間件的設(shè)計(jì)原則和系統(tǒng)架構(gòu)。 本文首發(fā)于“微博平臺(tái)架構(gòu)”微信公眾號(hào)，發(fā)布時(shí)有少量的文字潤色和調(diào)整。 關(guān)于作者衛(wèi)向軍（@衛(wèi)向軍_微博），畢業(yè)于北京郵電大學(xué)，現(xiàn)任微博平臺(tái)架構(gòu)師，先后在微軟、金山云、新浪微博從事技術(shù)研發(fā)工作，專注于系統(tǒng)架構(gòu)設(shè)計(jì)、音視頻通訊系統(tǒng)、分布式文件系統(tǒng)和數(shù)據(jù)挖掘等領(lǐng)域。
原文：http://www./cn/articles/weibo-platform-archieture
作者： 衛(wèi)向軍 |
|
|
