本文根據(jù)第16期美團(tuán)點評技術(shù)沙龍“移動開發(fā)實踐（上海站）”演講內(nèi)容整理而成。

第18期沙龍：高可用系統(tǒng)背后的基礎(chǔ)架構(gòu)（3月25日）火熱來襲！快快點擊報名吧。

網(wǎng)絡(luò)優(yōu)化對于App產(chǎn)品的用戶體驗至關(guān)重要，與公司的運營和營收息息相關(guān)。這里列舉兩個公開的數(shù)據(jù)：

“頁面加載超過3秒，57%的用戶會離開。”

“Amazon頁面加載延長1秒，一年就會減少16億美金營收。”

在做網(wǎng)絡(luò)優(yōu)化前，我們首先要為網(wǎng)絡(luò)通信質(zhì)量設(shè)立一個標(biāo)尺。

在美團(tuán)點評，監(jiān)控團(tuán)隊開發(fā)了基于端到端的客戶端監(jiān)控平臺。這里要先解釋一下“端到端”的含義：是指請求從客戶端發(fā)出到服務(wù)端響應(yīng)返回的整個過程。它區(qū)別于后臺服務(wù)監(jiān)控，是一種從用戶角度觀察到的真實體驗監(jiān)控。

監(jiān)控頁面如圖所示：

通過基于命令字的、多維度、實時的監(jiān)控工具，可以及時發(fā)現(xiàn)線上問題。

為了方便發(fā)現(xiàn)問題，我們在公司內(nèi)統(tǒng)一了網(wǎng)絡(luò)響應(yīng)狀態(tài)碼的范圍。通過狀態(tài)碼的分段范圍，也可以迅速清晰地看到網(wǎng)絡(luò)成敗的原因和占比。

有了監(jiān)控工具后，我們來討論：移動網(wǎng)絡(luò)請求過程中，出現(xiàn)了哪些最常見的問題？

首先是網(wǎng)絡(luò)不可用的問題。主要由以下幾種原因?qū)е?#xff1a;

• GFW的攔截，原因你懂的。
• DNS的劫持，端口的意外封禁等。
• 偏遠(yuǎn)地區(qū)網(wǎng)絡(luò)基礎(chǔ)設(shè)施比較差。

其次是網(wǎng)絡(luò)加載時間長。原因包括： * 移動設(shè)備出于省電的目的，發(fā)出網(wǎng)絡(luò)請求前需要先預(yù)熱通信芯片。 * 網(wǎng)絡(luò)請求需要跨網(wǎng)絡(luò)運營商，物理路徑長。 * HTTP請求是基于Socket設(shè)計的，請求發(fā)起之前會經(jīng)歷三次握手，斷開時又會進(jìn)行四次揮手。

最后是HTTP協(xié)議的數(shù)據(jù)安全問題。原因有： * HTTP協(xié)議的數(shù)據(jù)容易被抓包。Post包體數(shù)據(jù)經(jīng)過加密能夠避免泄露，但協(xié)議中的URL和header部分還是會暴露給抓包軟件。HTTPS也面臨相似的問題。 * 運營商數(shù)據(jù)惡意篡改嚴(yán)重。如下圖中，App的網(wǎng)頁中就被運營商插入了廣告。

面對上述網(wǎng)絡(luò)問題，我們首先在HTTP短連請求中進(jìn)行了一些優(yōu)化嘗試。

短連方案一、域名合并方案

隨著開發(fā)規(guī)模逐漸擴(kuò)大，各業(yè)務(wù)團(tuán)隊出于獨立性和穩(wěn)定性的考慮，紛紛申請了自己的三級域名。App中的API域名越來越多。如下所示： search.api.dianping.com ad.api.dianping.com tuangou.api.dianping.com waimai.api.dianping.com movie.api.dianping.com …

