1. 程式人生 > >微博服務架構

微博服務架構

前幾天因為鹿晗關曉彤事件,導致新浪微博崩潰幾分鐘。這種情況發生不止一次了,但是新浪顯然並沒有去處理,不由得想起來雙11億級流量,淘寶也會有預測的加資源來解決高併發問題,但是在正常時期不會有那麼多那麼流量,所以不可能一直留有那麼資源,顯然要耗資很多啊。這次新浪的做法也是暫時從阿里雲伺服器租借1000臺,頂住了併發壓力,幾個小時後就歸還了。和淘寶雙11做法很像,只不過新浪微博這種併發是不可預測的,誰都沒有想到。。。
臨時加1000臺伺服器,抗住壓力,資料庫是無法做到那麼快的臨時彈性伸縮,能做彈性伸縮的無非就是Http Server、中介軟體等。
看了知乎大神的分析(連結:

https://www.zhihu.com/question/66346687),個人覺得還是微博的自動擴容演算法做的比較好,當流量突然升高了,而且需要很多臺伺服器時,不可能全部交給演算法來做,需要人工手動確認,要不然萬一出現神馬bug,這得損失多少錢啊。
下面是新浪微博的平臺架構,~

序言

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

微博平臺第一代架構為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由技術團隊搭建框架,應用在所有業務場景中,運維基於此係統完善監控平臺,業務和運維共同使用此係統,完成分散式服務治理,包括服務擴容與縮容、服務降級、流量切換、服務釋出與灰度。

結尾

現在,技術框架在平臺發揮著越來越重要的作用,驅動著平臺的技術升級、業務開發、系統運維服務,本文限於篇幅限制,沒有展開介紹,後續會不斷地介紹核心中介軟體的設計原則和系統架構。

本文首發於“微博平臺架構”微信公眾號,釋出時有少量的文字潤色和調整。

關於作者

衛向軍(@衛向軍_微博),畢業於北京郵電大學,現任微博平臺架構師,先後在微軟、金山雲、新浪微博從事技術研發工作,專注於系統架構設計、音視訊通訊系統、分散式檔案系統和資料探勘等領域。

前幾天因為鹿晗關曉彤事件,導致新浪微博崩潰幾分鐘。這種情況發生不止一次了,但是新浪顯然並沒有去處理,不由得想起來雙11億級流量,淘寶也會有預測的加資源來解決高併發問題,但是在正常時期不會有那麼多那麼流量,所以不可能一直留有那麼資源,顯然要耗資很多啊。這次新浪的做法也是暫時從阿里雲伺服器租借1000臺,頂住了併發壓力,幾個小時後就歸還了。和淘寶雙11做法很像,只不過新浪微博這種併發是不可預測的,誰都沒有想到。。。
臨時加1000臺伺服器,抗住壓力,資料庫是無法做到那麼快的臨時彈性伸縮,能做彈性伸縮的無非就是Http Server、中介軟體等。
看了知乎大神的分析(連結:https://www.zhihu.com/question/66346687),個人覺得還是微博的自動擴容演算法做的比較好,當流量突然升高了,而且需要很多臺伺服器時,不可能全部交給演算法來做,需要人工手動確認,要不然萬一出現神馬bug,這得損失多少錢啊。
下面是新浪微博的平臺架構,~