序言
微博平臺第一代架構為LAMP架構，數據庫使用的是MyIsam，后臺用的是php，緩存為Memcache。
隨著應用規模的增長，衍生出的第二代架構對業務功能進行了模塊化、服務化和組件化，后臺系統從php替換為Java，逐漸形成SOA架構，在很長一段時間支撐了微博平臺的業務發展。
在此基礎上又經過長時間的重構、線上運行、思索與沉淀，平臺形成了第三代架構體系。
我們先看一張微博的核心業務圖(如下)，是不是非常復雜?但這已經是一個簡化的不能再簡化的業務圖了，第三代技術體系就是為了保障在微博核心業務上快速、高效、可靠地發布新產品新功能。
第三代技術體系
微博平臺的第三代技術體系，使用正交分解法建立模型：在水平方向，采用典型的三級分層模型，即接口層、服務層與資源層;在垂直方向，進一步細分為業務架構、技術架構、監控平臺與服務治理平臺。下面是平臺的整體架構圖：
如上圖所示，正交分解法將整個圖分解為3*4=12個區域，每個區域代表一個水平維度與一個垂直維度的交點，相應的定義這個區域的核心功能點，比如區域5主要完成服務層的技術架構。
下面詳細介紹水平方向與垂直方向的設計原則，尤其會重點介紹4、5、6中的技術組件及其在整個架構體系中的作用。
水平分層
水平維度的劃分，在大中型互聯網后臺業務系統的設計中非常基礎，在平臺的每一代技術體系中都有體現。這里還是簡單介紹一下，為后續垂直維度的延伸講解做鋪墊：
接口層主要實現與Web頁面、移動客戶端的接口交互，定義統一的接口規范，平臺最核心的三個接口服務分別是內容(Feed)服務、用戶關系服務及通訊服務(單發私信、群發、群聊)。
服務層主要把核心業務模塊化、服務化，這里又分為兩類服務，一類為原子服務，其定義是不依賴任何其他服務的服務模塊，比如常用的短鏈服務、發號器服務都屬于這一類。圖中使用泳道隔離，表示它們的獨立性。另外一類為組合服務，通過各種原子服務和業務邏輯的組合來完成服務，比如Feed服務、通訊服務，它們除了本身的業務邏輯，還依賴短鏈、用戶及發號器服務。
資源層主要是數據模型的存儲，包含通用的緩存資源Redis和Memcached，以及持久化數據庫存儲MySQL、HBase，或者分布式文件系統TFS以及Sina S3服務。
水平分層有一個特點，依賴關系都是從上往下，上層的服務依賴下層，下層的服務不會依賴上層，構建了一種簡單直接的依賴關系。
與分層模型相對應，微博系統中的服務器主要包括三種類型：前端機(提供 API 接口服務)、隊列機(處理上行業務邏輯，主要是數據寫入)和存儲(mc、mysql、mcq、redis、HBase等)。
垂直延伸技術架構
隨著業務架構的發展和優化，平臺研發實現了許多卓越的中間件產品，用來支撐核心業務，這些中間件由業務驅動產生，隨著技術組件越來越豐富，形成完備的平臺技術框架，大大提升了平臺的產品研發效率和業務運行穩定性。
區別于水平方向上層依賴下層的關系，垂直方向以技術框架為地基支撐點，向兩側驅動影響業務架構、監控平臺、服務治理平臺，下面介紹一下其中的核心組件。
接口層Web V4框架
接口框架簡化和規范了業務接口開發工作，將通用的接口層功能打包到框架中，采用了Spring的面向切面(AOP)設計理念。接口框架基于Jersey 進行二次開發，基于annotation定義接口(url, 參數)，內置Auth、頻次控制、訪問日志、降級功能，支撐接口層監控平臺與服務治理，同時還有自動化的Bean-json/xml序列化。
服務層框架
服務層主要涉及RPC遠程調用框架以及消息隊列框架，這是微博平臺在服務層使用最為廣泛的兩個框架。
MCQ消息隊列
消息隊列提供一種先入先出的通訊機制，在平臺內部，最常見的場景是將數據的落地操作異步寫入隊列，隊列處理程序批量讀取并寫入DB，消息隊列提供的異步機制加快了前端機的響應時間，其次，批量的DB操作也間接提高了DB操作性能，另外一個應用場景，平臺通過消息隊列，向搜索、大數據、商業運營部門提供實時數據。
微博平臺內部大量使用的MCQ(SimpleQueue Service Over Memcache)消息隊列服務，基于MemCache協議，消息數據持久化寫入BerkeleyDB，只有get/set兩個命令，同時也非常容易做監控(stats queue)，有豐富的client library，線上運行多年，性能比通用的MQ高很多倍。
Motan RPC框架
微博的Motan RPC服務，底層通訊引擎采用了Netty網絡框架，序列化協議支持Hessian和Java序列化，通訊協議支持Motan、http、tcp、mc等，Motan框架在內部大量使用，在系統的健壯性和服務治理方面，有較為成熟的技術解決方案，健壯性上，基于Config配置管理服務實現了High Availability與Load Balance策略(支持靈活的FailOver和FailFast HA策略，以及Round Robin、LRU、Consistent Hash等Load Balance策略)，服務治理方面，生成完整的服務調用鏈數據，服務請求性能數據，響應時間(Response Time)、QPS以及標準化Error、Exception日志信息。
資源層框架
資源層的框架非常多，有封裝MySQL與HBase的Key-List DAL中間件、有定制化的計數組件，有支持分布式MC與Redis的Proxy，在這些方面業界有較多的經驗分享，我在這里分享一下平臺架構的對象庫與SSD Cache組件。
對象庫
對象庫支持便捷的序列化與反序列化微博中的對象數據：序列化時，將JVM內存中的對象序列化寫入在HBase中并生成唯一的ObjectID，當需要訪問該對象時，通過ObjectID讀取，對象庫支持任意類型的對象，支持PB、JSON、二進制序列化協議，微博中最大的應用場景將微博中引用的視頻、圖片、文章統一定義為對象，一共定義了幾十種對象類型，并抽象出標準的對象元數據Schema，對象的內容上傳到對象存儲系統(Sina S3)中，對象元數據中保存Sina S3的下載地址。
SSDCache
隨著SSD硬盤的普及，優越的IO性能使其被越來越多地用于替換傳統的SATA和SAS磁盤，常見的應用場景有三種：
1)替換MySQL數據庫的硬盤，目前社區還沒有針對SSD優化的MySQL版本，即使這樣，直接升級SSD硬盤也能帶來8倍左右的IOPS提升;
2)替換Redis的硬盤，提升其性能;
3)用在CDN中，加快靜態資源加載速度。
微博平臺將SSD應用在分布式緩存場景中，將傳統的Redis/MC + Mysql方式，擴展為Redis/MC + SSD Cache + Mysql方式，SSD Cache作為L2緩存使用，第一降低了MC/Redis成本過高，容量小的問題，也解決了穿透DB帶來的數據庫訪問壓力。
垂直的監控與服務治理
隨著服務規模和業務變得越來越復雜，即使業務架構師也很難準確地描述服務之間的依賴關系，服務的管理運維變得越來難，在這個背景下，參考google的dapper和twitter的zipkin，平臺實現了自己的大型分布式追蹤系統WatchMan。
WatchMan大型分布式追蹤系統
如其他大中型互聯網應用一樣，微博平臺由眾多的分布式組件構成，用戶通過瀏覽器或移動客戶端的每一個HTTP請求到達應用服務器后，會經過很多個業務系統或系統組件，并留下足跡(footprint)。但是這些分散的數據對于問題排查，或是流程優化都幫助有限。對于這樣一種典型的跨進程/跨線程的場景，匯總收集并分析這類日志就顯得尤為重要。另一方面，收集每一處足跡的性能數據，并根據策略對各子系統做流控或降級，也是確保微博平臺高可用的重要因素。要能做到追蹤每個請求的完整調用鏈路;收集調用鏈路上每個服務的性能數據;能追蹤系統中所有的Error和Exception;通過計算性能數據和比對性能指標(SLA)再回饋到控制流程(control flow)中，基于這些目標就誕生了微博的Watchman系統。
該系統設計的一個核心原則就是低侵入性(non-invasivenss)：作為非業務組件，應當盡可能少侵入或者不侵入其他業務系統，保持對使用方的透明性，可以大大減少開發人員的負擔和接入門檻。基于此考慮，所有的日志采集點都分布在技術框架中間件中，包括接口框架、RPC框架以及其他資源中間件。
WatchMan由技術團隊搭建框架，應用在所有業務場景中，運維基于此系統完善監控平臺，業務和運維共同使用此系統，完成分布式服務治理，包括服務擴容與縮容、服務降級、流量切換、服務發布與灰度。
cache設計
這里簡單說一下兩個部分，一部分是Feed架構簡介，第二是cache的設計。
微博技術核心主要三個，一條微博有很多關注的人，分別將你發表的微博分發到你所有關注的人，聚合就是打開微博首頁這里看到我關注人的信息，以及這個微博信息的展現，微博在技術上也稱之為status或者Feed，下面圖就是一個典型的Feed。
Feed架構剛才是兩種設計模式推或者拉，還有第三種方式叫做復合型。做到一定程度單純推或者拉是不夠的。推的話如果把Feed比喻成郵件，推就是inbo不惜是收到的微博，OUTPOX是已發表的微博，發表到所有的粉絲，查看就是直接訪問到。PUSH優點就是實現簡單，通常做一個種型是首選方案，缺點就是分發量。PULL發表是在自己的outbox，查看是所有關注對象的inbox。 優點節約存儲，缺點是計算大量，峰值問題。當前訪問量比較大是不是計算得過來，服務器是不是夠用，假如說你的服務器是按照你峰值規劃你的服務器，在平時時 候是非常多的空閑，這個是不合理，不管推和拉都有一些共同的難題比如說峰值的挑戰，比如說世界杯活動在新浪微博每秒鐘發表量達到2500條，可以使用異步處理2500個峰值，處理速度慢一點，你關注人不能馬上看到，峰值過后保證系統不會被峰值壓跨，下面就是cache，現在有一句話對于這種real—time就是說：傳統硬盤已經不夠用，很多東西要分放在硬盤里面才能滿足需求。因此cache設計決定了一個微博系統的優劣。
里面是一種復合型，不是一個簡單的推或者拉的類型，因為就是說像新浪微博到這個級別要做很多優化，從模型上就是一個推或者拉的模型，按照它的關系來說，把cache分成需要四種存儲的東西，這兩個里面跟索引比較類似，第三就是列表和客戶自己資料。
看一下第一部分就是inbox微博首頁開始ID列表，完全是內存里面，但是有一個缺點，要添加元素需要先AET再SET；第二部分outbox發出微博有存儲最新ID在于聚合。為了高效，通常分兩部分，第一就是說最新的一個ID列表比如說有100條內容，這個用戶很久沒有來，這個是空要過來取就要從我工作列表用ID地址聚合起來；第三部分是關注列表，這些都是純ID，然后following，following加載開銷比較大，上百萬粉絲，越大的集合越容易變更，改變則需要deleteall減少使用followinglist場景；第四部分contetcache微博內容體里面有一個很重要的內容，熱內容。這個用戶有200萬粉絲，這個內容是熱內容，在線粉絲也非常多，多分防止單點訪問瓶頸，最終格式預生成，apenAPI需要返回xml，json格式。
剛才說了介紹cache的架構，現在介紹cache的第二個方面就是使用流程。有一個典型的場景，比如說發表cache怎么操作，首頁展現怎么操作。發表需要改變三個內容，首先要聲稱contentcache，對于常規contentcache也要做復制，如果對方粉絲在線會在inbox數值ID變更。
第三方面修改outbox，根據粉絲列表修改inbox數據列表，然后首頁Feed操作流程。左邊有兩個：inbox，outbox。兩個是可選的，如果inbox沒有一個樹型計算，會根據ID列表聚合起來反饋給I用戶。
獲取首頁Feed的流程，首先間看inbocache是否可用，獲取關注列表，聚合內容從following關系，根據idlist返回最終Feed聚合內容。最常用兩個流程就是這樣。
下面介紹微博cache經驗談，首先說流量。打開首頁，這個時候打一個I來說，比如說contentcache為例，比如multigntn條Feed，cache大小等于N，并發清且如1000次/秒，總流量等于50，20K。假如微博機房里面有1萬并發需要800MBPS貸款，如果不改變價格這個流量是實現不了。再一個1G內網做了很多壓力測試，一般環境跑三四百兆已經不錯了，你網內不光是訪問cache開銷，還有很多其他流量，因此微博需要優化帶寬訪問，可以把熱門數據加載到localcache，要用壓縮算法，可以做復制，有的時候將一個內部cache分組，不同的服務器組，訪問不同的cache減少內網通信的開銷。第一個問題就是帶寬的問題，其中內銷cache開銷訪問量大第一會碰到瓶頸。第二問題就是hotKeys，要訪問姚晨的微博，要建設一個Ilocolcache，刪除時間要把所有的都刪除。
cache規劃方面一些問題，將不同業務，不同長度KEY存儲到不同的MEMcache，不同的業務有不同的生命周期，LRUcache小量，memorystorage大部分，更高效的內存利用。
mutex，什么情況會出現這個問題，比如說一個很熱的內容，cache里面沒有了，因為memcache不是很可靠的東西，你放在里面可能會消失，經常出現這樣的情況：一個很熱的cache沒有了，因為微博系統有很多并發很熱數據沒有了，非常多的并發如果微博沒有一個很好的策略，比如說幾十個，幾百個加一個內容這會是一個悲劇。給每個KEY加載MUTEX，這個并發連接取數據庫，然后把mutex刪除成規，這個時候我只需要一個連接，數據庫加載到BD里面有可以了。
因為前面已經介紹很多內容，我今天介紹一個很簡單的東西就是想關注更多微博平臺的技術，有三個方向一個就是S2技 術沙龍，每個月舉行一次，另外就是說對很多講師光做講座不過癮，講座只是傳授別人東西，沒有能夠交流，所以微博對一線架構師有一個自己線下交流，一些實際中遇到的問題，對這些架構師有幫助提高，交流一下自己正在做，或者有一些東西還不成熟，不適合拿出來講的東西，可以線下交流。另外微博有各新浪微博開發大會，會介紹更多微博平臺架構分享的東西。
S2技術沙龍介紹了希望關注分享Web2.0技術，下面有一個它的網址，另外就是說介紹一下即將舉行一個新浪微博開發者大會，主要除了宣傳作用，希望更多分享新浪微博技術，比如說這個平臺需要架構與存儲，可能到時候講比今天更深入一些，會講一些sinaappengine技術，數據挖掘，合作與商業模式，開發者與平臺。目前有一個開發平臺的網站。
