阿里無線11.11：手機淘寶移動端接入網關基礎架構演進之路

移動網絡優化是超級App永恆的話題，對於無線電商來講更爲重要，網絡請求體驗跟用戶的購買行爲息息相關，手機淘寶從過去的HTTP API網關，到2014年升級支持SPDY，2015年雙十一自研高性能、全雙工、安全的ACCS（阿里雲通道服務)扛住雙十一戰場主要流量，不管是基礎架構的演進、網絡調優、協議的優化、異地多活、網絡調度上都有很多寶貴的經驗與你們分享。

ACCS基於無線場景精心設計的雙工 、安全、低時延、開放的移動統一接入層服務，在雙十一當天穩定高效地服務了近2億的在線用戶，支持了峯值4500萬的在線長鏈接，這個背後的故事以及咱們的思考是什麼呢？

1.業務高速發展下訴求

回到一年前，移動電商在2014年雙十一業務開始興起，2014年雙十一當天移動成交243億佔總體571億的42.6%，業務高速發展但願更多主動推送去觸達用戶，一些新的玩法和互動形式，須要鏈接買家與買家、買家與賣家、買家與達人，由於沒有有效的通道能力，業務採起的是不停去輪詢服務器，一來對服務器形成沒必要要的壓力，二來對於用戶手機的電量流量也是極大的浪費，關鍵在大促當天沒必要要的請求過大甚至會致使後端集羣限流，從而影響到用戶體驗。

信息傳播形態的變化的背後是移動化帶來新的技術特徵致使的結果。在過去的幾年，移動電商從無到有，手機淘寶一直是這個領域的先行者。移動電商從最初的複製WEB的業務形態到移動特性不斷涌現，更多的互動形式的出現，向社交化、娛樂化不斷邁進的今天，一個單純的商品的陳列架形式已經不能知足業務的需求。業務上須要實時的觸達用戶，充分發揮移動的特性，將消費時間的碎片利用起來，事實也證實了用戶的消費時間隨着移動化的進程不斷髮生變化，逐步分佈到全天的碎片時間中。同時貨架形態也在向社區化、娛樂化的方向發展，這些都對網絡層鏈接用戶有了更高的要求。更多的媒體形態和展現方式，對網絡層提出了更多元的要求。你們能夠關注到手機淘寶內的消息盒子、微淘、淘友這些產品都是業務求變的體現，業務的變化倒逼技術的前進。

2.移動網絡環境依然嚴峻

移動網絡的速度在過去幾年有很大提高，但網絡環境的多樣性和差別性使移動網絡的環境更加複雜，在去年雙十一以前咱們還常遇到一些移動網絡劫持的事情。網絡劫持這塊問題的排查效率很低，須要找到用戶、復現現場，甚至找網工、運營商配合排查，一查就是幾天過去。同時在咱們的輿情反饋上老是看到用戶在說－「某個頁面加載中、頁面打不開、請求很慢、打開某個功能很慢」，面對這些問題過去咱們是沒有太好的辦法，只能貓抓耗子一樁樁去排雷很被動。不少網絡的問題是偶現的，一旦錯過如今就無從查起，背後的緣由不少：

1. 運營商問題
2. 機房部署緣由
3. 客戶端SDK Bug
4. 弱網和網絡抖動
5. DNS劫持和數據篡改

PC時代咱們訪問網站的接入條件是相對恆定的，因此在開發時不多考慮網絡對用戶體驗的影響。可是移動APP則否則，尤爲是在中國，基礎的移動網絡環境並很差，並且咱們有不少用戶的訪問是發生在地鐵、公交車這樣的移動環境下，移動基站的頻繁切換進一步增長了網絡的不穩定。從手機淘寶的數據能夠看出，咱們天天活躍用戶中有很多來自於相似2G這樣的弱網環境。若是端到雲的鏈接不穩定、高延時，那麼全部的用戶體驗都無從談起。

