11.11大促，隨著移動端業務量的急劇提升，像小米推送這樣的基礎服務也經受了巨大的考驗。11月12日，小米的項目總監汪軒然在微博上宣布，“小米推送服務共發出9.65億條消息，平均每分鐘發送67萬條。更值得一提的是，后臺監控顯示，推送服務后臺系統在全天運作非常平穩，沒有任何卡頓擁堵現象，讓各種促銷、返利、訂單更新消息***時間觸達用戶。”

汪軒然，2007年畢業于清華大學計算機系，后加入微軟亞洲工程院，曾參與WP7上的瀏覽器的開發。2010年7月加入小米，曾擔任米聊安卓團隊的團隊主管，現在在小米任項目總監，負責小米的開發者服務，掌管推送服務、統計服務和移動廣告聯盟三大業務，旨在為小米搭建一個移動App業務的互聯網生態圈。

我們聯系了汪軒然，就小米推送服務的架構、特點、性能等問題對他進行了采訪，以下內容根據本次采訪整理而成。

基礎技術架構

協議是推送服務的核心。小米推送服務所采用的協議是由之前的米聊演變過來的，而米聊從一開始就選擇使用XMPP協議，之后開發團隊對XMPP協議做過幾輪精簡和重構。現在XMPP部分只是作為一個數據的傳輸層，之上跑著各種獨立的業務，每個業務稱為一個“channel”；每個channel上跑的數據格式可以是不一樣的。消息推送服務是其中一個channel，這個channel上傳輸的數據是通過Thrift進行二進制化的協議格式。

再來看一下小米推送服務的服務端架構。下圖是后臺服務端的一個基本架構圖。整個服務端包含如下幾層：

1. XMPP前端：用于維護跟客戶端之間的長連接，使用EJabberd項目來處理來自客戶端的XMPP請求，同時通過XMQ模塊來處理推送服務特有的XMPP消息協議。
2. 中間層：業務邏輯層，主要用于將消息請求異步化、創建和維護消息隊列、以及處理客戶端的一些命令請求（注冊、設置別名、設置topic等）。
3. HTTP前端：這一層負責對接來自第三方App的服務器的發消息的HTTPS請求，以及來自客戶端生成賬號的HTTPS請求。

再就是數據存儲，這里采用了小米的統一HBase存儲，同時還使用MySQL來保存一些量不大，但需要復雜過濾條件的數據（topic等），并且為了降低對HBase的壓力，中間還加了一層Redis作為緩存。

***看一下客戶端架構。客戶端SDK主要包含兩個層次：SDK層和PushService層。前者提供了面向App接入的接口、回調方法以及對Thrift的數據進行反序列化的處理邏輯；后者用于維護XMPP長連接和收發消息。兩層之間使用Intent方式來傳輸數據。值得一提的是，在MIUI系統上，PushService層是系統共用的，即MIUI系統提供了一個統一的PushService管理模塊，不需要每個應用單獨啟動自己的PushService。

功能實現

小米推送服務支持單發和群發消息兩種推送方式。單發消息支持針對regID和別名兩種方式，regID是小米推送服務后臺根據設備標識+appID+時間戳生成，為了減少設備碰撞概率，設備標識我們采用的依據是imei+AndroidID+build序列號。別名是App在客戶端設置上報的，便于應用將自己的設備/用戶標識符同我們的regID作關聯，這樣App就不需要在后臺維護regID跟設備/用戶的對應關系了。群發消息采用打標簽的方式來區分，客戶端和服務端都可以給指定設備設置標簽，發消息的時候，只需選取指定標簽發送即可，小米推送后臺會將標簽所對應的設備展開。一個標簽支持的設備數無上限。

那小米推送服務的穩定性是如何保證的呢？小米推送服務采用多機房方案，平時流量均攤，一旦某個機房出現故障，流量無縫切換到其它機房，并且單個機房的容量能保證提供無損服務。目前是雙機房部署，預計明年會擴展第三個機房。

安全性也是小米推送服務重點考慮的一個因素。數據傳輸過程中，得益于推送服務采用的雙層協議方案，消息會采取雙重加密，***重是XMPP傳輸層，保證數據在網絡傳輸的過程中不會被篡改、監聽。第二重是在Thrift二進制層，用以保證消息到達Service之后，通過broadcast發送給App進程的過程中不會被截獲和偽造。第二重加密往往會被其它第三方推送服務忽略，但其風險同樣很大。

性能指標

11.11大促，所面對的請求量是在小米推送服務的設計容量之內的，目前設計和機器規模可以支持峰值每分鐘1000萬條消息；平時業務量至少每分鐘40萬，峰值每分鐘600萬條消息。

推送消息量平時波動很大，所以開發團隊準備著流量隨時可能忽增200%的情況，并在線下做好壓力測試和優化；如果流量特別大，還有以下應對措施：

1. 異步排隊處理，此時消息送達時間可能會比平時稍慢，但不會對整個系統有太大沖擊；
2. 消息有優先級，廣播消息會以低優先級處理；
3. 限流，控制開發者發送消息的頻率；
4. 擴容，如果機器負載過高或者某個服務有瓶頸，可以很快速地增加機器，部署服務，增強系統處理能力。

小米推送服務所經歷的重構

軟件系統在開發和演進過程中，經常會經歷較大規模的重構。小米推送服務有兩次比較大的重構。

一是開發語言從Erlang 轉為Java。 小米原來的消息系統是使用Erlang開發的，所以推送系統的***版也是基于Erlang；但是Erlang的社區不夠活躍，開發人員很難找，學習曲線陡，支持工具和類庫少，所以后來開發團隊選擇了使用Java重新開發；遷移到Java后，對開發人員的要求降低，各種工具和類庫較多，大大提高了開發效率。

二是無處不在的Cache。客戶端使用小米推送服務的SDK，開發者使用API的情況千變萬化，很多場景是意料之外的；需要對調用頻繁的業務添加Cache，盡可能在本地進程內處理；例如，對于客戶端調用API設置別名和訂閱topic，先檢查Cache是否已經設置過，只有沒有設置才往后端服務發送；優化后，后臺服務的業務壓力大大減少。

在開發小米推送過程中的一些感悟

1. 服務要支持水平擴展，盡可能實現為無狀態，或者使用一致性哈希進行劃分；方便擴容，可以保證即使系統暫時有性能瓶頸也能通過加機器解決。

2. 監控先行，能夠很方便地采集、分析服務器的負載和業務的請求量、percentile、slow log，能夠清楚了解到系統的瓶頸，有針對性地改進。
3. 不要過早優化，先實現功能并盡快上線，根據監控數據對關鍵地方進行優化。
4. 敏捷開發，快速迭代，日拱一卒，每天都有簡短的站立會議，能夠迅速響應變化，持續改進系統。