一、專案背景

為什麼需要架構升級

• promise時效包含兩個子系統：核心時效計算系統（系統核心是時效計算）和元件化時效系統（系統核心是複雜業務處理以及多種時效業務聚合，承接結算下單黃金流程流量），後者依賴前者，分別由兩組技術團隊支援；因為有些業務的滲透造成兩個系統的邊界越來越不清晰；有些需求從PRD評審到專案上線，需要兩組研發全程參與，耗費大量人力；
• promise時效計算業務邏輯經過多年的沉澱越來越複雜，時效計算系統中有很多業務邏輯，導致計算核心也需要跟隨需求頻繁更新；
• 時效計算分為預約和非預約，下單前和下單後，結算頁時效和商詳頁時效。有共性也存在差異，導致共用一部分核心計算的同時存在大量冗餘重複程式碼，需要同時維護和儲存兩份時效計算的快取資料。
• 多種業務從核心系統中提供專用介面，導致系統嚴重腐化。
• 存在部分未採用RPC方式的依賴，導致jar包依賴和時效計算的切量開關需要設定在元件化時效系統中，影響開發和聯調效率。

綜上，決定這次技術驅動的重構，需要架構升級解決系統中存在的問題。

重構目標

業務邊界更清晰

重構之後的需求邊界從產品側就能夠確定，如果新增倉配時效計算規則需要修改或新增核心計算，其他業務的需求基本元件化時效中修改即可；

業務邏輯更聚合

元件化中整合業務邏輯；

核心計算邏輯更純淨

一套時效計算快取，節省一半硬體資源費用；

增加系統複用性，一套計算模式同時支援預約和非預約兩種模式，支援結算和商詳，下單前和下單後的場景；維護一套核心計算邏輯程式碼，與具體業務分離，節省更多人力資源；

二、方案設計

核心計算業務梳理

現有業務介面：

• 標準達日曆：考慮控單，產能，大宗禁止 標準達日曆
• 京準達日曆：考慮控單，產能，大宗禁止 京準達日曆
• 無人車日曆：無人車日曆 倉自提/無人車日曆
• 倉自提日曆：倉自提日曆，不走干支線 倉自提/無人車日曆
• 自提日曆：獲取自提點四級地址，考慮控單，產能，大宗禁止 標準達日曆
• Vxp日曆：考慮控單，節假日，大宗禁止，不考慮產能，固定最大天數和可選天數 標準日曆
• 7Fresh日曆：標準達日曆計算完成後根據門店波次替換日曆波次 標準達日曆
• 全球購報稅日曆：加上全球購報稅備貨buffer後走標準達日曆計算 標準達日曆
• B2B日曆：B2B日曆計算
• 奪寶島日曆：奪寶島日曆計算

根據業務特點，將原來的8種業務時效計算介面聚合為3個核心通用計算介面，消除了5種業務的特殊處理介面。重新定義設計新的核心計算介面：京準達時效、標準時效、倉自提時效。減少了大量重複程式碼，避免改一個需求就要改好多相同的地方，便於統一管理。

新core系統三個核心介面方法可以為多個業務系統提供服務

系統重構相關業務如下圖所示，

主要變更點：

• core介面聚合，元件化系統適配，補充處理前置資訊；
• 重構之前控單介面的呼叫和產能邏輯分散在元件化時效和base系統中，重構後產能提供新介面，控單和產能邏輯從core系統剝離，集中到元件化時效系統中；
• 大宗商品、二級倉、全球購清關、VXP節假日等業務邏輯上浮到元件化系統，減少了系統間報文大小和介面複雜度；

系統重構業務

三、專案實施

元件化業務梳理

• 考慮產能
• 考慮控單
• 考慮走干支線
• 判斷是否大宗
• 新增全球購清關時長加buffer
• 新增產能白名單
• 新增產能白名單打標
• 新增自提波次格式轉換
• 新增二級倉出參資訊整合
• core新介面轉單據型別
• 節能補貼增加預設buffer
• 增7鮮門店波次轉換
• 新增全球購多倉遮蔽邏輯

元件化時效中對新介面進行適配，可用切量開關進行控制

四、穩定性保障

怎樣保證系統重構的安全性和準確性，重構前後一致性驗證上線前主要有兩種方式：單測覆蓋和流量回放驗證；上線後通過多維度切量開關進行控制，保障系統的穩定性。

上線前

• 單測場景覆蓋

1700+個測試用例，覆蓋大部分單一業務場景和部分組合業務場景。

• 流量回放驗證

通過實時引流線上流量，回放到重構後的系統中。流量回放過程中發現差異，分析具體原因，發現多個重構測試用例未覆蓋到的複雜場景問題。