App中域名多了之后，將面臨下面幾個問題： * HTTP請求需要跟不同服務(wù)器建立連接。增加了網(wǎng)絡(luò)的并發(fā)連接數(shù)量。 * 每條域名都需要經(jīng)過DNS服務(wù)來解析服務(wù)器IP。

如果想將所有的三級域名都合并為一個域名，又會面臨巨大的項目推進(jìn)難題。因為不同業(yè)務(wù)團(tuán)隊當(dāng)初正是出于獨立性和穩(wěn)定性的考慮才把域名進(jìn)行拆分，現(xiàn)在再想把域名合并起來，勢必會遭遇巨大的阻力。

所以我們面臨的是：既要將域名合并，提升網(wǎng)絡(luò)連接效率，又不能改造后端業(yè)務(wù)服務(wù)器。經(jīng)過討論，我們想到了一個折中的方案。

該方案的核心思想在于：保持客戶端業(yè)務(wù)層代碼編寫的網(wǎng)絡(luò)請求與后端業(yè)務(wù)服務(wù)器收到的請求保持一致，請求發(fā)出前，在客戶端網(wǎng)絡(luò)層對域名收編，請求送入后端，在SLB(Server Load Balancing)中對域名進(jìn)行還原。

網(wǎng)絡(luò)請求發(fā)出前，在客戶端的網(wǎng)絡(luò)底層將URL中的域名做簡單的替換，我們稱之為“域名收編”。

例如：URL “http://ad.api.dianping.com/command?param1=123" 在網(wǎng)絡(luò)底層被修改為 “http://api.dianping.com/ad/command?param1=123" 。

這里，將域名”ad.api.dianping.com”替換成了”api.dianping.com”，而緊跟在域名后的其后的”ad”表示了這是一條與廣告業(yè)務(wù)有關(guān)的域名請求。

依此類推，所有URL的域名都被合并為”api.dianping.com”。子級域名信息被隱藏在了域名后的path中。

被改造的請求被送到網(wǎng)絡(luò)后端，在SLB中，擁有與客戶端網(wǎng)絡(luò)層相反的一套域名反收編邏輯，稱為“域名還原”。

例如：”http://api.dianping.com/ad/command?param1=123" 在SLB中被還原為 “http://ad.api.dianping.com/command?param1=123" 。 SLB的作用是將請求分發(fā)到不同的業(yè)務(wù)服務(wù)器，在經(jīng)過域名還原之后，請求已經(jīng)與客戶端業(yè)務(wù)代碼中原始請求一致了。

該方案具有如下優(yōu)勢： 1. 域名得到了收編，減少了DNS調(diào)用次數(shù)，降低了DNS劫持風(fēng)險。 2. 針對同一域名，可以利用Keep-Alive來復(fù)用Http的連接。 3. 客戶端業(yè)務(wù)層不需要修改代碼，后端業(yè)務(wù)服務(wù)也不需要進(jìn)行任何修改。

短連方案二、IP直連方案

經(jīng)過域名合并方案，我們已經(jīng)將所有的域名都統(tǒng)一成了”api.dianping.com”。針對這唯一的域名，我們可以在客戶端架設(shè)自己的DNS服務(wù)。

方案很簡單：程序啟動的時候拉取”api.dianping.com”對應(yīng)的所有的IP列表；對所有IP進(jìn)行跑馬測試，找到速度最快的IP。后續(xù)所有的HTTPS請求都將域名更換為跑馬最快的IP即可。

舉個例子，假如：經(jīng)過跑馬測試發(fā)現(xiàn)域名”api.dianping.com”對應(yīng)最快的IP是”1.23.456.789”。

URL”http://api.dianping.com/ad/command?param1=123"將被替換為"http://1.23.456.789/ad/command?param1=123"

IP直連方案有下面幾大優(yōu)勢： 1. 摒棄了系統(tǒng)DNS，減少外界干擾，擺脫DNS劫持困擾。 2. 自建DNS更新時機(jī)可以控制。 3. IP列表更換方便。

