貨管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn))
做物流寄件發(fā)貨管理系統(tǒng)這個(gè)題目大部分人第一反應(yīng)是“不就是個(gè)增刪改查嗎”但真正動(dòng)手才發(fā)現(xiàn)從下單、派單到運(yùn)費(fèi)計(jì)算、軌跡回傳每一步都有藏著細(xì)節(jié)的坑。尤其是用SpringBoot搭這種多角色、多狀態(tài)的業(yè)務(wù)系統(tǒng)框架本身不難難的是業(yè)務(wù)流程怎么落地成表結(jié)構(gòu)和接口設(shè)計(jì)。這篇文章我會(huì)把整個(gè)系統(tǒng)的設(shè)計(jì)思路、核心模塊拆解、關(guān)鍵代碼實(shí)現(xiàn)和實(shí)際開發(fā)中遇到的坑一次講清楚基本都是可以直接抄作業(yè)的級(jí)別適合正在做畢業(yè)設(shè)計(jì)、或者公司內(nèi)部要快速搭一套寄件管理后臺(tái)的同學(xué)參考。1. 需求梳理與整體架構(gòu)設(shè)計(jì)1.1 業(yè)務(wù)角色與核心流程拆解物流寄件發(fā)貨管理系統(tǒng)本質(zhì)上是個(gè)多角色協(xié)作平臺(tái)光“下單”這一個(gè)動(dòng)作背后就牽扯到用戶、快遞員、網(wǎng)點(diǎn)管理員、系統(tǒng)管理員四類角色。我在設(shè)計(jì)的時(shí)候先把完整業(yè)務(wù)鏈路畫了一遍用戶提交寄件申請(qǐng) → 系統(tǒng)根據(jù)地址和重量計(jì)算運(yùn)費(fèi) → 快遞員接單攬收 → 包裹進(jìn)入運(yùn)輸節(jié)點(diǎn) → 簽收完成。每個(gè)環(huán)節(jié)都會(huì)改變訂單狀態(tài)所以第一步不是寫代碼而是把這張狀態(tài)流轉(zhuǎn)圖理清楚。系統(tǒng)最終劃分為六大模塊用戶管理、寄件下單、訂單管理、快遞員任務(wù)、運(yùn)費(fèi)管理、數(shù)據(jù)統(tǒng)計(jì)。用戶端負(fù)責(zé)維護(hù)地址簿和下單快遞員端負(fù)責(zé)接單和更新運(yùn)輸狀態(tài)管理后臺(tái)則處理人員分配、價(jià)格策略和異常訂單。每個(gè)模塊之間通過訂單ID這條主線關(guān)聯(lián)數(shù)據(jù)結(jié)構(gòu)上要求訂單表能串聯(lián)起所有業(yè)務(wù)動(dòng)作。做這類系統(tǒng)最忌諱一上來就建表我建議先用文字把每個(gè)角色的操作場(chǎng)景列出來再從中提取實(shí)體和關(guān)系。比如“用戶下單”這個(gè)場(chǎng)景就能提取出用戶表、地址表、訂單表“快遞員攬收”會(huì)提取出快遞員表、攬收記錄表以及訂單表里的分配字段。角色明確、場(chǎng)景清晰表結(jié)構(gòu)自然就浮出來了。1.2 SpringBoot 在中小型管理系統(tǒng)中的技術(shù)選型邏輯選擇SpringBoot作為基礎(chǔ)框架不是因?yàn)楦L(fēng)而是它確實(shí)適合這種業(yè)務(wù)密集型系統(tǒng)。物流寄件系統(tǒng)的核心訴求是快速開發(fā)、穩(wěn)定運(yùn)行、易于維護(hù)SpringBoot的自動(dòng)裝配機(jī)制把大量繁瑣的配置工作消化掉了一個(gè)starter就能搞定數(shù)據(jù)源連接不用像傳統(tǒng)SSH那樣寫一堆XML配置文件。具體技術(shù)棧我用了SpringBoot 2.7.18 MyBatis-Plus MySQL 8.0 Redis Vue 3這套組合在今天看來依然是比較穩(wěn)的選擇。MyBatis-Plus讓單表CRUD完全不用寫SQL復(fù)雜的多表統(tǒng)計(jì)查詢?cè)偈謱慩ML開發(fā)效率很高。Redis主要用來存登錄token和快遞員地理位置緩存雖然小項(xiàng)目里也可以用JWT自校驗(yàn)代替但有了Redis做集中管理后續(xù)做會(huì)話踢出、在線狀態(tài)展示都很方便。安全認(rèn)證這塊用的是Spring Security JWT這個(gè)組合既能滿足接口鑒權(quán)需求又能保持服務(wù)無狀態(tài)方便后續(xù)擴(kuò)展成前后端分離架構(gòu)。文件上傳用的本地存儲(chǔ)因?yàn)檫@類系統(tǒng)的運(yùn)單照片、身份證照片量級(jí)不大沒必要一開始就接OSS或者M(jìn)inIO等真正跑起來了再換不遲。2. 數(shù)據(jù)庫設(shè)計(jì)與核心模塊實(shí)現(xiàn)2.1 訂單主表設(shè)計(jì)狀態(tài)字段是靈魂訂單表是整個(gè)系統(tǒng)的心臟我在設(shè)計(jì)時(shí)分了三個(gè)層次訂單主表存基礎(chǔ)信息和當(dāng)前狀態(tài)訂單狀態(tài)履歷表存每一次狀態(tài)變更的日志訂單擴(kuò)展表存不同快遞類型普通件、生鮮件、大件的個(gè)性化字段。三表通過order_id關(guān)聯(lián)既保證了主表查詢效率又保留了業(yè)務(wù)擴(kuò)展空間。CREATE TABLE order_info ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) COLLATE utf8mb4_general_ci NOT NULL COMMENT 訂單編號(hào), user_id bigint NOT NULL COMMENT 下單用戶ID, sender_name varchar(50) COLLATE utf8mb4_general_ci NOT NULL COMMENT 寄件人姓名, sender_phone varchar(20) COLLATE utf8mb4_general_ci NOT NULL COMMENT 寄件人電話, sender_address varchar(255) COLLATE utf8mb4_general_ci NOT NULL COMMENT 寄件地址, receiver_name varchar(50) COLLATE utf8mb4_general_ci NOT NULL COMMENT 收件人姓名, receiver_phone varchar(20) COLLATE utf8mb4_general_ci NOT NULL COMMENT 收件人電話, receiver_address varchar(255) COLLATE utf8mb4_general_ci NOT NULL COMMENT 收件地址, goods_name varchar(100) COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT 物品名稱, goods_weight decimal(10,2) DEFAULT NULL COMMENT 物品重量(kg), freight decimal(10,2) NOT NULL COMMENT 運(yùn)費(fèi)金額, status tinyint NOT NULL DEFAULT 0 COMMENT 訂單狀態(tài):0待支付,1待攬收,2已攬收,3運(yùn)輸中,4已簽收,5已取消, courier_id bigint DEFAULT NULL COMMENT 接單快遞員ID, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_courier_id (courier_id), KEY idx_status (status), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT寄件訂單表;狀態(tài)字段我用了tinyint而不是字符串原因很簡(jiǎn)單查詢快、存儲(chǔ)小、排序方便。0到5的數(shù)字代表不同狀態(tài)在代碼里維護(hù)一個(gè)枚舉類做映射可讀性完全夠用。關(guān)鍵索引要覆蓋查詢場(chǎng)景用戶查自己的訂單列表走idx_user_id快遞員查待接單列表走idx_status后臺(tái)按快遞員查派單記錄走idx_courier_id這些索引加完后基本能保證所有查詢都在毫秒級(jí)返回。2.2 地址簿與常用寄件人管理地址簿是提升用戶體驗(yàn)的重要模塊用戶下單時(shí)不用每次重新輸入地址直接從地址簿選擇即可。我設(shè)計(jì)了獨(dú)立的address_book表存用戶ID、聯(lián)系人姓名、電話、省市區(qū)編碼、詳細(xì)地址、地址標(biāo)簽家/公司/其他、是否默認(rèn)地址。這里有個(gè)細(xì)節(jié)刪除地址時(shí)不能物理刪除要用邏輯刪除標(biāo)記因?yàn)闅v史訂單里可能引用過這個(gè)地址真刪了會(huì)讓訂單信息不完整。Service public class AddressBookServiceImpl extends ServiceImplAddressBookMapper, AddressBook implements AddressBookService { Override public boolean saveAddress(AddressBook addressBook) { if (Boolean.TRUE.equals(addressBook.getIsDefault())) { // 如果設(shè)置當(dāng)前地址為默認(rèn)先把該用戶其他地址的默認(rèn)標(biāo)記取消 LambdaUpdateWrapperAddressBook updateWrapper new LambdaUpdateWrapper(); updateWrapper.eq(AddressBook::getUserId, addressBook.getUserId()) .set(AddressBook::getIsDefault, false); this.update(updateWrapper); } return this.save(addressBook); } }這段代碼解決了一個(gè)很容易被忽略的業(yè)務(wù)規(guī)則同一個(gè)用戶只能有一個(gè)默認(rèn)地址。每次設(shè)置新的默認(rèn)地址時(shí)必須先把舊的默認(rèn)標(biāo)記清零。如果忘了這步用戶每次下單都會(huì)彈出兩個(gè)默認(rèn)地址非常影響體驗(yàn)。2.3 運(yùn)費(fèi)計(jì)算引擎按地區(qū)階梯定價(jià)運(yùn)費(fèi)計(jì)算是業(yè)務(wù)核心中的核心不能寫死在業(yè)務(wù)代碼里。我在設(shè)計(jì)時(shí)將運(yùn)費(fèi)策略分成三個(gè)維度基礎(chǔ)運(yùn)費(fèi)首重價(jià)格、續(xù)重單價(jià)、偏遠(yuǎn)地區(qū)附加費(fèi)。每個(gè)維度都做成可配置的數(shù)據(jù)庫表管理員可以在后臺(tái)調(diào)整不需要改代碼重新部署。實(shí)現(xiàn)思路也很直接先根據(jù)收件地址的省份和城市在運(yùn)費(fèi)配置表中查出對(duì)應(yīng)的地區(qū)規(guī)則再根據(jù)商品重量套用首重續(xù)重公式總運(yùn)費(fèi) 首重價(jià)格 ceil((重量 - 首重)/續(xù)重單位) * 續(xù)重單價(jià)最后判斷是否屬于偏遠(yuǎn)地區(qū)是則加上附加費(fèi)。整個(gè)過程用策略模式封裝后續(xù)如果接入不同快遞公司的計(jì)價(jià)規(guī)則只需新增一個(gè)實(shí)現(xiàn)類即可。public class FreightCalculator { private static final double FIRST_WEIGHT 1.0; public static BigDecimal calculate(BigDecimal weight, FreightRule rule) { if (weight.compareTo(BigDecimal.ZERO) 0) { throw new BusinessException(重量必須大于0); } BigDecimal firstPrice rule.getFirstPrice(); BigDecimal additionalPrice rule.getAdditionalPrice(); // 首重1kg內(nèi)按首重價(jià)格超出部分按續(xù)重單價(jià)計(jì)算 if (weight.compareTo(BigDecimal.valueOf(FIRST_WEIGHT)) 0) { return firstPrice; } double additionalWeight Math.ceil(weight.doubleValue() - FIRST_WEIGHT); BigDecimal freight firstPrice.add(BigDecimal.valueOf(additionalWeight).multiply(additionalPrice)); // 判斷是否加偏遠(yuǎn)地區(qū)附加費(fèi) if (Boolean.TRUE.equals(rule.getIsRemote())) { freight freight.add(rule.getRemoteFee()); } return freight.setScale(2, RoundingMode.HALF_UP); } }重量向上取整是整個(gè)計(jì)算的關(guān)鍵2.1kg按3kg算這是物流行業(yè)通行的計(jì)費(fèi)規(guī)則不能四舍五入。我見過有同事在這個(gè)地方用BigDecimal的setScale做四舍五入結(jié)果每單少收幾毛錢月底對(duì)賬怎么都對(duì)不上。另外價(jià)格計(jì)算一定要用BigDecimaldouble直接算錢會(huì)出大問題。3. 核心接口與業(yè)務(wù)邏輯實(shí)現(xiàn)3.1 下單流程事務(wù)與唯一編號(hào)生成用戶下單接口是調(diào)用頻率最高的接口也是并發(fā)壓力最大的點(diǎn)設(shè)計(jì)得不好容易產(chǎn)生重復(fù)訂單和超賣問題。我實(shí)現(xiàn)下單接口時(shí)做了三件事生成唯一訂單編號(hào)、計(jì)算運(yùn)費(fèi)、保存訂單和預(yù)扣庫存。訂單編號(hào)規(guī)則是日期隨機(jī)數(shù)自增序列用Redis的INCR命令生成序列部分確保高并發(fā)下不會(huì)重復(fù)。Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 生成訂單編號(hào) yyyyMMdd 6位自增 String datePrefix LocalDate.now().format(DateTimeFormatter.ofPattern(yyyyMMdd)); Long seq redisTemplate.opsForValue().increment(order:seq: datePrefix); String orderNo datePrefix String.format(%06d, seq); // 2. 查詢運(yùn)費(fèi)規(guī)則并計(jì)算運(yùn)費(fèi) FreightRule rule freightRuleMapper.selectByRegion(dto.getReceiverProvince(), dto.getReceiverCity()); BigDecimal freight FreightCalculator.calculate(dto.getGoodsWeight(), rule); // 3. 構(gòu)建訂單實(shí)體并保存 OrderInfo order new OrderInfo(); BeanUtils.copyProperties(dto, order); order.setOrderNo(orderNo); order.setFreight(freight); order.setStatus(OrderStatusEnum.PENDING_PAYMENT.getCode()); orderInfoMapper.insert(order); // 4. 記錄狀態(tài)履歷 orderStatusLogMapper.insert(new OrderStatusLog(order.getId(), order.getStatus(), 用戶提交訂單)); return OrderVO.fromEntity(order); }Transactional注解在高并發(fā)場(chǎng)景下有一個(gè)需要特別注意的點(diǎn)聲明式事務(wù)默認(rèn)只在拋出RuntimeException時(shí)回滾如果方法里catch住了異常但不往外拋事務(wù)是不會(huì)回滾的。我習(xí)慣把rollbackFor設(shè)置為Exception.class讓所有異常都觸發(fā)回滾防止臟數(shù)據(jù)落庫。至于為什么用Redis生成訂單號(hào)而不是數(shù)據(jù)庫自增ID原因是訂單號(hào)要暴露給用戶不能讓別人通過訂單號(hào)猜測(cè)出平臺(tái)一天有多少單。自增ID在分布式環(huán)境下也會(huì)出現(xiàn)沖突Redis的INCR命令單線程原子性無論多少并發(fā)請(qǐng)求拿到的序列號(hào)都不會(huì)重復(fù)。3.2 快遞員接單樂觀鎖防超賣快遞員接單接口是并發(fā)沖突的重災(zāi)區(qū)同一個(gè)訂單如果被兩個(gè)快遞員同時(shí)點(diǎn)擊接單處理不好就會(huì)產(chǎn)生雙重指派。常規(guī)做法是先查訂單狀態(tài)再更新但這在并發(fā)下會(huì)出問題。我用的方案是樂觀鎖更新時(shí)帶上狀態(tài)條件如果影響行數(shù)為0說明有人搶先了直接返回“訂單已被接單”。Transactional(rollbackFor Exception.class) public boolean acceptOrder(Long orderId, Long courierId) { // 指定status1待攬收作為條件只有狀態(tài)匹配才能更新成功 int updateCount orderInfoMapper.update(null, new LambdaUpdateWrapperOrderInfo() .eq(OrderInfo::getId, orderId) .eq(OrderInfo::getStatus, OrderStatusEnum.PENDING_PICKUP.getCode()) .set(OrderInfo::getCourierId, courierId) .set(OrderInfo::getStatus, OrderStatusEnum.PICKED_UP.getCode())); if (updateCount 0) { throw new BusinessException(手慢了訂單已被其他快遞員接走); } return true; }用UPDATE...WHERE status1這種方式數(shù)據(jù)庫行鎖天然保證了同一時(shí)刻只有一個(gè)事務(wù)能更新成功邏輯既簡(jiǎn)單又可靠。我以前用過先SELECT再UPDATE的方式壓測(cè)時(shí)100個(gè)并發(fā)請(qǐng)求里有3個(gè)會(huì)產(chǎn)生重復(fù)指派后來換成條件更新后這個(gè)問題徹底消失了。核心思想就是不要把判斷和操作分成兩步要讓數(shù)據(jù)庫在原子操作里完成校驗(yàn)。同時(shí)狀態(tài)機(jī)里的每一個(gè)分支都是類似的寫法狀態(tài)變更、記錄履歷、附帶業(yè)務(wù)動(dòng)作。比如“攬收”動(dòng)作會(huì)記錄攬收人、攬收時(shí)間“運(yùn)輸中”動(dòng)作會(huì)更新當(dāng)前節(jié)點(diǎn)編碼。這些節(jié)點(diǎn)信息合起來就形成了用戶端看到的物流軌跡。3.3 物流軌跡狀態(tài)履歷與Node節(jié)點(diǎn)物流軌跡模塊一開始我只設(shè)計(jì)了一張訂單狀態(tài)履歷表但后來發(fā)現(xiàn)不夠用——用戶需要看到的是“包裹已到達(dá)【杭州轉(zhuǎn)運(yùn)中心】”這種帶節(jié)點(diǎn)的信息而不只是“運(yùn)輸中”三個(gè)字。所以我增加了transport_node表專門記錄包裹每次經(jīng)過的節(jié)點(diǎn)編碼和描述。快遞員每更新一次節(jié)點(diǎn)系統(tǒng)就會(huì)同時(shí)寫入兩條記錄一條進(jìn)狀態(tài)履歷表一條進(jìn)節(jié)點(diǎn)表。查詢用戶的物流軌跡時(shí)把這兩個(gè)表的數(shù)據(jù)按時(shí)間合并展示就能拼出完整的路徑。這里需要注意的是節(jié)點(diǎn)表的數(shù)據(jù)量會(huì)持續(xù)增長我做了按訂單號(hào)分表的預(yù)留設(shè)計(jì)目前單表查詢用order_id加索引響應(yīng)時(shí)間穩(wěn)定在幾十毫秒內(nèi)。3.4 角色權(quán)限JWT Spring Security 的輕量級(jí)實(shí)現(xiàn)管理系統(tǒng)的權(quán)限模型一般分三到四級(jí)我這邊是管理員、網(wǎng)點(diǎn)經(jīng)理、快遞員、用戶四種角色。由于是單體應(yīng)用沒有引入Spring Security OAuth2這種重框架只用Spring Security JWT就足夠了。核心思路是登錄成功后簽發(fā)JWTJWT里帶上用戶ID和角色編碼請(qǐng)求攔截器解析Token后把用戶信息放入ThreadLocal接口通過自定義注解校驗(yàn)角色。Component public class JwtAuthenticationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); try { Claims claims JwtUtil.parseToken(token); Long userId claims.get(userId, Long.class); String role claims.get(role, String.class); // 存入上下文業(yè)務(wù)代碼直接獲取當(dāng)前登錄用戶 UserContext.set(userId, role); } catch (Exception e) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); return; } } chain.doFilter(request, response); } }這里有一個(gè)細(xì)節(jié)值得說JWT天然無狀態(tài)但如果用戶修改了密碼或者被管理員封禁已簽發(fā)的Token依然是有效的。要解決這個(gè)問題簽發(fā)Token時(shí)可以順便把Token版本號(hào)存到Redis每次請(qǐng)求都校驗(yàn)一次版本。代價(jià)是多一次Redis查詢但對(duì)于即時(shí)生效的賬號(hào)封禁場(chǎng)景非常值得。4. 管理后臺(tái)與數(shù)據(jù)看板4.1 商品分類與價(jià)格規(guī)則管理后臺(tái)核心功能之一是維護(hù)運(yùn)費(fèi)規(guī)則表。我實(shí)現(xiàn)了運(yùn)費(fèi)規(guī)則的可視化配置界面管理員可以按照省份、城市、首重價(jià)格、續(xù)重單價(jià)、偏遠(yuǎn)地區(qū)標(biāo)記、生效時(shí)間六個(gè)維度維護(hù)策略。規(guī)則表設(shè)計(jì)為支持多版本修改規(guī)則時(shí)新數(shù)據(jù)默認(rèn)從次日起生效歷史訂單查詢時(shí)仍用下單時(shí)的規(guī)則快照保證對(duì)賬數(shù)據(jù)準(zhǔn)確。CREATE TABLE freight_rule ( id bigint NOT NULL AUTO_INCREMENT, province varchar(50) NOT NULL COMMENT 省份, city varchar(50) DEFAULT NULL COMMENT 城市, first_weight decimal(4,2) NOT NULL DEFAULT 1.00 COMMENT 首重重量(kg), first_price decimal(10,2) NOT NULL COMMENT 首重價(jià)格(元), additional_unit decimal(4,2) NOT NULL DEFAULT 1.00 COMMENT 續(xù)重單位(kg), additional_price decimal(10,2) NOT NULL COMMENT 續(xù)重單價(jià)(元/kg), is_remote tinyint(1) NOT NULL DEFAULT 0 COMMENT 是否偏遠(yuǎn)地區(qū), remote_fee decimal(10,2) DEFAULT 0.00 COMMENT 偏遠(yuǎn)地區(qū)附加費(fèi)(元), effective_date date NOT NULL COMMENT 生效日期, create_time datetime NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT運(yùn)費(fèi)規(guī)則表;運(yùn)費(fèi)規(guī)則配置完成后后臺(tái)還要能模擬算價(jià)。我在管理端加了一個(gè)“試算運(yùn)費(fèi)”功能輸入省份和重量立刻返回運(yùn)費(fèi)方便運(yùn)營人員快速核對(duì)計(jì)算結(jié)果是否正確。這個(gè)功能不到一百行代碼但極大減輕了測(cè)試負(fù)擔(dān)每次調(diào)整價(jià)格策略后鼠標(biāo)點(diǎn)幾下就能完成驗(yàn)證。4.2 數(shù)據(jù)看板訂單趨勢(shì)與收入統(tǒng)計(jì)數(shù)據(jù)看板是管理者每天打開系統(tǒng)的第一屏我設(shè)計(jì)了三個(gè)核心指標(biāo)卡今日訂單量、今日營收、待處理異常件數(shù)。下面配兩張趨勢(shì)圖一張是近7天訂單量折線圖一張是不同快遞類型訂單占比餅圖。這些統(tǒng)計(jì)數(shù)據(jù)不需要實(shí)時(shí)計(jì)算我用定時(shí)任務(wù)每5分鐘聚合一次把結(jié)果寫入統(tǒng)計(jì)表查詢時(shí)直接返回緩存數(shù)據(jù)大幅降低數(shù)據(jù)庫壓力。Component public class OrderStatisticsTask { Scheduled(cron 0 */5 * * * ?) public void aggregate() { // 1. 查最近7天每天的訂單量和營收 ListMapString, Object list orderInfoMapper.selectDailyStats( LocalDate.now().minusDays(6), LocalDate.now()); // 2. 寫入統(tǒng)計(jì)表已存在則更新 for (MapString, Object item : list) { String date String.valueOf(item.get(stat_date)); Integer orderCount ((Number) item.get(order_count)).intValue(); BigDecimal amount (BigDecimal) item.get(total_amount); dailyStatsMapper.insertOrUpdate(date, orderCount, amount); } } }定時(shí)任務(wù)用Spring自帶的Scheduled就能搞定不需要額外引入XXL-Job這種重框架。但要注意定時(shí)任務(wù)默認(rèn)是單線程串行執(zhí)行的如果有多個(gè)任務(wù)要分開配置線程池。我在項(xiàng)目里專門定義了一個(gè)ScheduledConfig類把線程池核心線程數(shù)設(shè)為5避免一個(gè)耗時(shí)任務(wù)拖慢其他任務(wù)。4.3 異常訂單處理機(jī)制線上跑了一段時(shí)間后發(fā)現(xiàn)訂單流程總會(huì)出現(xiàn)各種異常情況用戶支付成功但快遞員一直不接單、包裹在途中超48小時(shí)沒有節(jié)點(diǎn)更新、用戶發(fā)貨前取消訂單但運(yùn)費(fèi)已扣。針對(duì)這些場(chǎng)景我給后臺(tái)增加了一個(gè)異常訂單管理頁面按異常類型分類展示運(yùn)營人員可以直接在頁面上做退款、改派、標(biāo)記丟失等操作。這里最重要的是退款操作和財(cái)務(wù)記錄的聯(lián)動(dòng)。每次退款都要生成一條財(cái)務(wù)流水字段包括訂單號(hào)、退款金額、退款原因、操作人、時(shí)間。這樣一來后續(xù)對(duì)賬時(shí)所有資金變動(dòng)都有據(jù)可查。我在財(cái)務(wù)流水表上加了唯一索引order_id, type防止運(yùn)營人員手滑重復(fù)退款。5. 系統(tǒng)優(yōu)化與部署實(shí)戰(zhàn)5.1 數(shù)據(jù)庫層面優(yōu)化索引與SQL執(zhí)行計(jì)劃系統(tǒng)上線不久訂單列表查詢?cè)絹碓铰绕涫呛笈_(tái)按用戶ID時(shí)間范圍狀態(tài)組合篩選時(shí)響應(yīng)時(shí)間一度超過3秒。我通過EXPLAIN命令分析執(zhí)行計(jì)劃發(fā)現(xiàn)主要問題有兩個(gè)一是查詢條件里用了函數(shù)如DATE_FORMAT(create_time)導(dǎo)致索引失效二是排序字段沒有索引導(dǎo)致文件排序。優(yōu)化的具體操作把create_time條件改成等值或范圍查詢直接傳日期對(duì)象讓MyBatis-Plus生成format參數(shù)避免在SQL里對(duì)字段套函數(shù)然后給組合查詢場(chǎng)景添加聯(lián)合索引(create_time, status, user_id)最后把分頁查詢的結(jié)果總數(shù)COUNT語句單獨(dú)優(yōu)化去掉不必要的JOIN。優(yōu)化后同樣的查詢響應(yīng)時(shí)間降到200毫秒以內(nèi)。5.2 Redis緩存策略熱點(diǎn)數(shù)據(jù)與防穿透用戶端的首頁會(huì)展示運(yùn)費(fèi)價(jià)格表、常見問題、公告信息這些數(shù)據(jù)變化頻率極低但訪問量大是典型的緩存場(chǎng)景。我用Redis做了兩級(jí)緩存策略第一級(jí)HashMap本地緩存用于單機(jī)環(huán)境快速返回第二級(jí)Redis緩存用于多實(shí)例共享。數(shù)據(jù)更新時(shí)主動(dòng)刪除緩存下次請(qǐng)求自動(dòng)回源數(shù)據(jù)庫并重建緩存。另一個(gè)要防的是緩存穿透惡意請(qǐng)求反復(fù)用一個(gè)不存在的訂單號(hào)查詢數(shù)據(jù)庫每次都會(huì)命中空結(jié)果。解決辦法是用空值緩存查詢結(jié)果為null時(shí)也寫入Redis過期時(shí)間設(shè)置為3分鐘。此外在接口入?yún)幼隽嘶A(chǔ)校驗(yàn)訂單號(hào)必須符合日期數(shù)字的格式規(guī)范不合法直接拒絕。5.3 本地Docker Desktop部署與容器化項(xiàng)目完成后部署到服務(wù)器前我在本地先用Docker Desktop跑了一遍全流程。這里說一個(gè)自己在實(shí)踐中摸索出的經(jīng)驗(yàn)SpringBoot項(xiàng)目用JDK 1.8打包成Docker鏡像時(shí)基礎(chǔ)的openjdk:8鏡像體積偏大建議直接用帶Alpine版本的。Dockerfile我寫成了多階段構(gòu)建先Maven打包再拷貝到運(yùn)行鏡像整個(gè)鏡像控制在250MB以內(nèi)。# 構(gòu)建階段 FROM maven:3.8-openjdk-8 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn package -DskipTests # 運(yùn)行階段 FROM openjdk:8-jre-alpine WORKDIR /app COPY --frombuilder /app/target/logistics-system.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar, --spring.profiles.activeprod]MySQL和Redis同樣用Docker容器運(yùn)行我專門寫了一個(gè)docker-compose.yml把三個(gè)服務(wù)編排在一起。data目錄掛載到宿主機(jī)保證容器重啟數(shù)據(jù)庫不丟這點(diǎn)非常關(guān)鍵——我有一次圖省事沒掛載Docker一更新整個(gè)庫都沒了教訓(xùn)深刻。上線前再檢查一遍環(huán)境和數(shù)據(jù)卷掛載測(cè)試環(huán)境跑幾天確保穩(wěn)定后切生產(chǎn)。5.4 配置文件管理與多環(huán)境切換項(xiàng)目從開發(fā)到測(cè)試再到生產(chǎn)三套環(huán)境的配置肯定不一樣。我用的方案是SpringBoot的Profile多環(huán)境配置application.yml里只放公共配置application-dev.yml、application-test.yml、application-prod.yml分別存放各自環(huán)境的數(shù)據(jù)庫地址、Redis地址、日志級(jí)別等。啟動(dòng)時(shí)通過--spring.profiles.active參數(shù)指定跑哪套配置。數(shù)據(jù)庫密碼這類敏感信息我沒有明文寫在配置文件里用了Jasypt做加密。配置項(xiàng)寫成ENC(加密串)的形式應(yīng)用啟動(dòng)時(shí)自動(dòng)解密。這樣即使配置文件泄露了別人也拿不到明文密碼。Jasypt集成SpringBoot很簡(jiǎn)單加依賴、改配置、用工具類加密原始密碼三步搞定。6. 踩坑記錄與開發(fā)工具推薦6.1 常見問題速查表與解決思路開發(fā)過程中我整理了一份問題排查清單都是自己碰到過且有明確解決辦法的。最典型的是循環(huán)依賴問題訂單服務(wù)和快遞員服務(wù)互相調(diào)用導(dǎo)致啟動(dòng)直接報(bào)錯(cuò)。解決辦法不是加Lazy注解糊弄過去而是從設(shè)計(jì)層面把公共邏輯抽出來放到獨(dú)立的Service里打破依賴環(huán)。問題現(xiàn)象根本原因解決方案訂單狀態(tài)更新丟失并發(fā)更新未加版本號(hào)或狀態(tài)條件UPDATE使用WHERE status預(yù)期值金額對(duì)賬不平double計(jì)算精度丟失全部改成BigDecimal計(jì)算緩存穿透導(dǎo)致DB壓力大查詢不存在的數(shù)據(jù)反復(fù)打庫空值緩存 入?yún)⑿ｒ?yàn)事務(wù)未回滾異常被catch后未拋出事務(wù)方法內(nèi)不吞異常rollbackForException跨域請(qǐng)求被攔截前后端分離未配跨域?qū)崿F(xiàn)WebMvcConfigurer配置CorsMapping6.2 我常用的幾個(gè)效率提升工具說實(shí)話做這類管理系統(tǒng)真正拉開效率差距的是工具鏈的熟練度。SpringBoot項(xiàng)目里L(fēng)ombok幾乎是我必裝的Data注解直接省掉所有g(shù)etter/setter代碼量瞬間少一半。MapStruct做屬性拷貝比BeanUtils性能好很多編譯期就生成轉(zhuǎn)換代碼不會(huì)像反射那樣在頻繁調(diào)用時(shí)損耗性能。接口調(diào)試用Apifox對(duì)比Swagger和Postman它的優(yōu)勢(shì)是直接把接口文檔、調(diào)試、Mock數(shù)據(jù)整合在一個(gè)工具里方便前端快速聯(lián)調(diào)。還有一個(gè)非常實(shí)用的小工具是Spring官方提供的Spring Initializr創(chuàng)建項(xiàng)目時(shí)勾選依賴就自動(dòng)生成完整骨架比在開發(fā)工具里新建省事很多。數(shù)據(jù)庫層面配合MySQL Workbench做表結(jié)構(gòu)版本管理加上Flyway做數(shù)據(jù)庫遷移表結(jié)構(gòu)變更不再直接在生產(chǎn)庫上手工執(zhí)行SQL。這樣每次發(fā)版數(shù)據(jù)庫變更腳本和應(yīng)用代碼一起走版本控制基本杜絕了環(huán)境之間表結(jié)構(gòu)不一致的尷尬場(chǎng)面。6.3 application.yml 不自動(dòng)提示的解決辦法開發(fā)過程中不少同事遇到過IDEA里寫application.yml沒有自動(dòng)提示的問題第一次遇到其實(shí)很困惑。原因是IDEA無法識(shí)別這個(gè)文件對(duì)應(yīng)的配置元數(shù)據(jù)解決方法是手動(dòng)把a(bǔ)pplication.yml標(biāo)記為Spring配置文件右鍵文件 → 點(diǎn)擊“Add as Spring Boot Configuration File”之后寫配置項(xiàng)就會(huì)有自動(dòng)提示了。另外如果引入了自定義starter但I(xiàn)DEA里就是不提示自定義配置項(xiàng)需要依賴spring-boot-configuration-processor這個(gè)注解處理器來自動(dòng)生成配置元數(shù)據(jù)。在pom.xml引入該依賴后重新編譯項(xiàng)目IDEA就能識(shí)別所有配置項(xiàng)。沒加之前很多配置只能靠手寫非常容易拼錯(cuò)加上后效率翻倍。7. 項(xiàng)目測(cè)試與系統(tǒng)部署7.1 單元測(cè)試與接口自動(dòng)化測(cè)試管理系統(tǒng)最容易忽視質(zhì)量保障但我堅(jiān)持把核心計(jì)算和狀態(tài)流轉(zhuǎn)的邏輯用單元測(cè)試覆蓋起來。比如運(yùn)費(fèi)計(jì)算器我寫了六個(gè)測(cè)試用例覆蓋首重內(nèi)、超首重、偏遠(yuǎn)地區(qū)、重量為零、超重邊界、極端大重量六個(gè)場(chǎng)景保證每次修改價(jià)格策略后回歸測(cè)試一鍵執(zhí)行。Test void testCalculateOverFirstWeight() { FreightRule rule new FreightRule(); rule.setFirstPrice(new BigDecimal(10.00)); rule.setAdditionalPrice(new BigDecimal(2.00)); rule.setIsRemote(false); rule.setRemoteFee(BigDecimal.ZERO); BigDecimal freight FreightCalculator.calculate(new BigDecimal(2.1), rule); // 2.1kg按3kg算運(yùn)費(fèi)102*214 Assertions.assertEquals(0, freight.compareTo(new BigDecimal(14.00))); }接口自動(dòng)化測(cè)試方面我用了RestAssured配合JUnit5寫了一套冒煙測(cè)試腳本覆蓋登錄、下單、接單、軌跡查詢、后臺(tái)統(tǒng)計(jì)五個(gè)核心鏈路。每次構(gòu)建后自動(dòng)跑一遍接口掛了會(huì)第一時(shí)間發(fā)現(xiàn)不用等到上線被用戶投訴才知道。7.2 部署流程與上線檢查清單最終部署我整理了一份操作清單每次發(fā)布前都過一遍打新包前先跑一遍所有單元測(cè)試確認(rèn)核心邏輯沒被改掛備份生產(chǎn)數(shù)據(jù)庫防止發(fā)布過程中數(shù)據(jù)操作失誤關(guān)閉舊服務(wù)再啟動(dòng)新包避免版本不一致導(dǎo)致數(shù)據(jù)庫連接異常啟動(dòng)后立刻檢查日志有沒有報(bào)錯(cuò)堆棧再跑一遍核心接口冒煙測(cè)試。系統(tǒng)上線后第一周我持續(xù)觀察了日志和慢查詢記錄沒出現(xiàn)致命問題后整個(gè)項(xiàng)目才算真正交付完成。之后我結(jié)合用戶反饋又迭代了幾個(gè)小功能用戶地址簿增加地圖選點(diǎn)、快遞員端增加批量攬收、后臺(tái)報(bào)表支持導(dǎo)出Excel。管理系統(tǒng)就是這樣核心框架搭扎實(shí)了后續(xù)想加什么功能都能快速實(shí)現(xiàn)。8. 項(xiàng)目復(fù)盤與個(gè)人心得如果要給這個(gè)物流寄件系統(tǒng)做一個(gè)復(fù)盤總結(jié)我最深的體會(huì)是SpringBoot這類框架再強(qiáng)大也只是解決了技術(shù)層面的問題而系統(tǒng)設(shè)計(jì)真正的難點(diǎn)在于業(yè)務(wù)流程的梳理和邊界條件的考慮。做這個(gè)系統(tǒng)的過程中我花在理解物流業(yè)務(wù)上的時(shí)間遠(yuǎn)多于寫代碼的時(shí)間。第二個(gè)心得是不要追求一步到位先做出來再用起來再優(yōu)化。第一版系統(tǒng)我只實(shí)現(xiàn)了基礎(chǔ)的下單、接單、狀態(tài)流轉(zhuǎn)和管理后臺(tái)上線跑了兩周后結(jié)合真實(shí)使用場(chǎng)景才逐步加入運(yùn)費(fèi)規(guī)則配置、異常訂單處理、數(shù)據(jù)看板這些進(jìn)階功能。如果一開始就想著把所有功能全部做完再交付周期會(huì)拉得很長容易遙遙無期。最后分享一個(gè)小經(jīng)驗(yàn)寫這類系統(tǒng)的過程中數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計(jì)千萬別圖省事把大量信息堆在一張大表里。適度拆分表、增加冗余字段、預(yù)留擴(kuò)展位雖然前期多花一點(diǎn)時(shí)間但后期維護(hù)起來會(huì)輕松非常多。比如訂單表的擴(kuò)展字段我預(yù)留了一個(gè)json類型的extra列后續(xù)接第三方快遞接口時(shí)很多自定義屬性直接往里塞就行不用頻繁改表結(jié)構(gòu)。這個(gè)“小設(shè)計(jì)”幫我在后期的需求變更里省了不少事。 SpringBoot物流寄件發(fā)貨管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)
做物流寄件發(fā)貨管理系統(tǒng)這個(gè)題目大部分人第一反應(yīng)是“不就是個(gè)增刪改查嗎”但真正動(dòng)手才發(fā)現(xiàn)從下單、派單到運(yùn)費(fèi)計(jì)算、軌跡回傳每一步都有藏著細(xì)節(jié)的坑。尤其是用SpringBoot搭這種多角色、多狀態(tài)的業(yè)務(wù)系統(tǒng)框架本身不難難的是業(yè)務(wù)流程怎么落地成表結(jié)構(gòu)和接口設(shè)計(jì)。這篇文章我會(huì)把整個(gè)系統(tǒng)的設(shè)計(jì)思路、核心模塊拆解、關(guān)鍵代碼實(shí)現(xiàn)和實(shí)際開發(fā)中遇到的坑一次講清楚基本都是可以直接抄作業(yè)的級(jí)別適合正在做畢業(yè)設(shè)計(jì)、或者公司內(nèi)部要快速搭一套寄件管理后臺(tái)的同學(xué)參考。1. 需求梳理與整體架構(gòu)設(shè)計(jì)1.1 業(yè)務(wù)角色與核心流程拆解物流寄件發(fā)貨管理系統(tǒng)本質(zhì)上是個(gè)多角色協(xié)作平臺(tái)光“下單”這一個(gè)動(dòng)作背后就牽扯到用戶、快遞員、網(wǎng)點(diǎn)管理員、系統(tǒng)管理員四類角色。我在設(shè)計(jì)的時(shí)候先把完整業(yè)務(wù)鏈路畫了一遍用戶提交寄件申請(qǐng) → 系統(tǒng)根據(jù)地址和重量計(jì)算運(yùn)費(fèi) → 快遞員接單攬收 → 包裹進(jìn)入運(yùn)輸節(jié)點(diǎn) → 簽收完成。每個(gè)環(huán)節(jié)都會(huì)改變訂單狀態(tài)所以第一步不是寫代碼而是把這張狀態(tài)流轉(zhuǎn)圖理清楚。系統(tǒng)最終劃分為六大模塊用戶管理、寄件下單、訂單管理、快遞員任務(wù)、運(yùn)費(fèi)管理、數(shù)據(jù)統(tǒng)計(jì)。用戶端負(fù)責(zé)維護(hù)地址簿和下單快遞員端負(fù)責(zé)接單和更新運(yùn)輸狀態(tài)管理后臺(tái)則處理人員分配、價(jià)格策略和異常訂單。每個(gè)模塊之間通過訂單ID這條主線關(guān)聯(lián)數(shù)據(jù)結(jié)構(gòu)上要求訂單表能串聯(lián)起所有業(yè)務(wù)動(dòng)作。做這類系統(tǒng)最忌諱一上來就建表我建議先用文字把每個(gè)角色的操作場(chǎng)景列出來再從中提取實(shí)體和關(guān)系。比如“用戶下單”這個(gè)場(chǎng)景就能提取出用戶表、地址表、訂單表“快遞員攬收”會(huì)提取出快遞員表、攬收記錄表以及訂單表里的分配字段。角色明確、場(chǎng)景清晰表結(jié)構(gòu)自然就浮出來了。1.2 SpringBoot 在中小型管理系統(tǒng)中的技術(shù)選型邏輯選擇SpringBoot作為基礎(chǔ)框架不是因?yàn)楦L(fēng)而是它確實(shí)適合這種業(yè)務(wù)密集型系統(tǒng)。物流寄件系統(tǒng)的核心訴求是快速開發(fā)、穩(wěn)定運(yùn)行、易于維護(hù)SpringBoot的自動(dòng)裝配機(jī)制把大量繁瑣的配置工作消化掉了一個(gè)starter就能搞定數(shù)據(jù)源連接不用像傳統(tǒng)SSH那樣寫一堆XML配置文件。具體技術(shù)棧我用了SpringBoot 2.7.18 MyBatis-Plus MySQL 8.0 Redis Vue 3這套組合在今天看來依然是比較穩(wěn)的選擇。MyBatis-Plus讓單表CRUD完全不用寫SQL復(fù)雜的多表統(tǒng)計(jì)查詢?cè)偈謱慩ML開發(fā)效率很高。Redis主要用來存登錄token和快遞員地理位置緩存雖然小項(xiàng)目里也可以用JWT自校驗(yàn)代替但有了Redis做集中管理后續(xù)做會(huì)話踢出、在線狀態(tài)展示都很方便。安全認(rèn)證這塊用的是Spring Security JWT這個(gè)組合既能滿足接口鑒權(quán)需求又能保持服務(wù)無狀態(tài)方便后續(xù)擴(kuò)展成前后端分離架構(gòu)。文件上傳用的本地存儲(chǔ)因?yàn)檫@類系統(tǒng)的運(yùn)單照片、身份證照片量級(jí)不大沒必要一開始就接OSS或者M(jìn)inIO等真正跑起來了再換不遲。2. 數(shù)據(jù)庫設(shè)計(jì)與核心模塊實(shí)現(xiàn)2.1 訂單主表設(shè)計(jì)狀態(tài)字段是靈魂訂單表是整個(gè)系統(tǒng)的心臟我在設(shè)計(jì)時(shí)分了三個(gè)層次訂單主表存基礎(chǔ)信息和當(dāng)前狀態(tài)訂單狀態(tài)履歷表存每一次狀態(tài)變更的日志訂單擴(kuò)展表存不同快遞類型普通件、生鮮件、大件的個(gè)性化字段。三表通過order_id關(guān)聯(lián)既保證了主表查詢效率又保留了業(yè)務(wù)擴(kuò)展空間。CREATE TABLE order_info ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) COLLATE utf8mb4_general_ci NOT NULL COMMENT 訂單編號(hào), user_id bigint NOT NULL COMMENT 下單用戶ID, sender_name varchar(50) COLLATE utf8mb4_general_ci NOT NULL COMMENT 寄件人姓名, sender_phone varchar(20) COLLATE utf8mb4_general_ci NOT NULL COMMENT 寄件人電話, sender_address varchar(255) COLLATE utf8mb4_general_ci NOT NULL COMMENT 寄件地址, receiver_name varchar(50) COLLATE utf8mb4_general_ci NOT NULL COMMENT 收件人姓名, receiver_phone varchar(20) COLLATE utf8mb4_general_ci NOT NULL COMMENT 收件人電話, receiver_address varchar(255) COLLATE utf8mb4_general_ci NOT NULL COMMENT 收件地址, goods_name varchar(100) COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT 物品名稱, goods_weight decimal(10,2) DEFAULT NULL COMMENT 物品重量(kg), freight decimal(10,2) NOT NULL COMMENT 運(yùn)費(fèi)金額, status tinyint NOT NULL DEFAULT 0 COMMENT 訂單狀態(tài):0待支付,1待攬收,2已攬收,3運(yùn)輸中,4已簽收,5已取消, courier_id bigint DEFAULT NULL COMMENT 接單快遞員ID, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_courier_id (courier_id), KEY idx_status (status), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT寄件訂單表;狀態(tài)字段我用了tinyint而不是字符串原因很簡(jiǎn)單查詢快、存儲(chǔ)小、排序方便。0到5的數(shù)字代表不同狀態(tài)在代碼里維護(hù)一個(gè)枚舉類做映射可讀性完全夠用。關(guān)鍵索引要覆蓋查詢場(chǎng)景用戶查自己的訂單列表走idx_user_id快遞員查待接單列表走idx_status后臺(tái)按快遞員查派單記錄走idx_courier_id這些索引加完后基本能保證所有查詢都在毫秒級(jí)返回。2.2 地址簿與常用寄件人管理地址簿是提升用戶體驗(yàn)的重要模塊用戶下單時(shí)不用每次重新輸入地址直接從地址簿選擇即可。我設(shè)計(jì)了獨(dú)立的address_book表存用戶ID、聯(lián)系人姓名、電話、省市區(qū)編碼、詳細(xì)地址、地址標(biāo)簽家/公司/其他、是否默認(rèn)地址。這里有個(gè)細(xì)節(jié)刪除地址時(shí)不能物理刪除要用邏輯刪除標(biāo)記因?yàn)闅v史訂單里可能引用過這個(gè)地址真刪了會(huì)讓訂單信息不完整。Service public class AddressBookServiceImpl extends ServiceImplAddressBookMapper, AddressBook implements AddressBookService { Override public boolean saveAddress(AddressBook addressBook) { if (Boolean.TRUE.equals(addressBook.getIsDefault())) { // 如果設(shè)置當(dāng)前地址為默認(rèn)先把該用戶其他地址的默認(rèn)標(biāo)記取消 LambdaUpdateWrapperAddressBook updateWrapper new LambdaUpdateWrapper(); updateWrapper.eq(AddressBook::getUserId, addressBook.getUserId()) .set(AddressBook::getIsDefault, false); this.update(updateWrapper); } return this.save(addressBook); } }這段代碼解決了一個(gè)很容易被忽略的業(yè)務(wù)規(guī)則同一個(gè)用戶只能有一個(gè)默認(rèn)地址。每次設(shè)置新的默認(rèn)地址時(shí)必須先把舊的默認(rèn)標(biāo)記清零。如果忘了這步用戶每次下單都會(huì)彈出兩個(gè)默認(rèn)地址非常影響體驗(yàn)。2.3 運(yùn)費(fèi)計(jì)算引擎按地區(qū)階梯定價(jià)運(yùn)費(fèi)計(jì)算是業(yè)務(wù)核心中的核心不能寫死在業(yè)務(wù)代碼里。我在設(shè)計(jì)時(shí)將運(yùn)費(fèi)策略分成三個(gè)維度基礎(chǔ)運(yùn)費(fèi)首重價(jià)格、續(xù)重單價(jià)、偏遠(yuǎn)地區(qū)附加費(fèi)。每個(gè)維度都做成可配置的數(shù)據(jù)庫表管理員可以在后臺(tái)調(diào)整不需要改代碼重新部署。實(shí)現(xiàn)思路也很直接先根據(jù)收件地址的省份和城市在運(yùn)費(fèi)配置表中查出對(duì)應(yīng)的地區(qū)規(guī)則再根據(jù)商品重量套用首重續(xù)重公式總運(yùn)費(fèi) 首重價(jià)格 ceil((重量 - 首重)/續(xù)重單位) * 續(xù)重單價(jià)最后判斷是否屬于偏遠(yuǎn)地區(qū)是則加上附加費(fèi)。整個(gè)過程用策略模式封裝后續(xù)如果接入不同快遞公司的計(jì)價(jià)規(guī)則只需新增一個(gè)實(shí)現(xiàn)類即可。public class FreightCalculator { private static final double FIRST_WEIGHT 1.0; public static BigDecimal calculate(BigDecimal weight, FreightRule rule) { if (weight.compareTo(BigDecimal.ZERO) 0) { throw new BusinessException(重量必須大于0); } BigDecimal firstPrice rule.getFirstPrice(); BigDecimal additionalPrice rule.getAdditionalPrice(); // 首重1kg內(nèi)按首重價(jià)格超出部分按續(xù)重單價(jià)計(jì)算 if (weight.compareTo(BigDecimal.valueOf(FIRST_WEIGHT)) 0) { return firstPrice; } double additionalWeight Math.ceil(weight.doubleValue() - FIRST_WEIGHT); BigDecimal freight firstPrice.add(BigDecimal.valueOf(additionalWeight).multiply(additionalPrice)); // 判斷是否加偏遠(yuǎn)地區(qū)附加費(fèi) if (Boolean.TRUE.equals(rule.getIsRemote())) { freight freight.add(rule.getRemoteFee()); } return freight.setScale(2, RoundingMode.HALF_UP); } }重量向上取整是整個(gè)計(jì)算的關(guān)鍵2.1kg按3kg算這是物流行業(yè)通行的計(jì)費(fèi)規(guī)則不能四舍五入。我見過有同事在這個(gè)地方用BigDecimal的setScale做四舍五入結(jié)果每單少收幾毛錢月底對(duì)賬怎么都對(duì)不上。另外價(jià)格計(jì)算一定要用BigDecimaldouble直接算錢會(huì)出大問題。3. 核心接口與業(yè)務(wù)邏輯實(shí)現(xiàn)3.1 下單流程事務(wù)與唯一編號(hào)生成用戶下單接口是調(diào)用頻率最高的接口也是并發(fā)壓力最大的點(diǎn)設(shè)計(jì)得不好容易產(chǎn)生重復(fù)訂單和超賣問題。我實(shí)現(xiàn)下單接口時(shí)做了三件事生成唯一訂單編號(hào)、計(jì)算運(yùn)費(fèi)、保存訂單和預(yù)扣庫存。訂單編號(hào)規(guī)則是日期隨機(jī)數(shù)自增序列用Redis的INCR命令生成序列部分確保高并發(fā)下不會(huì)重復(fù)。Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 生成訂單編號(hào) yyyyMMdd 6位自增 String datePrefix LocalDate.now().format(DateTimeFormatter.ofPattern(yyyyMMdd)); Long seq redisTemplate.opsForValue().increment(order:seq: datePrefix); String orderNo datePrefix String.format(%06d, seq); // 2. 查詢運(yùn)費(fèi)規(guī)則并計(jì)算運(yùn)費(fèi) FreightRule rule freightRuleMapper.selectByRegion(dto.getReceiverProvince(), dto.getReceiverCity()); BigDecimal freight FreightCalculator.calculate(dto.getGoodsWeight(), rule); // 3. 構(gòu)建訂單實(shí)體并保存 OrderInfo order new OrderInfo(); BeanUtils.copyProperties(dto, order); order.setOrderNo(orderNo); order.setFreight(freight); order.setStatus(OrderStatusEnum.PENDING_PAYMENT.getCode()); orderInfoMapper.insert(order); // 4. 記錄狀態(tài)履歷 orderStatusLogMapper.insert(new OrderStatusLog(order.getId(), order.getStatus(), 用戶提交訂單)); return OrderVO.fromEntity(order); }Transactional注解在高并發(fā)場(chǎng)景下有一個(gè)需要特別注意的點(diǎn)聲明式事務(wù)默認(rèn)只在拋出RuntimeException時(shí)回滾如果方法里catch住了異常但不往外拋事務(wù)是不會(huì)回滾的。我習(xí)慣把rollbackFor設(shè)置為Exception.class讓所有異常都觸發(fā)回滾防止臟數(shù)據(jù)落庫。至于為什么用Redis生成訂單號(hào)而不是數(shù)據(jù)庫自增ID原因是訂單號(hào)要暴露給用戶不能讓別人通過訂單號(hào)猜測(cè)出平臺(tái)一天有多少單。自增ID在分布式環(huán)境下也會(huì)出現(xiàn)沖突Redis的INCR命令單線程原子性無論多少并發(fā)請(qǐng)求拿到的序列號(hào)都不會(huì)重復(fù)。3.2 快遞員接單樂觀鎖防超賣快遞員接單接口是并發(fā)沖突的重災(zāi)區(qū)同一個(gè)訂單如果被兩個(gè)快遞員同時(shí)點(diǎn)擊接單處理不好就會(huì)產(chǎn)生雙重指派。常規(guī)做法是先查訂單狀態(tài)再更新但這在并發(fā)下會(huì)出問題。我用的方案是樂觀鎖更新時(shí)帶上狀態(tài)條件如果影響行數(shù)為0說明有人搶先了直接返回“訂單已被接單”。Transactional(rollbackFor Exception.class) public boolean acceptOrder(Long orderId, Long courierId) { // 指定status1待攬收作為條件只有狀態(tài)匹配才能更新成功 int updateCount orderInfoMapper.update(null, new LambdaUpdateWrapperOrderInfo() .eq(OrderInfo::getId, orderId) .eq(OrderInfo::getStatus, OrderStatusEnum.PENDING_PICKUP.getCode()) .set(OrderInfo::getCourierId, courierId) .set(OrderInfo::getStatus, OrderStatusEnum.PICKED_UP.getCode())); if (updateCount 0) { throw new BusinessException(手慢了訂單已被其他快遞員接走); } return true; }用UPDATE...WHERE status1這種方式數(shù)據(jù)庫行鎖天然保證了同一時(shí)刻只有一個(gè)事務(wù)能更新成功邏輯既簡(jiǎn)單又可靠。我以前用過先SELECT再UPDATE的方式壓測(cè)時(shí)100個(gè)并發(fā)請(qǐng)求里有3個(gè)會(huì)產(chǎn)生重復(fù)指派后來換成條件更新后這個(gè)問題徹底消失了。核心思想就是不要把判斷和操作分成兩步要讓數(shù)據(jù)庫在原子操作里完成校驗(yàn)。同時(shí)狀態(tài)機(jī)里的每一個(gè)分支都是類似的寫法狀態(tài)變更、記錄履歷、附帶業(yè)務(wù)動(dòng)作。比如“攬收”動(dòng)作會(huì)記錄攬收人、攬收時(shí)間“運(yùn)輸中”動(dòng)作會(huì)更新當(dāng)前節(jié)點(diǎn)編碼。這些節(jié)點(diǎn)信息合起來就形成了用戶端看到的物流軌跡。3.3 物流軌跡狀態(tài)履歷與Node節(jié)點(diǎn)物流軌跡模塊一開始我只設(shè)計(jì)了一張訂單狀態(tài)履歷表但后來發(fā)現(xiàn)不夠用——用戶需要看到的是“包裹已到達(dá)【杭州轉(zhuǎn)運(yùn)中心】”這種帶節(jié)點(diǎn)的信息而不只是“運(yùn)輸中”三個(gè)字。所以我增加了transport_node表專門記錄包裹每次經(jīng)過的節(jié)點(diǎn)編碼和描述。快遞員每更新一次節(jié)點(diǎn)系統(tǒng)就會(huì)同時(shí)寫入兩條記錄一條進(jìn)狀態(tài)履歷表一條進(jìn)節(jié)點(diǎn)表。查詢用戶的物流軌跡時(shí)把這兩個(gè)表的數(shù)據(jù)按時(shí)間合并展示就能拼出完整的路徑。這里需要注意的是節(jié)點(diǎn)表的數(shù)據(jù)量會(huì)持續(xù)增長我做了按訂單號(hào)分表的預(yù)留設(shè)計(jì)目前單表查詢用order_id加索引響應(yīng)時(shí)間穩(wěn)定在幾十毫秒內(nèi)。3.4 角色權(quán)限JWT Spring Security 的輕量級(jí)實(shí)現(xiàn)管理系統(tǒng)的權(quán)限模型一般分三到四級(jí)我這邊是管理員、網(wǎng)點(diǎn)經(jīng)理、快遞員、用戶四種角色。由于是單體應(yīng)用沒有引入Spring Security OAuth2這種重框架只用Spring Security JWT就足夠了。核心思路是登錄成功后簽發(fā)JWTJWT里帶上用戶ID和角色編碼請(qǐng)求攔截器解析Token后把用戶信息放入ThreadLocal接口通過自定義注解校驗(yàn)角色。Component public class JwtAuthenticationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); try { Claims claims JwtUtil.parseToken(token); Long userId claims.get(userId, Long.class); String role claims.get(role, String.class); // 存入上下文業(yè)務(wù)代碼直接獲取當(dāng)前登錄用戶 UserContext.set(userId, role); } catch (Exception e) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); return; } } chain.doFilter(request, response); } }這里有一個(gè)細(xì)節(jié)值得說JWT天然無狀態(tài)但如果用戶修改了密碼或者被管理員封禁已簽發(fā)的Token依然是有效的。要解決這個(gè)問題簽發(fā)Token時(shí)可以順便把Token版本號(hào)存到Redis每次請(qǐng)求都校驗(yàn)一次版本。代價(jià)是多一次Redis查詢但對(duì)于即時(shí)生效的賬號(hào)封禁場(chǎng)景非常值得。4. 管理后臺(tái)與數(shù)據(jù)看板4.1 商品分類與價(jià)格規(guī)則管理后臺(tái)核心功能之一是維護(hù)運(yùn)費(fèi)規(guī)則表。我實(shí)現(xiàn)了運(yùn)費(fèi)規(guī)則的可視化配置界面管理員可以按照省份、城市、首重價(jià)格、續(xù)重單價(jià)、偏遠(yuǎn)地區(qū)標(biāo)記、生效時(shí)間六個(gè)維度維護(hù)策略。規(guī)則表設(shè)計(jì)為支持多版本修改規(guī)則時(shí)新數(shù)據(jù)默認(rèn)從次日起生效歷史訂單查詢時(shí)仍用下單時(shí)的規(guī)則快照保證對(duì)賬數(shù)據(jù)準(zhǔn)確。CREATE TABLE freight_rule ( id bigint NOT NULL AUTO_INCREMENT, province varchar(50) NOT NULL COMMENT 省份, city varchar(50) DEFAULT NULL COMMENT 城市, first_weight decimal(4,2) NOT NULL DEFAULT 1.00 COMMENT 首重重量(kg), first_price decimal(10,2) NOT NULL COMMENT 首重價(jià)格(元), additional_unit decimal(4,2) NOT NULL DEFAULT 1.00 COMMENT 續(xù)重單位(kg), additional_price decimal(10,2) NOT NULL COMMENT 續(xù)重單價(jià)(元/kg), is_remote tinyint(1) NOT NULL DEFAULT 0 COMMENT 是否偏遠(yuǎn)地區(qū), remote_fee decimal(10,2) DEFAULT 0.00 COMMENT 偏遠(yuǎn)地區(qū)附加費(fèi)(元), effective_date date NOT NULL COMMENT 生效日期, create_time datetime NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT運(yùn)費(fèi)規(guī)則表;運(yùn)費(fèi)規(guī)則配置完成后后臺(tái)還要能模擬算價(jià)。我在管理端加了一個(gè)“試算運(yùn)費(fèi)”功能輸入省份和重量立刻返回運(yùn)費(fèi)方便運(yùn)營人員快速核對(duì)計(jì)算結(jié)果是否正確。這個(gè)功能不到一百行代碼但極大減輕了測(cè)試負(fù)擔(dān)每次調(diào)整價(jià)格策略后鼠標(biāo)點(diǎn)幾下就能完成驗(yàn)證。4.2 數(shù)據(jù)看板訂單趨勢(shì)與收入統(tǒng)計(jì)數(shù)據(jù)看板是管理者每天打開系統(tǒng)的第一屏我設(shè)計(jì)了三個(gè)核心指標(biāo)卡今日訂單量、今日營收、待處理異常件數(shù)。下面配兩張趨勢(shì)圖一張是近7天訂單量折線圖一張是不同快遞類型訂單占比餅圖。這些統(tǒng)計(jì)數(shù)據(jù)不需要實(shí)時(shí)計(jì)算我用定時(shí)任務(wù)每5分鐘聚合一次把結(jié)果寫入統(tǒng)計(jì)表查詢時(shí)直接返回緩存數(shù)據(jù)大幅降低數(shù)據(jù)庫壓力。Component public class OrderStatisticsTask { Scheduled(cron 0 */5 * * * ?) public void aggregate() { // 1. 查最近7天每天的訂單量和營收 ListMapString, Object list orderInfoMapper.selectDailyStats( LocalDate.now().minusDays(6), LocalDate.now()); // 2. 寫入統(tǒng)計(jì)表已存在則更新 for (MapString, Object item : list) { String date String.valueOf(item.get(stat_date)); Integer orderCount ((Number) item.get(order_count)).intValue(); BigDecimal amount (BigDecimal) item.get(total_amount); dailyStatsMapper.insertOrUpdate(date, orderCount, amount); } } }定時(shí)任務(wù)用Spring自帶的Scheduled就能搞定不需要額外引入XXL-Job這種重框架。但要注意定時(shí)任務(wù)默認(rèn)是單線程串行執(zhí)行的如果有多個(gè)任務(wù)要分開配置線程池。我在項(xiàng)目里專門定義了一個(gè)ScheduledConfig類把線程池核心線程數(shù)設(shè)為5避免一個(gè)耗時(shí)任務(wù)拖慢其他任務(wù)。4.3 異常訂單處理機(jī)制線上跑了一段時(shí)間后發(fā)現(xiàn)訂單流程總會(huì)出現(xiàn)各種異常情況用戶支付成功但快遞員一直不接單、包裹在途中超48小時(shí)沒有節(jié)點(diǎn)更新、用戶發(fā)貨前取消訂單但運(yùn)費(fèi)已扣。針對(duì)這些場(chǎng)景我給后臺(tái)增加了一個(gè)異常訂單管理頁面按異常類型分類展示運(yùn)營人員可以直接在頁面上做退款、改派、標(biāo)記丟失等操作。這里最重要的是退款操作和財(cái)務(wù)記錄的聯(lián)動(dòng)。每次退款都要生成一條財(cái)務(wù)流水字段包括訂單號(hào)、退款金額、退款原因、操作人、時(shí)間。這樣一來后續(xù)對(duì)賬時(shí)所有資金變動(dòng)都有據(jù)可查。我在財(cái)務(wù)流水表上加了唯一索引order_id, type防止運(yùn)營人員手滑重復(fù)退款。5. 系統(tǒng)優(yōu)化與部署實(shí)戰(zhàn)5.1 數(shù)據(jù)庫層面優(yōu)化索引與SQL執(zhí)行計(jì)劃系統(tǒng)上線不久訂單列表查詢?cè)絹碓铰绕涫呛笈_(tái)按用戶ID時(shí)間范圍狀態(tài)組合篩選時(shí)響應(yīng)時(shí)間一度超過3秒。我通過EXPLAIN命令分析執(zhí)行計(jì)劃發(fā)現(xiàn)主要問題有兩個(gè)一是查詢條件里用了函數(shù)如DATE_FORMAT(create_time)導(dǎo)致索引失效二是排序字段沒有索引導(dǎo)致文件排序。優(yōu)化的具體操作把create_time條件改成等值或范圍查詢直接傳日期對(duì)象讓MyBatis-Plus生成format參數(shù)避免在SQL里對(duì)字段套函數(shù)然后給組合查詢場(chǎng)景添加聯(lián)合索引(create_time, status, user_id)最后把分頁查詢的結(jié)果總數(shù)COUNT語句單獨(dú)優(yōu)化去掉不必要的JOIN。優(yōu)化后同樣的查詢響應(yīng)時(shí)間降到200毫秒以內(nèi)。5.2 Redis緩存策略熱點(diǎn)數(shù)據(jù)與防穿透用戶端的首頁會(huì)展示運(yùn)費(fèi)價(jià)格表、常見問題、公告信息這些數(shù)據(jù)變化頻率極低但訪問量大是典型的緩存場(chǎng)景。我用Redis做了兩級(jí)緩存策略第一級(jí)HashMap本地緩存用于單機(jī)環(huán)境快速返回第二級(jí)Redis緩存用于多實(shí)例共享。數(shù)據(jù)更新時(shí)主動(dòng)刪除緩存下次請(qǐng)求自動(dòng)回源數(shù)據(jù)庫并重建緩存。另一個(gè)要防的是緩存穿透惡意請(qǐng)求反復(fù)用一個(gè)不存在的訂單號(hào)查詢數(shù)據(jù)庫每次都會(huì)命中空結(jié)果。解決辦法是用空值緩存查詢結(jié)果為null時(shí)也寫入Redis過期時(shí)間設(shè)置為3分鐘。此外在接口入?yún)幼隽嘶A(chǔ)校驗(yàn)訂單號(hào)必須符合日期數(shù)字的格式規(guī)范不合法直接拒絕。5.3 本地Docker Desktop部署與容器化項(xiàng)目完成后部署到服務(wù)器前我在本地先用Docker Desktop跑了一遍全流程。這里說一個(gè)自己在實(shí)踐中摸索出的經(jīng)驗(yàn)SpringBoot項(xiàng)目用JDK 1.8打包成Docker鏡像時(shí)基礎(chǔ)的openjdk:8鏡像體積偏大建議直接用帶Alpine版本的。Dockerfile我寫成了多階段構(gòu)建先Maven打包再拷貝到運(yùn)行鏡像整個(gè)鏡像控制在250MB以內(nèi)。# 構(gòu)建階段 FROM maven:3.8-openjdk-8 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn package -DskipTests # 運(yùn)行階段 FROM openjdk:8-jre-alpine WORKDIR /app COPY --frombuilder /app/target/logistics-system.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar, --spring.profiles.activeprod]MySQL和Redis同樣用Docker容器運(yùn)行我專門寫了一個(gè)docker-compose.yml把三個(gè)服務(wù)編排在一起。data目錄掛載到宿主機(jī)保證容器重啟數(shù)據(jù)庫不丟這點(diǎn)非常關(guān)鍵——我有一次圖省事沒掛載Docker一更新整個(gè)庫都沒了教訓(xùn)深刻。上線前再檢查一遍環(huán)境和數(shù)據(jù)卷掛載測(cè)試環(huán)境跑幾天確保穩(wěn)定后切生產(chǎn)。5.4 配置文件管理與多環(huán)境切換項(xiàng)目從開發(fā)到測(cè)試再到生產(chǎn)三套環(huán)境的配置肯定不一樣。我用的方案是SpringBoot的Profile多環(huán)境配置application.yml里只放公共配置application-dev.yml、application-test.yml、application-prod.yml分別存放各自環(huán)境的數(shù)據(jù)庫地址、Redis地址、日志級(jí)別等。啟動(dòng)時(shí)通過--spring.profiles.active參數(shù)指定跑哪套配置。數(shù)據(jù)庫密碼這類敏感信息我沒有明文寫在配置文件里用了Jasypt做加密。配置項(xiàng)寫成ENC(加密串)的形式應(yīng)用啟動(dòng)時(shí)自動(dòng)解密。這樣即使配置文件泄露了別人也拿不到明文密碼。Jasypt集成SpringBoot很簡(jiǎn)單加依賴、改配置、用工具類加密原始密碼三步搞定。6. 踩坑記錄與開發(fā)工具推薦6.1 常見問題速查表與解決思路開發(fā)過程中我整理了一份問題排查清單都是自己碰到過且有明確解決辦法的。最典型的是循環(huán)依賴問題訂單服務(wù)和快遞員服務(wù)互相調(diào)用導(dǎo)致啟動(dòng)直接報(bào)錯(cuò)。解決辦法不是加Lazy注解糊弄過去而是從設(shè)計(jì)層面把公共邏輯抽出來放到獨(dú)立的Service里打破依賴環(huán)。問題現(xiàn)象根本原因解決方案訂單狀態(tài)更新丟失并發(fā)更新未加版本號(hào)或狀態(tài)條件UPDATE使用WHERE status預(yù)期值金額對(duì)賬不平double計(jì)算精度丟失全部改成BigDecimal計(jì)算緩存穿透導(dǎo)致DB壓力大查詢不存在的數(shù)據(jù)反復(fù)打庫空值緩存 入?yún)⑿ｒ?yàn)事務(wù)未回滾異常被catch后未拋出事務(wù)方法內(nèi)不吞異常rollbackForException跨域請(qǐng)求被攔截前后端分離未配跨域?qū)崿F(xiàn)WebMvcConfigurer配置CorsMapping6.2 我常用的幾個(gè)效率提升工具說實(shí)話做這類管理系統(tǒng)真正拉開效率差距的是工具鏈的熟練度。SpringBoot項(xiàng)目里L(fēng)ombok幾乎是我必裝的Data注解直接省掉所有g(shù)etter/setter代碼量瞬間少一半。MapStruct做屬性拷貝比BeanUtils性能好很多編譯期就生成轉(zhuǎn)換代碼不會(huì)像反射那樣在頻繁調(diào)用時(shí)損耗性能。接口調(diào)試用Apifox對(duì)比Swagger和Postman它的優(yōu)勢(shì)是直接把接口文檔、調(diào)試、Mock數(shù)據(jù)整合在一個(gè)工具里方便前端快速聯(lián)調(diào)。還有一個(gè)非常實(shí)用的小工具是Spring官方提供的Spring Initializr創(chuàng)建項(xiàng)目時(shí)勾選依賴就自動(dòng)生成完整骨架比在開發(fā)工具里新建省事很多。數(shù)據(jù)庫層面配合MySQL Workbench做表結(jié)構(gòu)版本管理加上Flyway做數(shù)據(jù)庫遷移表結(jié)構(gòu)變更不再直接在生產(chǎn)庫上手工執(zhí)行SQL。這樣每次發(fā)版數(shù)據(jù)庫變更腳本和應(yīng)用代碼一起走版本控制基本杜絕了環(huán)境之間表結(jié)構(gòu)不一致的尷尬場(chǎng)面。6.3 application.yml 不自動(dòng)提示的解決辦法開發(fā)過程中不少同事遇到過IDEA里寫application.yml沒有自動(dòng)提示的問題第一次遇到其實(shí)很困惑。原因是IDEA無法識(shí)別這個(gè)文件對(duì)應(yīng)的配置元數(shù)據(jù)解決方法是手動(dòng)把a(bǔ)pplication.yml標(biāo)記為Spring配置文件右鍵文件 → 點(diǎn)擊“Add as Spring Boot Configuration File”之后寫配置項(xiàng)就會(huì)有自動(dòng)提示了。另外如果引入了自定義starter但I(xiàn)DEA里就是不提示自定義配置項(xiàng)需要依賴spring-boot-configuration-processor這個(gè)注解處理器來自動(dòng)生成配置元數(shù)據(jù)。在pom.xml引入該依賴后重新編譯項(xiàng)目IDEA就能識(shí)別所有配置項(xiàng)。沒加之前很多配置只能靠手寫非常容易拼錯(cuò)加上后效率翻倍。7. 項(xiàng)目測(cè)試與系統(tǒng)部署7.1 單元測(cè)試與接口自動(dòng)化測(cè)試管理系統(tǒng)最容易忽視質(zhì)量保障但我堅(jiān)持把核心計(jì)算和狀態(tài)流轉(zhuǎn)的邏輯用單元測(cè)試覆蓋起來。比如運(yùn)費(fèi)計(jì)算器我寫了六個(gè)測(cè)試用例覆蓋首重內(nèi)、超首重、偏遠(yuǎn)地區(qū)、重量為零、超重邊界、極端大重量六個(gè)場(chǎng)景保證每次修改價(jià)格策略后回歸測(cè)試一鍵執(zhí)行。Test void testCalculateOverFirstWeight() { FreightRule rule new FreightRule(); rule.setFirstPrice(new BigDecimal(10.00)); rule.setAdditionalPrice(new BigDecimal(2.00)); rule.setIsRemote(false); rule.setRemoteFee(BigDecimal.ZERO); BigDecimal freight FreightCalculator.calculate(new BigDecimal(2.1), rule); // 2.1kg按3kg算運(yùn)費(fèi)102*214 Assertions.assertEquals(0, freight.compareTo(new BigDecimal(14.00))); }接口自動(dòng)化測(cè)試方面我用了RestAssured配合JUnit5寫了一套冒煙測(cè)試腳本覆蓋登錄、下單、接單、軌跡查詢、后臺(tái)統(tǒng)計(jì)五個(gè)核心鏈路。每次構(gòu)建后自動(dòng)跑一遍接口掛了會(huì)第一時(shí)間發(fā)現(xiàn)不用等到上線被用戶投訴才知道。7.2 部署流程與上線檢查清單最終部署我整理了一份操作清單每次發(fā)布前都過一遍打新包前先跑一遍所有單元測(cè)試確認(rèn)核心邏輯沒被改掛備份生產(chǎn)數(shù)據(jù)庫防止發(fā)布過程中數(shù)據(jù)操作失誤關(guān)閉舊服務(wù)再啟動(dòng)新包避免版本不一致導(dǎo)致數(shù)據(jù)庫連接異常啟動(dòng)后立刻檢查日志有沒有報(bào)錯(cuò)堆棧再跑一遍核心接口冒煙測(cè)試。系統(tǒng)上線后第一周我持續(xù)觀察了日志和慢查詢記錄沒出現(xiàn)致命問題后整個(gè)項(xiàng)目才算真正交付完成。之后我結(jié)合用戶反饋又迭代了幾個(gè)小功能用戶地址簿增加地圖選點(diǎn)、快遞員端增加批量攬收、后臺(tái)報(bào)表支持導(dǎo)出Excel。管理系統(tǒng)就是這樣核心框架搭扎實(shí)了后續(xù)想加什么功能都能快速實(shí)現(xiàn)。8. 項(xiàng)目復(fù)盤與個(gè)人心得如果要給這個(gè)物流寄件系統(tǒng)做一個(gè)復(fù)盤總結(jié)我最深的體會(huì)是SpringBoot這類框架再強(qiáng)大也只是解決了技術(shù)層面的問題而系統(tǒng)設(shè)計(jì)真正的難點(diǎn)在于業(yè)務(wù)流程的梳理和邊界條件的考慮。做這個(gè)系統(tǒng)的過程中我花在理解物流業(yè)務(wù)上的時(shí)間遠(yuǎn)多于寫代碼的時(shí)間。第二個(gè)心得是不要追求一步到位先做出來再用起來再優(yōu)化。第一版系統(tǒng)我只實(shí)現(xiàn)了基礎(chǔ)的下單、接單、狀態(tài)流轉(zhuǎn)和管理后臺(tái)上線跑了兩周后結(jié)合真實(shí)使用場(chǎng)景才逐步加入運(yùn)費(fèi)規(guī)則配置、異常訂單處理、數(shù)據(jù)看板這些進(jìn)階功能。如果一開始就想著把所有功能全部做完再交付周期會(huì)拉得很長容易遙遙無期。最后分享一個(gè)小經(jīng)驗(yàn)寫這類系統(tǒng)的過程中數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計(jì)千萬別圖省事把大量信息堆在一張大表里。適度拆分表、增加冗余字段、預(yù)留擴(kuò)展位雖然前期多花一點(diǎn)時(shí)間但后期維護(hù)起來會(huì)輕松非常多。比如訂單表的擴(kuò)展字段我預(yù)留了一個(gè)json類型的extra列后續(xù)接第三方快遞接口時(shí)很多自定義屬性直接往里塞就行不用頻繁改表結(jié)構(gòu)。這個(gè)“小設(shè)計(jì)”幫我在后期的需求變更里省了不少事。