據(jù)了解，隨著用戶數(shù)量的不斷擴(kuò)增，在高峰期，新浪微博的服務(wù)器每秒要接受100萬(wàn)以上的響應(yīng)請(qǐng)求，壓力可謂空前。童劍表示，面對(duì)如此高的并發(fā)訪問(wèn)量，新浪在技術(shù)上所遇到的挑戰(zhàn)也相當(dāng)大。比如整體的技術(shù)平臺(tái)如何做性能擴(kuò)展?局部技術(shù)單元如何做性能擴(kuò)展?并設(shè)計(jì)系統(tǒng)使能通過(guò)增加服務(wù)器即可實(shí)現(xiàn)服務(wù)能力擴(kuò)容。不過(guò)，服務(wù)器數(shù)量的增加，會(huì)帶來(lái)服務(wù)器采購(gòu)成本的激增，而大量服務(wù)器快速部署上線又會(huì)對(duì)效率提出新的挑戰(zhàn)，新困難層出不窮。
　　對(duì)此，新浪也在不斷地尋找更完善的解決方案來(lái)滿足他們的需求。新浪網(wǎng)研發(fā)中心平臺(tái)架構(gòu)部的思路是：
　　1、先規(guī)劃整體，從大的技術(shù)體系上來(lái)保證能有效解決性能問(wèn)題、成本問(wèn)題、效率問(wèn)題、可靠性問(wèn)題;
　　2、然后再?gòu)木植恐郑ＷC每個(gè)技術(shù)單元都能夠從性能、可靠性方面滿足需求;
　　3、同時(shí)在應(yīng)用和系統(tǒng)的設(shè)計(jì)上，增加對(duì)故障容錯(cuò)的處理能力;
　　4、在產(chǎn)品運(yùn)維上，加強(qiáng)風(fēng)險(xiǎn)控制，提高監(jiān)控的有效性。
　　而在海量數(shù)據(jù)的處理方面，新浪則分別利用Hadoop的HDFS實(shí)現(xiàn)海量數(shù)據(jù)存儲(chǔ)、用MapReduce實(shí)現(xiàn)分布式計(jì)算，有些數(shù)據(jù)還使用了HBase進(jìn)行存儲(chǔ)和查詢。除此之外，也大量采用了Hive、Zookeepr等技術(shù)。

集群的運(yùn)維管理和交互仍是Hadoop應(yīng)用瓶頸
　　Hadoop源于互聯(lián)網(wǎng)，也回饋于互聯(lián)網(wǎng)，互聯(lián)網(wǎng)企業(yè)可以說(shuō)是當(dāng)前Hadoop技術(shù)應(yīng)用最廣泛、最深入的領(lǐng)域。如今大多數(shù)機(jī)構(gòu)都已經(jīng)部署了各自的IT業(yè)務(wù)系統(tǒng)，Hadoop技術(shù)與現(xiàn)有IT架構(gòu)如何實(shí)現(xiàn)無(wú)縫整合，成為了許多用戶非常關(guān)心的話題。在童劍看來(lái)，目前互聯(lián)網(wǎng)領(lǐng)域的Hadoop應(yīng)用在大規(guī)模的使用情況下，瓶頸還是比較多的。一方面是集群的運(yùn)維管理和監(jiān)控，這方面的工具現(xiàn)在還不夠成熟，需要運(yùn)維工程師有較為豐富的經(jīng)驗(yàn)。運(yùn)維工程師除了要掌握硬件的資源使用情況，還需要部署一些管理軟件來(lái)實(shí)現(xiàn)管理。另一方面則是由于集群中各組件之間的交互響應(yīng)性能較差，在集群達(dá)到一定規(guī)模后，要有針對(duì)性的對(duì)其進(jìn)行改進(jìn)和優(yōu)化。

微博平臺(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ù)垂直維度的延伸講解做鋪墊：