此外，如果你的App域名沒有經(jīng)過合并，域名比較多，也建議可以嘗試使用HttpDNS方案。參考：http://www.tuicool.com/articles/7nAJBb 對HTTPS中的證書處理： > HTTPS由于要求證書綁定域名，如果做IP直連方案可能會遇到一些麻煩，這時我們需要對客戶端的HTTPS的域名校驗部分進(jìn)行改造，參見：http://blog.csdn.net/github_34613936/article/details/51490032 。

經(jīng)過域名合并加上IP直連方案改造后，HTTP短連的端到端成功率從95%提升到97.5%，網(wǎng)絡(luò)延時從1500毫秒降低到了1000毫秒，可謂小投入大產(chǎn)出。

接下來要想進(jìn)一步提升端到端成功率，就要開始進(jìn)行長連通道建設(shè)了。

提到長連通道建設(shè)，首先讓人想到的應(yīng)該是HTTP/2技術(shù)。它具有異步連接多路復(fù)用、頭部壓縮、請求響應(yīng)管線化等眾多優(yōu)點。

如果查看HTTP/2的拓?fù)浣Y(jié)構(gòu)，其實非常簡單：

HTTP/2在客戶端與服務(wù)器之間建立長連通道，將同一域名的請求都放在長連通道上進(jìn)行。這種拓?fù)浣Y(jié)構(gòu)有如下一些缺點： 1. 請求基于DNS，仍將面臨DNS劫持風(fēng)險。 2. 不同域名的請求需要建立多條連接。 3. 網(wǎng)絡(luò)通道難以優(yōu)化。客戶端與服務(wù)器之間是公網(wǎng)鏈路。如果在多地部署服務(wù)器，成本消耗又會很大。 4. 業(yè)務(wù)改造難度大。部署HTTP/2，需要對業(yè)務(wù)服務(wù)器進(jìn)行改造，而且使用的業(yè)務(wù)服務(wù)器越多，需要改造的成本也越大。 5. 網(wǎng)絡(luò)協(xié)議可訂制程度小。

與HTTP/2相區(qū)別，我們這里推薦另一種代理長連的模式。這種模式的拓?fù)鋱D如下：

基本思路為：在客戶端與業(yè)務(wù)服務(wù)器之間架設(shè)代理長連服務(wù)器，客戶端與代理服務(wù)器建立TCP長連通道，客戶端的HTTP請求被轉(zhuǎn)換為了TCP通道上的二進(jìn)制數(shù)據(jù)包。代理服務(wù)器負(fù)責(zé)與業(yè)務(wù)服務(wù)器進(jìn)行HTTP請求，請求的結(jié)果通過長連通道送回客戶端。

與HTTP/2模式對比，代理長連模式具有下面一些優(yōu)勢： 1. 對DNS無依賴。客戶端與代理服務(wù)器之間的長連通道是通過IP建立的，與DNS沒有關(guān)系。客戶端的HTTP請求被轉(zhuǎn)換為二進(jìn)制數(shù)據(jù)流送到代理服務(wù)器，也不需要進(jìn)行DNS解析。代理服務(wù)器轉(zhuǎn)發(fā)請求到業(yè)務(wù)服務(wù)器時，都處于同一內(nèi)網(wǎng)，因此可以自己搭建DNS服務(wù)，減少對公網(wǎng)DNS服務(wù)的依賴。從這個層面上說，代理長連模式天生具有防DNS劫持的能力。 2. 不同域名的請求可以復(fù)用同一條長連通道。 3. 通道易優(yōu)化。與部署業(yè)務(wù)服務(wù)器相比，部署代理長連服務(wù)器的代價就小了很多，可以在全國甚至全世界多地部署代理長連服務(wù)器。客戶端在選擇代理長連服務(wù)器時，可以通過跑馬找到最快的服務(wù)器IP進(jìn)行連接。另一方面，代理服務(wù)器與業(yè)務(wù)服務(wù)器之間的網(wǎng)絡(luò)通道也可以進(jìn)行優(yōu)化，通過架設(shè)專線或者租用騰訊云等方式可以大大提升通道服務(wù)質(zhì)量。 4. 對業(yè)務(wù)完全透明。客戶端的業(yè)務(wù)代碼只要接入網(wǎng)絡(luò)層的SDK即可，完全不用關(guān)心網(wǎng)絡(luò)請求使用的是長連通道還是短連通道。代理服務(wù)器將客戶端的請求還原為HTTP短連方式送到業(yè)務(wù)服務(wù)器，業(yè)務(wù)服務(wù)器不需要進(jìn)行任何改造。 5. 網(wǎng)絡(luò)協(xié)議完全自定義。

