移動網(wǎng)絡(luò)優(yōu)化是超級App永恒的話題，對于無線電商來說更為重要，網(wǎng)絡(luò)請求體驗(yàn)跟用戶的購買行為息息相關(guān)，手機(jī)淘寶從過去的HTTP API網(wǎng)關(guān)，到2014年升級支持SPDY，2015年雙十一自研高性能、全雙工、安全的ACCS(阿里云通道服務(wù))扛住雙十一戰(zhàn)場主要流量，無論是基礎(chǔ)架構(gòu)的演進(jìn)、網(wǎng)絡(luò)調(diào)優(yōu)、協(xié)議的優(yōu)化、異地多活、網(wǎng)絡(luò)調(diào)度上都有不少寶貴的經(jīng)驗(yàn)與大家分享。

ACCS基于無線場景精心設(shè)計(jì)的雙工 、安全、低時延、開放的移動統(tǒng)一接入層服務(wù)，在雙十一當(dāng)天穩(wěn)定高效地服務(wù)了近2億的在線用戶，支持了峰值4500萬的在線長連接，這個背后的故事以及我們的思考是什么呢?

1.業(yè)務(wù)高速發(fā)展下訴求

回到一年前，移動電商在2014年雙十一業(yè)務(wù)開始興起，2014年雙十一當(dāng)天移動成交243億占整體571億的42.6%，業(yè)務(wù)高速發(fā)展希望更多主動推送去觸達(dá)用戶，一些新的玩法和互動形式，需要連接買家與買家、買家與賣家、買家與達(dá)人，因?yàn)闆]有有效的通道能力，業(yè)務(wù)采取的是不停去輪詢服務(wù)器，一來對服務(wù)器造成不必要的壓力，二來對于用戶手機(jī)的電量流量也是極大的浪費(fèi)，關(guān)鍵在大促當(dāng)天不必要的請求過大甚至?xí)?dǎo)致后端集群限流，從而影響到用戶體驗(yàn)。

信息傳播形態(tài)的變化的背后是移動化帶來新的技術(shù)特征導(dǎo)致的結(jié)果。在過去的幾年，移動電商從無到有，手機(jī)淘寶一直是這個領(lǐng)域的先行者。移動電商從最初的復(fù)制WEB的業(yè)務(wù)形態(tài)到移動特性不斷涌現(xiàn)，更多的互動形式的出現(xiàn)，向社交化、娛樂化不斷邁進(jìn)的今天，一個單純的商品的陳列架形式已經(jīng)不能滿足業(yè)務(wù)的需求。

業(yè)務(wù)上需要實(shí)時的觸達(dá)用戶，充分發(fā)揮移動的特性，將消費(fèi)時間的碎片利用起來，事實(shí)也證明了用戶的消費(fèi)時間隨著移動化的進(jìn)程不斷發(fā)生變化，逐步分布到全天的碎片時間中。同時貨架形態(tài)也在向社區(qū)化、娛樂化的方向發(fā)展，這些都對網(wǎng)絡(luò)層連接用戶有了更高的要求。更多的媒體形態(tài)和展示方式，對網(wǎng)絡(luò)層提出了更多元的要求。大家可以關(guān)注到手機(jī)淘寶內(nèi)的消息盒子、微淘、淘友這些產(chǎn)品都是業(yè)務(wù)求變的體現(xiàn)，業(yè)務(wù)的變化倒逼技術(shù)的前進(jìn)。

2.移動網(wǎng)絡(luò)環(huán)境依然嚴(yán)峻

移動網(wǎng)絡(luò)的速度在過去幾年有很大提升，但網(wǎng)絡(luò)環(huán)境的多樣性和差異性使移動網(wǎng)絡(luò)的環(huán)境更加復(fù)雜，在去年雙十一之前我們還常遇到一些移動網(wǎng)絡(luò)劫持的事情。網(wǎng)絡(luò)劫持這塊問題的排查效率很低，需要找到用戶、復(fù)現(xiàn)現(xiàn)場，甚至找網(wǎng)工、運(yùn)營商配合排查，一查就是幾天過去。

