我最近剛把一套企業(yè)級(jí)商城系統(tǒng)的源碼從頭到尾梳理完技術(shù)棧正好就是標(biāo)題里那套SpringBoot Vue MyBatis MySQL。項(xiàng)目代號(hào)叫“米家商城”配套的運(yùn)營(yíng)后臺(tái)我們內(nèi)部叫“ABO”全稱是 Admin-Back-office-Operations就是給運(yùn)營(yíng)、客服、倉(cāng)儲(chǔ)人員用的管理操作平臺(tái)。如果你正準(zhǔn)備做類似的全棧電商項(xiàng)目或者只是想把前后端分離的這套組合吃透那么這篇東西應(yīng)該能幫你少踩幾天的坑。我盡量不寫教科書式的廢話直接講項(xiàng)目里真實(shí)遇到的設(shè)計(jì)決策、代碼思路和上線前必須留意的細(xì)節(jié)。先說(shuō)結(jié)論這個(gè)組合放在今天依然是非常穩(wěn)妥的工業(yè)化選擇。SpringBoot負(fù)責(zé)快速封裝業(yè)務(wù)接口Vue負(fù)責(zé)前端交互和工程化MyBatis把SQL操作權(quán)完全還給開發(fā)人員MySQL則穩(wěn)扎穩(wěn)打地扛住核心業(yè)務(wù)數(shù)據(jù)。別看網(wǎng)上天天吹微服務(wù)、吹云原生對(duì)于絕大多數(shù)年交易額在千萬(wàn)級(jí)別的商城項(xiàng)目來(lái)說(shuō)這套架構(gòu)的性價(jià)比其實(shí)是最高的。原因很簡(jiǎn)單團(tuán)隊(duì)招聘成本低、排錯(cuò)鏈路短、部署運(yùn)維也輕。下面我按整個(gè)項(xiàng)目的落地順序把關(guān)鍵設(shè)計(jì)一步步拆開講。1. 一個(gè)真實(shí)電商項(xiàng)目的技術(shù)選型與設(shè)計(jì)取舍1.1 項(xiàng)目為什么鎖定這四件套立項(xiàng)之初我們也討論過(guò)用不用Spring Cloud、要不要上MongoDB之類的選項(xiàng)。最后拍板用SpringBootVueMyBatisMySQL不是因?yàn)楸Ｊ囟腔谌齻€(gè)硬指標(biāo)團(tuán)隊(duì)熟悉度、交付周期、運(yùn)維成本。項(xiàng)目團(tuán)隊(duì)一共六個(gè)人后端三個(gè)、前端兩個(gè)、測(cè)試一個(gè)。后端里真正精通Spring Cloud整套組件的其實(shí)只有一個(gè)如果強(qiáng)行上微服務(wù)光搭基礎(chǔ)設(shè)施就要拉長(zhǎng)兩周。而SpringBoot可以在一天之內(nèi)把骨架工程跑起來(lái)加上它內(nèi)置的Tomcat和自動(dòng)配置能讓團(tuán)隊(duì)集中精力寫業(yè)務(wù)而不是調(diào)框架。前端用Vue也是一樣的邏輯大家熟組件生態(tài)全招聘市場(chǎng)上也容易補(bǔ)人。MyBatis和MySQL的搭配則更多是從SQL可控性考慮的。商城類業(yè)務(wù)有很多復(fù)雜的多表關(guān)聯(lián)查詢比如“根據(jù)規(guī)格參數(shù)篩選SKU”、“查詢訂單時(shí)帶上商品快照和物流信息”這些用JPA/Hibernate寫起來(lái)非常別扭最后還得補(bǔ)原生SQL。MyBatis允許我們直接維護(hù)SQL同時(shí)用動(dòng)態(tài)SQL處理不確定的查詢條件剛好命中電商場(chǎng)景。MySQL則讓數(shù)據(jù)庫(kù)容量和熟練度都處在舒適區(qū)先用主從緩存頂住壓力真到了海量數(shù)據(jù)再考慮分庫(kù)也不遲。1.2 商城核心鏈路與ABO管理系統(tǒng)的定位整個(gè)米家商城分兩個(gè)端用戶端商城和ABO后臺(tái)管理系統(tǒng)。用戶端的核心鏈路很常規(guī)瀏覽商品 - 加購(gòu)物車 - 下單 - 支付 - 發(fā)貨 - 確認(rèn)收貨。ABO這邊的核心鏈路則圍繞運(yùn)營(yíng)動(dòng)作展開商品上下架、價(jià)格調(diào)整、庫(kù)存同步、訂單改價(jià)、退款審核、物流單號(hào)回填等。我特別想強(qiáng)調(diào)ABO系統(tǒng)的定位因?yàn)樗?jīng)常被當(dāng)作普通CRUD后臺(tái)來(lái)做結(jié)果上線后運(yùn)營(yíng)抱怨一堆。ABO的核心不是“能管理數(shù)據(jù)”而是“能高效、安全地完成業(yè)務(wù)操作”。比如客服在ABO里給用戶退款系統(tǒng)需要同時(shí)完成訂單狀態(tài)變更、支付渠道退款請(qǐng)求、庫(kù)存回滾、操作日志記錄四個(gè)動(dòng)作。如果只做了數(shù)據(jù)庫(kù)字段更新那就會(huì)出現(xiàn)訂單顯示已退款但用戶沒收到錢的問(wèn)題。所以ABO在設(shè)計(jì)上必須和商城共用同一套Service層不能簡(jiǎn)單復(fù)制一份Mapper去讀寫訂單表。2. 米家商城業(yè)務(wù)域拆分從商品到訂單的狀態(tài)流轉(zhuǎn)設(shè)計(jì)2.1 商品與庫(kù)存模型SKU/SPU的落地商城第一個(gè)要建模的是商品域。我們采用了SPUStandard Product Unit標(biāo)準(zhǔn)產(chǎn)品單元和SKUStock Keeping Unit庫(kù)存量單位兩層模型。SPU是商品的概念層比如“米家臺(tái)燈1S”SKU是具體可下單的規(guī)格層比如“白色插電版”庫(kù)存和價(jià)格都掛在SKU上。這個(gè)模型本身不新鮮但落地時(shí)有幾個(gè)坑要提前處理。第一是規(guī)格屬性的JSON存儲(chǔ)問(wèn)題我見過(guò)有人把規(guī)格拆成十幾個(gè)字段結(jié)果每次加規(guī)格都要改表。我們采用的是規(guī)格名稱為鍵、規(guī)格值為值的JSON字符串存儲(chǔ)MySQL的json類型直接支持索引和查詢前端渲染時(shí)直接解析兼容性很好。第二是商品詳情的多端聯(lián)動(dòng)詳情頁(yè)由富文本、圖片輪播、視頻地址、參數(shù)表格組成我建議單獨(dú)建一張商品詳情表和SPU一對(duì)一關(guān)聯(lián)避免在SPU表里塞大字段。庫(kù)存數(shù)據(jù)我分了兩個(gè)維度SKU可用庫(kù)存和SKU鎖定庫(kù)存。可用庫(kù)存是真正能賣的鎖定庫(kù)存是下單但未支付時(shí)的暫扣。這樣設(shè)計(jì)方便處理“超賣”問(wèn)題后面會(huì)講到具體的扣減邏輯。2.2 訂單與支付流程的狀態(tài)機(jī)設(shè)計(jì)訂單狀態(tài)是最容易寫崩的部分。我們定義了如下狀態(tài)集待支付、待發(fā)貨、待收貨、已完成、已關(guān)閉、售后中。所有狀態(tài)變更都必須經(jīng)過(guò)一個(gè)獨(dú)立的訂單狀態(tài)機(jī)類不允許在Mapper層隨便改狀態(tài)字段。下面這張表格展示了核心狀態(tài)流轉(zhuǎn)路徑當(dāng)前狀態(tài)觸發(fā)動(dòng)作下一狀態(tài)涉及系統(tǒng)待支付用戶付款待發(fā)貨支付回調(diào)、訂單服務(wù)待支付超時(shí)未付已關(guān)閉定時(shí)任務(wù)、庫(kù)存服務(wù)待發(fā)貨商家發(fā)貨待收貨物流服務(wù)、訂單服務(wù)待收貨用戶確認(rèn)收貨已完成訂單服務(wù)待收貨超時(shí)自動(dòng)確認(rèn)已完成定時(shí)任務(wù)已完成用戶申請(qǐng)售后售后中售后工單、支付渠道狀態(tài)機(jī)的好處是讓流轉(zhuǎn)路徑清晰可控每個(gè)動(dòng)作后面都可以加鉤子函數(shù)。比如從“待支付”到“待發(fā)貨”鉤子函數(shù)里要先解鎖庫(kù)存并扣減可用庫(kù)存再生成履約單推給倉(cāng)儲(chǔ)系統(tǒng)。如果先改狀態(tài)再扣庫(kù)存一旦扣失敗訂單就卡在狀態(tài)錯(cuò)亂里了。我們?cè)诖a里把狀態(tài)變更和庫(kù)存操作放在同一個(gè)事務(wù)里后面事務(wù)部分會(huì)細(xì)講。2.3 多級(jí)分銷與會(huì)員價(jià)本次實(shí)現(xiàn)中的業(yè)務(wù)擴(kuò)展點(diǎn)米家商城這個(gè)項(xiàng)目里還接了一個(gè)分銷需求用戶A推薦用戶B下單A能拿到一定比例的傭金。這個(gè)邏輯并不復(fù)雜但要注意兩點(diǎn)。第一推薦關(guān)系表里要記錄“上下線關(guān)系生效時(shí)間”避免歷史訂單的傭金計(jì)算混亂。第二傭金結(jié)算做成異步任務(wù)用戶確認(rèn)收貨后再觸發(fā)避免在主訂單事務(wù)里做太多計(jì)算。會(huì)員價(jià)則是在SKU價(jià)格之外再加一檔“會(huì)員售價(jià)”。我們把價(jià)格放在單獨(dú)的price表中包含SKU_ID、價(jià)格類型普通/會(huì)員/活動(dòng)、價(jià)格值、生效時(shí)間。這樣比直接在SKU上加會(huì)員價(jià)字段靈活得多雙十一時(shí)可以增加“活動(dòng)價(jià)”類型而不改表結(jié)構(gòu)。3. MySQL數(shù)據(jù)庫(kù)設(shè)計(jì)核心表結(jié)構(gòu)、索引與分庫(kù)分表思路3.1 商品、訂單、用戶核心表結(jié)構(gòu)詳解數(shù)據(jù)庫(kù)是整套商城的心臟我給出幾個(gè)核心表的關(guān)鍵字段設(shè)計(jì)方便你直接參考。商品表spuid主鍵spu_codeSPU編碼唯一索引title標(biāo)題cover_url主圖detail_id關(guān)聯(lián)詳情表status上下架狀態(tài)created_time / updated_time時(shí)間戳SKU表skuidspu_id關(guān)聯(lián)SPUsku_codeSKU編碼唯一索引specs規(guī)格JSON比如 {顏色:白色,版本:插電版}可用庫(kù)存、鎖定庫(kù)存用int非負(fù)數(shù)price_id關(guān)聯(lián)價(jià)格表status訂單表ordersidorder_sn訂單號(hào)唯一索引用全局ID生成器user_id下單用戶spu_id、sku_id下單時(shí)的核心信息sku_snapshot下單時(shí)的SKU快照J(rèn)SON防止后續(xù)修改影響歷史quantity數(shù)量order_status狀態(tài)字段total_amount / pay_amount金額用decimal(10,2)receiver_info收貨人JSONcreated_time用戶表t_useridphone手機(jī)號(hào)唯一索引nicknameinvite_code邀請(qǐng)碼parent_id上級(jí)推薦人ABO后臺(tái)表后臺(tái)員工、角色、權(quán)限、操作日志sys_user后臺(tái)賬號(hào)密碼用BCrypt存儲(chǔ)sys_role角色sys_menu菜單/按鈕權(quán)限sys_operation_log操作日志3.2 索引策略從慢查詢?nèi)罩痉赐扑饕O(shè)計(jì)索引不是建得越多越好而是要從實(shí)際查詢路徑出發(fā)。上線第一周我們開了MySQL慢查詢?nèi)罩鹃撝翟O(shè)置為1秒然后收集了一天里最慢的20條SQL。結(jié)果發(fā)現(xiàn)兩類查詢最危險(xiǎn)一是按用戶ID查詢訂單列表時(shí)如果只建了user_id普通索引ORDER BY created_time會(huì)讓文件排序非常慢二是后臺(tái)運(yùn)營(yíng)按訂單號(hào)模糊查詢時(shí)用了LIKE %xxx%直接導(dǎo)致全表掃描。對(duì)第一個(gè)問(wèn)題建議建聯(lián)合索引user_id, created_time可以同時(shí)滿足WHERE和ORDER BY。對(duì)第二個(gè)問(wèn)題我們的方案是讓運(yùn)營(yíng)盡可能使用完整訂單號(hào)并給order_sn建唯一索引如果實(shí)在要模糊搜就單獨(dú)建一張訂單搜索輔助表用Elasticsearch或簡(jiǎn)單的關(guān)鍵字表來(lái)兜底避免在核心訂單表上跑模糊查詢。另外一個(gè)容易被忽視的點(diǎn)是索引列上的函數(shù)操作比如WHERE DATE_FORMAT(created_time, %Y-%m-%d) 2025-01-01這種寫法讓索引直接失效。正確做法是查詢范圍created_time 2025-01-01 00:00:00 AND created_time 2025-01-02 00:00:00。3.3 數(shù)據(jù)量增長(zhǎng)后的問(wèn)題分庫(kù)分表與讀寫分離預(yù)留雖然單庫(kù)單表能撐一陣子但我們要提前預(yù)留擴(kuò)展點(diǎn)。我的建議是訂單表按照user_id哈希分成256張子表分表鍵用user_id這樣可以保證同一個(gè)用戶的訂單都在同一個(gè)表里方便分頁(yè)查詢。商品表數(shù)據(jù)量相對(duì)小可以先做讀寫分離不急著分表。讀寫分離的話我們?cè)赟pringBoot里配置了動(dòng)態(tài)數(shù)據(jù)源利用DataSource注解把只讀方法路由到從庫(kù)。注意要點(diǎn)事務(wù)必須是只讀的才能走從庫(kù)否則主從延遲會(huì)帶來(lái)臟讀。我們實(shí)際遇到過(guò)一次問(wèn)題用戶支付成功后跳轉(zhuǎn)訂單詳情結(jié)果讀從庫(kù)延遲頁(yè)面顯示“待支付”把用戶嚇一跳。后來(lái)做了“支付成功后強(qiáng)制主庫(kù)讀”的標(biāo)記才解決。4. SpringBoot MyBatis 落地細(xì)節(jié)Mapper、事務(wù)與緩存4.1 XML與注解的選擇為什么推薦XML管理復(fù)雜SQL我接手項(xiàng)目后把團(tuán)隊(duì)里的規(guī)則統(tǒng)一了簡(jiǎn)單CRUD用MyBatis注解復(fù)雜聯(lián)動(dòng)查詢一律使用XML Mapper。原因是XML可以顯式地管理SQL并且支持動(dòng)態(tài)SQL的標(biāo)簽比如 、 、 。當(dāng)查詢條件超過(guò)三個(gè)時(shí)注解方式會(huì)變得極其難以閱讀而XML配合縮進(jìn)和注釋代碼評(píng)審時(shí)可以非常清晰地看到SQL全貌。舉一個(gè)我們經(jīng)常用的動(dòng)態(tài)更新案例ABO后臺(tái)編輯商品時(shí)只更新非空字段update idupdateSkuSelective parameterTypemap UPDATE sku set if testprice ! nullprice_id #{price},/if if teststatus ! nullstatus #{status},/if if testspecs ! nullspecs #{specs},/if updated_time NOW() /set WHERE id #{id} /update這是把“部分字段更新”的控制權(quán)全部拉到SQL層避免了寫一堆Java if判斷來(lái)拼接Update對(duì)象。4.2 事務(wù)邊界下單場(chǎng)景的分布式事務(wù)隱患下單接口是最典型的需要精確定義事務(wù)邊界的地方。簡(jiǎn)化版代碼如下Transactional(rollbackFor Exception.class) public OrderResult createOrder(CreateOrderDTO dto) { // 1. 鎖定庫(kù)存 int updated skuStockMapper.lockStock(dto.getSkuId(), dto.getQuantity()); if (updated 0) { throw new BizException(庫(kù)存不足); } // 2. 創(chuàng)建訂單 Order order buildOrder(dto); orderMapper.insert(order); // 3. 清空購(gòu)物車 cartMapper.deleteByUserAndSku(dto.getUserId(), dto.getSkuId()); return success(order); }這里每個(gè)步驟都依賴同一個(gè)數(shù)據(jù)庫(kù)連接事務(wù)所以從理論上講中間出現(xiàn)異常都能回滾庫(kù)存和訂單不會(huì)不一致。但要注意兩個(gè)隱藏風(fēng)險(xiǎn)第一lockStock方法里的SQL是UPDATE sku SET locked_stock locked_stock #{quantity}, available_stock available_stock - #{quantity} WHERE id #{skuId} AND available_stock #{quantity}。這行SQL本身在MySQL的InnoDB引擎下會(huì)鎖住那一行SKU記錄。如果同一時(shí)間很多用戶搶購(gòu)?fù)籗KU后續(xù)請(qǐng)求都會(huì)阻塞在這把行鎖上造成吞吐量下降。我們的應(yīng)對(duì)方式是在高并發(fā)場(chǎng)景下改成Redis預(yù)扣庫(kù)存異步扣減數(shù)據(jù)庫(kù)庫(kù)存或者使用樂(lè)觀鎖加版本號(hào)重試。第二事務(wù)里盡量不要做遠(yuǎn)程調(diào)用比如下單成功后再調(diào)用第三方支付接口這會(huì)拖長(zhǎng)數(shù)據(jù)庫(kù)事務(wù)讓連接池迅速耗盡。我們?cè)陧?xiàng)目里把支付動(dòng)作放在訂單創(chuàng)建成功之后不在同一個(gè)事務(wù)里訂單狀態(tài)先置為“待支付”然后去調(diào)支付網(wǎng)關(guān)。即使支付網(wǎng)關(guān)超時(shí)也能通過(guò)定時(shí)任務(wù)去對(duì)賬保證最終一致。4.3 MyBatis緩存機(jī)制與一次緩存失效問(wèn)題的追查MyBatis的二級(jí)緩存我們一開始沒打算用但為了提升熱點(diǎn)SKU的查詢性能給商品模塊開了二級(jí)緩存。結(jié)果上線后出現(xiàn)一個(gè)詭異的Bug后臺(tái)運(yùn)營(yíng)改了某個(gè)商品的標(biāo)題前臺(tái)頁(yè)面過(guò)了一個(gè)小時(shí)還是舊標(biāo)題。排查鏈路是這樣走的先懷疑是瀏覽器緩存清掉后仍然復(fù)現(xiàn)然后看Vue端是否有狀態(tài)緩存也沒有最后查MyBatis的二級(jí)緩存發(fā)現(xiàn)默認(rèn)的PerpetualCache是進(jìn)程內(nèi)本地緩存后臺(tái)管理系統(tǒng)和商城服務(wù)是同一個(gè)SpringBoot進(jìn)程理論上應(yīng)該能更新。問(wèn)題出在我們的緩存命名空間設(shè)置商品查詢Mapper的namespace是com.xxx.mapper.SpuMapper但后臺(tái)更新商品時(shí)更新的是SpuDetailMapper兩個(gè)Mapper各自的緩存沒有聯(lián)動(dòng)導(dǎo)致SpuMapper的二級(jí)緩存里還是一小時(shí)前的舊數(shù)據(jù)。最后方案很簡(jiǎn)單要么關(guān)閉商品查詢的二級(jí)緩存要么在更新時(shí)手動(dòng)調(diào)用清空相關(guān)緩存。我們最終選擇了用Spring Cache注解 Redis緩存來(lái)做統(tǒng)一緩存管理因?yàn)镸yBatis的二級(jí)緩存跟Transactional結(jié)合時(shí)如果有多數(shù)據(jù)源還容易出現(xiàn)臟數(shù)據(jù)不如緩存統(tǒng)一走Redis可控。5. Vue前端工程化動(dòng)態(tài)路由、狀態(tài)管理與移動(dòng)端適配5.1 基于Vue Router的動(dòng)態(tài)路由與權(quán)限控制用戶端商城的前端相對(duì)簡(jiǎn)單ABO管理系統(tǒng)倒是花了不少心思。ABO要求不同角色的登錄用戶看到不同的菜單甚至同一菜單下按鈕的可見性也由權(quán)限控制。我們采用動(dòng)態(tài)路由方案用戶登錄后后端返回當(dāng)前角色能訪問(wèn)的路由配置前端用router.addRoute動(dòng)態(tài)掛載。具體流程是用戶輸入賬號(hào)密碼登錄成功后拿到token請(qǐng)求 /sys/user/permissions 接口返回菜單樹和按鈕權(quán)限標(biāo)識(shí)前端把菜單樹遞歸轉(zhuǎn)換成Vue Router的RouteRecordRaw數(shù)組通過(guò)router.addRoute注冊(cè)側(cè)邊欄渲染時(shí)也基于同一份菜單樹保證路由和菜單一致。這里一定要提防一個(gè)問(wèn)題動(dòng)態(tài)路由只在全局前置守衛(wèi)里判斷了一次如果用戶刷新頁(yè)面Vue Router的緩存會(huì)被清空必須重新拉取權(quán)限。我們當(dāng)時(shí)的做法是在main.js初始化時(shí)檢查本地是否已有token并有用戶信息如果沒有完整路由就重新走一遍動(dòng)態(tài)添加邏輯。否則就會(huì)出現(xiàn)“登錄后能訪問(wèn)一刷新就白屏”的經(jīng)典坑。5.2 狀態(tài)管理Vuex與Pinia的取舍商城這個(gè)項(xiàng)目啟動(dòng)時(shí)我們還用的是Vue2所以狀態(tài)管理用的Vuex。如果你是Vue3新項(xiàng)目我建議直接用Pinia更簡(jiǎn)潔且天然支持組合式API。不過(guò)這里的核心不是選哪個(gè)而是明確哪些狀態(tài)需要放到全局Store哪些不需要。我把購(gòu)物車、用戶信息、當(dāng)前訂單的支付倒計(jì)時(shí)放到了全局Store。商品列表頁(yè)的篩選條件、詳情頁(yè)的當(dāng)前SKU規(guī)格選擇等盡量不要放全局否則切換頁(yè)面時(shí)狀態(tài)殘留會(huì)導(dǎo)致各種莫名其妙的問(wèn)題。有一個(gè)典型例子用戶從商品詳情頁(yè)選好規(guī)格加入購(gòu)物車成功后跳轉(zhuǎn)購(gòu)物車頁(yè)面購(gòu)物車頁(yè)面讀取到了上一個(gè)頁(yè)面殘留的規(guī)格狀態(tài)導(dǎo)致展示異常。后來(lái)我們?cè)黾恿藸顟B(tài)重置邏輯進(jìn)入頁(yè)面時(shí)主動(dòng)清空非必要緩存。5.3 組件庫(kù)選型與移動(dòng)端適配實(shí)戰(zhàn)用戶端商城的移動(dòng)端我們選擇了uni-app一套代碼同時(shí)覆蓋H5和小程序。ABO管理系統(tǒng)則使用桌面端組件庫(kù)Element UI配合Vue2的生態(tài)非常成熟。兩個(gè)端分開維護(hù)避免在同一個(gè)工程里混用組件庫(kù)導(dǎo)致包體積失控。移動(dòng)端適配方面我建議規(guī)范使用viewport單位配合rem方案。我們的基準(zhǔn)是設(shè)計(jì)稿750px寬根字號(hào)設(shè)置37.5px組件庫(kù)內(nèi)部自帶響應(yīng)式則直接用百分比。有一個(gè)實(shí)際經(jīng)驗(yàn)圖片列表使用懶加載但懶加載組件在低端Android機(jī)上容易出現(xiàn)閃爍后來(lái)我們把圖片區(qū)域的高度提前用占位比例鎖定寬度以容器為準(zhǔn)解決了滾動(dòng)時(shí)的高度跳動(dòng)問(wèn)題。這類細(xì)節(jié)對(duì)商城首屏體驗(yàn)影響很大值得多花時(shí)間打磨。6. ABO管理系統(tǒng)權(quán)限模型、操作審計(jì)與低代碼思路6.1 ABO系統(tǒng)的整體功能結(jié)構(gòu)ABO覆蓋的功能包括商品管理、訂單管理、用戶管理、營(yíng)銷管理、財(cái)務(wù)結(jié)算、系統(tǒng)設(shè)置、操作日志。每個(gè)模塊在導(dǎo)航上都有對(duì)應(yīng)的菜單子頁(yè)面則承載各類明細(xì)操作。我用一張表格列出主要模塊和核心交互模塊核心交互商品管理商品上下架、SKU編輯、審核、批量改價(jià)訂單管理訂單查詢、發(fā)貨、改價(jià)、關(guān)閉、備注用戶管理用戶列表、等級(jí)設(shè)置、邀請(qǐng)關(guān)系查看營(yíng)銷管理優(yōu)惠券創(chuàng)建、活動(dòng)配置、分銷傭金設(shè)置財(cái)務(wù)結(jié)算訂單對(duì)賬、退款審核、數(shù)據(jù)報(bào)表系統(tǒng)設(shè)置管理員維護(hù)、角色權(quán)限、數(shù)據(jù)字典ABO的頁(yè)面請(qǐng)求頻率不高但對(duì)數(shù)據(jù)一致性要求極高所以前端在提交操作時(shí)要有確認(rèn)提示后端則需要對(duì)每個(gè)寫操作做冪等校驗(yàn)。6.2 基于RBAC的權(quán)限模型擴(kuò)展數(shù)據(jù)權(quán)限與操作日志權(quán)限模型我們采用經(jīng)典RBAC用戶-角色-權(quán)限。權(quán)限細(xì)化到按鈕級(jí)別比如“商品管理-編輯按鈕”就是一個(gè)權(quán)限碼。后端使用Spring Security的PreAuthorize注解做接口控制PreAuthorize(hasAuthority(product:edit)) PostMapping(/product/edit) public Result editProduct(RequestBody ProductEditDTO dto) { return productService.edit(dto); }但RBAC只解決了“能不能操作”的問(wèn)題沒解決“能操作哪些數(shù)據(jù)”的問(wèn)題。比如運(yùn)營(yíng)A只能管理自己負(fù)責(zé)的商品分類客服B只能查看自己創(chuàng)建的售后工單。我們擴(kuò)展了“數(shù)據(jù)權(quán)限”配置角色上增加數(shù)據(jù)范圍字段取值包括全部、本部門、本人。后端在查詢時(shí)自動(dòng)拼接SQL條件例如select idselectProductPage resultType... SELECT * FROM spu where if testdataScope SELF AND created_by #{userId} /if if testdataScope DEPT AND created_by IN (SELECT user_id FROM sys_user WHERE dept_id #{deptId}) /if /where /select操作日志是審計(jì)必需項(xiàng)。我們?cè)贏BO統(tǒng)一封裝了一個(gè)OperationLog注解在需要記錄的方法上標(biāo)注操作類型通過(guò)AOP自動(dòng)記錄操作人、操作時(shí)間、請(qǐng)求參數(shù)、響應(yīng)結(jié)果和IP地址。這個(gè)日志不能只寫成功記錄異常操作也要記錄否則運(yùn)營(yíng)誤操作后沒有證據(jù)扯皮都扯不清。6.3 用設(shè)計(jì)稿驅(qū)動(dòng)前端頁(yè)面后臺(tái)系統(tǒng)的標(biāo)準(zhǔn)化開發(fā)流程做ABO這類后臺(tái)系統(tǒng)最浪費(fèi)時(shí)間的不是寫代碼而是界面規(guī)范不統(tǒng)一。今天這個(gè)程序員給表格加了個(gè)“導(dǎo)出”按鈕明天那個(gè)程序員把彈窗按鈕放在左側(cè)運(yùn)營(yíng)用起來(lái)非常別扭。我們的做法是固定一套頁(yè)面模板列表頁(yè)統(tǒng)一左上方搜索區(qū)、右側(cè)表格、底部翻頁(yè)編輯頁(yè)統(tǒng)一彈出式Dialog或抽屜詳情頁(yè)統(tǒng)一只讀描述列表。前端寫了一批通用組件——SearchForm、DataTable、ModalForm、DetailDescriptions。新頁(yè)面通過(guò)配置這些組件的字段數(shù)組即可完成80%的開發(fā)量相當(dāng)于一個(gè)輕量的低代碼方案。這樣也帶來(lái)了一個(gè)好處新增菜單時(shí)后端只需提供對(duì)應(yīng)的CRUD接口前端復(fù)制一個(gè)現(xiàn)有頁(yè)面改改配置半小時(shí)就能上線一個(gè)新功能。運(yùn)營(yíng)和產(chǎn)品都非常喜歡這種效率。7. 上線前必做的壓測(cè)、安全加固與問(wèn)題排查7.1 壓測(cè)過(guò)程中發(fā)現(xiàn)的熱點(diǎn)行鎖問(wèn)題我們的下單接口在壓測(cè)到200并發(fā)時(shí)數(shù)據(jù)庫(kù)出現(xiàn)大量鎖等待。原因前面提過(guò)庫(kù)存扣減SQL鎖定同一行SKU記錄。當(dāng)時(shí)用JMeter壓測(cè)TPS卡在80左右thread dump里大量線程處于等待鎖狀態(tài)。解決思路有三個(gè)第一把“可用庫(kù)存”和“鎖定庫(kù)存”字段拆到單獨(dú)一張庫(kù)存流水表每次操作插入一條流水然后匯總計(jì)算剩余庫(kù)存這樣避免在同一行上反復(fù)update第二引入Redis預(yù)扣庫(kù)存用Lua腳本保證原子性數(shù)據(jù)庫(kù)庫(kù)存通過(guò)異步任務(wù)最終扣減第三熱門SKU切割庫(kù)存行比如一個(gè)SKU拆成10個(gè)子庫(kù)存記錄隨機(jī)選一個(gè)扣減減少行鎖競(jìng)爭(zhēng)。最終實(shí)戰(zhàn)我選了方案二因?yàn)閷?shí)現(xiàn)相對(duì)簡(jiǎn)單對(duì)業(yè)務(wù)代碼改動(dòng)小。Redis key設(shè)計(jì)為stock:{skuId}值就是可用庫(kù)存。下單時(shí)執(zhí)行Lua腳本if redis.call(get, KEYS[1]) - ARGV[1] 0 then return redis.call(decrby, KEYS[1], ARGV[1]) else return -1 end數(shù)據(jù)庫(kù)中則把庫(kù)存扣減放到異步任務(wù)里。壓測(cè)結(jié)果表明TPS從80提升到700以上效果明顯。7.2 安全加固參數(shù)校驗(yàn)、SQL注入與XSS的防護(hù)實(shí)踐電商系統(tǒng)比較容易成為攻擊目標(biāo)所以安全加固這塊我單獨(dú)提一下。第一所有對(duì)外接口要經(jīng)過(guò)參數(shù)校驗(yàn)框架使用javax.validation的NotNull、Size、Pattern等注解。最容易被忽視的是金額和數(shù)量字段必須限制范圍比如訂單數(shù)量不能超過(guò)99單價(jià)不能為負(fù)數(shù)。我們?cè)龅揭粋€(gè)測(cè)試小伙伴用負(fù)數(shù)的數(shù)量下單結(jié)果金額變成負(fù)數(shù)還好是測(cè)試環(huán)境不然就是事故。第二SQL注入。由于MyBatis的#{}會(huì)轉(zhuǎn)義參數(shù)所以大部分注入漏洞被天然堵住。但有一次開發(fā)圖方便把動(dòng)態(tài)排序字段直接拼接了Order By后面的部分這地方不能使用#{}如果不對(duì)字段做白名單校驗(yàn)就會(huì)產(chǎn)生注入風(fēng)險(xiǎn)。我的做法是維護(hù)一個(gè)排序字段白名單orderBy只能是allowedMap中的key否則強(qiáng)制使用默認(rèn)排序。第三XSS攻擊。后臺(tái)系統(tǒng)的輸入框比較多運(yùn)營(yíng)可能會(huì)直接粘貼一些包含腳本的內(nèi)容。我們使用全局過(guò)濾器對(duì)請(qǐng)求體中的字符串進(jìn)行HTML標(biāo)簽轉(zhuǎn)義存儲(chǔ)時(shí)保持轉(zhuǎn)義后的內(nèi)容展示時(shí)再通過(guò)富文本組件的安全配置過(guò)濾。需要注意如果富文本需要保留圖片和超鏈接不能簡(jiǎn)單全文轉(zhuǎn)義而是要按需配置白名單標(biāo)簽。7.3 一次內(nèi)存溢出排查從OOM到dump分析的思路上線后大概第三周ABO系統(tǒng)某天下午突然頻繁Full GC最后直接OutOfMemoryError。當(dāng)時(shí)我從表象判斷是導(dǎo)出功能引起的因?yàn)檫\(yùn)營(yíng)在使用“導(dǎo)出全部訂單”時(shí)系統(tǒng)會(huì)在內(nèi)存里把全部訂單列表一次性生成Excel數(shù)據(jù)量達(dá)到幾十萬(wàn)條時(shí)HashMap和List對(duì)象把堆撐爆了。這也是一個(gè)很典型的教訓(xùn)后臺(tái)列表的“導(dǎo)出”必須帶去異步化。壓縮回方案后我們把導(dǎo)出改成異步任務(wù)先生成CSV臨時(shí)文件再通過(guò)消息推送提示運(yùn)營(yíng)下載。對(duì)內(nèi)存里的查詢結(jié)果則必須做分頁(yè)循環(huán)去讀取而不是一次性List裝入內(nèi)存while (true) { ListOrder pageList orderMapper.selectPage(page, 1000); if (CollectionUtils.isEmpty(pageList)) break; appendToCsv(pageList, writer); page; }此外我們給JVM加了-Xmx4g并配置了HeapDumpOnOutOfMemoryError參數(shù)。出問(wèn)題時(shí)直接拿到dump文件用MAT分析出是org.apache.poi.xssf.usermodel.XSSFWorkbook占用了超過(guò)80%的空間這才定位到根因。排查內(nèi)存問(wèn)題就是這么枯燥先看參數(shù)再看dump最后對(duì)應(yīng)到代碼熱點(diǎn)。踩完這一圈坑整個(gè)項(xiàng)目的穩(wěn)定性才算真正立住了。最后再分享一點(diǎn)個(gè)人體會(huì)企業(yè)級(jí)商城項(xiàng)目最考驗(yàn)人的不是某個(gè)單一技術(shù)而是把所有技術(shù)串起來(lái)后的數(shù)據(jù)一致性和邊界梳理能力。SpringBoot、Vue、MyBatis、MySQL這套東西你大概率都認(rèn)識(shí)但真正把它們組合成一套能穩(wěn)定運(yùn)營(yíng)的系統(tǒng)需要大量“摳細(xì)節(jié)”的時(shí)刻。比如訂單狀態(tài)機(jī)的每一步校驗(yàn)、事務(wù)的邊界、SQL的索引、前端路由的權(quán)限控制每一個(gè)點(diǎn)都可能成為上線后的定時(shí)炸彈。希望這篇梳理能給你一些提前預(yù)判的參考少走幾段彎路。