在長連通道項目的早期，出于快速推進(jìn)的目的，同時受限于建設(shè)代理長連服務(wù)器需要投入大量資金，我們首先接入使用了騰訊的維納斯（WNS）服務(wù)（官網(wǎng)地址：https://www.qcloud.com/product/wns ）。

WNS服務(wù)采用的也是代理長連模式，依托騰訊云的強(qiáng)大硬件建設(shè)，我們使用下來發(fā)現(xiàn)端到端成功率可以達(dá)到99.6%以上。（PS：這里的提到的端到端成功率與官網(wǎng)宣傳的99.9%不同是由于統(tǒng)計口徑的不同。）

由于騰訊WNS服務(wù)是面向公眾的云服務(wù)，服務(wù)的客戶遠(yuǎn)不止一家，無法完全滿足我們公司技術(shù)需求的快速變更，因此還是需要進(jìn)行自己的長連通道項目建設(shè)。

自建長連建設(shè)大概可以分為以下幾個周期：

① 中轉(zhuǎn)服務(wù)的開發(fā)和部署

作為開發(fā)的初級階段，這一時期的任務(wù)主要是搭建代理中轉(zhuǎn)服務(wù)器，并架設(shè)完整鏈路結(jié)構(gòu)。

② 加密通道的建設(shè)

為了保護(hù)TCP通道上數(shù)據(jù)的安全性，客戶端與代理長連服務(wù)器之間的二進(jìn)制通信數(shù)據(jù)可以利用加密來保障數(shù)據(jù)安全。

③ 專線建設(shè)

在代理長連服務(wù)器與后臺業(yè)務(wù)服務(wù)器之間建設(shè)專線。使用專線，可以大大降低公網(wǎng)環(huán)境的干擾，保障服務(wù)的穩(wěn)定性。

④ 自動降級Failover建設(shè)

由于客戶端的請求都放在TCP通道上進(jìn)行，當(dāng)代理長連服務(wù)器需要升級或者由于極端情況發(fā)生了故障時，將會造成客戶端的整體網(wǎng)絡(luò)服務(wù)不可用。為了解決這個問題，我們準(zhǔn)備了Failover降級方案。當(dāng)TCP通道無法建立或者發(fā)生故障時，可以使用UDP面向無連接的特性提供另一條請求通道，或者繞過代理長連服務(wù)器之間向業(yè)務(wù)服務(wù)器發(fā)起HTTP公網(wǎng)請求。本文的后面章節(jié)有展示Failover機(jī)制的實際效果。

⑤ 多地部署接入點

在全國多地部署代理長連接入點。客戶端與接入點建立長連通道時，可以選擇最快的服務(wù)器就近接入，從而大大降低通道連接速度并提升通信質(zhì)量。 我們在近兩年的網(wǎng)絡(luò)優(yōu)化實踐中，將客戶端的網(wǎng)絡(luò)通道服務(wù)整理成了一個獨立的SDK，SDK內(nèi)除了包含了自建的長連通信服務(wù)，也包含了WNS等網(wǎng)絡(luò)通道。

完整的網(wǎng)絡(luò)通道拓?fù)鋱D如下所示：

