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