接口層主要實(shí)現(xiàn)與Web頁(yè)面、移動(dòng)客戶端的接口交互，定義統(tǒng)一的接口規(guī)范，平臺(tái)最核心的三個(gè)接口服務(wù)分別是內(nèi)容（Feed）服務(wù)、用戶關(guān)系服務(wù)及通訊服務(wù)（單發(fā)私信、群發(fā)、群聊）。
服務(wù)層主要把核心業(yè)務(wù)模塊化、服務(wù)化，這里又分為兩類服務(wù)，一類為原子服務(wù)，其定義是不依賴任何其他服務(wù)的服務(wù)模塊，比如常用的短鏈服務(wù)、發(fā)號(hào)器服務(wù)都屬于這一類。圖中使用泳道隔離，表示它們的獨(dú)立性。另外一類為組合服務(wù)，通過(guò)各種原子服務(wù)和業(yè)務(wù)邏輯的組合來(lái)完成服務(wù)，比如Feed服務(wù)、通訊服務(wù)，它們除了本身的業(yè)務(wù)邏輯，還依賴短鏈、用戶及發(fā)號(hào)器服務(wù)。
資源層主要是數(shù)據(jù)模型的存儲(chǔ)，包含通用的緩存資源Redis和Memcached，以及持久化數(shù)據(jù)庫(kù)存儲(chǔ)MySQL、HBase，或者分布式文件系統(tǒng)TFS以及Sina S3服務(wù)。

水平分層有一個(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)品，用來(lái)支撐核心業(yè)務(wù)，這些中間件由業(yè)務(wù)驅(qū)動(dòng)產(chǎn)生，隨著技術(shù)組件越來(lái)越豐富，形成完備的平臺(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、頻次控制、訪問(wèn)日志、降級(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)通過(guò)消息隊(duì)列，向搜索、大數(shù)據(jù)、商業(yè)運(yùn)營(yíng)部門提供實(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ì)象庫(kù)與SSD Cache組件。

對(duì)象庫(kù)
對(duì)象庫(kù)支持便捷的序列化與反序列化微博中的對(duì)象數(shù)據(jù)：序列化時(shí)，將JVM內(nèi)存中的對(duì)象序列化寫入在HBase中并生成唯一的ObjectID，當(dāng)需要訪問(wèn)該對(duì)象時(shí)，通過(guò)ObjectID讀取，對(duì)象庫(kù)支持任意類型的對(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性能使其被越來(lái)越多地用于替換傳統(tǒng)的SATA和SAS磁盤，常見的應(yīng)用場(chǎng)景有三種：1）替換MySQL數(shù)據(jù)庫(kù)的硬盤，目前社區(qū)還沒(méi)有針對(duì)SSD優(yōu)化的MySQL版本，即使這樣，直接升級(jí)SSD硬盤也能帶來(lái)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成本過(guò)高，容量小的問(wèn)題，也解決了穿透DB帶來(lái)的數(shù)據(jù)庫(kù)訪問(wèn)壓力。

垂直的監(jiān)控與服務(wù)治理
隨著服務(wù)規(guī)模和業(yè)務(wù)變得越來(lái)越復(fù)雜，即使業(yè)務(wù)架構(gòu)師也很難準(zhǔn)確地描述服務(wù)之間的依賴關(guān)系，服務(wù)的管理運(yùn)維變得越來(lái)難，在這個(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)成，用戶通過(guò)瀏覽器或移動(dòng)客戶端的每一個(gè)HTTP請(qǐng)求到達(dá)應(yīng)用服務(wù)器后，會(huì)經(jīng)過(guò)很多個(gè)業(yè)務(wù)系統(tǒng)或系統(tǒng)組件，并留下足跡（footprint）。但是這些分散的數(shù)據(jù)對(duì)于問(wèn)題排查，或是流程優(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；通過(guò)計(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ā)揮著越來(lái)越重要的作用，驅(qū)動(dòng)著平臺(tái)的技術(shù)升級(jí)、業(yè)務(wù)開發(fā)、系統(tǒng)運(yùn)維服務(wù)，本文限于篇幅限制，沒(méi)有展開介紹，后續(xù)會(huì)不斷地介紹核心中間件的設(shè)計(jì)原則和系統(tǒng)架構(gòu)。