基礎網絡的效率就像一輛列車，時延是火車的速度(啓動時間)，而帶寬就像火車的車箱裝載量，整個傳輸的物理鏈路就像火車的鐵軌。目前現實條件下的移動網絡條件很是複雜，既有高鐵這樣先進的傳輸渠道，也有很多老舊緩慢的綠皮車還在服務不少用戶。咱們的目標很簡單，就是想讓全部用戶都能在手機淘寶得到流暢的體驗，不論你坐的是「高鐵」仍是「綠皮車」。

下面這張圖，可以讓你們更加直觀的瞭解中國的移動網絡環境。描述了從用戶到IDC的端到端的路由狀況，不只數據傳輸耗時長且丟包率高，同時安全性也是至關糟糕的，DNS劫持、內容劫持在中國就是屢見不鮮。

所以咱們在改善網絡通道上有不少的事情能夠去作，去探索突破運營商基礎網絡的限制，力爭爲用戶創造極致的購物體驗。

3.ACCS總體架構

爲了知足移動電商業務高速發展的需求，咱們決定打造一個世界級的網絡接入服務，構建一個無線網絡下」水、電、煤「 同樣的基礎設施。這樣一個基礎設施須要作到的四個目標：

「 雙工、低延時、安全、開放」。在這四個目標之上是圍繞這個接入服務配套的運維體系，幫助最終用戶取得良好的端上體驗的同時，幫助開發者快速構建本身的業務。

如圖-1所示，在整個接入服務上咱們劃分爲兩層，接入網關層和應用網關層。接入網關負責鏈接的保持、消息的解析、消息的分發。應用網關實現各類應用層協議：API、SYNC、RPC、PUSH等，在應用網關的背後是具體的業務系統。同時咱們創建了一個統一調度服務，而不是採用傳統的DNS，調度服務是咱們的控制中心，經過它咱們能夠強有力的指揮咱們的客戶端，而且不會受到DNS污染的影響。

與服務端的分層架構對應的是客戶端的SDK，最底層的統一網絡庫SDK集中了咱們對網絡優化的策略，並向上爲各個應用網關技術的SDK提供API。

(圖-1)

基於上面的開放架構，業務方能夠選擇直接開放具體的後端服務對接不一樣的應用網關，不須要了解網絡背後的細節，並經過應用網關如API網關提供的開發工具快速生成客戶端代碼。業務方也能夠基於這個接入層設計本身的協議。

統一接入層集中管理了用戶的設備、在線狀態，並提供信息的雙向傳遞能力。以下圖所示：

(點擊放大圖像)

網關將致力於解決中間網絡的通信，爲上層的服務提供高質量的雙向通信能力。

4.穩定性與容災

穩定性與容災是服務端中間件永恆的主題，統一接入層這樣一個匯聚網關收益和風險是並存的，一旦這個入口故障了，波及的用戶範圍是不可想象的，如何作的更加穩定，是一個巨大的挑戰。

4.1 網關架構的優化

對於一個統一網關來講，對接的業務網關的信息傳遞特色是不同的，大部分的業務在全天都是比較平緩的，可是個別營銷類業務會在短期內發佈海量的信息，這樣的信息發佈會搶佔網關的大量資源，對於用戶的正常訪問會產生影響。

舉個例子，push服務須要經過網關推送2億條消息，而這些消息須要在短期內所有推送完，而同時網關在爲正常的用戶的交互提供服務，海量信息的推送和正常的用戶交互相互競爭資源，最終會形成正經常使用戶的交互失敗，對於業務來講，這是不可接受的。

基於上面的狀況考慮整個網關在佈署上分爲兩個集羣，一個集羣處理常態的在線用戶訪問，另外一個集羣處理海量信息的推送。以下圖-2所示，經過這樣的方式，避免了業務形態不一樣，對統一網關的衝擊，將不一樣的業務形態進行了隔離。

(點擊放大圖像)

(圖-2)

4.2 異地多活

阿里這兩年一直在實施的異地多活的架構，在異地多活的總體方案中，統一網關承擔了快速引導流量的職責，也是這一方案順利實施的一個重要環節。