同時在我們的輿情反饋上總是看到用戶在說-“某個頁面加載中、頁面打不開、請求很慢、打開某個功能很慢”，面對這些問題過去我們是沒有太好的辦法，只能貓抓耗子一樁樁去排雷很被動。很多網(wǎng)絡(luò)的問題是偶現(xiàn)的，一旦錯過現(xiàn)在就無從查起，背后的原因很多：

1. 運(yùn)營商問題
2. 機(jī)房部署原因
3. 客戶端SDK Bug
4. 弱網(wǎng)和網(wǎng)絡(luò)抖動
5. DNS劫持和數(shù)據(jù)篡改

PC時代我們訪問網(wǎng)站的接入條件是相對恒定的，所以在開發(fā)時很少考慮網(wǎng)絡(luò)對用戶體驗(yàn)的影響。但是移動APP則不然，尤其是在中國，基礎(chǔ)的移動網(wǎng)絡(luò)環(huán)境并不好，而且我們有很多用戶的訪問是發(fā)生在地鐵、公交車這樣的移動環(huán)境下，移動基站的頻繁切換進(jìn)一步增加了網(wǎng)絡(luò)的不穩(wěn)定。從手機(jī)淘寶的數(shù)據(jù)可以看出，我們每天活躍用戶中有不少來自于類似2G這樣的弱網(wǎng)環(huán)境。如果端到云的連接不穩(wěn)定、高延時，那么所有的用戶體驗(yàn)都無從談起。

基礎(chǔ)網(wǎng)絡(luò)的效率就像一輛列車，時延是火車的速度(啟動時間)，而帶寬就像火車的車廂裝載量，整個傳輸?shù)奈锢礞溌肪拖窕疖嚨蔫F軌。目前現(xiàn)實(shí)條件下的移動網(wǎng)絡(luò)條件非常復(fù)雜，既有高鐵這樣先進(jìn)的傳輸渠道，也有不少老舊緩慢的綠皮車還在服務(wù)很多用戶。我們的目標(biāo)很簡單，就是想讓所有用戶都能在手機(jī)淘寶獲得流暢的體驗(yàn)，不論你坐的是“高鐵”還是“綠皮車”。

下面這張圖，能夠讓大家更加直觀的了解中國的移動網(wǎng)絡(luò)環(huán)境。描述了從用戶到IDC的端到端的路由情況，不僅數(shù)據(jù)傳輸耗時長且丟包率高，同時安全性也是相當(dāng)糟糕的，DNS劫持、內(nèi)容劫持在中國就是家常便飯。

因此我們在改善網(wǎng)絡(luò)通道上有很多的事情可以去做，去探索突破運(yùn)營商基礎(chǔ)網(wǎng)絡(luò)的限制，力爭為用戶創(chuàng)造極致的購物體驗(yàn)。

3.ACCS整體架構(gòu)

為了滿足移動電商業(yè)務(wù)高速發(fā)展的需求，我們決定打造一個世界級的網(wǎng)絡(luò)接入服務(wù)，構(gòu)建一個無線網(wǎng)絡(luò)下”水、電、煤“ 一樣的基礎(chǔ)設(shè)施。這樣一個基礎(chǔ)設(shè)施需要做到的四個目標(biāo)：

“ 雙工、低延時、安全、開放”。在這四個目標(biāo)之上是圍繞這個接入服務(wù)配套的運(yùn)維體系，幫助最終用戶取得良好的端上體驗(yàn)的同時，幫助開發(fā)者快速構(gòu)建自己的業(yè)務(wù)。

