淘寶技術分享：手淘億級移動端接入層網關的技術演進之路
本文由手機淘寶技術團隊原創分享，吳志華（天施）、洪海（孤星）、陳虓將（仲升）等專家參與了本文創做，首次發表於公衆號「淘系技術」，收錄整理時有修訂和改動。php
一、引言
移動端網絡的優化是超級APP們永恆的話題，而對於無線電商來講這更爲重要，由於網絡請求體驗跟用戶的購買行爲息息相關。html
手機淘寶從過去的HTTP API網關，到後來扛住雙十一戰場主要流量的自研高性能、全雙工、安全的ACCS（阿里雲通道服務），不管是基礎架構的演進、網絡調優、協議的優化、異地多活、網絡調度上，都有很多寶貴的經驗與你們分享，本文藉此機會總結了整個技術演進過程。web
*** 閱讀對象：**本文屬於移動端網絡優化的深水區總結性文章，適合有必定移動端網絡應用經驗的開發者閱讀（尤爲對移動弱網有必定了解的），初學者若是沒有相關知識積累的話，能夠簡單瞭解無需深刻。若是你對移動弱網頗有興趣，能夠進一步閱讀本文末尾「附錄」部分的推薦文章。算法
本文已同步發佈於「即時通信技術圈」公衆號，歡迎關注：編程
▲ 本文在公衆號上的連接是：點此進入，原文連接是：www.52im.net/thread-3110…後端
二、相關文章
《Netty乾貨分享：京東京麥的生產級TCP網關技術實踐總結》api
三、技術背景
回想移動電商在雙十一業務開始興起的時候，當時雙十一當天移動成交243億佔總體571億的42.6%。服務器
業務高速發展但願更多主動推送去觸達用戶，一些新的玩法和互動形式，須要鏈接買家與買家、買家與賣家、買家與達人，由於沒有有效的通道能力，業務採起的是不停去輪詢服務器，一來對服務器形成沒必要要的壓力，二來對於用戶手機的電量流量也是極大的浪費，關鍵在雙十五這種大促的狀況下，沒必要要的請求過大甚至會致使後端集羣限流，從而影響到用戶體驗。
信息傳播形態的變化的背後是移動化帶來新的技術特徵致使的結果。移動電商領域，手機淘寶一直是先行者。移動電商從最初的複製WEB的業務形態到移動特性不斷涌現，更多的互動形式的出現，向社交化、娛樂化不斷邁進的今天，一個單純的商品的陳列架形式已經不能知足業務的需求。
業務上須要實時的觸達用戶，充分發揮移動的特性，將消費時間的碎片利用起來，事實也證實了用戶的消費時間隨着移動化的進程不斷髮生變化，逐步分佈到全天的碎片時間中。同時貨架形態也在向社區化、娛樂化的方向發展，這些都對網絡層鏈接用戶有了更高的要求。更多的媒體形態和展現方式，對網絡層提出了更多元的要求。
你們能夠關注到手機淘寶內的消息盒子這些產品都是業務求變的體現，業務的變化倒逼技術的前進。
四、移動網絡環境的挑戰性一直都存在
移動網絡的速度隨便3g、4g、5g的普及，速度有很大提高，但網絡環境的多樣性和差別性使移動網絡的環境更加複雜，在過去雙十一前還常遇到一些移動網絡劫持的事情。網絡劫持這塊問題的排查效率很低，須要找到用戶、復現現場，甚至找網工、運營商配合排查，一查就是幾天過去。
同時在咱們的輿情反饋上老是看到用戶在說「某個頁面加載中、頁面打不開、請求很慢、打開某個功能很慢」，面對這些問題過去咱們是沒有太好的辦法，只能貓抓耗子一樁樁去排雷很被動。不少網絡的問題是偶現的，一旦錯過如今就無從查起。
諸如此類的問題，背後的緣由不少：
- 1）運營商問題；
- 2）機房部署緣由；
- 3）客戶端SDK Bug；
- 4）弱網和網絡抖動；
- 5）DNS劫持和數據篡改。
在PC時代，咱們訪問網站的接入條件是相對恆定的，因此在開發時不多考慮網絡對用戶體驗的影響。可是移動APP則否則，尤爲是在國內，基礎的移動網絡環境還不算太好，並且咱們有不少用戶的訪問是發生在地鐵、公交車這樣的移動環境下，移動基站的頻繁切換進一步增長了網絡的不穩定。從手機淘寶的數據能夠看出，咱們天天活躍用戶中有很多來自於弱網環境。若是端到雲的鏈接不穩定、高延時，那麼全部的用戶體驗都無從談起。
基礎網絡的效率就像一輛列車，時延是火車的速度(啓動時間)，而帶寬就像火車的車箱裝載量，整個傳輸的物理鏈路就像火車的鐵軌。目前現實條件下的移動網絡條件很是複雜，咱們的目標很簡單，就是想讓全部用戶都能在手機淘寶得到流暢的體驗。
下面這張圖，可以讓你們更加直觀的瞭解國內的移動網絡環境。描述了從用戶到IDC的端到端的路由狀況，不只數據傳輸耗時長且丟包率高，同時安全性也是至關糟糕的，DNS劫持、內容劫持在中國就是屢見不鮮。
所以，咱們在改善網絡通道上有不少的事情能夠去作，去探索突破運營商基礎網絡的限制，力爭爲用戶創造極致的購物體驗。
移動端的DNS問題至關廣泛，能夠詳讀如下專題文章：
《全面瞭解移動端DNS域名劫持等雜症：原理、根源、HttpDNS解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減少近半》
五、總體技術架構
爲了知足移動電商業務高速發展的需求，咱們決定打造一個世界級的網絡接入服務，構建一個無線網絡下」水、電、煤「 同樣的基礎設施。
這樣一個基礎設施須要作到的四個目標：
- 1）全雙工；
- 2）低延時；
- 3）高安全；
- 4）開放。
在這四個目標之上是圍繞這個接入服務配套的運維體系，幫助最終用戶取得良好的端上體驗的同時，幫助開發者快速構建本身的業務。
如上圖所示，在整個接入服務上咱們劃分爲兩層：
- 1）接入網關：負責鏈接的保持、消息的解析、消息的分發；
- 2）應用網關：實現各類應用層協議：API、SYNC、RPC、PUSH等，在應用網關的背後是具體的業務系統。
同時咱們創建了一個統一調度服務，而不是採用傳統的DNS，調度服務是咱們的控制中心，經過它咱們能夠強有力的指揮咱們的客戶端，而且不會受到DNS污染的影響。
與服務端的分層架構對應的是客戶端的SDK，最底層的統一網絡庫SDK集中了咱們對網絡優化的策略，並向上爲各個應用網關技術的SDK提供API。
基於上面的開放架構，業務方能夠選擇直接開放具體的後端服務對接不一樣的應用網關，不須要了解網絡背後的細節，並經過應用網關如API網關提供的開發工具快速生成客戶端代碼。業務方也能夠基於這個接入層設計本身的協議。
統一接入層集中管理了用戶的設備、在線狀態，並提供信息的雙向傳遞能力。
以下圖所示：
網關將致力於解決中間網絡的通信，爲上層的服務提供高質量的雙向通信能力。
六、穩定性與容災
穩定性與容災是服務端中間件永恆的主題，統一接入層這樣一個匯聚網關收益和風險是並存的，一旦這個入口故障了，波及的用戶範圍是不可想象的，如何作的更加穩定，是一個巨大的挑戰。
6.1 網關架構的優化
對於一個統一網關來講，對接的業務網關的信息傳遞特色是不同的，大部分的業務在全天都是比較平緩的，可是個別營銷類業務會在短期內發佈海量的信息，這樣的信息發佈會搶佔網關的大量資源，對於用戶的正常訪問會產生影響。
**舉個例子：**push服務須要經過網關推送2億條消息，而這些消息須要在短期內所有推送完，而同時網關在爲正常的用戶的交互提供服務，海量信息的推送和正常的用戶交互相互競爭資源，最終會形成正經常使用戶的交互失敗，對於業務來講，這是不可接受的。
基於上面的狀況考慮，整個網關在佈署上分爲兩個集羣：
- 1）一個集羣處理常態的在線用戶訪問；
- 2）一個集羣處理海量信息的推送。
以下圖所示，經過這樣的方式，避免了業務形態不一樣，對統一網關的衝擊，將不一樣的業務形態進行了隔離。
6.2 異地多活
在異地多活的總體方案中，統一網關承擔了快速引導流量的職責，也是這一方案順利實施的一個重要環節。
異地多活是一個多機房的總體方案，在多個地區同時存在對等的多個機房，以用戶維度劃分，多機房共同承擔全量用戶的流量；在單個機房發生故障時，故障機房的流量能夠快速的被遷引到可用機房，減小故障的恢復時間。
先看一下web端在這異地多活中的實現方式：
從上圖能夠看到，瀏覽器的業務器求會發給CDN，由CDN上保存的分發規則，向後續的單元機房分發。
無線端也這樣作嗎？
- 1）客戶端擁有強大的能力，能夠作的更靈活；
- 2）CDN的分發節點帶來更多的機器成本；
- 3）對於須要雙工通信能力的客戶端，消息投遞更爲複雜。
這些是咱們思考與WEB不一樣的地方，是否是能作些不同的選擇？
如上圖所示, 咱們藉助了客戶端的強大能力，利用協商的機制來完成用戶的請求正確被分配到不一樣的單元。
含如下幾點：
- 1）客戶端的請求始終帶上當前用戶歸屬單元的信息；
- 2）當請求到達服務端時，服務端判斷用戶歸屬單元是否正確，不正確將用戶重定向到正確的單元 ；
- 3）當前請求由網關在服務端上經過跨單元調用保證業務的正確性；
- 4）當客戶端歸屬單元更新後，後續的請求都會發到正確的單元機房。
協商機制看起來很不錯，這裏一個重磅炸彈丟過來了，機房的入口網絡斷了！
如上圖，外網不可用，協商的機會都沒有故障單元的用戶沒法恢復，這時旁路的調度服務出場了。
如上圖，咱們設計的調度中心這時又承擔了單元化的旁路調度職責，當app訪問的單元沒法訪問的時候，app會訪問不一樣單元的調度中心，詢問用戶的歸屬單元。經過這種方式取得可用的單元節點，將用戶切到正確的單元。這個方案一樣適用於單機房的接入層網關不可用的場景。
某個單元機房的應用層網關不可用，這時等待應用網關排查問題須要的時間比較久，爲了達到最快的故障恢復，咱們經過開關把修改接入層的轉發規則，將流量切到可用的單元。
以下圖所示：
七、端到端網絡優化
7.1 統一網絡庫
在作網絡優化一開始，咱們想作一個通用的網絡庫，這個網絡庫包含策略、httpDNS、SPDY協議等一切系統網絡優化須要的方方面面。（若是你對httpDNS不甚瞭解，能夠詳讀《全面瞭解移動端DNS域名劫持等雜症：原理、根源、HttpDNS解決方案等》）
上層api網關請求邏輯、推送邏輯、上傳下載邏輯對於這樣一個通用網絡庫來講都是業務。在分層上將通用網絡庫和上層應用邏輯分開、完全解耦，對長期持續優化網絡是頗有必要。
以下圖所示架構：
這樣架構上分離，可讓咱們更專一更系統化去作無線網絡優化。
統一網絡庫的幾個重要特性：
- 1）靈活控制客戶端網絡行爲策略（建連、超時處理、請求協議、是否加密）；
- 2）包含HTTPDNS；
- 3）支持異地多活；
- 4）更細粒度控制和調度(域名級和域名下參數級)。
一、二、三、4均由網絡調度中心的集羣控制，咱們但願這個能夠作到與業務無關，去掉一些阿里的業務屬性後，這個模塊你們能夠理解爲HTTPDNS，能夠理解咱們在HTTPDNS以外作了大量網絡優化的端到端的工做。
7.2 就近就快接入
基於網絡庫咱們實現了一套智能學習的網絡策略，智能學習客戶端在不一樣網絡環境下建連策略，用戶從新回到這個網絡環境會給出最優的策略進行快速鏈接，並按期去更新或淘汰本地cache的歷史最優網絡策略。
爲了創建更加迅速在各自網絡下穿透性更好，接入服務器支持了多種協議和端口，客戶端建連時能夠極速接入網絡。
咱們有一個重要指標是打開客戶端30秒內網絡請求成功率，就是關注連的快給用戶體驗帶來的價值。
基於調度中心，咱們搭建了一個智能大數據分析平臺，將客戶端在在網絡請求過程當中的數據如建連時間、首包收取時間、整包收取時間、ssl握手時間等重要指標收集上來 。根據這些指標分析出網絡異常區域，調整咱們的就近就快接入規則，甚至推進IDC建設和CDN的布點完善。
7.3 弱網優化和抗抖動
在弱網優化上咱們嘗試了QUIC協議，在網絡延時較高、丟包嚴重狀況下比TCP有更好表現。
線上手機淘寶灰度版本實測切換到QUIC後，平均RT收益有接近20%。考慮QUIC在移動網絡可能存在穿透性問題，將來咱們將採起SPDY爲主，QUIC爲輔助的模式來完善咱們的網絡連接策略。
如今QUIC協議在移動端應用的愈來愈普遍，有興趣的話可詳細如下文章：
《網絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》
一樣在一些網絡環境較差狀況下，咱們採起長短連接結合方式，在長連接遇到請求超時或穿透性較差狀況，利用短連接HTTP短連接去請求數據（在移動網絡環境下HTTP協議尤爲HTTP1.0的穿透性是最好的），這樣能夠在一些極端狀況下最大程度保證用戶體驗。
數據以下圖：
網絡切換和網絡抖動狀況下的技術優化也是一個很重要的方面，咱們常常遇到移動設備網絡切換和信號不穩定的狀況，在這種狀況咱們怎麼保證用戶的體驗？
針對這種狀況咱們的思路是有策略合理增長重試。咱們對一個網絡請求以是否發送到socket緩衝區做爲分割，將網絡請求生命週期劃分爲「請求開始到發送到 socket緩衝區」和「已經發送到socket緩衝區到請求結束」兩個階段。在階段一內請求失敗了，會根據業務需求幫助業務請求去作重試。階段二請求失敗只針對讀操做提供重試能力。
**設想一個場景：**用戶在進電梯發起一個刷新數據請求，進到電梯由於網絡抖動的緣由網絡連接斷了，這個時候咱們可以合理策略去作重試，這樣當用戶離開電梯時極可能網絡請求重試成功，幫助用戶拉到了想要的數據，提高了用戶體驗和客戶端的網絡抗抖動能力。
7.4 加密傳輸1秒鐘法則
衆所周知的傳統https的整個握手流程是很是重的，在網絡質量不高的狀況下，形成建連過慢，用戶體驗慘不能睹，甚至都沒法完成安全握手。然而從安全的角度咱們是須要一個安全的傳輸通道保護用戶的隱私數據。
安全與網絡這一對衝突放在咱們的面前，須要在技術上有所突破，所以咱們自建了一套slight-ssl的技術，參考了tls1.3的協議，經過合併請求，優化加密算法，運用session-ticket等策略，最終在安全和體驗之間找到了一個平衡點，在基本不犧牲用戶體驗的基礎上，達到了安全傳輸的目地, 同時還大幅度提高了服務端的性能。經過技術的創新，咱們實現了無線網絡加密傳輸下1秒鐘法則。
關於TLS1.3在移動端的應用，也能夠詳讀微信團隊分享的這篇《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》。
附錄：有關移動端弱網方面的資料彙總
《IM開發者的零基礎通訊技術入門(十一)：爲何WiFi信號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通訊技術入門(十三)：爲何手機信號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《全面瞭解移動端DNS域名劫持等雜症：原理、根源、HttpDNS解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減少近半》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網絡深度優化實踐分享(二)：網絡鏈接優化篇》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《美團點評的移動端網絡優化實踐：大幅提高鏈接成功率、速度等》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《騰訊原創分享(一)：如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《IM開發者的零基礎通訊技術入門(十一)：爲何WiFi信號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通訊技術入門(十三)：爲何手機信號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
（本文已同步發佈於：www.52im.net/thread-3110…）
- 1. 淘寶技術分享：手淘億級移動端接入層網關的技術演進之路
- 2. 淘寶架構技術的演變
- 3. 淘寶的技術博客
- 4. 淘寶網站的架構技術演進
- 5. 阿里無線11.11：手機淘寶移動端接入網關基礎架構演進之路
- 6. 阿里百川技術分享：OneSDK與手機淘寶技術能力開放
- 7. 淘寶網技術架構介紹
- 8. 0到千萬DAU，微淘技術架構演進之路
- 9. 講一講移動端跨平臺技術的演進之路
- 10. 聊聊淘寶天貓個性化推薦技術演進史
- 更多相關文章...
- • XML 相關技術 - XML 教程
- • 網站主機 技術 - 網站主機教程
- • Docker容器實戰(一) - 封神Server端技術
- • 三篇文章瞭解 TiDB 技術內幕——說存儲
-
每一个你不满意的现在，都有一个你没有努力的曾经。