圖中網(wǎng)絡(luò)通道SDK包含了三大通信通道： 1. CIP通道：CIP通道就是上文中提到的自建代理長連通道。CIP是China Internet Plus的縮寫，為美團(tuán)點評集團(tuán)的注冊英文名稱。App中絕大部分的請求通過CIP通道中的TCP子通道與長連服務(wù)器（CIP Connection Server）通信，長連服務(wù)器將收到的請求代理轉(zhuǎn)發(fā)到業(yè)務(wù)服務(wù)器（API Server）。由于TCP子通道在一些極端情況下可能會無法工作，我們在CIP通道中額外部署了UDP子通道和HTTP子通道，其中HTTP子通道通過公網(wǎng)繞過長連服務(wù)器與業(yè)務(wù)服務(wù)器進(jìn)行直接請求。CIP通道的平均端到端成功率目前已達(dá)99.7%，耗時平均在350毫秒左右。 2. WNS通道：出于災(zāi)備的需要，騰訊的WNS目前仍被包含在網(wǎng)絡(luò)通道SDK中。當(dāng)極端情況發(fā)生，CIP通道不可用時，WNS通道還可以作為備用的長連替代方案。 3. HTTP通道：此處的HTTP通道是在公網(wǎng)直接請求API Server的網(wǎng)絡(luò)通道。出于長連通道重要性的考慮，上傳和下載大數(shù)據(jù)包的請求如果放在長連上進(jìn)行都有可能導(dǎo)致長連通道的擁堵，因此我們將CDN訪問、文件上傳和頻繁的日志上報等放在公網(wǎng)利用HTTP短連進(jìn)行請求，同時也減輕代理長連服務(wù)器的負(fù)擔(dān)。

推送方案：在網(wǎng)絡(luò)通道拓?fù)鋱D的右上角，有個Push Server。它是考慮到TCP通道的雙工特性，為網(wǎng)絡(luò)通道SDK提供推送的能力。利用通知推送，可以在服務(wù)器數(shù)據(jù)發(fā)生變化時及時通知客戶端。推送方案可以替換掉代碼中常見的耗時低效的輪詢方案。

案例展示

下圖展示了某開機(jī)接口在接入長連后的端到端成功率對比：

上圖中黑色曲線是某開機(jī)接口在短連通道下的成功率曲線。成功率平均只有81%，抖動的特別劇烈，說明網(wǎng)絡(luò)服務(wù)穩(wěn)定性不夠。

藍(lán)色曲線是同一接口在長連通道下的成功率曲線。成功率平均已達(dá)到99%，抖動大幅減小。

成功延時對比圖：

上圖中展示了同樣情況下的成功延時曲線。藍(lán)色線為長連延時曲線，黑色線為短連延時曲線。

接下來我們看Failover的效果展示圖。

下圖展示了2015年的一次長連服務(wù)器故障。

當(dāng)時Android客戶端采用了Failover方案，在長連不可用時Failover到短鏈或者UDP通道上。與未采用Failover方案的iOS客戶端相比，Failover機(jī)制在維持網(wǎng)絡(luò)整體可用性方面體現(xiàn)出了非常大的優(yōu)勢。

網(wǎng)絡(luò)配置系統(tǒng)

網(wǎng)絡(luò)通道SDK包含了CIP|WNS|HTTP三大通道，不同的通道具有各自的優(yōu)缺點，控制各請求選擇合適的網(wǎng)絡(luò)通道成了迫在眉睫的重要課題。

為此我們開發(fā)了網(wǎng)絡(luò)配置系統(tǒng)，通過下發(fā)指令，調(diào)整App中網(wǎng)絡(luò)通道SDK中的通道選擇策略，可以控制不同的API請求動態(tài)切換網(wǎng)絡(luò)通道。

下圖是某接口的線上通道切換示意圖：

圖中展示了某接口切換WNS通道的過程。圖中的黑色線代表短連通道下的請求數(shù)量曲線，藍(lán)色線代表WNS通道下的請求數(shù)量曲線。通過線上控制系統(tǒng)下發(fā)了通道切換指令后，絕大部分的短連請求在5分鐘之內(nèi)被切換成了WNS通道請求。