如圖-1所示，在整個接入服務(wù)上我們劃分為兩層，接入網(wǎng)關(guān)層和應(yīng)用網(wǎng)關(guān)層。接入網(wǎng)關(guān)負(fù)責(zé)連接的保持、消息的解析、消息的分發(fā)。應(yīng)用網(wǎng)關(guān)實(shí)現(xiàn)各種應(yīng)用層協(xié)議：API、SYNC、RPC、PUSH等，在應(yīng)用網(wǎng)關(guān)的背后是具體的業(yè)務(wù)系統(tǒng)。同時我們建立了一個統(tǒng)一調(diào)度服務(wù)，而不是采用傳統(tǒng)的DNS，調(diào)度服務(wù)是我們的控制中心，通過它我們可以強(qiáng)有力的指揮我們的客戶端，并且不會受到DNS污染的影響。

與服務(wù)端的分層架構(gòu)對應(yīng)的是客戶端的SDK，最底層的統(tǒng)一網(wǎng)絡(luò)庫SDK集中了我們對網(wǎng)絡(luò)優(yōu)化的策略，并向上為各個應(yīng)用網(wǎng)關(guān)技術(shù)的SDK提供API。

圖-1

基于上面的開放架構(gòu)，業(yè)務(wù)方可以選擇直接開放具體的后端服務(wù)對接不同的應(yīng)用網(wǎng)關(guān)，不需要了解網(wǎng)絡(luò)背后的細(xì)節(jié)，并通過應(yīng)用網(wǎng)關(guān)如API網(wǎng)關(guān)提供的開發(fā)工具快速生成客戶端代碼。業(yè)務(wù)方也可以基于這個接入層設(shè)計(jì)自己的協(xié)議。

統(tǒng)一接入層集中管理了用戶的設(shè)備、在線狀態(tài)，并提供信息的雙向傳遞能力。如下圖所示：

網(wǎng)關(guān)將致力于解決中間網(wǎng)絡(luò)的通訊，為上層的服務(wù)提供高質(zhì)量的雙向通訊能力。

4.穩(wěn)定性與容災(zāi)

穩(wěn)定性與容災(zāi)是服務(wù)端中間件永恒的主題，統(tǒng)一接入層這樣一個匯聚網(wǎng)關(guān)收益和風(fēng)險是并存的，一旦這個入口故障了，波及的用戶范圍是不可想象的，如何做的更加穩(wěn)定，是一個巨大的挑戰(zhàn)。

4.1 網(wǎng)關(guān)架構(gòu)的優(yōu)化

對于一個統(tǒng)一網(wǎng)關(guān)來說，對接的業(yè)務(wù)網(wǎng)關(guān)的信息傳遞特點(diǎn)是不一樣的，大部分的業(yè)務(wù)在全天都是比較平緩的，但是個別營銷類業(yè)務(wù)會在短時間內(nèi)發(fā)布海量的信息，這樣的信息發(fā)布會搶占網(wǎng)關(guān)的大量資源，對于用戶的正常訪問會產(chǎn)生影響。

舉個例子，push服務(wù)需要通過網(wǎng)關(guān)推送2億條消息，而這些消息需要在短時間內(nèi)全部推送完，而同時網(wǎng)關(guān)在為正常的用戶的交互提供服務(wù)，海量信息的推送和正常的用戶交互相互競爭資源，最終會造成正常用戶的交互失敗，對于業(yè)務(wù)來說，這是不可接受的。

基于上面的情況考慮整個網(wǎng)關(guān)在布署上分為兩個集群，一個集群處理常態(tài)的在線用戶訪問，另一個集群處理海量信息的推送。如下圖-2所示，通過這樣的方式，避免了業(yè)務(wù)形態(tài)不同，對統(tǒng)一網(wǎng)關(guān)的沖擊，將不同的業(yè)務(wù)形態(tài)進(jìn)行了隔離。

圖-2

4.2 異地多活

阿里這兩年一直在實(shí)施的異地多活的架構(gòu)，在異地多活的整體方案中，統(tǒng)一網(wǎng)關(guān)承擔(dān)了快速引導(dǎo)流量的職責(zé)，也是這一方案順利實(shí)施的一個重要環(huán)節(jié)。

