拿到租車寶 token-1002 算法分析這個(gè)需求的時(shí)候我第一反應(yīng)不是去翻代碼而是先問(wèn)了自己一個(gè)問(wèn)題這個(gè) token 到底是什么形態(tài)的 token1002 又是誰(shuí)定的編號(hào)。干過(guò)計(jì)費(fèi)、結(jié)算、網(wǎng)關(guān)這類系統(tǒng)的同學(xué)都懂token 這詞在不同上下文里含義完全不一樣。它是用戶登錄后的會(huì)話憑證還是訂單里的優(yōu)惠抵扣憑證或者是下發(fā)到車機(jī)端的授權(quán)令牌這三條路線的分析思路可能完全不同。先說(shuō)結(jié)論這類帶編號(hào)的算法分析真正耗費(fèi)時(shí)間的不是破解算法本身而是先搞清楚它服務(wù)的業(yè)務(wù)場(chǎng)景。token-1002 大概率是租車計(jì)費(fèi)或訂單業(yè)務(wù)域里的一個(gè)算法編號(hào)名字里的token承載的是一次租車訂單的憑證信息而不只是單純的登錄態(tài)。這篇文章我就從業(yè)務(wù)拆解、算法設(shè)計(jì)、代碼實(shí)現(xiàn)、現(xiàn)場(chǎng)排查四個(gè)維度把這類令牌算法的分析思路完整走一遍順手附上可以直接抄走的實(shí)現(xiàn)方案和踩坑記錄。1. token-1002 到底是哪種 token先看懂編號(hào)背后的業(yè)務(wù)現(xiàn)場(chǎng)1.1 租車系統(tǒng)里的 token 至少有三種形態(tài)做算法分析的第一步永遠(yuǎn)是先確認(rèn)對(duì)象。我在租車行業(yè)的系統(tǒng)里見(jiàn)過(guò)至少三種 token每一種的生命周期和算法要求都不一樣。第一種是會(huì)話令牌。用戶登錄后發(fā)一個(gè)身份憑證后續(xù)請(qǐng)求帶著它訪問(wèn)接口。這種 token 關(guān)注的是簽發(fā)、驗(yàn)簽、過(guò)期續(xù)簽核心訴求是防止身份偽造和會(huì)話劫持常見(jiàn)做法是 JWT 或服務(wù)端 Session 結(jié)合 Redis。第二種是業(yè)務(wù)憑證令牌。比如一張優(yōu)惠券、一個(gè)抵扣券、一次免押金資格甚至是一筆預(yù)授權(quán)憑證。它和用戶身份沒(méi)有強(qiáng)綁定關(guān)系但和訂單、金額、有效期強(qiáng)相關(guān)。這種 token 的要求更苛刻必須防篡改、防重放、防超額使用而且經(jīng)常要支持離線校驗(yàn)。第三種是設(shè)備令牌。租車場(chǎng)景里有車機(jī)端、藍(lán)牙鑰匙、自助取還車終端設(shè)備之間需要短時(shí)效、低碰撞的授權(quán)憑證。這種 token 更看重隨機(jī)性和一次性。從項(xiàng)目的取值來(lái)看token-1002 不是用戶登錄態(tài)因?yàn)榈卿洃B(tài)通常不會(huì)有一個(gè)1002這種業(yè)務(wù)算法編號(hào)掛在后面。它更像是第二類——業(yè)務(wù)憑證令牌。也就是說(shuō)我們分析的是一套負(fù)責(zé)生成、校驗(yàn)、續(xù)期租車業(yè)務(wù)憑證的算法編號(hào) 1002 大概率是公司在計(jì)費(fèi)或者訂單系統(tǒng)里登記的算法版本號(hào)。1.2 從算法編號(hào)反推它屬于哪個(gè)業(yè)務(wù)域不要小看token-1002里這個(gè) 1002。很多公司內(nèi)部系統(tǒng)對(duì)算法編號(hào)是有規(guī)范的前兩位經(jīng)常代表業(yè)務(wù)域后兩位代表功能點(diǎn)。比如 10 可能是租車訂單域02 可能代表計(jì)價(jià)子模塊。如果公司有這份編號(hào)注冊(cè)表直接能從編號(hào)反查出它掛在哪個(gè)服務(wù)、哪個(gè)接口、哪個(gè)定時(shí)任務(wù)下面。沒(méi)有注冊(cè)表的話就靠調(diào)用鏈反查。把這個(gè) token 放到日志平臺(tái)里搜看它出現(xiàn)在哪些接口的入?yún)⒒虺鰠⒗铩Ｎ耶?dāng)時(shí)的做法是抓了一天的網(wǎng)關(guān)日志篩出所有帶著 token-1002 字樣的請(qǐng)求按接口維度做聚合。結(jié)果很快出來(lái)了它出現(xiàn)在下單預(yù)估價(jià)、訂單結(jié)算、取消單退款這三個(gè)接口里。這就印證了前面的猜測(cè)——它服務(wù)于整個(gè)訂單計(jì)費(fèi)鏈路而不是單點(diǎn)登錄。順帶說(shuō)一個(gè)經(jīng)驗(yàn)分析這種業(yè)務(wù)編號(hào)型算法最忌諱的就是一上來(lái)就盯著一處代碼看。你盯著一個(gè)函數(shù)看不出來(lái)它的設(shè)計(jì)意圖但你把它在整個(gè)調(diào)用鏈上的位置畫出來(lái)思路立刻就清晰了。它在哪里被簽發(fā)在哪里被消費(fèi)在哪里被作廢這三個(gè)問(wèn)題回答完算法骨架已經(jīng)出來(lái)一半。1.3 為什么租車計(jì)費(fèi)要令牌化確定了 token-1002 是計(jì)費(fèi)鏈路的業(yè)務(wù)憑證后還要回答一個(gè)為什么為什么不直接查數(shù)據(jù)庫(kù)非要用一個(gè) token 把訂單金額、權(quán)益信息包起來(lái)傳來(lái)傳去這個(gè)問(wèn)題直接決定了你對(duì)算法價(jià)值判斷的準(zhǔn)確度。我理解至少有三個(gè)原因。第一是解耦。估價(jià)、下單、結(jié)算、退款往往不是同一個(gè)服務(wù)。如果每個(gè)服務(wù)都去讀訂單主表算金額只要計(jì)費(fèi)規(guī)則一變就得同步改所有服務(wù)。把計(jì)價(jià)結(jié)果封裝進(jìn) token 后下游服務(wù)只認(rèn) token業(yè)務(wù)規(guī)則收斂在簽發(fā)方一處。第二是性能。租車下單高峰期每個(gè)請(qǐng)求都要實(shí)時(shí)查價(jià)格、查優(yōu)惠、查庫(kù)存數(shù)據(jù)庫(kù)壓力很大。token 相當(dāng)于把一次復(fù)雜計(jì)算的結(jié)果固化下來(lái)下游不必重復(fù)計(jì)算校驗(yàn)成本遠(yuǎn)低于計(jì)算成本。第三是防篡改。用戶在客戶端操作時(shí)訂單金額、用車時(shí)長(zhǎng)、優(yōu)惠信息如果直接傳給后端有心人可以偽造。令牌化之后關(guān)鍵字段有簽名保護(hù)任何篡改在校驗(yàn)環(huán)節(jié)都會(huì)被識(shí)別出來(lái)。弄明白了這三個(gè)為什么你再看 token-1002 的算法設(shè)計(jì)就能理解它為什么必須在消息體里既放業(yè)務(wù)字段又放簽名為什么校驗(yàn)順序有一堆講究為什么過(guò)期策略要比普通登錄態(tài)復(fù)雜得多。2. token-1002 算法設(shè)計(jì)拆解生成、校驗(yàn)、續(xù)簽一條線2.1 生成側(cè)載荷里放什么不放什么令牌算法設(shè)計(jì)的第一件事是明確載荷。token-1002 這種業(yè)務(wù)憑證載荷信息怎么取舍直接決定這個(gè)令牌的功能邊界和安全性。我當(dāng)時(shí)梳理出來(lái)的核心字段可以分成四組。第一組是業(yè)務(wù)定位字段包括訂單號(hào)、商戶編號(hào)、車輛編號(hào)、城市編號(hào)這些字段用來(lái)確定這個(gè) token 適用哪些業(yè)務(wù)范圍第二組是計(jì)費(fèi)依據(jù)字段包括計(jì)價(jià)版本號(hào)、預(yù)估價(jià)、優(yōu)惠金額、最終應(yīng)付金額、時(shí)長(zhǎng)單位第三組是時(shí)間控制字段包括簽發(fā)時(shí)間、生效時(shí)間、失效時(shí)間第四組是安全字段包括隨機(jī)串、業(yè)務(wù)流水號(hào)用來(lái)做防重放和冪等。有一個(gè)字段取舍的原則值得單獨(dú)講所有參與計(jì)費(fèi)的字段必須進(jìn) token 并且參與簽名所有不參與計(jì)費(fèi)的字段盡量別放進(jìn)去。比如車輛圖片、門店地址這類展示信息放進(jìn) token 只會(huì)讓令牌變肥白白增加每一筆訂單的傳輸成本。反過(guò)來(lái)說(shuō)計(jì)費(fèi)版本號(hào)這種元信息很多人容易漏掉它是排查線上疑難雜癥的關(guān)鍵。計(jì)價(jià)規(guī)則一變老的 token 還能不能用全靠版本號(hào)來(lái)判斷。服務(wù)端不能把敏感密鑰之類放進(jìn)去這個(gè)不用多講。還有一個(gè)容易被忽略的是盡量不要放用戶手機(jī)號(hào)、身份證號(hào)這類隱私信息。租車行業(yè)的合規(guī)要求越來(lái)越嚴(yán)業(yè)務(wù)令牌應(yīng)該只保留業(yè)務(wù)必要字段能引用用戶 ID 就絕不放明文隱私。2.2 簽名與密鑰HMAC 還是非對(duì)稱token-1002 的簽名方案我建議在 HMAC-SHA256 和 RSA/ECDSA 之間做選擇這對(duì)絕大多數(shù)租車業(yè)務(wù)場(chǎng)景已經(jīng)夠用。怎么選核心看校驗(yàn)方是誰(shuí)。如果簽發(fā)方和校驗(yàn)方都是自己的后端服務(wù)密鑰不離開內(nèi)網(wǎng)那 HMAC-SHA256 是最合適的選擇。它計(jì)算快、實(shí)現(xiàn)簡(jiǎn)單、密鑰管理成本低適合內(nèi)部服務(wù)間的高頻調(diào)用。我當(dāng)時(shí)給 token-1002 選的也是 HMAC-SHA256。如果這個(gè) token 可能要下發(fā)到第三方渠道比如合作的車行、保險(xiǎn)公司、銀行接口那必須用非對(duì)稱簽名。原因很簡(jiǎn)單HMAC 是對(duì)稱密鑰你把密鑰給了別人校驗(yàn)別人就能自己照樣簽發(fā)一個(gè)簽名就失去意義了。非對(duì)稱簽名下你手里的私鑰只用來(lái)簽發(fā)對(duì)方手里只有公鑰只能驗(yàn)簽偽造成本才會(huì)被抬起來(lái)。還有一個(gè)容易被忽略的點(diǎn)密鑰至少要有旋轉(zhuǎn)機(jī)制也就是定期更換。很多團(tuán)隊(duì)密鑰一配就是兩三年不換一旦泄露攻擊者可以用舊密鑰偽造任意訂單。我當(dāng)時(shí)做了一個(gè)雙密鑰并存方案新密鑰負(fù)責(zé)簽發(fā)舊密鑰保留一個(gè)灰度期用于校驗(yàn)存量令牌過(guò)了灰度期再?gòu)男ｒ?yàn)列表里摘掉。這樣既保證老用戶無(wú)縫過(guò)渡又不會(huì)出現(xiàn)密鑰切換瞬間的錯(cuò)誤爆發(fā)。2.3 校驗(yàn)側(cè)四步校驗(yàn)法校驗(yàn)側(cè)是 token-1002 這類算法最容易踩坑的地方。很多線上問(wèn)題不是令牌生成錯(cuò)了而是校驗(yàn)順序有問(wèn)題。我實(shí)踐的校驗(yàn)流程是固定四步順序不能亂。第一步是格式校驗(yàn)。先看 token 是不是符合預(yù)期的編碼格式Base64 能不能正常解碼JSON 能不能解析。這一不通過(guò)直接返回參數(shù)錯(cuò)誤不進(jìn)后續(xù)邏輯。第二步是簽名校驗(yàn)。用約定好的密鑰對(duì)消息體重新計(jì)算簽名和傳來(lái)的簽名做比對(duì)。這一步是防止數(shù)據(jù)被篡改的關(guān)鍵也是性能開銷最大的一步所以要放在格式校驗(yàn)之后。第三步是時(shí)間校驗(yàn)。判斷當(dāng)前時(shí)間是否在 token 的生效時(shí)間和失效時(shí)間之間。這里要注意留出時(shí)鐘偏移窗口一般前后各留 30 到 60 秒避免服務(wù)端集群時(shí)鐘抖動(dòng)導(dǎo)致合法令牌被誤殺。第四步是業(yè)務(wù)狀態(tài)校驗(yàn)。查訂單狀態(tài)、查 token 是否已被消費(fèi)確認(rèn)這個(gè)令牌沒(méi)有被作廢、沒(méi)有被撤銷。這一步雖然最常見(jiàn)但很多團(tuán)隊(duì)會(huì)漏掉導(dǎo)致令牌本身沒(méi)錯(cuò)但因?yàn)橛唵螤顟B(tài)已經(jīng)變化卻還繼續(xù)使用的問(wèn)題。這四步的順序之所以不能亂核心原因是成本遞增。格式校驗(yàn)幾乎零成本能快速攔截大量非法輸入簽名校驗(yàn)成本較高用格式校驗(yàn)先過(guò)濾一遍可以避免無(wú)效計(jì)算時(shí)間校驗(yàn)比業(yè)務(wù)校驗(yàn)快得多時(shí)間都不對(duì)就不用查數(shù)據(jù)庫(kù)了。把最貴的業(yè)務(wù)查詢放到最后是性能和安全之間的一個(gè)合理折中。2.4 續(xù)簽與失效雙 token 模型業(yè)務(wù)憑證令牌和登錄令牌在失效策略上有一個(gè)關(guān)鍵差異登錄令牌的續(xù)簽關(guān)心的是會(huì)話是否活躍業(yè)務(wù)令牌的續(xù)簽關(guān)心的是業(yè)務(wù)是否還處于可執(zhí)行狀態(tài)。我推薦在 token-1002 這類場(chǎng)景里直接套用雙 token 模型就是短期令牌加長(zhǎng)期刷新令牌的組合。短期令牌時(shí)效短比如 30 分鐘用于日常請(qǐng)求刷新令牌時(shí)效長(zhǎng)比如 7 天用于在短期令牌快過(guò)期時(shí)換取新的短期令牌。租車場(chǎng)景里用戶從下單到還車可能隔好幾天單靠一個(gè)短期令牌根本撐不住整個(gè)流程用戶每次打開 App 都要重新登錄顯然不現(xiàn)實(shí)。但也有一個(gè)差異登錄場(chǎng)景里刷新令牌是隱式的用戶無(wú)感知業(yè)務(wù)場(chǎng)景里刷新必須有業(yè)務(wù)條件。比如訂單還在進(jìn)行中、車輛未歸還、沒(méi)有被風(fēng)控鎖定才能允許續(xù)簽。一旦訂單已經(jīng)完成或取消刷新令牌必須立即失效。這個(gè)條件很容易被做成一個(gè)統(tǒng)一的token 未過(guò)期則可續(xù)結(jié)果就導(dǎo)致已完結(jié)訂單的令牌還能繼續(xù)跑白送用戶權(quán)益。失效主要是主動(dòng)失效和被動(dòng)失效兩層。主動(dòng)失效是業(yè)務(wù)狀態(tài)變化時(shí)的強(qiáng)制作廢比如退款成功、訂單取消、車輛異常歸還要主動(dòng)把這些 token 拉黑被動(dòng)失效就是讓時(shí)間說(shuō)話到期自動(dòng)失效。還有一個(gè)兜底方案是黑白名單機(jī)制針對(duì)極少數(shù)高價(jià)值 token 做 Redis 級(jí)別的實(shí)時(shí)管控雖然增加了一點(diǎn)存儲(chǔ)成本但在資損風(fēng)險(xiǎn)面前完全值得。3. 實(shí)操參考一個(gè)可落地的 token-1002 實(shí)現(xiàn)示例3.1 整體流程與存儲(chǔ)設(shè)計(jì)接下來(lái)說(shuō)一個(gè)可以直接照著搭的實(shí)現(xiàn)。整個(gè)流程我會(huì)拆成三個(gè)環(huán)節(jié)簽發(fā)、校驗(yàn)、續(xù)期。簽發(fā)側(cè)用戶在 App 端選擇租車時(shí)長(zhǎng)和車型后計(jì)價(jià)服務(wù)計(jì)算預(yù)估費(fèi)用把訂單號(hào)、車輛編號(hào)、城市、金額、時(shí)長(zhǎng)單位、計(jì)費(fèi)版本號(hào)、簽發(fā)時(shí)間、失效時(shí)間裝進(jìn)載荷加上隨機(jī)串后做 HMAC-SHA256 簽名最后編碼成字符串返回給客戶端。注意簽發(fā)時(shí)機(jī)不是用戶點(diǎn)下單那一刻而是在用戶看到預(yù)估價(jià)頁(yè)面時(shí)就要先簽一個(gè)估價(jià) token真正下單時(shí)再用一個(gè)結(jié)算 token。校驗(yàn)側(cè)網(wǎng)關(guān)層收到請(qǐng)求后先做格式解析和簽名驗(yàn)證驗(yàn)證通過(guò)后把業(yè)務(wù)數(shù)據(jù)放進(jìn)上下文里供下游服務(wù)使用同時(shí)再查一次訂單狀態(tài)確保 token 沒(méi)有被撤銷。存儲(chǔ)側(cè)要區(qū)分開兩類數(shù)據(jù)token 本身盡量無(wú)狀態(tài)不落庫(kù)服務(wù)重啟也不受影響但已消費(fèi) token和已撤銷 token必須落存儲(chǔ)。我用的是一張消費(fèi)記錄表和一份 Redis 黑名單。Redis 里存的是 token 摘要和撤銷時(shí)間TTL 設(shè)置成 token 剩余有效期的最大值這樣黑名單不會(huì)無(wú)限膨脹。3.2 生成與校驗(yàn)代碼示例下面這段代碼是當(dāng)時(shí)方案的一個(gè)簡(jiǎn)化版用 Python 寫的生產(chǎn)上換成 Java、Go 都沒(méi)問(wèn)題。關(guān)鍵是看結(jié)構(gòu)不是看語(yǔ)法。import base64 import hashlib import hmac import json import time import uuid SECRET_KEY byour-256-bit-secret-key ALGORITHM HS256 TOKEN_TTL 1800 # 30分鐘 CLOCK_SKEW 60 # 允許60秒時(shí)鐘偏移 def _b64url_encode(data: bytes) - str: return base64.urlsafe_b64encode(data).rstrip(b).decode(utf-8) def _b64url_decode(data: str) - bytes: padding * (4 - len(data) % 4) return base64.urlsafe_b64decode(data padding) def _sign(payload: dict) - str: msg json.dumps(payload, separators(,, :), sort_keysTrue).encode(utf-8) digest hmac.new(SECRET_KEY, msg, hashlib.sha256).digest() return _b64url_encode(digest) def issue_token(biz_payload: dict) - str: now int(time.time()) payload { # 業(yè)務(wù)字段 order_id: biz_payload[order_id], car_id: biz_payload[car_id], city_id: biz_payload[city_id], amount: biz_payload[amount], price_version: biz_payload.get(price_version, v1), # 時(shí)間字段 iat: now, exp: now TOKEN_TTL, # 安全字段 jti: uuid.uuid4().hex, nonce: uuid.uuid4().hex, } header {alg: ALGORITHM, typ: BIZ-TOKEN} header_seg _b64url_encode(json.dumps(header).encode(utf-8)) payload_seg _b64url_encode(json.dumps(payload).encode(utf-8)) signing_input f{header_seg}.{payload_seg} sig _sign({header: header, payload: payload}) return f{signing_input}.{sig} def verify_token(token: str) - dict: try: header_seg, payload_seg, sig_seg token.split(.) header json.loads(_b64url_decode(header_seg)) payload json.loads(_b64url_decode(payload_seg)) except Exception: raise ValueError(token 格式不合法) # 第一步簽名校驗(yàn) expected_sig _sign({header: header, payload: payload}) if not hmac.compare_digest(expected_sig, sig_seg): raise ValueError(token 簽名校驗(yàn)失敗) # 第二步時(shí)間校驗(yàn) now int(time.time()) if now payload[iat] - CLOCK_SKEW or now payload[exp] CLOCK_SKEW: raise ValueError(token 已過(guò)期或未生效) return payload這里有兩個(gè)細(xì)節(jié)值得說(shuō)明。第一個(gè)是 JSON 序列化時(shí)用了 sort_keysTrue這是為了保證簽名原文在不同語(yǔ)言、不同環(huán)境下的字節(jié)一致性。第二個(gè)是用 hmac.compare_digest 做簽名比對(duì)而不是直接用字符串等號(hào)這個(gè)方法可以規(guī)避簡(jiǎn)單的時(shí)序側(cè)信道攻擊雖然在這個(gè)場(chǎng)景里風(fēng)險(xiǎn)不高但寫順手了反而安心。3.3 關(guān)鍵參數(shù)怎么定過(guò)期時(shí)間、偏移窗口、密鑰輪換參數(shù)選型是很多人在實(shí)現(xiàn)類似算法時(shí)最沒(méi)把握的地方。我給出一個(gè)經(jīng)過(guò)線上驗(yàn)證的參數(shù)基準(zhǔn)供參考。過(guò)期時(shí)間取決于業(yè)務(wù)動(dòng)作的跨度。租車估價(jià) token 我設(shè)的是 30 分鐘因?yàn)橛脩魪倪x車到下單一般不會(huì)超過(guò)這個(gè)時(shí)間。結(jié)算 token 我設(shè)的是 2 小時(shí)考慮到用戶可能在下單后猶豫一段時(shí)間才確認(rèn)支付。如果設(shè)計(jì)的是整個(gè)租車周期的授權(quán)令牌那應(yīng)該跟著訂單周期走比如日租 24 小時(shí)周租 7 天。一句話過(guò)期時(shí)間要覆蓋業(yè)務(wù)動(dòng)作的最長(zhǎng)合理耗時(shí)但不要超出太多。時(shí)鐘偏移窗口我固定給了 60 秒。這個(gè)值不是拍腦袋定的而是測(cè)出來(lái)的。當(dāng)時(shí)線上有幾十個(gè)節(jié)點(diǎn)NTP 同步正常情況下節(jié)點(diǎn)間時(shí)鐘差不超過(guò) 5 秒但偶爾會(huì)出現(xiàn)同步失敗的情況極端時(shí)能偏到 40 多秒。留 60 秒是一個(gè)安全余量既不會(huì)誤殺正常請(qǐng)求又不至于讓已過(guò)期十幾分鐘的 token 還能通過(guò)校驗(yàn)。密鑰輪換周期建議按季度執(zhí)行每次輪換保留 72 小時(shí)的灰度期。也就是說(shuō)新密鑰簽發(fā)的同時(shí)舊密鑰繼續(xù)保留在校驗(yàn)名單里三天三天后摘除。這個(gè)周期兼顧了安全和運(yùn)維成本一年四次每次都有充足時(shí)間觀察灰度期的異常指標(biāo)。3.4 部署注意事項(xiàng)部署層面有四個(gè)點(diǎn)每一個(gè)都出過(guò)事值得單獨(dú)說(shuō)一下。一是網(wǎng)關(guān)層校驗(yàn)和業(yè)務(wù)層校驗(yàn)要分工。網(wǎng)關(guān)層做格式校驗(yàn)和簽名校驗(yàn)業(yè)務(wù)層做業(yè)務(wù)狀態(tài)校驗(yàn)。千萬(wàn)不要在網(wǎng)關(guān)層查數(shù)據(jù)庫(kù)否則一個(gè)大促流量過(guò)來(lái)網(wǎng)關(guān)先被打掛了這是典型的架構(gòu)級(jí)失誤。二是日志要脫敏。token 明文不能完整打印打印出來(lái)等同于把用戶的租車憑證泄露出去。我當(dāng)時(shí)的做法是日志里只保留 token 的前八位和最后四位中間用星號(hào)打碼同時(shí)把 jti 單獨(dú)打出來(lái)用作問(wèn)題追蹤。排查問(wèn)題時(shí)用 jti 做全局檢索既快又安全。三是簽名誤差要可觀測(cè)。強(qiáng)烈建議給簽名校驗(yàn)失敗單獨(dú)打一個(gè)錯(cuò)誤碼和業(yè)務(wù)錯(cuò)誤碼區(qū)分開。否則你分不清那些報(bào)錯(cuò)是參數(shù)亂傳還是有人惡意篡改安全運(yùn)營(yíng)連基礎(chǔ)數(shù)據(jù)都沒(méi)有。四是壓測(cè)時(shí)必須帶上真實(shí) token 樣本。很多團(tuán)隊(duì)壓測(cè)時(shí)生成一批測(cè)試 token而且都是剛簽發(fā)的、沒(méi)經(jīng)過(guò)任何磨損的 token。真實(shí)線上 token 五花八門有快要到期的、有密鑰切換前簽發(fā)的、有帶著各種奇怪業(yè)務(wù)字段的。用真實(shí)分布的 token 樣本壓測(cè)才能暴露簽名算法的極端性能問(wèn)題。4. 現(xiàn)場(chǎng)踩坑與排查技巧實(shí)錄4.1 高頻報(bào)錯(cuò)速查表分析 token 類算法跑不了要面對(duì)線上報(bào)錯(cuò)。我按自己的經(jīng)驗(yàn)整理了一張速查表遇到問(wèn)題可以對(duì)著查。錯(cuò)誤現(xiàn)象可能原因排查動(dòng)作token 校驗(yàn)失敗載荷被篡改 / 簽名密鑰不一致拿原始 token 離線重算簽名對(duì)比簽名段token 已過(guò)期客戶端與服務(wù)端時(shí)間差過(guò)大查客戶端上報(bào)時(shí)間與服務(wù)端時(shí)間差確認(rèn)是否走了錯(cuò)誤的本地時(shí)間token 不存在緩存被清理 / 簽發(fā)后未正確落存儲(chǔ)按 jti 查簽發(fā)日志確認(rèn)簽發(fā)時(shí)是否寫存儲(chǔ)失敗請(qǐng)求返回 403來(lái)源 IP 不在白名單 / 權(quán)限策略攔截查網(wǎng)關(guān)訪問(wèn)控制策略確認(rèn)來(lái)源是否被新策略誤傷續(xù)簽失敗提示字符串為空上游沒(méi)傳刷新令牌或刷新令牌被過(guò)濾掉抓接口入?yún)⒖此⑿铝钆谱侄问欠裨诰W(wǎng)關(guān)層被脫敏誤刪重復(fù)扣費(fèi)并發(fā)請(qǐng)求下同一個(gè) token 被消費(fèi)兩次查消費(fèi)表是否有唯一索引確認(rèn)是否缺少冪等控制密鑰輪換后大量報(bào)錯(cuò)灰度期內(nèi)沒(méi)有兼容舊密鑰確認(rèn)校驗(yàn)邏輯里是否同時(shí)掛了新舊兩個(gè)密鑰這里單獨(dú)說(shuō)說(shuō) 403 的問(wèn)題。很多團(tuán)隊(duì)的 token 校驗(yàn)服務(wù)會(huì)有一層來(lái)源控制比如只允許內(nèi)網(wǎng)調(diào)用、只允許特定環(huán)境調(diào)用。有時(shí)候新擴(kuò)容一批節(jié)點(diǎn)忘了把新節(jié)點(diǎn)的出口 IP 加進(jìn)白名單就會(huì)導(dǎo)致用戶請(qǐng)求全部 403。排查這類問(wèn)題先看報(bào)錯(cuò)是在哪個(gè)環(huán)節(jié)返回的是網(wǎng)關(guān)層返回的還是業(yè)務(wù)服務(wù)返回的再順著環(huán)節(jié)查配置比直接懷疑簽名算法靠譜得多。4.2 三個(gè)印象深刻的線上事故第一個(gè)事故是時(shí)鐘不同步引發(fā)的大面積 token 失效。當(dāng)時(shí)擴(kuò)容了一批新節(jié)點(diǎn)運(yùn)維在初始化鏡像時(shí)漏掉了 NTP 配置結(jié)果這批節(jié)點(diǎn)的系統(tǒng)時(shí)間比標(biāo)準(zhǔn)時(shí)間慢了將近兩分鐘。所有經(jīng)過(guò)這批節(jié)點(diǎn)的請(qǐng)求都判定 token 未生效用戶端表現(xiàn)就是明明剛登錄卻提示憑證無(wú)效重新登錄也沒(méi)用。排查到這個(gè)問(wèn)題的時(shí)候還挺意外因?yàn)樵诰€時(shí)長(zhǎng)、業(yè)務(wù)日志都沒(méi)異常純粹是底層基礎(chǔ)設(shè)施問(wèn)題。這次之后我做了一個(gè)硬性要求任何新節(jié)點(diǎn)上線第一件事就是檢查時(shí)鐘同步狀態(tài)并且在監(jiān)控里加了節(jié)點(diǎn)時(shí)間偏移的看板。第二個(gè)事故是并發(fā)請(qǐng)求導(dǎo)致重復(fù)結(jié)算。用戶在下單支付時(shí)同時(shí)點(diǎn)了兩次支付按鈕兩個(gè)請(qǐng)求幾乎同時(shí)到達(dá)服務(wù)端。校驗(yàn)時(shí)訂單狀態(tài)都是待支付兩個(gè)請(qǐng)求都通過(guò)了業(yè)務(wù)校驗(yàn)結(jié)果一筆訂單被扣了兩次款。原因就是消費(fèi)標(biāo)記和支付動(dòng)作之間沒(méi)有做原子控制。修復(fù)方案是把消費(fèi)標(biāo)記改成了數(shù)據(jù)庫(kù)唯一索引加分布式鎖并且在下單接口做了冪等鍵校驗(yàn)。這個(gè)事故讓我養(yǎng)成了一個(gè)習(xí)慣所有涉及扣款、發(fā)放、權(quán)益變更的 token 消費(fèi)邏輯必須有一個(gè)數(shù)據(jù)庫(kù)層面的唯一約束作為兜底不能只靠應(yīng)用層判斷。第三個(gè)事故是密鑰輪換的灰度遺漏。那次輪換密鑰新密鑰上線后大概一分鐘線上突然出現(xiàn)大量簽名校驗(yàn)失敗。查了半天才發(fā)現(xiàn)校驗(yàn)服務(wù)發(fā)布時(shí)只把新密鑰加進(jìn)去了灰度兼容配置沒(méi)生效舊密鑰被覆蓋了。從那以后我每次做這類變更都會(huì)先在測(cè)試環(huán)境把新老密鑰同時(shí)存在的場(chǎng)景完整跑一遍并且專門留一個(gè)用舊密鑰簽發(fā)的樣本 token在發(fā)布后第一時(shí)間用來(lái)驗(yàn)證兼容性。4.3 排查此類算法的通用方法論經(jīng)驗(yàn)攢多了我總結(jié)了一套分析XX 算法類需求的通用流程不只是 token 場(chǎng)景適用。第一步是畫生命周期。把簽發(fā)的入口、消費(fèi)的出口、作廢的觸發(fā)點(diǎn)都找出來(lái)畫一張狀態(tài)流轉(zhuǎn)圖。重點(diǎn)看有沒(méi)有出口在入口之前的邏輯比如訂單還沒(méi)生成就開始消費(fèi) token這種多半是設(shè)計(jì)缺陷。第二步是拆數(shù)據(jù)結(jié)構(gòu)。把 token 載荷里的字段逐個(gè)列出來(lái)每一個(gè)字段都問(wèn)一遍它用來(lái)做什么如果不帶會(huì)導(dǎo)致什么后果很多時(shí)候排查一個(gè)問(wèn)題最后定位到的是字段漏放了而不是算法寫錯(cuò)了。第三步是驗(yàn)證時(shí)間線。把一次請(qǐng)求從發(fā)出到返回的全過(guò)程按時(shí)間軸把每一條日志排出來(lái)。token 類問(wèn)題最典型的表現(xiàn)是時(shí)序錯(cuò)亂比如簽發(fā)時(shí)間比消費(fèi)時(shí)間還晚或者失效時(shí)間已經(jīng)過(guò)了還能繼續(xù)用。第四步是回歸業(yè)務(wù)規(guī)則。token 報(bào)錯(cuò)本身往往不是根因根因通常在業(yè)務(wù)邏輯里。參數(shù)校驗(yàn)失敗可能是前端傳錯(cuò)了字段過(guò)期可能是訂單流程拖太久重復(fù)消費(fèi)可能是狀態(tài)機(jī)缺少流轉(zhuǎn)約束。永遠(yuǎn)記住一點(diǎn)token 只是業(yè)務(wù)規(guī)則的載體業(yè)務(wù)規(guī)則變了token 的行為一定會(huì)跟著變。5. 分析 token-1002 給我的一些經(jīng)驗(yàn)整個(gè)分析下來(lái)我最想分享的一個(gè)體會(huì)是分析這類業(yè)務(wù)型算法代碼永遠(yuǎn)只是最后一公里。前面業(yè)務(wù)場(chǎng)景的拆解、調(diào)用鏈的梳理、狀態(tài)流轉(zhuǎn)的還原才是真正決定分析質(zhì)量的部分。token-1002 這個(gè)名字看上去只是一個(gè)編號(hào)但當(dāng)你把它的業(yè)務(wù)上下文、設(shè)計(jì)目標(biāo)、失效策略全部還原出來(lái)后它在整個(gè)系統(tǒng)里的定位就非常清晰了它是租車訂單從估價(jià)到結(jié)算再到退款這條鏈路上一個(gè)既有簽名保護(hù)又帶業(yè)務(wù)狀態(tài)的憑證載體。再分享一個(gè)小技巧給正在做類似工作的人分析完一個(gè)算法后不要急著寫長(zhǎng)篇報(bào)告先畫一張 token 生命周期卡。上面寫清楚它在哪里簽發(fā)、在哪里校驗(yàn)、在哪里作廢、誰(shuí)有權(quán)限觸碰它、每個(gè)環(huán)節(jié)如果出錯(cuò)了返回什么錯(cuò)誤碼。這張卡比任何代碼注釋都有用以后不管是接手維護(hù)還是排查線上問(wèn)題拿出來(lái)一看就能快速定位到具體代碼位置。我后來(lái)每次接手新的業(yè)務(wù)系統(tǒng)第一件事就是找老同事要這張卡沒(méi)有的話就自己畫一張。這比悶頭讀一整天代碼的效率高得多。