本文從客戶端的視角，分享客戶端如何協(xié)同服務(wù)端進行接口時間的優(yōu)化。
Compose是什么
接口性能優(yōu)化對于客戶端的同學(xué)來講涉及可能不是很多，但是接口的性能對于客戶端的體驗影響是巨大的；請求失敗、loading、無數(shù)據(jù)這幾個關(guān)鍵詞跟客戶端的同學(xué)一提，想必接口優(yōu)化的意義就不用多說了吧。
一個快速而又穩(wěn)定的接口，對于客戶端的用戶體驗來說是大有裨益的。本文從客戶端的視角，分享客戶端如何協(xié)同服務(wù)端進行接口時間的優(yōu)化。
分析
?簡析
客戶端的一次完整的接口請求主要包括：
- 業(yè)務(wù)發(fā)起請求
- 網(wǎng)絡(luò)傳輸
- 服務(wù)端處理
- 數(shù)據(jù)響應(yīng)后解析
- 圖層布局與渲染
那么我們來看一下通常客戶端發(fā)起一次接口請求，耗時都發(fā)生在哪些階段：
- Prepare：主要包括請求前的參數(shù)拼裝以及發(fā)送請求處理的線程切換；
：主要包括，鑒權(quán)、網(wǎng)絡(luò)傳輸、服務(wù)端處理、Network SDK的數(shù)據(jù)處理等。 - Data Parse：業(yè)務(wù)上的數(shù)據(jù)解析，如json解析等的操作，以及線程間的切換等耗時。
- UI Refresh：主要是視圖布局，渲染的操作。
- First Item Render：第一張卡片的渲染時間。
從上面數(shù)據(jù)上來看，客戶端的耗時主要是：
- 請求前的參數(shù)綁定過程
- 請求后數(shù)據(jù)解析
- 數(shù)據(jù)上屏的圖層布局以及渲染
- 異步請求過程中的線程不斷切換造成切換耗時
客戶端上這些操作往往在整個鏈路上占比較小，且過程優(yōu)化空間較小；
然而大頭往往在這兩個方面：網(wǎng)絡(luò)傳輸和服務(wù)端處理。
方案
?降低ServerRT（服務(wù)端處理耗時）
通常降低服務(wù)端處理耗時，是由服務(wù)端小伙伴來優(yōu)化，當然優(yōu)化過程中需要端上一起協(xié)助完成，大致了解一下服務(wù)端耗時的幾種處理方案；
主要有這幾種方式：
- 接口加緩存：合理設(shè)計臨時緩存、持久緩存可以提高接口性能
- 內(nèi)部接口并發(fā)請求：通常一個復(fù)雜的接口需要調(diào)用下游幾個業(yè)務(wù)的接口，如果合理的進行并發(fā)請求，將會收到很好的效果
- 異步化：如寫日志，更新緩存等不會影響接口準確性的非核心流程，可以采用異步方式進行處理，不阻塞主計算邏輯處理
- 數(shù)據(jù)批量處理：接口存在較大量計算，可以通過批量分批次(分而治之)方式來解決大量數(shù)據(jù)計算耗時問題
- sql加索引：數(shù)據(jù)庫SQL是最常見的性能瓶頸，如SQL子查詢、不合理索引設(shè)計、全表掃描、大量數(shù)據(jù)返回、大SQL等，通過監(jiān)控平臺查看慢查詢SQL可立即找出影響接口性能瓶頸關(guān)鍵點
?降低網(wǎng)絡(luò)傳輸時間
雖然現(xiàn)有階段大多數(shù)用戶網(wǎng)絡(luò)已經(jīng)很不錯了，但是還是有很多場景下，網(wǎng)絡(luò)耗時占比還是非常高，尤其長尾數(shù)據(jù)中，網(wǎng)絡(luò)耗時往往是最大的占比，所以網(wǎng)絡(luò)耗時的優(yōu)化依然是非常重要；當然端上的小伙伴在這個階段可參與的空間也更多。
主要有哪些方式呢？
- 接口多段返回
通常一個接口承載了較多的內(nèi)容的話，其內(nèi)容就會無限的進行膨脹，如果將埋點，日志，反饋等非主線的數(shù)據(jù)進行多段返回的話將會有很大的收益，此方案主要結(jié)合接口組成進行分析；當然，此方案改動量也比較大，成本也比較高。
- 更換協(xié)議
大多數(shù)我們接口使用的是TCP協(xié)議，相比來說如果更換UDP協(xié)議，接口返回速度會快不少，詳細原因可以翻一下資料學(xué)習(xí)一下，這里不再多說。
目前也已經(jīng)有成熟的方案，比如阿里的XQUIC，有感興趣的可以了解一下，具體的收益我這里也還在測試中。
- 縮小網(wǎng)絡(luò)包
為何縮小網(wǎng)絡(luò)包會降低網(wǎng)絡(luò)傳輸時間呢？
客戶端和服務(wù)端網(wǎng)絡(luò)通信時數(shù)據(jù)傳輸過程如下圖所示：
數(shù)據(jù)包越大，則在光纖傳輸時所需的時間就會越久，因此接收方等待數(shù)據(jù)包的時間也會更長，最終會導(dǎo)致應(yīng)用層等待數(shù)據(jù)時間變長。
還有，由于TCP采用的滑動窗口機制來提升傳輸性能，窗口的大小受接收端處理速率和網(wǎng)絡(luò)擁塞情況影響，因此如果傳輸?shù)陌叫。瑒t可以在盡量少的窗口周期完成數(shù)據(jù)的傳輸，減少響應(yīng)的等待時間，反之，響應(yīng)等待更長。
從上面幾個方式來看，業(yè)務(wù)客戶端能夠做的一部分其實是縮小網(wǎng)絡(luò)包的大小，那么我們下面介紹一下縮小網(wǎng)絡(luò)包研究。
收益
?縮小接口網(wǎng)絡(luò)數(shù)據(jù)包方案與收益
- 縮小網(wǎng)絡(luò)包，是否真的會對網(wǎng)絡(luò)的傳輸有效果呢？
我們對數(shù)據(jù)包的大小與網(wǎng)絡(luò)傳輸時長做了一個線下的實驗，以下是實驗的數(shù)據(jù)：
其他條件不變，我們將一頁返回數(shù)據(jù)改變后的數(shù)據(jù)；
可以看出網(wǎng)絡(luò)傳輸時間與數(shù)據(jù)包的大小是有著正相關(guān)的關(guān)系的。
- 減少網(wǎng)絡(luò)包大小有哪些措施呢？
更優(yōu)的壓縮算法
不同的壓縮算法，壓縮算法是不一樣的：
圖片來源于網(wǎng)上大佬的圖片
但是，壓縮算法的調(diào)整需要考慮方面很多，如果僅僅是網(wǎng)絡(luò)時間的收益在很多場景下可能成本較高，暫未考慮。
減少返回數(shù)據(jù)個數(shù)
減少返回數(shù)據(jù)個數(shù)，服務(wù)端的同學(xué)已經(jīng)在投入，但是遇到了一個問題，數(shù)據(jù)個數(shù)的減少就需要增加請求的次數(shù)，機器資源的成本就會升高，需要申請機器的資源；那就比較尷尬了，本身是優(yōu)化，卻讓成本來買單。
精簡返回字段
在原有的請求數(shù)據(jù)上通過精簡字段，減少數(shù)據(jù)包的大小。這樣既能降低數(shù)據(jù)包，成本又不增高。如何做呢？下面來研究一下。
?精簡數(shù)據(jù)報文
- 做一個實驗
一個接口的分頁接口數(shù)據(jù)包大小在1.5M左右，Server使用的是gzip（best模式）的壓縮方式，我進行壓縮后的大小為106KB左右。通常其他接口數(shù)據(jù)包大小壓縮后普遍在10KB以下，所以可以看出分頁接口橫向?qū)Ρ葋砜矗瑪?shù)據(jù)包大小是非常嚴重的。這也是為什么會選擇精簡數(shù)據(jù)報文作為優(yōu)化手段一大原因。
- 分析
精簡數(shù)據(jù)報文需要根據(jù)業(yè)務(wù)的場景來看，我這里來舉一個我這邊實踐的例子：
從數(shù)據(jù)包上分析，業(yè)務(wù)A的數(shù)據(jù)占比59.8%，而且該業(yè)務(wù)數(shù)據(jù)元素字段重復(fù)率非常高，來看一下去除該業(yè)務(wù)后的數(shù)據(jù)包大小：
原始數(shù)據(jù)
精簡后
降低率
59.8%
從數(shù)據(jù)比對來看，不同的卡片有大約18處的不同，其占比：
占比 = 1 - (5350 / 17439) ≈ 0.693
那么，此時就有一個問題了，重復(fù)的數(shù)據(jù)，經(jīng)過壓縮后還會占包大小嗎？
所以我就用服務(wù)端的壓縮方式對數(shù)據(jù)做了個壓縮：
原始數(shù)據(jù)
精簡后
原始數(shù)據(jù)Gzip壓縮
精簡后Gzip壓縮
降低率
59.8%
90%
95%
數(shù)據(jù)表明，針對重復(fù)字段的精簡，壓縮后依然是有效的。
壓縮后降低率依然有46.9%。
拿到這個結(jié)果后，如何做呢？
?數(shù)據(jù)查找表
將重復(fù)的業(yè)務(wù)數(shù)據(jù)在第一頁的數(shù)據(jù)中建立字段的查找表，然后通過端上進行合并操作，具體方式：
但是，與服務(wù)端的同學(xué)對方案時，發(fā)現(xiàn)請求的第一頁數(shù)據(jù)放置查找表，服務(wù)端不容易實現(xiàn)，因為數(shù)據(jù)在下游。
調(diào)整方案，將數(shù)據(jù)查找表改放置在每一頁數(shù)據(jù)中，這樣服務(wù)端更改就非常少了，實現(xiàn)也比較簡單。
但是數(shù)據(jù)放在每一頁，壓縮后還會有收益嗎？來看一下實驗的結(jié)果：
采用壓縮方式：gzip的壓縮方式
壓縮比：best模式（系統(tǒng)缺省值6）
方案1：
將負反饋數(shù)據(jù)查找表放在第一頁數(shù)據(jù)中：
優(yōu)化前后：降低45KB
降低率 ：1 - 61 / 106 ≈ 42.2%
方案2：
將負反饋數(shù)據(jù)查找表放置于每一頁數(shù)據(jù)的頭部：
優(yōu)化前后：降低43KB
降低率 ：1 - 63 / 106 ≈ 40.5%
實驗發(fā)現(xiàn)，查找表的數(shù)據(jù)僅僅占用2KB，優(yōu)化依然有效。
?優(yōu)化效果
- 精簡報文
在原有的數(shù)據(jù)包下，線下實驗，精簡字段會將數(shù)據(jù)包從106KB降低至63KB；線下的實驗可以得到接近90ms的優(yōu)化；
- 縮小返回數(shù)據(jù)個數(shù)
縮小接口返回數(shù)據(jù)的個數(shù)，從50個降低至20個，數(shù)據(jù)大小大約降低63KB，網(wǎng)絡(luò)傳輸耗時減低107ms；
結(jié)論
- 數(shù)據(jù)包的大小對于接口的性能、響應(yīng)以及失敗率都有影響
- 在一定場景下，數(shù)據(jù)中的重復(fù)字段對壓縮后數(shù)據(jù)包依然有較大的影響。
注：
- 網(wǎng)絡(luò)傳輸使用的是服務(wù)端的壓縮包，所以大小要看壓縮后的包大小
- 精簡報文有很多同學(xué)可能都試過，實現(xiàn)后發(fā)現(xiàn)收益很小，所以需要先衡量包的大小會不會對網(wǎng)絡(luò)傳輸造成影響，如果僅僅是幾KB的優(yōu)化，從上面實驗可以看出，基本收益不大，如果是上百KB，收益肯定是有的。
團隊介紹
我們是大淘寶技術(shù)-用戶產(chǎn)品技術(shù)，團隊主要負責(zé)電商核心基礎(chǔ)鏈路業(yè)務(wù)和平臺的研發(fā)，包含：手機淘寶首頁、信息流、NewDetail、商品詳情、購物車、全域觸達、分享購物車、消息平臺等電商核心基礎(chǔ)能力及創(chuàng)新型業(yè)務(wù)。這里有世界一流的技術(shù)產(chǎn)品，有超大的電商基礎(chǔ)場景，有百億級別的數(shù)據(jù)、有超過百萬QPS的高并發(fā)流量，有豐富的業(yè)務(wù)場景，服務(wù)于10億級的消費者，這里有巨大的挑戰(zhàn)等著你的到來。
作者:馬啟超（是也）
出處:https://mp.weixin.qq.com/s/NYUuP1mG2o1E6QkVUoRjiw