異地多活是一個多機房的總體方案，在多個地區同時存在對等的多個機房，以用戶維度劃分，多機房共同承擔全量用戶的流量；在單個機房發生故障時，故障機房的流量能夠快速的被遷引到可用機房，減小故障的恢復時間。

4.2.1 無線接入層單元化的協商機制

先看一下web端在這異地多活中的實現方式

(圖-3)

從圖-3能夠看到，瀏覽器的業務器求會發給CDN，由CDN上保存的分發規則，向後續的單元機房分發。無線端也這樣作嗎？客戶端擁有強大的能力，能夠作的更靈活；CDN的分發節點帶來更多的機器成本；對於須要雙工通信能力的客戶端，消息投遞更爲複雜。這些是咱們思考與WEB不一樣的地方，是否是能作些不同的選擇？

(圖-4)

如圖-4, 咱們藉助了客戶端的強大能力，利用協商的機制來完成用戶的請求正確被分配到不一樣的單元，含如下幾點:

1. 客戶端的請求始終帶上當前用戶歸屬單元的信息。
2. 當請求到達服務端時，服務端判斷用戶歸屬單元是否正確，不正確將用戶重定向到正確的單元 。
3. 當前請求由網關在服務端上經過跨單元調用保證業務的正確性。
4. 當客戶端歸屬單元更新後，後續的請求都會發到正確的單元機房。

4.2.2 無線接入層單元化的旁路調度

協商機制看起來很不錯，這裏一個重磅炸彈丟過來了，機房的入口網絡斷了！

(圖-5)

如圖-5, 外網不可用，協商的機會都沒有故障單元的用戶沒法恢復，這時旁路的調度服務出場了。

(圖-6)

如上圖-6, 咱們設計的調度中心這時又承擔了單元化的旁路調度職責,當app訪問的單元沒法訪問的時候, app會訪問不一樣單元的調度中心，詢問用戶的歸屬單元，經過這種方式取得可用的單元節點，將用戶切到正確的單元。這個方案一樣適用於單機房的接入層網關不可用的場景。

4.2.3 應用層網關不可用

某個單元機房的應用層網關不可用，這時等待應用網關排查問題須要的時間比較久，爲了達到最快的故障恢復，咱們經過開關把修改接入層的轉發規則，將流量切到可用的單元。以下圖-7

(圖-7)

5.端到端網絡優化

5.1 統一網絡庫

在作網絡優化一開始，咱們想作一個通用的網絡庫，這個網絡庫包含策略、httpDNS、SPDY協議等一切系統網絡優化須要的方方面面。上層api網關請求邏輯、推送邏輯、上傳下載邏輯對於這樣一個通用網絡庫來講都是業務。在分層上將通用網絡庫和上層應用邏輯分開、完全解耦，對長期持續優化網絡是頗有必要。以下圖-8所示架構。

(圖-8)

這樣架構上分離，可讓咱們更專一更系統化去作無線網絡優化。統一網絡庫的幾個重要特性:

