上個(gè)月我們線上系統(tǒng)跑出一個(gè)告警某個(gè)接口的P99耗時(shí)從前一天的320毫秒突然飆到1.8秒值班同事第一反應(yīng)是數(shù)據(jù)庫(kù)慢查詢結(jié)果查下來(lái)發(fā)現(xiàn)是某中老年用戶群體常用的社交功能列表頁(yè)在晚間活躍高峰把后端打穿了。這個(gè)排查過(guò)程讓我重新審視了一個(gè)問(wèn)題服務(wù)端技術(shù)本身沒有變但當(dāng)你的用戶是一群五六十歲、用著三四年前安卓手機(jī)、在客廳和臥室之間來(lái)回走動(dòng)著刷消息的人API接口設(shè)計(jì)的那套通用最佳實(shí)踐就明顯不夠用了。這篇文章想聊的就是這件事。中老年社交場(chǎng)景下的API接口設(shè)計(jì)聽起來(lái)是個(gè)垂直到不能再垂直的話題但它牽扯出來(lái)的問(wèn)題——弱網(wǎng)容忍、低端機(jī)適配、數(shù)據(jù)包體積控制、緩存策略、甚至安全校驗(yàn)的容錯(cuò)率——其實(shí)對(duì)任何面向泛人群的C端產(chǎn)品都有參考價(jià)值。我結(jié)合自己做過(guò)的一個(gè)模擬項(xiàng)目X來(lái)拆解項(xiàng)目本身是給中老年用戶做的興趣社群App核心功能包括圈子動(dòng)態(tài)、私信、語(yǔ)音消息和每日健康打卡。我會(huì)把接口設(shè)計(jì)里的關(guān)鍵取舍、踩過(guò)的坑、還有最終沉淀下來(lái)的方案一并寫出來(lái)希望對(duì)做社交產(chǎn)品后端的朋友有點(diǎn)用。1. 先搞清楚你的用戶到底在用什么設(shè)備很多接口設(shè)計(jì)的問(wèn)題根源不在接口本身而在你根本沒搞明白用戶的真實(shí)網(wǎng)絡(luò)環(huán)境和設(shè)備性能。我們團(tuán)隊(duì)一開始也犯過(guò)這個(gè)錯(cuò)用自己手里的旗艦機(jī)測(cè)接口感覺快得飛起結(jié)果跑到用戶群里一看完全不是一回事。1.1 中老年用戶設(shè)備畫像的四個(gè)典型特征第一個(gè)特征是設(shè)備整體偏老。我們統(tǒng)計(jì)過(guò)模擬項(xiàng)目X接入用戶的設(shè)備型號(hào)分布主力機(jī)型集中在一款三年前的千元機(jī)和一款兩年前的國(guó)產(chǎn)中端機(jī)內(nèi)存多數(shù)是4GB6GB的都算好的。這些設(shè)備的CPU性能和當(dāng)前主流中端機(jī)差了一整個(gè)代際意味著同樣一個(gè)JSON解析操作在新機(jī)上耗時(shí)5毫秒在舊機(jī)上可能要跑到20毫秒甚至更多。別小看這十幾毫秒當(dāng)一次列表刷新要解析幾百個(gè)字段時(shí)差距就會(huì)從毫秒級(jí)放大到幾百毫秒級(jí)用戶體感就是轉(zhuǎn)圈圈。第二個(gè)特征是網(wǎng)絡(luò)環(huán)境并不差但穩(wěn)定性很差。中老年用戶大多在家用Wi-Fi寬帶速率其實(shí)不低但問(wèn)題在于一是路由器老舊穿墻能力弱人一挪到陽(yáng)臺(tái)或衛(wèi)生間信號(hào)就劇烈波動(dòng)二是很多人習(xí)慣把手機(jī)放在一個(gè)固定位置人在屋里走動(dòng)手機(jī)在遠(yuǎn)處自動(dòng)切到蜂窩網(wǎng)絡(luò)切換過(guò)程會(huì)產(chǎn)生幾秒的請(qǐng)求中斷。我們測(cè)過(guò)這種場(chǎng)景下請(qǐng)求失敗重試的比例比年輕人通勤場(chǎng)景高得多。第三個(gè)特征是操作節(jié)奏慢但手速快。中老年用戶不會(huì)像年輕人那樣快速滑動(dòng)列表但他們會(huì)更頻繁地點(diǎn)擊按鈕、下拉刷新、反復(fù)進(jìn)入同一個(gè)頁(yè)面因?yàn)樗麄儗?duì)操作結(jié)果不確定總覺得剛才是不是沒點(diǎn)中。反應(yīng)到后端就是短時(shí)間內(nèi)對(duì)同一個(gè)接口的重復(fù)請(qǐng)求量明顯偏高。我們觀察到一個(gè)極端case有位用戶在三分鐘內(nèi)對(duì)某個(gè)詳情接口發(fā)起了47次請(qǐng)求而同期年輕用戶的均值只有4次。第四個(gè)特征是流量焦慮。中老年用戶對(duì)手機(jī)流量的敏感度極高很多人雖然連著Wi-Fi但心里總覺得用多了要花錢。這不是產(chǎn)品層面的偏見而是直接影響接口設(shè)計(jì)決策的因素同樣的功能如果一個(gè)方案要傳5MB數(shù)據(jù)另一個(gè)方案只需要傳800KB哪怕前者體驗(yàn)更流暢也要慎重。省流量在年輕用戶里是個(gè)賣點(diǎn)在中老年用戶里是底線需求。1.2 這些特征如何倒推API設(shè)計(jì)約束把上面四個(gè)特征翻譯成API設(shè)計(jì)約束大概有這么幾條接口響應(yīng)必須精簡(jiǎn)冗余字段能砍就砍能用數(shù)字枚舉的不要用長(zhǎng)字符串能合并的請(qǐng)求不要拆開。超時(shí)和重試策略必須寬容弱網(wǎng)下一次請(qǐng)求從發(fā)出到收到響應(yīng)可能需要8到10秒服務(wù)端不能按常規(guī)3秒超時(shí)直接斷開。接口必須具備冪等性因?yàn)橛脩魰?huì)重復(fù)點(diǎn)擊前端也需要在交互層做防抖但后端不能假設(shè)前端一定做了。數(shù)據(jù)預(yù)加載和緩存要主動(dòng)做不能指望每次操作都實(shí)時(shí)拉取最新數(shù)據(jù)要在用戶下一步很可能要看什么上做預(yù)判。兼容性要下沉不止是系統(tǒng)版本的兼容還包括老設(shè)備上WebView、TLS協(xié)議、JSON解析庫(kù)的兼容。這一節(jié)的核心結(jié)論是不要拿你自己的手機(jī)去衡量用戶的體驗(yàn)也不要拿通用行業(yè)基準(zhǔn)去設(shè)計(jì)你的接口?；ㄒ恢軙r(shí)間把線上日志里的設(shè)備模型、網(wǎng)絡(luò)類型、請(qǐng)求耗時(shí)分布拉出來(lái)看看比看十篇架構(gòu)文章都有用。2. 接口粒度設(shè)計(jì)少一次請(qǐng)求勝過(guò)優(yōu)化十次慢查詢接下來(lái)說(shuō)落地。中老年社交場(chǎng)景里接口設(shè)計(jì)最重要的一條原則我總結(jié)為一句話接口粒度要粗不要細(xì)。這不是說(shuō)所有接口都無(wú)腦合并成大接口而是在明確場(chǎng)景下做合理取舍。2.1 列表頁(yè)接口單次請(qǐng)求承載完整渲染我們團(tuán)隊(duì)的社交功能核心是圈子動(dòng)態(tài)Feed流。第一版設(shè)計(jì)沿用了常見的列表接口只返回摘要數(shù)據(jù)詳情靠點(diǎn)擊后再拉取模式結(jié)果用戶反饋點(diǎn)進(jìn)去半天不顯示內(nèi)容而且列表頁(yè)頻繁出現(xiàn)圖片裂開的樣式錯(cuò)亂問(wèn)題。排查發(fā)現(xiàn)原因有兩層第一層是網(wǎng)絡(luò)延遲列表頁(yè)加載完后用戶點(diǎn)擊某條動(dòng)態(tài)前端要再去請(qǐng)求詳情接口這中間多了一次完整RTT弱網(wǎng)下用戶等不了第二層是渲染不確定性摘要數(shù)據(jù)拿回來(lái)后前端要等圖片URL加載完成才渲染整張卡片某些圖片URL對(duì)應(yīng)的資源在老設(shè)備上解碼特別慢導(dǎo)致卡片區(qū)域長(zhǎng)時(shí)間空白。最終我們改成了Feed流列表接口一次性返回完整卡片所需的所有數(shù)據(jù)包括正文全文、圖片URL列表、音頻URL、點(diǎn)贊評(píng)論概要、作者信息。單條數(shù)據(jù)的體積從原來(lái)的4KB增加到9KB列表頁(yè)一次返回20條接口體量從原來(lái)的80KB增大到180KB左右。但換來(lái)的是頁(yè)面渲染一次到位用戶不需要再等待二次跳轉(zhuǎn)請(qǐng)求。同時(shí)我們引入了圖片漸進(jìn)式加載策略先返回小尺寸模糊圖URL再在客戶端閑時(shí)加載原圖保證用戶第一眼看到的是完整布局而非破碎圖片。這個(gè)改動(dòng)上線后列表到詳情的轉(zhuǎn)化路徑縮短了一半針對(duì)詳情接口的重復(fù)請(qǐng)求量下降了70%整體接口P95耗時(shí)因?yàn)樯倭硕翁D(zhuǎn)反而比原來(lái)快了260毫秒。2.2 命名原則和字段映射要服務(wù)端做掉第二件事是關(guān)于字段返回的。中老年用戶的設(shè)備老前端做復(fù)雜的數(shù)據(jù)映射時(shí)容易出現(xiàn)卡頓比如把服務(wù)端返回的性別代碼1/2映射為男/女把時(shí)間戳轉(zhuǎn)成10分鐘前這些邏輯如果都放在前端做每次渲染都要跑一遍在低端機(jī)上會(huì)造成可感知的卡頓。我們的做法是讓服務(wù)端直接返回前端渲染的最終形態(tài)。具體例子動(dòng)態(tài)發(fā)布時(shí)間服務(wù)端直接返回10分鐘前、昨天 14:30這樣的展示字符串動(dòng)態(tài)類型服務(wù)端直接返回普通動(dòng)態(tài)、語(yǔ)音動(dòng)態(tài)、打卡動(dòng)態(tài)這樣的枚舉文案頭像URL服務(wù)端直接返回已經(jīng)組裝好尺寸參數(shù)的完整地址前端不用自己去拼接裁剪參數(shù)。可能有同事會(huì)質(zhì)疑這樣會(huì)增加服務(wù)端計(jì)算和傳輸成本但實(shí)際算下來(lái)收益更大。服務(wù)端做這些映射是一次性的CPU開銷而且可以通過(guò)本地緩存字典減少重復(fù)計(jì)算前端的JavaScript解析和String處理在低端機(jī)上卻是每一次渲染都要跑的。你把復(fù)雜度放在你更可控、算力更強(qiáng)的那一端永遠(yuǎn)是對(duì)的。這里還要補(bǔ)充一個(gè)經(jīng)驗(yàn)接口返回的字段名也別用太精簡(jiǎn)的縮寫。我見過(guò)有些團(tuán)隊(duì)為了省流量把用戶昵稱返回成nn把頭像返回成av結(jié)果前端維護(hù)成本極高每次都要查字段對(duì)照表。中老年社交場(chǎng)景下的接口設(shè)計(jì)字段名清晰比省那幾KB重要得多因?yàn)槟愕那岸藞F(tuán)隊(duì)大概率不是一套人維護(hù)到底交接成本也是成本。2.3 按需加載的邊界在哪里接口粒度變粗不等于所有場(chǎng)景都一把梭。我們的實(shí)踐是分成三類場(chǎng)景分別定策略首頁(yè)Feed流粗粒度一次拉全卡片信息因?yàn)檫@是用戶停留最久、最核心的消費(fèi)場(chǎng)景卡頓感知最強(qiáng)。個(gè)人主頁(yè)中等粒度基礎(chǔ)信息一次返回但動(dòng)態(tài)列表、相冊(cè)等按Tab懶加載因?yàn)橛脩暨M(jìn)入主頁(yè)后不一定會(huì)點(diǎn)全部Tab。消息會(huì)話列表細(xì)粒度只返回最近一條消息的摘要和未讀數(shù)因?yàn)橄?chǎng)景強(qiáng)調(diào)即時(shí)更新拉全量歷史會(huì)造成明顯的流量浪費(fèi)。核心判斷標(biāo)準(zhǔn)是用戶下一步動(dòng)作的確定性。如果用戶進(jìn)入這個(gè)頁(yè)面的目的非常明確且預(yù)判他的下一步交互是確定的就盡量把數(shù)據(jù)一次給足如果用戶進(jìn)頁(yè)面后有多種分支可能就留一部分按需加載。這條規(guī)則放之四海皆準(zhǔn)但在中老年場(chǎng)景下尤其重要因?yàn)樗麄儗?duì)頁(yè)面半天刷不出來(lái)的耐心比年輕人低得多。3. 數(shù)據(jù)傳輸優(yōu)化省流、降耗、體驗(yàn)快三件事怎么同時(shí)做到接口設(shè)計(jì)不只是定義URL和返回結(jié)構(gòu)真正的比拼在數(shù)據(jù)傳輸鏈路。中老年社交場(chǎng)景對(duì)數(shù)據(jù)包的敏感度遠(yuǎn)超普通C端產(chǎn)品這一節(jié)說(shuō)幾個(gè)我們實(shí)測(cè)有效的策略。3.1 數(shù)據(jù)壓縮的層次選擇很多團(tuán)隊(duì)會(huì)直接上Gzip覺得這就算做了優(yōu)化。但Gzip是通用方案對(duì)JSON文本確實(shí)有效但在我們的場(chǎng)景里還不夠。我們最終采用的是分級(jí)壓縮策略。協(xié)議層面服務(wù)端到App走HTTP/2開啟了頭部壓縮這能有效減少每次請(qǐng)求的頭部體積極小體量的請(qǐng)求收益尤其明顯。內(nèi)容層面對(duì)JSON響應(yīng)體啟用Gzip壓縮實(shí)測(cè)壓縮率約70%180KB的響應(yīng)能壓到50多KB。更細(xì)一層針對(duì)圖片資源做了專門的體積控制所有頭像和配圖在服務(wù)端統(tǒng)一壓成三檔120px、480px、960px列表頁(yè)默認(rèn)取480px詳情頁(yè)根據(jù)屏幕寬度按需取960px同時(shí)全部轉(zhuǎn)成WebP格式。這里特別說(shuō)一下WebP的坑。WebP的壓縮率確實(shí)比JPEG高30%以上但老設(shè)備的解碼支持并不完美部分安卓7.0以下機(jī)型在解碼大尺寸WebP圖時(shí)會(huì)出現(xiàn)明顯的掉幀甚至黑屏。我們最后做了一個(gè)兼容方案服務(wù)端根據(jù)請(qǐng)求頭里的User-Agent判斷設(shè)備系統(tǒng)版本對(duì)安卓7.0以下的設(shè)備返回JPEG格式其他設(shè)備返回WebP。這個(gè)雙格式策略讓圖片數(shù)據(jù)量只優(yōu)化了一部分但換來(lái)的是所有機(jī)型都流暢顯示值了。3.2 端到端的流量記賬和觸達(dá)控制我強(qiáng)烈建議做中老年社交產(chǎn)品的團(tuán)隊(duì)在App端埋點(diǎn)統(tǒng)計(jì)每個(gè)頁(yè)面的實(shí)際流量消耗。我們當(dāng)時(shí)接入了流量統(tǒng)計(jì)SDK后臺(tái)能看到每個(gè)接口、每個(gè)圖片資源的平均流量這個(gè)數(shù)據(jù)對(duì)優(yōu)化方向的判斷很有用。舉例來(lái)說(shuō)我們發(fā)現(xiàn)一個(gè)問(wèn)題首頁(yè)Feed流背景圖是一張2K分辨率的全屏圖片每次進(jìn)首頁(yè)都會(huì)重新拉取這張圖單次就吃掉約900KB流量。對(duì)于每天打開App二十幾次的用戶來(lái)說(shuō)這個(gè)消耗相當(dāng)可觀。后來(lái)我們做成了首啟拉取并緩存后端主動(dòng)推送更新的模式圖片只在服務(wù)端更換主題時(shí)通過(guò)配置更新下發(fā)給客戶端平時(shí)直接讀本地緩存用戶單日流量消耗從平均6.2MB降到了2.8MB。這類觸達(dá)控制的思路在中老年場(chǎng)景里特別管用。中老年用戶不會(huì)主動(dòng)去清理緩存、不會(huì)刻意選擇僅在Wi-Fi下加載圖片他們更習(xí)慣能用就行。所以產(chǎn)品和技術(shù)得替他們做決定默認(rèn)開啟智能流量模式在移動(dòng)網(wǎng)絡(luò)下自動(dòng)降低圖片清晰度放慢預(yù)加載頻率Wi-Fi下才恢復(fù)高質(zhì)量加載。這個(gè)開關(guān)不需要讓用戶知道默認(rèn)開啟就好。3.3 分頁(yè)設(shè)計(jì)游標(biāo)分頁(yè)比頁(yè)碼分頁(yè)更適合分頁(yè)方式的選擇聽起來(lái)是技術(shù)細(xì)節(jié)但在中老年社交場(chǎng)景里直接關(guān)系到用戶體驗(yàn)。我們第一版用了傳統(tǒng)的頁(yè)碼分頁(yè)也就是page1size20這種結(jié)果在數(shù)據(jù)發(fā)生新增或刪除時(shí)用戶翻到第二頁(yè)會(huì)看到第一頁(yè)的重復(fù)內(nèi)容或直接跳頁(yè)對(duì)年輕人來(lái)說(shuō)這是個(gè)可接受的瑕疵但對(duì)中老年用戶來(lái)說(shuō)這會(huì)讓他們覺得手機(jī)壞了或者軟件出問(wèn)題了。后來(lái)我們改成了游標(biāo)分頁(yè)接口參數(shù)變成cursorxxxlimit20服務(wù)端返回下一頁(yè)的游標(biāo)值。游標(biāo)是上一頁(yè)最后一條數(shù)據(jù)的排序值通常是時(shí)間戳這樣即使有新數(shù)據(jù)插入下一頁(yè)也不會(huì)出現(xiàn)重復(fù)。這個(gè)改動(dòng)對(duì)用戶無(wú)感但它把翻頁(yè)錯(cuò)亂這一類投訴直接清零了。這也是中老年社交場(chǎng)景的一個(gè)特征技術(shù)上的坑最終都會(huì)以用戶覺得產(chǎn)品壞了的形式暴露出來(lái)。另外分頁(yè)大小也值得調(diào)。我們默認(rèn)每頁(yè)返回20條這個(gè)數(shù)值是在觀察用戶行為后定的——中老年用戶滑到列表底部需要大約35秒20條足夠他在這段時(shí)間里消費(fèi)完如果一次拉30條反而容易讓用戶在滑到底部時(shí)覺得列表太長(zhǎng)看不完產(chǎn)生挫敗感。順便說(shuō)一句列表到底部的加載中狀態(tài)提示中老年用戶是真的會(huì)等的但這個(gè)等待不要超過(guò)5秒所以我們把下拉加載更多的觸發(fā)閾值調(diào)得比普通App更靈敏用戶滑到接近底部時(shí)就開始預(yù)拉下一頁(yè)。4. 核心鏈路性能緩存體系、超時(shí)策略與重試冪等上面講的傳輸優(yōu)化解決的是數(shù)據(jù)太大的問(wèn)題接下來(lái)這個(gè)部分解決的是響應(yīng)太慢和失敗率太高的問(wèn)題。中老年社交場(chǎng)景里用戶操作節(jié)奏慢但等待耐心差這兩個(gè)特點(diǎn)疊加對(duì)核心鏈路的性能要求反而更高。4.1 三級(jí)緩存體系的搭建和參數(shù)選擇我們搭建了一套三級(jí)緩存體系客戶端本地緩存、邊緣節(jié)點(diǎn)緩存、服務(wù)端進(jìn)程內(nèi)緩存。第一級(jí)是客戶端本地緩存。以Feed流為例我們?cè)O(shè)計(jì)成首拉取成功后立即存入本地?cái)?shù)據(jù)庫(kù)下次打開列表頁(yè)先渲染本地緩存同時(shí)在后臺(tái)發(fā)起網(wǎng)絡(luò)請(qǐng)求等新數(shù)據(jù)回來(lái)后再做增量合并。這保證了用戶即使處于弱網(wǎng)甚至無(wú)網(wǎng)狀態(tài)打開App也一定能看到上一次的內(nèi)容不會(huì)出現(xiàn)白屏。這個(gè)先顯示舊數(shù)據(jù)再安靜更新的模式對(duì)中老年用戶來(lái)說(shuō)特別重要他們?cè)谝獾牟皇菙?shù)據(jù)絕對(duì)最新而是我能看到東西。第二級(jí)是邊緣節(jié)點(diǎn)緩存。我們當(dāng)時(shí)沒有自建CDN而是直接在接入層用了全站加速服務(wù)對(duì)GET類的列表接口開啟邊緣緩存緩存時(shí)間設(shè)成60秒。這意味著在60秒窗口內(nèi)命中邊緣節(jié)點(diǎn)的請(qǐng)求不會(huì)打到源站源站壓力大幅降低。有同學(xué)可能擔(dān)心緩存導(dǎo)致數(shù)據(jù)延遲但對(duì)于Feed流這種60秒前的內(nèi)容和現(xiàn)在的內(nèi)容幾乎無(wú)差別的場(chǎng)景完全沒問(wèn)題。我們的實(shí)踐是列表頁(yè)緩存60秒詳情頁(yè)緩存300秒個(gè)人信息緩存120秒各類配置信息緩存30分鐘。第三級(jí)是服務(wù)端進(jìn)程內(nèi)緩存。熱點(diǎn)圈子動(dòng)態(tài)的Top100數(shù)據(jù)常駐內(nèi)存過(guò)期時(shí)間30秒用一個(gè)定時(shí)任務(wù)從數(shù)據(jù)庫(kù)異步刷新。這樣即使同一時(shí)刻有一千個(gè)用戶同時(shí)請(qǐng)求同一個(gè)熱點(diǎn)圈子源站數(shù)據(jù)庫(kù)承受的查詢壓力也僅僅是每30秒一次全量刷新。實(shí)測(cè)下來(lái)熱點(diǎn)圈的接口P99從原始數(shù)據(jù)庫(kù)直查的1.2秒降到了180毫秒而且數(shù)據(jù)庫(kù)負(fù)載降低了85%。這里分享一個(gè)指標(biāo)三級(jí)緩存命中率。我們的目標(biāo)是整體緩存命中率達(dá)到90%以上實(shí)測(cè)穩(wěn)定在93%左右。如果你們的緩存命中率低于80%說(shuō)明緩存的設(shè)計(jì)粒度或過(guò)期策略有問(wèn)題要往回排查。4.2 超時(shí)時(shí)間和重試機(jī)制從快速失敗到合理等待通用后端設(shè)計(jì)中接口超時(shí)通常建議設(shè)短一點(diǎn)比如3秒以便快速失敗、快速釋放連接。但中老年社交場(chǎng)景真的不能這么做。我們一開始也設(shè)了3秒超時(shí)結(jié)果用戶投訴消息發(fā)不出去。后來(lái)用日志追蹤發(fā)現(xiàn)大批請(qǐng)求其實(shí)是發(fā)出去了服務(wù)端也處理完了但響應(yīng)在弱網(wǎng)回傳路徑上多花了2到3秒客戶端等不及就斷開連接了。用戶看到的是發(fā)送失敗實(shí)際上對(duì)方已經(jīng)收到消息這個(gè)體驗(yàn)是非常糟糕的——用戶會(huì)反復(fù)重發(fā)造成重復(fù)消息。調(diào)整后的策略是分場(chǎng)景設(shè)置超時(shí)普通列表請(qǐng)求超時(shí)設(shè)為8秒消息發(fā)送請(qǐng)求超時(shí)設(shè)為10秒大圖片上傳請(qǐng)求超時(shí)設(shè)為30秒。弱網(wǎng)下8秒等待確實(shí)會(huì)讓用戶覺得慢但配合四級(jí)加載狀態(tài)提示加載中、加載超時(shí)、可重試、已失敗用戶的情緒會(huì)可控很多。這里有個(gè)細(xì)節(jié)超時(shí)提示不要用請(qǐng)求超時(shí)請(qǐng)重試這種程序員語(yǔ)言我們改成了網(wǎng)絡(luò)有點(diǎn)慢正在努力加載中…配合一個(gè)轉(zhuǎn)圈動(dòng)畫實(shí)際等待8秒也不會(huì)被用戶罵垃圾App。重試機(jī)制要重點(diǎn)關(guān)注冪等性。中老年用戶重復(fù)點(diǎn)擊的概率高所以凡是寫操作的接口我們都強(qiáng)制要求前端生成一個(gè)全局唯一的請(qǐng)求IDrequestId服務(wù)端對(duì)這個(gè)ID做去重。具體實(shí)現(xiàn)是在接入層用Redis存一個(gè)已處理請(qǐng)求ID集合有效期10分鐘如果新請(qǐng)求的requestId已經(jīng)存在直接返回上一次的處理結(jié)果不再重復(fù)執(zhí)行業(yè)務(wù)邏輯。這套機(jī)制上線后重復(fù)發(fā)送消息、重復(fù)點(diǎn)贊、重復(fù)打卡的臟數(shù)據(jù)問(wèn)題基本清零。4.3 定時(shí)任務(wù)與預(yù)加載把性能問(wèn)題挪到閑時(shí)中老年用戶有一個(gè)明顯的使用時(shí)間規(guī)律上午8到10點(diǎn)、晚上8到9點(diǎn)是高峰其余時(shí)間相對(duì)平緩。針對(duì)這個(gè)規(guī)律我們?cè)陂e時(shí)窗口凌晨2點(diǎn)到4點(diǎn)做數(shù)據(jù)預(yù)構(gòu)建和推送。舉個(gè)具體例子每天的健康打卡動(dòng)態(tài)匯總榜需要聚合全站用戶的打卡數(shù)據(jù)如果等用戶早上打開App時(shí)實(shí)時(shí)算數(shù)據(jù)庫(kù)壓力非常大。我們的方案是凌晨跑定時(shí)任務(wù)算好榜單把結(jié)果寫成一份JSON快照上傳到對(duì)象存儲(chǔ)。用戶早上打開App時(shí)接口只返回一個(gè)對(duì)象存儲(chǔ)的CDN地址客戶端直接從這個(gè)地址下載榜單數(shù)據(jù)整個(gè)請(qǐng)求過(guò)程不碰數(shù)據(jù)庫(kù)。這個(gè)方案的接口耗時(shí)穩(wěn)定在50毫秒以內(nèi)不管有多少用戶同時(shí)打開它都不會(huì)被打垮。類似的還有圈子熱門話題榜、每日早安問(wèn)候包能離線預(yù)生成的都離線預(yù)生成。這個(gè)思路簡(jiǎn)單說(shuō)就是把用戶訪問(wèn)時(shí)才計(jì)算改成提前算好存好用戶訪問(wèn)時(shí)直接取。對(duì)技術(shù)團(tuán)隊(duì)來(lái)說(shuō)這犧牲了一點(diǎn)數(shù)據(jù)實(shí)時(shí)性但對(duì)中老年社交產(chǎn)品來(lái)說(shuō)實(shí)時(shí)性本身就不是核心訴求穩(wěn)定和便宜才是。5. 兼容性設(shè)計(jì)和安全校驗(yàn)的容錯(cuò)邊界做中老年社交產(chǎn)品的后端兼容性設(shè)計(jì)不是可選項(xiàng)而是需要專門花時(shí)間處理的硬性要求。很多在旗艦機(jī)上不是問(wèn)題的問(wèn)題在老舊設(shè)備上就是“致命傷”。5.1 系統(tǒng)版本與API Level的下沉策略我們當(dāng)時(shí)定了一個(gè)比較激進(jìn)的目標(biāo)支持到安卓6.0也就是API Level 23。這個(gè)決定本身就意味著很多現(xiàn)代特性不能用比如某些TLS加密套件、HTTP/2的完整支持、后臺(tái)任務(wù)調(diào)度等。實(shí)際踩過(guò)一個(gè)坑是TLS版本兼容。服務(wù)端強(qiáng)制開啟了TLS 1.2結(jié)果部分安卓6.0設(shè)備的WebView和OkHttp的老版本并不支持導(dǎo)致圖片加載和部分網(wǎng)頁(yè)打開直接失敗。排查后我們把服務(wù)端配置改成了TLS 1.2優(yōu)先、兼容TLS 1.1和1.0的降級(jí)策略雖然安全性稍有妥協(xié)但換來(lái)的是老設(shè)備都能正常訪問(wèn)。這里我想強(qiáng)調(diào)的是安全策略不能一刀切要在安全最低要求和用戶可用性之間找到平衡點(diǎn)尤其當(dāng)你的用戶是數(shù)字化接受度較低的群體時(shí)兼容性權(quán)重要更高。另外老設(shè)備的WebView版本普遍較低對(duì)ES6的JavaScript支持不全。我們前端因此放棄了部分現(xiàn)代框架的高級(jí)特性改用構(gòu)建時(shí)做ES5轉(zhuǎn)譯并且嚴(yán)格控制第三方依賴包的數(shù)量。這雖然不是后端API的直接工作但接口設(shè)計(jì)時(shí)要注意不要在接口響應(yīng)里嵌套過(guò)深的JSON結(jié)構(gòu)老設(shè)備的JSON解析器在解析超過(guò)5層的嵌套結(jié)構(gòu)時(shí)效率會(huì)明顯下降最好保持2到3層的平鋪結(jié)構(gòu)。5.2 接口安全校驗(yàn)的自適應(yīng)中老年用戶對(duì)安全驗(yàn)證的容忍度極低。比如圖形驗(yàn)證碼年輕人可能會(huì)覺得輸錯(cuò)了重來(lái)就行但中老年用戶會(huì)焦慮覺得是我眼睛不行了久而久之就不愿意使用這個(gè)功能。我們的做法是在風(fēng)控校驗(yàn)上做自適應(yīng)。正常使用場(chǎng)景下登錄和注冊(cè)只需要手機(jī)號(hào)加短信驗(yàn)證碼不做額外的人機(jī)驗(yàn)證。只有當(dāng)系統(tǒng)檢測(cè)到異常行為如同一IP短時(shí)間大量注冊(cè)、頻繁錯(cuò)誤密碼、請(qǐng)求特征異常時(shí)才升級(jí)驗(yàn)證強(qiáng)度要求用戶做滑塊或點(diǎn)擊驗(yàn)證。這個(gè)策略上線后用戶活躍度沒有明顯下降而惡意注冊(cè)量基本被擋住了。接口層面的安全措施包括強(qiáng)制HTTPS、登錄態(tài)Token短期有效并支持自動(dòng)續(xù)期、對(duì)寫操作接口做基于請(qǐng)求頻率的限流。限流的閾值也比通用標(biāo)準(zhǔn)放得寬一些比如點(diǎn)贊操作我們?cè)试S每分鐘60次因?yàn)橹欣夏暧脩粽`觸的概率真的很高。如果按通用的每分鐘20次來(lái)設(shè)會(huì)有大量正常用戶被誤傷影響口碑。5.3 無(wú)障礙與輔助功能倒推的接口需求中老年用戶里有一部分人開啟了系統(tǒng)的字體放大模式甚至使用屏幕朗讀輔助功能。這給接口設(shè)計(jì)帶了一個(gè)很實(shí)際的需求響應(yīng)文本不能是寫死的拼接句子。舉個(gè)例子動(dòng)態(tài)列表的點(diǎn)贊數(shù)如果服務(wù)端返回贊123人在屏幕朗讀模式下會(huì)讀成贊冒號(hào)一百二十三人非常生硬。我們最后改成同時(shí)返回兩個(gè)字段num123和label123人贊過(guò)朗讀模式下前端使用專用字段拼接成完整句子視覺模式下使用展示字段。這類細(xì)節(jié)不直接影響接口性能但對(duì)特定人群的使用體驗(yàn)是決定性的。還有字體放大的問(wèn)題。尺寸適配是前端的工作但接口側(cè)要保持高度靈活不能返回帶有固定文案拼接的HTML片段否則放大字體時(shí)排版必然錯(cuò)亂。我們的統(tǒng)一規(guī)則是接口永遠(yuǎn)返回?cái)?shù)據(jù)本身不帶樣式和展示邏輯。6. 監(jiān)控告警的建設(shè)從接口P99耗時(shí)到用戶體驗(yàn)健康度做性能優(yōu)化不能只靠上線前的測(cè)試線上真實(shí)流量下的表現(xiàn)才是唯一標(biāo)準(zhǔn)。我們花了不少精力搭了一套針對(duì)中老年場(chǎng)景的監(jiān)控體系下面說(shuō)幾個(gè)核心思路。6.1 用體驗(yàn)健康分代替單一耗時(shí)指標(biāo)單看平均耗時(shí)或P99耗時(shí)在中老年用戶群里容易失真因?yàn)樵O(shè)備型號(hào)差異太大平均值會(huì)被高性能設(shè)備拉低。我們綜合了幾個(gè)維度設(shè)計(jì)了一個(gè)體驗(yàn)健康分請(qǐng)求成功率權(quán)重30%、P90耗時(shí)權(quán)重25%、弱網(wǎng)請(qǐng)求占比權(quán)重20%、客戶端報(bào)錯(cuò)率權(quán)重15%、圖片加載失敗率權(quán)重10%。每周計(jì)算一次90分以上為優(yōu)75到89分為良低于75分觸發(fā)重點(diǎn)關(guān)注。這個(gè)分?jǐn)?shù)的意義在于它把接口快不快翻譯成了用戶能不能順暢地用起來(lái)。比如某接口平均耗時(shí)只有200毫秒但弱網(wǎng)請(qǐng)求占比達(dá)到40%說(shuō)明大量用戶正處在不穩(wěn)定的網(wǎng)絡(luò)環(huán)境中這個(gè)接口的實(shí)際體驗(yàn)可能比數(shù)據(jù)看起來(lái)差得多。用健康分做管理抓手技術(shù)團(tuán)隊(duì)能更直觀地和產(chǎn)品、運(yùn)營(yíng)溝通性能問(wèn)題。6.2 按設(shè)備、版本、地域進(jìn)行分維度監(jiān)控全局指標(biāo)往往掩蓋問(wèn)題。我們會(huì)定期跑一個(gè)分維度報(bào)表按設(shè)備型號(hào)維度、按App版本維度、按地域維度分別看各接口的健康分。按設(shè)備維度能看到某個(gè)老機(jī)型上的性能異常便于推動(dòng)前端做針對(duì)性優(yōu)化按版本維度能發(fā)現(xiàn)某個(gè)App版本是否引入了性能回退按地域維度能判斷某個(gè)區(qū)域的網(wǎng)絡(luò)基礎(chǔ)設(shè)施是否需要特殊處理比如我們?cè)诒狈侥呈y(cè)到過(guò)蜂窩網(wǎng)絡(luò)HTTP請(qǐng)求失敗率明顯偏高后來(lái)發(fā)現(xiàn)是當(dāng)?shù)夭糠只緦?duì)長(zhǎng)連接的支持不穩(wěn)定調(diào)整了連接?；畈呗院蠡謴?fù)了正常。這類問(wèn)題只看全局監(jiān)控是永遠(yuǎn)發(fā)現(xiàn)不了的。6.3 告警要準(zhǔn)而不是多告警疲勞是監(jiān)控體系最大的敵人。我們踩過(guò)的坑是剛開始接了一堆告警結(jié)果半夜被短信轟炸值班同事慢慢就麻木了真正嚴(yán)重的問(wèn)題反而被忽略。后來(lái)做了收斂核心寫操作接口發(fā)消息、打卡、注冊(cè)只要出現(xiàn)成功率低于96%立刻告警并附帶Top5失敗原因其他讀接口成功率低于99%才告警性能類告警只在健康分低于75分時(shí)觸發(fā)并且自動(dòng)帶上分維度數(shù)據(jù)。這一套下來(lái)告警量降低了70%但真正需要人工介入的問(wèn)題一次也沒漏掉。7. 一圖流排查手冊(cè)中老年社交場(chǎng)景接口問(wèn)題速查做技術(shù)分享不能只講思路還得給點(diǎn)能直接用的小抄。我整理了一個(gè)排查速查表覆蓋了我們實(shí)際開發(fā)運(yùn)維中最常見的12個(gè)問(wèn)題每個(gè)都標(biāo)注了根因和解決方向希望能幫各位減少踩坑時(shí)間。問(wèn)題描述根因分析解決方向列表頁(yè)偶發(fā)白屏老設(shè)備WebView對(duì)WebP解碼失敗根據(jù)User-Agent降級(jí)返回JPEG消息發(fā)送顯示失敗但對(duì)方已收到弱網(wǎng)響應(yīng)超時(shí)客戶端提前斷開超時(shí)調(diào)到10秒并做requestId冪等用戶反復(fù)下拉刷新下拉刷新無(wú)節(jié)流前端做防抖服務(wù)端對(duì)高頻刷新做限速Feed流圖片加載一半卡住大圖在小內(nèi)存設(shè)備上解碼崩潰降低默認(rèn)圖片檔位按屏幕寬度動(dòng)態(tài)選擇部分老機(jī)型打不開AppTLS版本不兼容服務(wù)端開啟TLS降級(jí)兼容策略詳情頁(yè)展示緩慢詳情數(shù)據(jù)依賴多個(gè)子接口列表接口直接返回完整卡片數(shù)據(jù)凌晨高峰源站被打垮熱點(diǎn)數(shù)據(jù)實(shí)時(shí)查詢壓力大熱點(diǎn)Top數(shù)據(jù)進(jìn)程內(nèi)緩存30秒過(guò)期翻頁(yè)看到重復(fù)內(nèi)容頁(yè)碼分頁(yè)在新數(shù)據(jù)插入時(shí)出現(xiàn)偏移改為基于游標(biāo)的分頁(yè)用戶操作過(guò)后數(shù)據(jù)未更新邊緣緩存TTL過(guò)長(zhǎng)動(dòng)態(tài)類接口關(guān)閉緩存或TTL縮短為5秒App日流量消耗異常高圖片重復(fù)拉取無(wú)緩存策略首啟拉取本地緩存閑時(shí)更新驗(yàn)證碼輸入正確卻登錄失敗老設(shè)備的Cookie或Token過(guò)期機(jī)制登錄態(tài)做自動(dòng)續(xù)期不強(qiáng)制重新登錄反復(fù)收到同一通知重試機(jī)制無(wú)去重全局requestId去重有效期10分鐘這張表看起來(lái)簡(jiǎn)單每一條背后都是一段線上事故。我建議各位在同類型項(xiàng)目中建一個(gè)自己的問(wèn)題速查庫(kù)把每次排查的經(jīng)歷沉淀下來(lái)別讓經(jīng)驗(yàn)只存在某一個(gè)人的腦子里。8. 幾個(gè)特別想強(qiáng)調(diào)的實(shí)戰(zhàn)心得文章走到這里已經(jīng)聊了很多具體方案。最后額外分享三個(gè)我事后復(fù)盤覺得最有價(jià)值的心得它們不一定在某一個(gè)接口設(shè)計(jì)上體現(xiàn)但會(huì)影響整個(gè)系統(tǒng)的走向。第一個(gè)心得是接口設(shè)計(jì)永遠(yuǎn)要為你真實(shí)的用戶畫像服務(wù)而不是為技術(shù)潮流服務(wù)。中老年社交場(chǎng)景讓我明白一件事所謂的技術(shù)最佳實(shí)踐往往隱含了一個(gè)默認(rèn)前提——用戶用的是近兩三年的設(shè)備、處在穩(wěn)定的網(wǎng)絡(luò)環(huán)境、具備一定的產(chǎn)品操作經(jīng)驗(yàn)。當(dāng)你的用戶不符合這個(gè)前提時(shí)大膽地偏離那些最佳實(shí)踐不是技術(shù)倒退而是務(wù)實(shí)的工程判斷。反向例子也有我們當(dāng)時(shí)因?yàn)閼峙戮S護(hù)成本而沒有在一開始就做客戶端緩存結(jié)果上線后被用戶投訴逼著補(bǔ)做返工成本遠(yuǎn)比一開始就規(guī)劃要高。第二個(gè)心得是性能優(yōu)化永遠(yuǎn)先解決最痛的那一個(gè)點(diǎn)不要全面鋪開。我們項(xiàng)目初期恨不得把壓測(cè)、調(diào)優(yōu)、緩存、CDN全都做一遍結(jié)果發(fā)現(xiàn)真正決定用戶體驗(yàn)的是一個(gè)最簡(jiǎn)單的問(wèn)題圖片不壓縮。當(dāng)我們把圖片體積從單張2MB降到300KB之后用戶投訴里關(guān)于加載慢的比例直接下降了60%。先找到那個(gè)最痛的20%問(wèn)題解決它再迭代去看下一個(gè)。全面鋪開的優(yōu)化往往陷入每個(gè)點(diǎn)都做了但每個(gè)點(diǎn)都沒做到位的尷尬。第三個(gè)心得是任何API設(shè)計(jì)都要為后續(xù)的運(yùn)營(yíng)動(dòng)作留余地。中老年社交產(chǎn)品很依賴運(yùn)營(yíng)活動(dòng)來(lái)拉活比如逢年過(guò)節(jié)的合影打卡、健康挑戰(zhàn)賽。這類活動(dòng)往往會(huì)瞬時(shí)帶來(lái)數(shù)倍于平日的請(qǐng)求量。我們之前設(shè)計(jì)接口時(shí)沒有考慮擴(kuò)容余量結(jié)果某次重陽(yáng)節(jié)活動(dòng)一上線簽到接口直接被打到超時(shí)。后來(lái)所有重點(diǎn)讀接口都強(qiáng)制支持邊緣緩存和進(jìn)程內(nèi)緩存寫接口都做了削峰填谷的異步化處理再遇到活動(dòng)流量高峰就從容多了。寧可在平時(shí)多花一點(diǎn)成本做冗余也不要在流量突增時(shí)節(jié)節(jié)敗退。中老年社交方向的產(chǎn)品從業(yè)務(wù)角度看天花板不高但從技術(shù)角度看它逼著你把基本功做扎實(shí)把每一個(gè)細(xì)節(jié)都扣到極致。希望大家在看完這篇分享后能帶著幾個(gè)實(shí)際可用的判斷標(biāo)準(zhǔn)回到自己的項(xiàng)目里你的用戶畫像真的符合你的技術(shù)假設(shè)嗎你的接口是否在替用戶決定該不該省流量你的監(jiān)控是否真的能反映用戶感受到的體驗(yàn)把這幾個(gè)問(wèn)題想透比抄十個(gè)接口模板都管用。