阿里無線11.11：手機淘寶移動端接入網關基礎架構演進之路
移動網絡優化是超級App永恒的話題，對于無線電商來說更為重要，網絡請求體驗跟用戶的購買行為息息相關，手機淘寶從過去的HTTP API網關，到2014年升級支持SPDY，2015年雙十一自研高性能、全雙工、安全的ACCS（阿里云通道服務)扛住雙十一戰場主要流量，無論是基礎 架構的演進、網絡調優、協議的優化、異地多活、網絡調度上都有不少寶貴的經驗與大家分享。
ACCS基于無線場景精心設計的雙工 、安全、低時延、開放的移動統一接入層服務，在雙十一當天穩定高效地服務了近2億的在線用戶，支持了峰值4500萬的在線長連接，這個背后的故事以及我們的思考是什么呢？
1.業務高速發展下訴求
回到一年前，移動電商在2014年雙十一業務開始興起，2014年雙十一當天移動成交243億占整體571億的42.6%，業務高速發展希望更多 主動推送去觸達用戶，一些新的玩法和互動形式，需要連接買家與買家、買家與賣家、買家與達人，因為沒有有效的通道能力，業務采取的是不停去輪詢服務器，一 來對服務器造成不必要的壓力，二來對于用戶手機的電量流量也是極大的浪費，關鍵在大促當天不必要的請求過大甚至會導致后端集群限流，從而影響到用戶體驗。
信息傳播形態的變化的背后是移動化帶來新的技術特征導致的結果。在過去的幾年，移動電商從無到有，手機淘寶一直是這個領域的先行者。移動電商從最 初的復制WEB的業務形態到移動特性不斷涌現，更多的互動形式的出現，向社交化、娛樂化不斷邁進的今天，一個單純的商品的陳列架形式已經不能滿足業務的需 求。業務上需要實時的觸達用戶，充分發揮移動的特性，將消費時間的碎片利用起來，事實也證明了用戶的消費時間隨著移動化的進程不斷發生變化，逐步分布到全 天的碎片時間中。同時貨架形態也在向社區化、娛樂化的方向發展，這些都對網絡層連接用戶有了更高的要求。更多的媒體形態和展示方式，對網絡層提出了更多元 的要求。大家可以關注到手機淘寶內的消息盒子、微淘、淘友這些產品都是業務求變的體現，業務的變化倒逼技術的前進。
2.移動網絡環境依然嚴峻
移動網絡的速度在過去幾年有很大提升，但網絡環境的多樣性和差異性使移動網絡的環境更加復雜，在去年雙十一之前我們還常遇到一些移動網絡劫持的事 情。網絡劫持這塊問題的排查效率很低，需要找到用戶、復現現場，甚至找網工、運營商配合排查，一查就是幾天過去。同時在我們的輿情反饋上總是看到用戶在說 －“某個頁面加載中、頁面打不開、請求很慢、打開某個功能很慢”，面對這些問題過去我們是沒有太好的辦法，只能貓抓耗子一樁樁去排雷很被動。很多網絡的問 題是偶現的，一旦錯過現在就無從查起，背后的原因很多：
- 運營商問題
- 機房部署原因
- 客戶端SDK Bug
- 弱網和網絡抖動
- 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, 我們借助了客戶端的強大能力，利用協商的機制來完成用戶的請求正確被分配到不同的單元，含以下幾點:
- 客戶端的請求始終帶上當前用戶歸屬單元的信息。
- 當請求到達服務端時，服務端判斷用戶歸屬單元是否正確，不正確將用戶重定向到正確的單元 。
- 當前請求由網關在服務端上通過跨單元調用保證業務的正確性。
- 當客戶端歸屬單元更新后，后續的請求都會發到正確的單元機房。
4.2.2 無線接入層單元化的旁路調度
協商機制看起來很不錯，這里一個重磅炸彈丟過來了，機房的入口網絡斷了！
(圖-5)
如圖-5, 外網不可用，協商的機會都沒有故障單元的用戶無法恢復，這時旁路的調度服務出場了。
(圖-6)
如上圖-6, 我們設計的調度中心這時又承擔了單元化的旁路調度職責,當app訪問的單元無法訪問的時候, app會訪問不同單元的調度中心，詢問用戶的歸屬單元，通過這種方式取得可用的單元節點，將用戶切到正確的單元。這個方案同樣適用于單機房的接入層網關不 可用的場景。
4.2.3 應用層網關不可用
某個單元機房的應用層網關不可用，這時等待應用網關排查問題需要的時間比較久，為了達到最快的故障恢復，我們通過開關把修改接入層的轉發規則，將流量切到可用的單元。如下圖-7
(圖-7)
5.端到端網絡優化
5.1 統一網絡庫
在做網絡優化一開始，我們想做一個通用的網絡庫，這個網絡庫包含 策略、 httpDNS 、 SPDY 協議 等一切系統網絡優化需要的方方面面。上層api網關請求邏輯、推送邏輯、上傳下載邏輯對于這樣一個通用網絡庫來說都是業務。在分層上將通用網絡庫和上層應用邏輯分開、徹底解耦，對長期持續優化網絡是很有必要。如下圖-8所示架構。
(圖-8)
這樣架構上分離，可以讓我們更專注更系統化去做無線網絡優化。統一網絡庫的幾個重要特性:
- 靈活控制客戶端網絡行為策略(建連、超時處理、請求協議、是否加密）
- 包含HTTPDNS，支持異地多活
- 更細粒度控制和調度(域名級和域名下參數級)
1、2、3均由網絡調度中心的集群控制，我們希望這個可以做到與業務無關，去掉一些阿里的業務屬性后，這個模塊大家可以理解為HTTPDNS，可以理解我們在HTTPDNS之外做了大量網絡優化的端到端的工作。
5.2 就近就快接入
基于網絡庫我們實現了一套智能學習的網絡策略，智能學習客戶端在不同網絡環境下建連策略，用戶重新回到這個網絡環境會給出最優的策略進行快速連接，并定期 去更新或淘汰本地cache的歷史最優網絡策略。為了建連更加迅速在各自網絡下穿透性更好，接入服務器支持了多種協議和端口，客戶端建連時可以極速接入網 絡。我們有一個重要指標是 打開客戶端 30 S 內網絡請求成功率 ，就是關注連的快給用戶體驗帶來的價值。
基于調度中心，我們搭建了一個智能大數據分析平臺，將客戶端在在網絡請求過程中的數據如建連時間、首包收取時間、整包收取時間、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鐘法則
幾點感悟：
- 網絡接入任重道遠，對于手機淘寶這樣一個億級UV無線電商平臺,穩定性是立足之本。
- 接入層架構調整要么基于業務需求（能夠適應業務的變化的架構才是最合適的)，要么能夠極大節省成本和提升穩定性。架構的演進一定是迭代式不能一蹴而就，重視積累和反思。
- 移動接入層解決方案上可以更多利用客戶端能力，這個是無線對比PC Web的優勢所在。
- 無線網絡這兩年網速是提升了但網絡環境更加復雜，萬物互聯、設備隨時隨地在線、運營商的復雜性會對移動網絡優化帶來更多的挑戰，端到端的網絡優化以及推進運營商合作任重而道遠。
最后打個廣告，基于ACCS的云推送服務Agoo已經在公測中，未來我們的移動基礎設施將逐步上云提供給業界開發者朋友們。
手機淘寶技術團隊吳志華（天施）、洪海（孤星）、陳虓將（仲升）等專家參與本文創作。