新浪微博，作為當今國內最大的基於社交媒體之一，我們就不用在這贅述了。
今天我站在架構的角度上，從技術跟設計方面給大家通俗的講一下，如果不對，請指出，我本是事實的角度，一定回承認，改正，謝謝。
12月31日跨年夜，網友再次刷新微博發送峰值。根據微博方面的數據，2016年第一分鐘,微博用戶共發出883536條微博，超過去年同期。
跨年期間，相關微博互動量達1.38億，2947萬用戶發佈4414萬條微博，整體閱讀量達到106億。微博推出的#哈嘍2016#新年許願活動，兩天裡收集了166萬多條網友的新年願望，閱讀量超過3億。
如此巨大的用戶規模和業務量，需要高可用（HA）、高併發訪問、低延時的強大後臺系統支撐。
微博平臺第一代架構為LAMP架構，數據庫使用的MyIsam，後臺用的php，緩存為Memcache。
隨著應用規模的增長，衍生出的第二代架構對業務功能模塊化、服務化、組件化，後臺系統從php替換為Java，逐漸形成面向服務的SOA架構（面向服務的架構），在很長一段時間支撐微博平臺業務發展。
SOA架構
在此基礎上又經過長時間的重構、線上運行、思索與沉澱，平臺形成了第三代架構體系。
我們先看一張微博的核心業務圖（如下），是不是非常複雜，但這已經是一個簡化的不能再簡化的業務圖啦，第三代技術體系就是為了保障在微博核心業務上快速、高效、可靠的發佈新產品新功能。
新浪微博心業務圖
第三代技術體系
微博平臺的第三代技術體系，使用正交分解法建立模型，在水平方向，採用典型的三級分層模型，即接口層、服務層與資源層，在垂直方向，進一步細分為業務架構、技術架構、監控平臺與服務治理平臺，接著看一下平臺的整體架構圖。
第三代技術體系
正交分解法將整個圖分解為3*4=12個區域，每一個區域代表一個水平維度與一個垂直維度的交點，相應的定義這個區域的核心功能點，比如區域5主要完成服務層的技術架構，下面詳細介紹水平方向與垂直方向的設計原則，尤其重點介紹4、5、6中的技術組件及其在整個架構體系中的作用。
水平維度的劃分，在大中型互聯網後臺業務系統的設計中非常基礎，在平臺的每一代技術體系中都有體現，這裡還是簡單介紹一下，為後續垂直維度的延伸講解做鋪墊：
- 接口層主要實現與Web頁面、移動客戶端的接口交互，定義統一的接口規範，平臺最核心的三個接口服務分別是內容（Feed）服務、用戶關係服務以及通訊服務（單發私信、群發、群聊）。
- 服務層主要把核心業務模塊化、服務化，這裡又分為兩類服務，一類為原子服務，定義是不依賴任何其他服務的服務模塊，比如常用的短鏈服務、發號器服務都屬於這一類，圖中使用泳道隔離，表示它們的獨立性，另外一類為組合服務，通過各種原子服務和業務邏輯的組合，完成的Composite服務，比如Feed服務、通訊服務除了本身的業務邏輯，還依賴於短鏈、用戶、以及發號器服務。
- 資源層主要數據模型的存，包含通用的緩存資源Redis和MC，以及持久化數據庫存儲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）。但是這些分散的數據對於問題排查，或是流程優化都幫助有限。對於這樣一種典型的跨進程/跨線程的場景，彙總收集並分析這類日誌就顯得尤為重要。另一方面，收集每一處足跡（footprint）的性能數據，並根據策略對各子系統做流控或降級也是確保微博平臺高可用的重要因素。要能做到追蹤每個請求的完整調用鏈路；收集調用鏈路上每個服務的性能數據；能追蹤系統中所有的Error和Exception；通過計算性能數據和比對性能指標（SLA）再回饋到控制流程（control flow）中，基於這些目標就誕生了微博的Watchman系統。
其系統設計一個核心原則就是低侵入性（non-invasivenss）：作為非業務組件，應當儘可能少侵入或者不侵入其他業務系統，保持對使用方的透明性，可以大大減少開發人員的負擔和接入門檻。基於此考慮，所有的日誌採集點都分佈在技術框架中間件中，包括接口框架、RPC框架以及其他資源中間件。
WatchMan由技術團隊搭建框架，應用在所有業務場景中，運維基於此係統完善監控平臺，業務和運維共同使用此係統，完成分佈式服務治理，包括服務擴容與縮容，服務降級，流量切換，服務發佈與灰度。
微博發佈模式
- 同步推模式
早期的架構中，用戶發表微博後，系統會立即將這條微博插入到數據庫所有分析的訂閱列表中。當用戶量較大時，特別是明星用戶發佈微博時，會引起大量的數據庫寫操作，系統性能急劇下降，發佈微博延遲加劇。
- 異步推拉模式
用戶發表微博後，系統將微博寫入消息隊列後立即返回，用戶響應迅速。消息隊列的消費者任務將微博推送給所有當前在線的粉絲的訂閱列表中，非在線用戶在登錄後再根據關注列表拉去微博訂閱列表。
我們再看一下目前即將推出的微博平臺的新架構。我們知道API大部分的請求都為了獲取最新的數據。API請求有一個特點，它大目前調用都是空返回的，比如說一款手機的客戶端每隔一分鐘它都要調用服務器一下，就是有沒有新數據，大目前的調用都是空返回，就是說不管服務器有沒有數據都要調用一次。這次詢問到下一次詢問中間，如果有新的數據來了，你是不會馬上知道的。因此我們想API能不能改用推的方式，就是客戶端不需要持續的調用，如果有新數據就會推過去。技術特點，顯而易見低延遲，就是從發表到接受1秒內完成，實際上可能用不了1秒。然後服務端的連接就是高併發長連接服務，就是多點都連接在我們的服務器上，這個比傳統的API要大。
我們再看一下內部細節，就是我們收到數據之後首先要經過最上面RECEIVER。然後推到我們的引擎裡面，這個引擎會做兩個事情，首先會把用戶的關係拿過來，然後按照用戶關係馬上推送給他相應的粉絲。所以我們調用方已經在那兒等待了，我們需要有一個喚醒操作，就是說在接口這兒把它喚醒，然後把它發送過去。最後是一個高併發的長連服務器，就是一臺服務器支持10萬以上的併發連接。最右邊中間有一個圓圈叫做Stream Buffer，我們需要Stream Buffer是要保存用戶最近的數據。因為用戶可能會有斷線的，比如說他發送數據的時候斷線半分鐘，我們需要把這半分鐘補給他。這就是我們的推送架構。
第二部分：設計原則
用戶規模影響設計，具體是指用戶數每上一個數量級，許多設計需要重新考慮。
10萬用戶級別
單服務器，前端、後端、cache、db在一起。
百萬級
db和cache單獨部署服務器，db或按業務進行拆分(sharding)。
cache或使用一致性hash擴展。
前端後端還是在一起，但是根據業務拆分，每個業務可分配不同數量的服務器
千萬級
開始重視架構設計，有專門技術架構師
需跨機房部署，前端在遠程增加反向代理加速，數據庫在異地機房使用slave數據庫副本
後端拆分出來，系統內部需要遠程調用，內部需遠程調用協議。
億級
架構更細分，或增加數據架構師，cache架構師，分佈式架構師
數據庫sharding碰到煩惱，開始考慮分佈式數據服務
數據訪問需要根據業務特點細分。
開發、運維、測量、調優具備有自己的專有工具。
所有服務需要地理多機房分佈，具備IDC容災設計。
服務可降級