1. 靈活控制客戶端網絡行爲策略(建連、超時處理、請求協議、是否加密）
2. 包含HTTPDNS，支持異地多活
3. 更細粒度控制和調度(域名級和域名下參數級)

一、二、3均由網絡調度中心的集羣控制，咱們但願這個能夠作到與業務無關，去掉一些阿里的業務屬性後，這個模塊你們能夠理解爲HTTPDNS，能夠理解咱們在HTTPDNS以外作了大量網絡優化的端到端的工做。

5.2 就近就快接入

基於網絡庫咱們實現了一套智能學習的網絡策略，智能學習客戶端在不一樣網絡環境下建連策略，用戶從新回到這個網絡環境會給出最優的策略進行快速鏈接，並按期去更新或淘汰本地cache的歷史最優網絡策略。爲了建連更加迅速在各自網絡下穿透性更好，接入服務器支持了多種協議和端口，客戶端建連時能夠極速接入網絡。咱們有一個重要指標是打開客戶端30S內網絡請求成功率，就是關注連的快給用戶體驗帶來的價值。

基於調度中心，咱們搭建了一個智能大數據分析平臺，將客戶端在在網絡請求過程當中的數據如建連時間、首包收取時間、整包收取時間、ssl握手時間等重要指標收集上來 。根據這些指標分析出網絡異常區域，調整咱們的就近就快接入規則，甚至推進IDC建設和CDN的布點完善。

5.3 弱網優化和抗抖動

在弱網優化上咱們嘗試了QUIC,在網絡延時較高、丟包嚴重狀況下比TCP有更好表現。線上手機淘寶灰度版本實測切換到QUIC後，平均RT收益有接近20%。考慮QUIC在移動網絡可能存在穿透性問題,將來咱們將採起SPDY爲主，QUIC爲輔助的模式來完善咱們的網絡連接策略。一樣在一些網絡環境較差狀況下，咱們採起長短連接結合方式，在長連接遇到請求超時或穿透性較差狀況，利用短連接HTTP短連接去請求數據(在移動網絡環境下HTTP協議尤爲HTTP1.0的穿透性是最好的)，這樣能夠在一些極端狀況下最大程度保證用戶體驗。數據以下圖-9

(點擊放大圖像)

網絡切換和網絡抖動狀況下的技術優化也是一個很重要的方面，咱們常常遇到移動設備網絡切換和信號不穩定的狀況，在這種狀況咱們怎麼保證用戶的體驗？

針對這種狀況咱們的思路是有策略合理增長重試。咱們對一個網絡請求以是否發送到socket緩衝區做爲分割，將網絡請求生命週期劃分爲「請求開始到發送到 socket緩衝區」和「已經發送到socket緩衝區到請求結束」兩個階段。在階段一內請求失敗了，會根據業務需求幫助業務請求去作重試。階段二請求失敗只針對讀操做提供重試能力。

設想一個場景：用戶在進電梯發起一個刷新數據請求，進到電梯由於網絡抖動的緣由網絡連接斷了，這個時候咱們可以合理策略去作重試，這樣當用戶離開電梯時極可能網絡請求重試成功，幫助用戶拉到了想要的數據，提高了用戶體驗和客戶端的網絡抗抖動能力。

5.4 加密傳輸1S鍾法則

衆所周知的傳統https的整個握手流程是很是重的，在網絡質量不高的狀況下，形成建連過慢，用戶體驗慘不能睹，甚至都沒法完成安全握手；然而從安全的角度咱們是須要一個安全的傳輸通道保護用戶的隱私數據。安全與網絡這一對衝突放在咱們的面前，須要在技術上有所突破，所以咱們自建了一套slight-ssl的技術，參考了tls1.3的協議，經過合併請求，優化加密算法，運用session-ticket等策略，最終在安全和體驗之間找到了一個平衡點，在基本不犧牲用戶體驗的基礎上，達到了安全傳輸的目地, 同時還大幅度提高了服務端的性能。經過技術的創新，咱們實現了無線網絡加密傳輸下1S鍾法則。

6.總結和感悟

手機淘寶2015年雙十一網絡接入工做關鍵字總結:

ACCS、網關架構優化、異地多活、弱網優化和抗抖動、加密傳輸1S鍾法則

幾點感悟：

1. 網絡接入任重道遠，對於手機淘寶這樣一個億級UV無線電商平臺,穩定性是立足之本。
2. 接入層架構調整要麼基於業務需求（可以適應業務的變化的架構纔是最合適的)，要麼可以極大節省成本和提高穩定性。架構的演進必定是迭代式不能一蹴而就，重視積累和反思。
3. 移動接入層解決方案上能夠更多利用客戶端能力，這個是無線對比PC Web的優點所在。
4. 無線網絡這兩年網速是提高了但網絡環境更加複雜，萬物互聯、設備隨時隨地在線、運營商的複雜性會對移動網絡優化帶來更多的挑戰，端到端的網絡優化以及推動運營商合做任重而道遠。

最後打個廣告，基於ACCS的雲推送服務Agoo已經在公測中，將來咱們的移動基礎設施將逐步上雲提供給業界開發者朋友們。

手機淘寶技術團隊吳志華（天施）、洪海（孤星）、陳虓將（仲升）等專家參與本文創做。