序言 新浪微博在2014年3月公佈的月活躍用戶（MAU）已經達到1.43億，2014年新年第一分鐘發送的微博達808298條，如此巨大的用戶規模和業務量，需要高可用（HA）、高併發訪問、低延時的強大後台系統支撐。
微博平台第一代架構為LAMP架構，資料庫使用的是MyIsam，後台用的是php，快取為Memcache。
隨著應用程式規模的成長，衍生出的第二代架構對業務功能進行了模組化、服務化和組件化，後台系統從php替換為Java，逐漸形成SOA架構，在很長一段時間支撐了微博平台的業務發展。
在此基礎上又經過長時間的重構、線上運作、思索與沉澱，平台形成了第三代架構體系。
我們先來看一張微博的核心業務圖（如下），是不是非常複雜？但這已經是一個簡化的不能再簡化的業務圖了，第三代技術體係就是為了保障在微博核心業務上快速、有效率、可靠地發布新產品新功能。
第三代技術體系 微博平台的第三代技術體系，使用正交分解法建立模型：在水平方向，採用典型的三級分層模型，即介面層、服務層與資源層；在垂直方向，進一步細分為業務架構、技術架構、監控平台與服務治理平台。以下是平台的整體架構圖：
如上圖所示，正交分解法將整個圖分解為3*4=12個區域，每個區域代表一個水平維度與一個垂直維度的交點，相應的定義這個區域的核心功能點，例如區域5主要完成服務層的技術架構。
以下詳細介紹水平方向與垂直方向的設計原則，特別會重點介紹4、5、6中的技術元件及其在整個架構體系中的作用。
水平分層 水平維度的劃分，在大中型網路後台業務系統的設計中非常基礎，在平台的每一代技術體系中都有體現。這裡還是簡單介紹一下，為後續垂直維度的延伸講解做鋪墊：
[size=15.4545450210571px]1，介面層主要實現與Web頁面、行動用戶端的介面交互，定義統一的介面規範，平台最核心的三個介面服務分別是內容（Feed）服務、用戶關係服務及通訊服務（單發私訊、群發、群組聊天）。
[size=15.4545450210571px]
[size=15.4545450210571px]2，服務層主要將核心業務模組化、服務化，這裡又分為兩類服務，一類服務，一類類別為原子服務，其定義是不依賴任何其他服務的服務模組，例如常用的短鏈服務、發號器服務都屬於這一類。圖中使用泳道隔離，表示它們的獨立性。另外一類為組合服務，透過各種原子服務和業務邏輯的組合來完成服務，例如Feed服務、通訊服務，它們除了本身的業務邏輯，還依賴短鏈、用戶及發號器服務。
[size=15.4545450210571px]
[size=15.4545450210571px]3，資源層主要是資料模型的存儲，包含通用的快取資源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由技術團隊建構框架，應用在所有業務場景中，維運基於此系統完善監控平台，業務與維運共同使用此系統，完成分散式服務治理，包括服務擴容與縮容、服務降級、流量切換、服務發布與灰階。
結尾 現在，技術框架在平台發揮越來越重要的作用，驅動著平台的技術升級、業務開發、系統運維服務，本文限於篇幅限制，沒有展開介紹，後續會不斷地介紹核心中間件的設計原則和系統架構。
關於作者 衛向軍（@衛向軍_微博），畢業於北京郵電大學，現任微博平台架構師，先後在微軟、金山雲、新浪微博從事技術研發工作，專注於系統架構設計、音視訊通訊系統、分散式檔案系統和資料探勘等領域。
[size=15.4545450210571px]本文轉自InfoQ 公眾號：ucaicn 誠意推薦
[url=]檢舉[/url |
