這個(gè)枚舉只有一個(gè)值我差點(diǎn)刪了——然后所有代發(fā)訂單都取不了號(hào)技術(shù)重構(gòu)系列 · 第2篇抖音代發(fā)共享店鋪Token設(shè)計(jì) 地址策略解耦本系列基于老系統(tǒng)真實(shí)改造復(fù)盤文中客戶名、地址、編碼值均已化名/脫敏處理坑的類型、解題思路、踩坑過程為一線實(shí)錄。系列背景與為什么重構(gòu)見首篇。上篇聊了奇門對(duì)接順豐的三個(gè)暗坑這篇進(jìn)入抖音代發(fā)。抖音代發(fā)是一個(gè)特殊的業(yè)務(wù)模式店鋪接到訂單但由另一個(gè)倉庫實(shí)際發(fā)貨。倉庫用自己的抖音賬號(hào)調(diào)API取號(hào)但訂單信息來自店鋪。這種模式帶來三個(gè)技術(shù)挑戰(zhàn)——Token從哪來、地址用哪個(gè)、路由怎么走。三個(gè)問題看似簡(jiǎn)單實(shí)則暗藏前任硬編碼的坑。文檔里一筆帶過代碼里卻藏著業(yè)務(wù)規(guī)則的全部秘密。這篇還多送一個(gè)故事一個(gè)沉睡了半年的Token是怎么在最不該炸的時(shí)候炸出一串空指針的。一、共享店鋪Token你差點(diǎn)手賤刪掉的枚舉1.1 問題背景代發(fā)模式下倉庫為多個(gè)店鋪代發(fā)。每個(gè)店鋪有自己的抖音授權(quán)Token但某些共享店鋪共享倉庫的Token。系統(tǒng)需要判斷當(dāng)前訂單的店鋪是不是共享店鋪如果是用倉庫的Token如果不是用店鋪?zhàn)约旱腡oken。原代碼的實(shí)現(xiàn)方式是在一個(gè)Java枚舉里硬編碼共享店鋪列表訂單進(jìn)來時(shí)先查枚舉命中了就走共享邏輯。1.2 你差點(diǎn)犯的錯(cuò)如果你不知道這個(gè)業(yè)務(wù)背景看到這個(gè)枚舉只有一個(gè)值可能會(huì)覺得“這個(gè)枚舉是不是可以刪掉只有一個(gè)值直接查數(shù)據(jù)庫不行嗎”但不能刪。這個(gè)枚舉是業(yè)務(wù)配置不是代碼冗余。刪除它會(huì)導(dǎo)致共享店鋪的Token獲取邏輯失效所有共享店鋪的訂單都會(huì)報(bào)未獲取到有效的AccessToken。這種看起來沒用但不能刪的代碼在遺留系統(tǒng)里特別多。刪之前先搞清楚它為什么在那里。1.3 新架構(gòu)的優(yōu)化在新架構(gòu)中Token獲取邏輯被提取為獨(dú)立方法增加了空值校驗(yàn)和友好的錯(cuò)誤信息含店鋪名稱。不再是3個(gè)方法里重復(fù)3遍而是一處定義、全局復(fù)用。為什么要特意強(qiáng)調(diào)空值校驗(yàn)因?yàn)槲覀冋娴谋豢誘oken炸過一次。往下看。二、一個(gè)沉睡半年的Token炸出5處防呆2.1 事故鏈代發(fā)業(yè)務(wù)有明顯的淡旺季可能連續(xù)幾個(gè)月一張代發(fā)訂單都沒有。于是發(fā)生了這樣一條事故鏈長期沒有代發(fā)訂單 → 沒人觸發(fā)Token刷新授權(quán)靜默過期 → 某天突然來了一張代發(fā)單 → 系統(tǒng)取Token拿到 null → 拼接請(qǐng)求參數(shù)時(shí)對(duì) null 做URL編碼 → 空指針異常NPE用戶看到的報(bào)錯(cuò)是什么一串和業(yè)務(wù)毫無關(guān)系的堆棧信息。沒有Token過期沒有請(qǐng)重新授權(quán)只有一個(gè)冷冰冰的空指針。2.2 排查從NPE堆棧往回推編碼的入?yún)⑹荰oken → Token從組織配置里取的 → 配置里的Token字段是空的 → 為什么是空的→ 授權(quán)早就過期了只是一直沒有訂單來發(fā)現(xiàn)它。低頻鏈路的憑證過期不會(huì)報(bào)警只會(huì)在最需要它的時(shí)候爆炸。2.3 修復(fù)5處防呆修復(fù)分兩步數(shù)據(jù)修復(fù)重新走授權(quán)流程把新Token更新到組織配置。代碼防呆在5個(gè)位置增加Token空值校驗(yàn)——統(tǒng)一取號(hào)入口、兩個(gè)請(qǐng)求構(gòu)建器、兩個(gè)HTTP處理器。Token為空時(shí)不再往下走直接拋出人話版異常“未獲取到有效的抖音代發(fā)AccessToken請(qǐng)檢查平臺(tái)配置店鋪XXX”為什么要5處而不是1處因?yàn)槿√?hào)有多個(gè)入口任何一個(gè)入口漏了校驗(yàn)NPE還是會(huì)從那個(gè)口炸出來。防呆的原則是在每一個(gè)消費(fèi)Token的地方守門而不是假設(shè)上游一定給了合法值。2.4 這個(gè)坑的通用教訓(xùn)防呆校驗(yàn)的價(jià)值不是防止出錯(cuò)——Token過期這種事防不住。它的價(jià)值是讓錯(cuò)誤一眼能看懂從一串空指針堆棧排查兩小時(shí)變成一行帶店鋪名的提示一分鐘定位。你的系統(tǒng)里有沒有這種半年才走一次的低頻鏈路它的憑證、配置、外部依賴過期了有人知道嗎三、地址策略硬編碼背后的三條規(guī)則3.1 表象發(fā)件人地址的選擇邏輯代碼里寫了一堆if/else中通用一個(gè)地址郵政和順豐用另一個(gè)地址其他情況用商家配置的地址看起來就是不同快遞用不同地址沒什么復(fù)雜的。3.2 背后的業(yè)務(wù)規(guī)則但仔細(xì)看規(guī)則比if/else復(fù)雜得多規(guī)則條件地址規(guī)則1中通地址A規(guī)則2郵政或順豐且不是書局A的訂單地址B規(guī)則3其他商家自己配置的地址為什么中通用地址A因?yàn)橹型ㄔ诘刂稟有網(wǎng)點(diǎn)取件方便。為什么郵政/順豐非書局A要用地址B因?yàn)闀諥在地址A有自己的收件點(diǎn)但其他商家沒有需要用地址B的公共收件點(diǎn)。為什么只有非重復(fù)訂單才執(zhí)行規(guī)則2因?yàn)榇l(fā)自身的業(yè)務(wù)邏輯差異——重復(fù)訂單不重新取號(hào)不需要重新判斷地址。順帶提醒一句不同平臺(tái)的網(wǎng)點(diǎn)綁定規(guī)則可能完全不同。同一家快遞在代發(fā)鏈路綁定的是這套地址換到另一個(gè)電商平臺(tái)可能又是另一套。對(duì)照多平臺(tái)代碼或文檔時(shí)看到地址規(guī)則不一樣先別急著當(dāng)成矛盾——大概率是平臺(tái)側(cè)網(wǎng)點(diǎn)綁定本來就不同。3.3 這個(gè)坑和渠道編碼的坑如出一轍回想上篇的渠道編碼坑文檔說根據(jù)訂單類型設(shè)置代碼里卻硬編碼了三種值分別對(duì)應(yīng)三種渠道。不知道含義就改改完就出事。地址策略也一樣文檔說不同快遞使用不同地址代碼里硬編碼了兩個(gè)地址和三條規(guī)則。不知道規(guī)則就改改完中通測(cè)試通過因?yàn)橹型ㄒ?guī)則最簡(jiǎn)單但郵政/順豐切換時(shí)就報(bào)錯(cuò)。這些坑的共同特點(diǎn)文檔一筆帶過前任把業(yè)務(wù)規(guī)則硬編碼在方法里新人看到代碼覺得不就是個(gè)地址選擇嗎殊不知背后藏著三條業(yè)務(wù)規(guī)則。3.4 未來優(yōu)化方向當(dāng)前地址選擇邏輯保留在代碼中使用常量引用消除魔法字符串。后續(xù)可以下沉到數(shù)據(jù)庫配置實(shí)現(xiàn)新增快遞只需改配置不改代碼。但這個(gè)改動(dòng)需要業(yè)務(wù)確認(rèn)暫不動(dòng)。四、DYXD路由數(shù)據(jù)庫有值代碼沒注冊(cè)4.1 問題抖音平臺(tái)有5種變體——普通、供銷、分銷端、代發(fā)等。每種變體調(diào)API時(shí)用的請(qǐng)求格式不同字段名不同、參數(shù)結(jié)構(gòu)不同。系統(tǒng)需要根據(jù)變體類型選擇正確的翻譯官來組裝請(qǐng)求。測(cè)試時(shí)發(fā)現(xiàn)某個(gè)變體的訂單報(bào)錯(cuò)參數(shù)缺失。打個(gè)比方你要寄國際快遞系統(tǒng)應(yīng)該找英語翻譯官對(duì)應(yīng)國際格式但找不到fallback 找了個(gè)中文翻譯官對(duì)應(yīng)國內(nèi)格式。翻譯官用中文格式寫了一張國際快遞單對(duì)方看不懂直接退回來了。4.2 根因數(shù)據(jù)庫中記錄了5種變體但代碼里只注冊(cè)了1種的翻譯官。其他4種找不到對(duì)應(yīng)的翻譯官就用了默認(rèn)的——但默認(rèn)的格式和實(shí)際需要的格式不匹配。我犯的錯(cuò)沒有先查原代碼的路由邏輯憑聽起來像代發(fā)的直覺直接注冊(cè)為代發(fā)處理器。用戶糾正“只有代發(fā)走代發(fā)其他所有變體走普通。”查了原代碼確認(rèn)原代碼中那個(gè)變體編碼出現(xiàn)0次——根本沒有特殊處理走的就是其他所有變體的默認(rèn)分支。4.3 修復(fù)后的路由表變體編碼走哪個(gè)翻譯官普通/默認(rèn)普通格式供銷普通格式分銷端普通格式代發(fā)代發(fā)格式只有代發(fā)用代發(fā)格式其他所有變體用普通格式。這個(gè)坑的完整排查過程和憑直覺的反思下篇講抖音普通訂單時(shí)還會(huì)從另一個(gè)角度收個(gè)尾。五、抖音平臺(tái)的快遞限制回歸測(cè)試中發(fā)現(xiàn)一個(gè)重要限制抖音平臺(tái)不支持京東快遞。當(dāng)用戶切換到京東快遞時(shí)系統(tǒng)直接攔截“暫不支持的渠道”。這是原代碼的硬編碼邏輯——京東快遞的電子面單系統(tǒng)與抖音平臺(tái)沒有對(duì)接。如果你不知道這個(gè)限制可能會(huì)在測(cè)試時(shí)跳過京東快遞上線后用戶切換時(shí)才發(fā)現(xiàn)報(bào)錯(cuò)排查半天才發(fā)現(xiàn)是平臺(tái)限制不是代碼bug。各平臺(tái)快遞支持對(duì)比平臺(tái)不支持的快遞抖音京東拼多多京東無模板奇門京東無映射微信視頻號(hào)京東未配置六、回歸測(cè)試抖音代發(fā)共完成7次測(cè)試3次成功快遞/場(chǎng)景結(jié)果說明順豐特快/電商標(biāo)快成功全鏈路通過產(chǎn)品編碼正確下發(fā)郵政成功全鏈路通過中通失敗面單賬戶余額不足——業(yè)務(wù)問題非代碼問題順豐服務(wù)類型切換被拒平臺(tái)冪等限制已取號(hào)訂單不允許變更服務(wù)類型失敗的每一次都定位到了明確原因且都不是新代碼引入的問題。測(cè)試的目的不是證明都能通過而是把哪些不能通過、為什么提前摸清楚。七、教訓(xùn)這篇文章的核心信息代碼里的每一個(gè)硬編碼背后都可能藏著一條業(yè)務(wù)規(guī)則每一條低頻鏈路背后都可能藏著一個(gè)過期的憑證。改代碼之前先搞清楚規(guī)則上線之前先想想最久沒人走的那條路。四個(gè)坑的根源都指向同一件事——知識(shí)沒有沉淀。共享店鋪枚舉沒注釋、地址規(guī)則沒文檔、路由規(guī)則只在前任腦子里、Token過期沒人知道。硬編碼不是罪但要留下注釋。前任把地址和快遞限制硬編碼在方法里這在當(dāng)時(shí)的業(yè)務(wù)環(huán)境下是合理的。但問題是沒有留下業(yè)務(wù)規(guī)則的注釋導(dǎo)致后來的開發(fā)者不知道這些硬編碼背后的邏輯。新架構(gòu)中我們用常量替換了魔法字符串并在代碼注釋中記錄了業(yè)務(wù)規(guī)則。這是對(duì)歷史的尊重也是對(duì)未來的負(fù)責(zé)。下篇預(yù)告下一篇進(jìn)入抖音普通訂單《取號(hào)為什么越來越慢100次數(shù)據(jù)庫查詢其實(shí)只需要1次》。代發(fā)搭好的分層架構(gòu)普通訂單直接復(fù)用——但復(fù)用不等于照搬四個(gè)差異點(diǎn)一個(gè)都不能漏。另外還有一個(gè)讓所有平臺(tái)受益的性能優(yōu)化。討論話題你們的系統(tǒng)里有沒有那種看起來沒用但不能刪的代碼或者半年才走一次、一走就炸的低頻鏈路評(píng)論區(qū)聊聊。