異地多活是一個多機(jī)房的整體方案，在多個地區(qū)同時存在對等的多個機(jī)房，以用戶維度劃分，多機(jī)房共同承擔(dān)全量用戶的流量;在單個機(jī)房發(fā)生故障時，故障機(jī)房的流量可以快速的被遷引到可用機(jī)房，減少故障的恢復(fù)時間。

4.2.1 無線接入層單元化的協(xié)商機(jī)制

先看一下web端在這異地多活中的實(shí)現(xiàn)方式

圖-3

從圖-3可以看到，瀏覽器的業(yè)務(wù)器求會發(fā)給CDN，由CDN上保存的分發(fā)規(guī)則，向后續(xù)的單元機(jī)房分發(fā)。無線端也這樣做嗎?客戶端擁有強(qiáng)大的能力，可以做的更靈活;CDN的分發(fā)節(jié)點(diǎn)帶來更多的機(jī)器成本;對于需要雙工通訊能力的客戶端，消息投遞更為復(fù)雜。這些是我們思考與WEB不同的地方，是不是能做些不一樣的選擇?

圖-4

如圖-4, 我們借助了客戶端的強(qiáng)大能力，利用協(xié)商的機(jī)制來完成用戶的請求正確被分配到不同的單元，含以下幾點(diǎn):

1. 客戶端的請求始終帶上當(dāng)前用戶歸屬單元的信息。
2. 當(dāng)請求到達(dá)服務(wù)端時，服務(wù)端判斷用戶歸屬單元是否正確，不正確將用戶重定向到正確的單元 。
3. 當(dāng)前請求由網(wǎng)關(guān)在服務(wù)端上通過跨單元調(diào)用保證業(yè)務(wù)的正確性。
4. 當(dāng)客戶端歸屬單元更新后，后續(xù)的請求都會發(fā)到正確的單元機(jī)房。

4.2.2 無線接入層單元化的旁路調(diào)度

協(xié)商機(jī)制看起來很不錯，這里一個重磅炸彈丟過來了，機(jī)房的入口網(wǎng)絡(luò)斷了!

圖-5

如圖-5, 外網(wǎng)不可用，協(xié)商的機(jī)會都沒有故障單元的用戶無法恢復(fù)，這時旁路的調(diào)度服務(wù)出場了。

圖-6

如上圖-6, 我們設(shè)計(jì)的調(diào)度中心這時又承擔(dān)了單元化的旁路調(diào)度職責(zé),當(dāng)app訪問的單元無法訪問的時候, app會訪問不同單元的調(diào)度中心，詢問用戶的歸屬單元，通過這種方式取得可用的單元節(jié)點(diǎn)，將用戶切到正確的單元。這個方案同樣適用于單機(jī)房的接入層網(wǎng)關(guān)不可用的場景。

4.2.3 應(yīng)用層網(wǎng)關(guān)不可用

某個單元機(jī)房的應(yīng)用層網(wǎng)關(guān)不可用，這時等待應(yīng)用網(wǎng)關(guān)排查問題需要的時間比較久，為了達(dá)到最快的故障恢復(fù)，我們通過開關(guān)把修改接入層的轉(zhuǎn)發(fā)規(guī)則，將流量切到可用的單元。如下圖-7

圖-7

5.端到端網(wǎng)絡(luò)優(yōu)化

5.1 統(tǒng)一網(wǎng)絡(luò)庫

在做網(wǎng)絡(luò)優(yōu)化一開始，我們想做一個通用的網(wǎng)絡(luò)庫，這個網(wǎng)絡(luò)庫包含策略、httpDNS、SPDY協(xié)議等一切系統(tǒng)網(wǎng)絡(luò)優(yōu)化需要的方方面面。上層api網(wǎng)關(guān)請求邏輯、推送邏輯、上傳下載邏輯對于這樣一個通用網(wǎng)絡(luò)庫來說都是業(yè)務(wù)。在分層上將通用網(wǎng)絡(luò)庫和上層應(yīng)用邏輯分開、徹底解耦，對長期持續(xù)優(yōu)化網(wǎng)絡(luò)是很有必要。如下圖-8所示架構(gòu)。

