北京
真正讓API崩潰的，從來不是那些高大上的架構(gòu)問題。而是那些你覺得“這能出什么事”的細(xì)節(jié)。
以前我總把驗(yàn)證邏輯藏在業(yè)務(wù)代碼深處。直到各種詭異bug從完全不相干的地方冒出來，我才意識(shí)到——臟數(shù)據(jù)就像病毒，會(huì)在系統(tǒng)里擴(kuò)散?，F(xiàn)在的做法很粗暴：在入口處就掐斷。
如果請(qǐng)求體里缺少email字段，或者類型不對(duì)，立刻返回400狀態(tài)碼和明確的錯(cuò)誤信息。業(yè)務(wù)邏輯層里絕不夾帶任何驗(yàn)證代碼，一行都不行。這個(gè)原則讓我少熬了無數(shù)個(gè)凌晨三點(diǎn)的夜。
另一個(gè)血淚教訓(xùn)：錯(cuò)誤信息也是API契約的一部分。生產(chǎn)環(huán)境里返回一個(gè)籠統(tǒng)的500錯(cuò)誤，跟沒返回差不多。用戶不知道發(fā)生了什么，你的Slack群里開始瘋狂彈消息問“為什么我的請(qǐng)求掛了”。
明確告訴調(diào)用者哪里出問題——是API密鑰無效返回401，還是額度用盡返回402。如果你的錯(cuò)誤信息還需要人工在聊天工具里額外解釋，那說明你的API消息本身就是失敗的。好的錯(cuò)誤響應(yīng)應(yīng)該讓人一看就知道下一步該怎么做。
中間件順序這件事，能讓你掉進(jìn)最深的坑。我曾經(jīng)花了幾個(gè)小時(shí)排查“明明配了認(rèn)證但就是不起作用”的問題。最后發(fā)現(xiàn)只是一行代碼放錯(cuò)了位置。
CORS、JSON解析、認(rèn)證中間件、路由掛載，這四個(gè)的順序動(dòng)一個(gè)字母，整個(gè)應(yīng)用的行為就徹底變了。而且這種bug最陰險(xiǎn)的地方在于——它不會(huì)報(bào)錯(cuò)，只會(huì)靜默失敗。你甚至意識(shí)不到中間件被跳過了。
日志也走過兩個(gè)極端。一開始什么都不記，出了事抓瞎。后來什么都記，凌晨三點(diǎn)對(duì)著海量日志發(fā)呆，有用的信息被噪音淹沒。
生產(chǎn)環(huán)境真正有用的是兩條：一條記錄每個(gè)請(qǐng)求的方法、路徑和返回的狀態(tài)碼，簡潔到可以一眼掃完；另一條在出錯(cuò)時(shí)記錄請(qǐng)求ID、錯(cuò)誤信息和堆棧。其他所有花里胡哨的日志格式，在凌晨三點(diǎn)排查故障時(shí)都會(huì)變成你的敵人。
最后一個(gè)教訓(xùn)是用真金白銀換來的?？粗硞€(gè)接口被瘋狂調(diào)用，賬單數(shù)字往上跳的時(shí)候，你才會(huì)明白“限流以后再說”這句話有多蠢。
60秒窗口期最多允許60次請(qǐng)求的配置，用幾行代碼就能集成進(jìn)去。如果你的API沒有限制，那它就沒有保護(hù)——它有的只是僥幸。而生產(chǎn)環(huán)境從來不在乎你的僥幸心理。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺(tái)“網(wǎng)易號(hào)”用戶上傳并發(fā)布，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