在客戶端開發(fā)過程中，我們發(fā)現(xiàn)： * 長連通道建立越早，成功率越高。長連通道越早建立，越多的請求能夠在長連通道上進(jìn)行。特別是當(dāng)App剛打開時，數(shù)量眾多的請求同時需要發(fā)出。面對這種情況，我們采取的策略是首先建立長連通道，將眾多請求放入等待發(fā)送隊列中，待長連通道建立完畢后再將等待隊列中的請求放在長連通道上依次送出。采用這種策略后，我們發(fā)現(xiàn)啟動時的接口成功率平均提升了1.4%，延時平均降低了160毫秒。 * TCP數(shù)據(jù)包越大，傳輸時間越長。如果長連通道未采用類似HTTP/2中的數(shù)據(jù)切片技術(shù)，大的數(shù)據(jù)包非常容易導(dǎo)致長連通道的堵塞。 * 底層SDK上線新功能一定要有線上降級手段。當(dāng)新功能上線了發(fā)生故障時，可以通過開關(guān)或參數(shù)控制，或是采用ABTest方式等進(jìn)行降級，防止故障擴(kuò)大化。 * iOS和Android系統(tǒng)網(wǎng)絡(luò)庫存在很多默認(rèn)行為。例如系統(tǒng)網(wǎng)絡(luò)庫會在內(nèi)部處理網(wǎng)絡(luò)重定向，再比如請求頭中如果沒有填寫Accept-Encoding或Content-Type等字段，系統(tǒng)網(wǎng)絡(luò)庫會自動填寫默認(rèn)值。 * 一個容易忽視的地方：HTTP的請求頭鍵值對中的的鍵是允許相同和重復(fù)的。例如下圖所示的”Set-Cookie”字段就是包含了多組的相同的鍵名稱。與之類似的還有”Cookie”字段。在長連通信中，如果對header中的鍵值對用不加處理的字典方式保存和傳輸，就會造成數(shù)據(jù)的丟失。

對于正在成長中的創(chuàng)業(yè)公司，我們有如下改善網(wǎng)絡(luò)狀況的建議： * 收攏網(wǎng)絡(luò)底層。隨著公司的成長，開發(fā)團(tuán)隊越來越多，不可避免的將會引入越來越多的網(wǎng)絡(luò)庫。網(wǎng)絡(luò)庫多了之后，再對網(wǎng)絡(luò)請求進(jìn)行集中管理就非常困難了。我們的建議是在網(wǎng)絡(luò)庫與業(yè)務(wù)代碼之間架設(shè)自己的網(wǎng)絡(luò)層，業(yè)務(wù)的網(wǎng)絡(luò)請求全部經(jīng)過網(wǎng)絡(luò)層代碼進(jìn)行請求。這樣未來進(jìn)行底層網(wǎng)絡(luò)庫的更換，或者網(wǎng)絡(luò)通道的優(yōu)化將變得容易很多。 * 使用網(wǎng)絡(luò)監(jiān)控。引入網(wǎng)絡(luò)監(jiān)控機(jī)制，發(fā)現(xiàn)網(wǎng)絡(luò)問題。這里推薦我公司開發(fā)的開源的Cat監(jiān)控系統(tǒng)。Cat開源地址為http://github.com/dianping/cat 。 * 嘗試進(jìn)行短連優(yōu)化。前文中提到的域名合并和IP直連方案都是簡單有效的手段。 * 可以嘗試HTTP/2或騰訊WNS長連服務(wù)。

周輝，美團(tuán)點評資深移動架構(gòu)師。所在團(tuán)隊負(fù)責(zé)整個集團(tuán)客戶端網(wǎng)絡(luò)通道、監(jiān)控、推送等底層SDK的開發(fā)和維護(hù)工作。

總結(jié)

以上是生活随笔為你收集整理的美团点评移动网络优化实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。