圖-8

這樣架構(gòu)上分離，可以讓我們更專注更系統(tǒng)化去做無線網(wǎng)絡(luò)優(yōu)化。統(tǒng)一網(wǎng)絡(luò)庫的幾個重要特性:

1. 靈活控制客戶端網(wǎng)絡(luò)行為策略(建連、超時處理、請求協(xié)議、是否加密)
2. 包含HTTPDNS，支持異地多活
3. 更細(xì)粒度控制和調(diào)度(域名級和域名下參數(shù)級)

1、2、3均由網(wǎng)絡(luò)調(diào)度中心的集群控制，我們希望這個可以做到與業(yè)務(wù)無關(guān)，去掉一些阿里的業(yè)務(wù)屬性后，這個模塊大家可以理解為HTTPDNS，可以理解我們在HTTPDNS之外做了大量網(wǎng)絡(luò)優(yōu)化的端到端的工作。

5.2 就近就快接入

基于網(wǎng)絡(luò)庫我們實(shí)現(xiàn)了一套智能學(xué)習(xí)的網(wǎng)絡(luò)策略，智能學(xué)習(xí)客戶端在不同網(wǎng)絡(luò)環(huán)境下建連策略，用戶重新回到這個網(wǎng)絡(luò)環(huán)境會給出最優(yōu)的策略進(jìn)行快速連接，并定期去更新或淘汰本地cache的歷史最優(yōu)網(wǎng)絡(luò)策略。為了建連更加迅速在各自網(wǎng)絡(luò)下穿透性更好，接入服務(wù)器支持了多種協(xié)議和端口，客戶端建連時可以極速接入網(wǎng)絡(luò)。我們有一個重要指標(biāo)是打開客戶端30S內(nèi)網(wǎng)絡(luò)請求成功率，就是關(guān)注連的快給用戶體驗(yàn)帶來的價值。

基于調(diào)度中心，我們搭建了一個智能大數(shù)據(jù)分析平臺，將客戶端在在網(wǎng)絡(luò)請求過程中的數(shù)據(jù)如建連時間、首包收取時間、整包收取時間、ssl握手時間等重要指標(biāo)收集上來 。根據(jù)這些指標(biāo)分析出網(wǎng)絡(luò)異常區(qū)域，調(diào)整我們的就近就快接入規(guī)則，甚至推動IDC建設(shè)和CDN的布點(diǎn)完善。

5.3 弱網(wǎng)優(yōu)化和抗抖動

在弱網(wǎng)優(yōu)化上我們嘗試了QUIC,在網(wǎng)絡(luò)延時較高、丟包嚴(yán)重情況下比TCP有更好表現(xiàn)。線上手機(jī)淘寶灰度版本實(shí)測切換到QUIC后，平均RT收益有接近20%。考慮QUIC在移動網(wǎng)絡(luò)可能存在穿透性問題,未來我們將采取SPDY為主，QUIC為輔助的模式來完善我們的網(wǎng)絡(luò)鏈接策略。

同樣在一些網(wǎng)絡(luò)環(huán)境較差情況下，我們采取長短鏈接結(jié)合方式，在長鏈接遇到請求超時或穿透性較差情況，利用短鏈接HTTP短鏈接去請求數(shù)據(jù)(在移動網(wǎng)絡(luò)環(huán)境下HTTP協(xié)議尤其HTTP1.0的穿透性是最好的)，這樣可以在一些極端情況下最大程度保證用戶體驗(yàn)。數(shù)據(jù)如下圖-9

網(wǎng)絡(luò)切換和網(wǎng)絡(luò)抖動情況下的技術(shù)優(yōu)化也是一個很重要的方面，我們經(jīng)常遇到移動設(shè)備網(wǎng)絡(luò)切換和信號不穩(wěn)定的情況，在這種情況我們怎么保證用戶的體驗(yàn)?

