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

閱讀文章：億級用戶下的新浪微博平臺架構

文章網址：https://mp.weixin.qq.com/s?__biz=MzA3NzgzMzUxMw==&mid=203412989&idx=4&sn=2df0c60f56ae1e228ff269420803c3ef&scene=21#wechat_redirect

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

 隨着應用規模的增加，衍生出的第二代架構對業務功能進行了模塊化、服務化和組件化，後臺系統從php替換爲Java，逐漸造成SOA架構，在很長一段時間支撐了微博平臺的業務發展。在此基礎上又通過長時間的重構、線上運行、思索與沉澱，平臺造成了第三代架構體系。

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

水平分層

（1）接口層主要實現與Web頁面、移動客戶端的接口交互，定義統一的接口規範，平臺最核心的三個接口服務分別是內容（Feed）服務、用戶關係服務及通信服務（單發私信、羣發、羣聊）。

（2）服務層主要把核心業務模塊化、服務化，這裏又分爲兩類服務，一類爲原子服務，其定義是不依賴任何其餘服務的服務模塊，好比經常使用的短鏈服務、發號器服務都屬於這一類。圖中使用泳道隔離，表示它們的獨立性。另一類爲組合服務，經過各類原子服務和業務邏輯的組合來完成服務，好比Feed服務、通信服務，它們除了自己的業務邏輯，還依賴短鏈、用戶及發號器服務。

（3）資源層主要是數據模型的存儲，包含通用的緩存資源Redis和Memcached，以及持久化數據庫存儲MySQL、HBase，或者分佈式文件系統TFS以及Sina S3服務。

垂直延伸技術架構

區別於水平方向上層依賴下層的關係，垂直方向以技術框架爲地基支撐點，向兩側驅動影響業務架構、監控平臺、服務治理平臺，下面介紹一下其中的核心組件。

（1）接口層Web V4框架

接口框架簡化和規範了業務接口開發工做，將通用的接口層功能打包到框架中，採用了Spring的面向切面（AOP）設計理念。接口框架基於Jersey 進行二次開發，基於annotation定義接口(url, 參數)，內置Auth、頻次控制、訪問日誌、降級功能，支撐接口層監控平臺與服務治理，同時還有自動化的Bean-json/xml序列化。

（2）服務層框架

服務層主要涉及RPC遠程調用框架以及消息隊列框架，這是微博平臺在服務層使用最爲普遍的兩個框架。

（3）資源層框架

資源層的框架很是多，有封裝MySQL與HBase的Key-List DAL中間件、有定製化的計數組件，有支持分佈式MC與Redis的Proxy。這裏分享一下平臺架構的對象庫與SSD Cache組件。

隨着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由技術團隊搭建框架，應用在全部業務場景中，運維基於此係統完善監控平臺，業務和運維共同使用此係統，完成分佈式服務治理，包括服務擴容與縮容、服務降級、流量切換、服務發佈與灰度。