eg.全球購商品滿足城配轉普通時效走大宗時效的場景:正常邏輯是①全球購商品命中了城配邏輯；②全球購不支援城配時效，需要轉普通時效；③轉成普通時效後又命中大宗業務場景。重構時從①走到了③,城配時效和大宗時效是互斥的，所以無法轉換成大宗時效，調整轉換邏輯後導致和重構前時效不一致，這種場景負責涉及業務設定很多，很難通過測試用例覆蓋，流量回放驗證是很好的驗證方案。

• 流量回放自定義對比差異

由於系統架構調整以及新介面的設計和老架構存在差異，導致採購、全球購、控單等業務場景下返回的起始日曆日期不一致，實際可用日曆和波次是一致的，所以這種是預期內的差異，導致流量回放時diff率較高，頁面設定的忽略欄位無法滿足我們的需求；

首次採用自定義指令碼進行差異對比，自定義實現排序和忽略項設定，將不影響時效的差異物件忽略掉，減少diff干擾。

• 業務方案確認

對未通過測試用、流量回放差異，研發測試分別列出清單，研發、測試、產品組會進行溝通，對系統現狀和業務影響範圍進行評審，確定最終處理方案。

測試中發現的問題驗證修復後，確認達到業務要求和上線標準，才可以灰度上線。

上線後

灰度釋出時，只接入一小部分流量，並及時跟蹤和分析線上的 log 與監控告警，並關注使用者反饋一有問題及時解決。當新系統趨於穩定時，逐漸加大灰度釋出的範圍和接入的流量，同時繼續跟蹤線上 log 與監控告警。

• 白名單驗證

上線後用白名單使用者進行驗證。

• 流量切換控制

系統上線後，支援使用者PIN的百分比進行切量，灰度驗證實現平穩過渡。

• 元件切換開關

新老邏輯元件可以一鍵切換，如發現問題可快速切回原邏輯，快速止損，保證線上系統安全；

五、專案價值

系統優化

• 按專案預期實現了全新純淨的時效核心計算介面，核心系統具有更高的複用性；
• 元件化系統中重新組織部分邏輯，增加上浮的業務邏輯。系統邏輯更聚合，提升易讀性、減小了系統維護成本；
• 降低上線風險，重塑業務邊界後，互動系統邏輯更集中，減少了相互依賴設定，更利於把控風險；
• 重構修復測試用例和引流驗證時，發現並修復多個線上BUG，保障並提高了系統的穩定性；

◦ 測試用例發現5個BUG，修復遺漏邊緣業務邏輯和處理邏輯錯誤等問題；

◦ 流量回放中發現7個BUG，修復530標位、京準達時效型別等線上bug；

• 修正40+個測試用例；

遇到的困難

系統重構總能留下比較深刻的印象，不僅會碰到技術的挑戰，需要思考用什麼方案更合理；也會碰到難以理清的業務邏輯，需要將產品、研發、測試搖到一起追思憶往；還會發現歷史的「bug」，讓人糾結要不要「更正」；都很耗費髮量。

1、流量回放階段，由於出引資料填充方式變化，導致無法比較，通過自定義指令碼的方式解決。

2、自提時效多倉場景新架構無法支援，協同產品、業務優化原有多倉場景的處理方式，既解決問題又優化了線上處理邏輯。

專案總結

重構有利於專案的健壯和精簡，平時要養成重構的好習慣，「小步快走」，儘量避免留著統一重構的思想，積累很多技術債後重構精力、時間成本很大，風險也會大很多。如果重構任務艱鉅，需要提前做好迭代計劃，重構方案設計之初就要考慮如何分階段實施，小步快走層層分離的策略就相當於搭建施工現場的腳手架，是一種把風險控制在可接受範圍的有效手段。更多關注「明天價值」，當發現好的資料結構、好的思想的時候，甚至一個變數名或方法名，把以前寫的程式碼重寫一下；

何時進行重構最好遵循「三次法則」，如果一件事需要做一兩次，可以不著急重構；但是如果需要重複三次甚至以上的話，就該考慮著手去重構了，保持系統的健康狀態。

公司業務在快速發展中，系統重構期間，需繼續保持業務需求的迭代速度，可以適當增加人員。

系統重構前需要對業務足夠熟悉（包括邊緣業務），重構時可能會遇到看著重構程式碼一樣，實際程式碼的執行順序影響業務的前後依賴或優先順序，最後影響結果的輸出，在複雜的業務處理流程中很難發現問題。

上線後跟蹤系統執行實際效能變動、資源消耗、穩定性。重構中發現了系統中存在相似的業務處理邏輯、城配相關的邏輯過於複雜等問題，下一步與產品業務溝通是否可以進行精簡，重構不是終點，更像是起點。

作者：京東物流 崔海君

來源：京東雲開發者社群 自猿其說 Tech 轉載請註明來源