億級用戶下的新浪微博平臺架構

本文轉自：https://www.infoq.cn/article/weibo-platform-archieture


編者按】《博文共賞》是 InfoQ 中文站新推出的一個專欄，精選來自國內外技術社區和我的博客上的技術文章，讓更多的讀者朋友受益，本欄目轉載的內容都通過原做者受權。文章推薦能夠發送郵件到editors@cn.infoq.com。

序言

新浪微博在 2014 年 3 月公佈的月活躍用戶（MAU）已經達到 1.43 億，2014 年新年第一分鐘發送的微博達 808298 條，如此巨大的用戶規模和業務量，須要高可用（HA）、高併發訪問、低延時的強大後臺系統支撐。

微博平臺第一代架構爲 LAMP 架構，數據庫使用的是 MyIsam，後臺用的是 php，緩存爲 Memcache。

隨着應用規模的增加，衍生出的第二代架構對業務功能進行了模塊化、服務化和組件化，後臺系統從 php 替換爲 Java，逐漸造成 SOA 架構，在很長一段時間支撐了微博平臺的業務發展。

在此基礎上又通過長時間的重構、線上運行、思索與沉澱，平臺造成了第三代架構體系。

咱們先看一張微博的核心業務圖（以下），是否是很是複雜？但這已是一個簡化的不能再簡化的業務圖了，第三代技術體系就是爲了保障在微博核心業務上快速、高效、可靠地發佈新產品新功能。

第三代技術體系

微博平臺的第三代技術體系，使用正交分解法創建模型：在水平方向，採用典型的三級分層模型，即接口層、服務層與資源層；在垂直方向，進一步細分爲業務架構、技術架構、監控平臺與服務治理平臺。下面是平臺的總體架構圖：

如上圖所示，正交分解法將整個圖分解爲 3*4=12 個區域，每一個區域表明一個水平維度與一個垂直維度的交點，相應的定義這個區域的核心功能點，好比區域 5 主要完成服務層的技術架構。

下面詳細介紹水平方向與垂直方向的設計原則，尤爲會重點介紹 四、五、6 中的技術組件及其在整個架構體系中的做用。

水平分層

水平維度的劃分，在大中型互聯網後臺業務系統的設計中很是基礎，在平臺的每一代技術體系中都有體現。這裏仍是簡單介紹一下，爲後續垂直維度的延伸講解作鋪墊：

1. 接口層主要實現與 Web 頁面、移動客戶端的接口交互，定義統一的接口規範，平臺最核心的三個接口服務分別是內容（Feed）服務、用戶關係服務及通信服務（單發私信、羣發、羣聊）。
2. 服務層主要把核心業務模塊化、服務化，這裏又分爲兩類服務，一類爲原子服務，其定義是不依賴任何其餘服務的服務模塊，好比經常使用的短鏈服務、發號器服務都屬於這一類。圖中使用泳道隔離，表示它們的獨立性。另一類爲組合服務，經過各類原子服務和業務邏輯的組合來完成服務，好比 Feed 服務、通信服務，它們除了自己的業務邏輯，還依賴短鏈、用戶及發號器服務。
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 由技術團隊搭建框架，應用在全部業務場景中，運維基於此係統完善監控平臺，業務和運維共同使用此係統，完成分佈式服務治理，包括服務擴容與縮容、服務降級、流量切換、服務發佈與灰度。

結尾

如今，技術框架在平臺發揮着愈來愈重要的做用，驅動着平臺的技術升級、業務開發、系統運維服務，本文限於篇幅限制，沒有展開介紹，後續會不斷地介紹核心中間件的設計原則和系統架構。