針對這種情況我們的思路是有策略合理增加重試。我們對一個網(wǎng)絡(luò)請求以是否發(fā)送到socket緩沖區(qū)作為分割，將網(wǎng)絡(luò)請求生命周期劃分為“請求開始到發(fā)送到 socket緩沖區(qū)”和“已經(jīng)發(fā)送到socket緩沖區(qū)到請求結(jié)束”兩個階段。在階段一內(nèi)請求失敗了，會根據(jù)業(yè)務(wù)需求幫助業(yè)務(wù)請求去做重試。階段二請求失敗只針對讀操作提供重試能力。

設(shè)想一個場景：用戶在進(jìn)電梯發(fā)起一個刷新數(shù)據(jù)請求，進(jìn)到電梯因?yàn)榫W(wǎng)絡(luò)抖動的原因網(wǎng)絡(luò)鏈接斷了，這個時候我們能夠合理策略去做重試，這樣當(dāng)用戶離開電梯時很可能網(wǎng)絡(luò)請求重試成功，幫助用戶拉到了想要的數(shù)據(jù)，提升了用戶體驗(yàn)和客戶端的網(wǎng)絡(luò)抗抖動能力。

5.4 加密傳輸1S鐘法則

眾所周知的傳統(tǒng)https的整個握手流程是非常重的，在網(wǎng)絡(luò)質(zhì)量不高的情況下，造成建連過慢，用戶體驗(yàn)慘不能睹，甚至都無法完成安全握手;然而從安全的角度我們是需要一個安全的傳輸通道保護(hù)用戶的隱私數(shù)據(jù)。

安全與網(wǎng)絡(luò)這一對沖突放在我們的面前，需要在技術(shù)上有所突破，因此我們自建了一套slight-ssl的技術(shù)，參考了tls1.3的協(xié)議，通過合并請求，優(yōu)化加密算法，運(yùn)用session-ticket等策略，最終在安全和體驗(yàn)之間找到了一個平衡點(diǎn)，在基本不犧牲用戶體驗(yàn)的基礎(chǔ)上，達(dá)到了安全傳輸?shù)哪康? 同時還大幅度提升了服務(wù)端的性能。通過技術(shù)的創(chuàng)新，我們實(shí)現(xiàn)了無線網(wǎng)絡(luò)加密傳輸下1S鐘法則。

6.總結(jié)和感悟

手機(jī)淘寶2015年雙十一網(wǎng)絡(luò)接入工作關(guān)鍵字總結(jié):

ACCS、網(wǎng)關(guān)架構(gòu)優(yōu)化、異地多活、弱網(wǎng)優(yōu)化和抗抖動、加密傳輸1S鐘法則

幾點(diǎn)感悟：

網(wǎng)絡(luò)接入任重道遠(yuǎn)，對于手機(jī)淘寶這樣一個億級UV無線電商平臺,穩(wěn)定性是立足之本。

接入層架構(gòu)調(diào)整要么基于業(yè)務(wù)需求(能夠適應(yīng)業(yè)務(wù)的變化的架構(gòu)才是最合適的)，要么能夠極大節(jié)省成本和提升穩(wěn)定性。架構(gòu)的演進(jìn)一定是迭代式不能一蹴而就，重視積累和反思。

移動接入層解決方案上可以更多利用客戶端能力，這個是無線對比PC Web的優(yōu)勢所在。

無線網(wǎng)絡(luò)這兩年網(wǎng)速是提升了但網(wǎng)絡(luò)環(huán)境更加復(fù)雜，萬物互聯(lián)、設(shè)備隨時隨地在線、運(yùn)營商的復(fù)雜性會對移動網(wǎng)絡(luò)優(yōu)化帶來更多的挑戰(zhàn)，端到端的網(wǎng)絡(luò)優(yōu)化以及推進(jìn)運(yùn)營商合作任重而道遠(yuǎn)。