做這個項目之前我在本地跑過不少零散的接口demo但真正動手把“蒼穹外賣”這套完整項目從頭到尾捋下來之后才感受到一個線上級業(yè)務系統(tǒng)涉及的東西遠不止CRUD那么簡單。這套外賣系統(tǒng)很像一個濃縮版的商業(yè)中臺用戶端小程序、商家端后臺、管理端控制臺外加一整套訂單流轉、購物車、支付回調、配送提醒、數(shù)據(jù)統(tǒng)計的鏈路。無論你是準備畢業(yè)設計、想寫進簡歷的練手項目還是想搞明白“一個真實業(yè)務系統(tǒng)怎么從零搭起來”這個項目都能給你很完整的參照系。主后端用的是Spring Boot持久層用了MyBatis也有一版是MyBatis Plus緩存交給Redis登錄鑒權走JWT前后端分離管理端用Vue構建。整個開發(fā)過程里最難的部分不是某個算法而是“多個模塊之間怎么把狀態(tài)同步好”——訂單狀態(tài)怎么變、庫存什么時候扣、超時單怎么處理、WebSocket怎么把配送狀態(tài)推給用戶。這篇文章我會把你需要關注的模塊設計、關鍵實現(xiàn)、部署細節(jié)以及我實際調試過程中踩過的坑全部拆開講盡量做到你照著往下走就能復現(xiàn)。1. 項目全貌與技術選型拆解1.1 為什么叫“蒼穹外賣”它在解決什么問題“蒼穹外賣”是一個典型的O2O外賣平臺項目名字本身是代號你可以把它理解成一套“小美外賣”或“某外賣系統(tǒng)”。它模擬真實外賣平臺的核心閉環(huán)用戶瀏覽菜品、加入購物車、下單支付模擬、商家接單、騎手配送、用戶確認收貨同時管理端還承擔分類管理、菜品管理、套餐管理、員工管理、訂單查詢和數(shù)據(jù)統(tǒng)計等功能。這個項目最大的價值在于覆蓋面廣它不是簡單的“增刪改查”而是把真實的業(yè)務狀態(tài)機、并發(fā)控制、緩存策略、權限模型都融入進來了。比如用戶端需要處理購物車勾選的一堆菜品下單時要同時考慮起送價、配送費、訂單總金額和結算明細商家端要能看到新訂單并執(zhí)行接單/拒單管理端要能按時間段查詢營業(yè)額和用戶下單趨勢。任何一個環(huán)節(jié)如果只寫表面接口都會在聯(lián)調時出問題。對于開發(fā)者來說它解決了“只會寫CRUD不知道業(yè)務怎么串聯(lián)”的痛點。你會真實地感受到一個訂單從創(chuàng)建到完成需要哪些表需要哪些狀態(tài)字段什么時候用Redis存購物車什么時候必須落到MySQL什么時候用定時任務去處理超時未支付訂單。這些經驗在面試和實際工作中都非常關鍵。1.2 技術棧清單與選型理由先列一份我在項目中實際使用的技術棧集合方便你對照環(huán)境層次技術選型說明后端Spring Boot 2.x主框架快速搭建RESTful服務持久層MyBatis含MyBatis Plus封裝靈活編寫SQL應對復雜報表緩存Redis緩存店鋪營業(yè)狀態(tài)、購物車數(shù)據(jù)存儲JWT黑名單鑒權JWT Spring Interceptor無狀態(tài)登錄校驗數(shù)據(jù)庫MySQL 5.7/8.0存儲持久化業(yè)務數(shù)據(jù)前端用戶端微信小程序原生或uni-app貼近真實C端場景前端管理端Vue Element UI管理后臺界面接口文檔Knife4j / Swagger前后端聯(lián)調必備部署Linux Nginx Docker可選模擬線上環(huán)境選型背后的邏輯我需要多說幾句。Spring Boot在Java生態(tài)里就是“約定優(yōu)于配置”的代言人起步快并且社區(qū)資料極其豐富。MyBatis和JPA的爭論一直存在但這個項目里我選MyBatis是因為很多查詢涉及多表關聯(lián)、動態(tài)條件、金額統(tǒng)計MyBatis的SQL可控性更強出現(xiàn)慢查詢時可以直接在XML里優(yōu)化。Redis在這里不是裝飾品而是真實承擔了高頻讀寫業(yè)務外賣系統(tǒng)里的店鋪營業(yè)狀態(tài)每天被看好幾次購物車數(shù)據(jù)用戶改來改去寫在MySQL里不僅要頻繁建會話表壓力也大放在Redis里天然帶過期時間數(shù)據(jù)結構又支持Hash和List非常契合。JWT則解決了分布式場景下的會話共享問題。雖然單體項目用Session也可以但JWT更接近現(xiàn)在的主流架構習慣登錄后服務端不保存用戶會話只需要在攔截器里校驗Token的簽名和有效期這樣后續(xù)如果要把服務拆成多實例也無須額外同步Session。1.3 系統(tǒng)角色與模塊劃分我從實際開發(fā)的角度把整個項目拆成三大塊用戶端小程序/移動H5登錄、瀏覽分類與菜品、購物車、下單、支付結算模擬、查看訂單狀態(tài)、催單。商家端管理后臺一部分主要是商家或店員視角管理菜品、接收新訂單、訂單狀態(tài)流轉比如接單、配送中、完成。管理端平臺運營視角員工管理、分類與菜品管理、套餐管理、訂單綜合查詢、營業(yè)數(shù)據(jù)統(tǒng)計、工作臺運營概覽。為什么要把商家端和管理端分開真實外賣平臺中商家只能管理自己的店鋪平臺運營可以查看全量數(shù)據(jù)。這個項目里Model劃分雖然沒有搞微服務那么重但Controller層的包結構、權限攔截、角色判斷還是要提前設計好。我一開始就是把所有接口都堆到同一個Controller里后面發(fā)現(xiàn)要么是權限混亂要么是字段輸出到前端時互相干擾所以項目里凡是標識了admin的路徑都統(tǒng)一管理凡是/user路徑都走用戶身份判斷形成約定后代碼好維護很多。2. 數(shù)據(jù)庫設計與核心表結構解析2.1 業(yè)務實體拆解做任何項目數(shù)據(jù)庫設計都是地基。我最初設計這張表清單花了兩天時間來回調整了三版。最終的核心表大概包括員工表employee管理端登錄賬號包含賬號、密碼加鹽加密、狀態(tài)。分類表category類型區(qū)分菜品分類和套餐分類名稱、排序、是否刪除。菜品表dish菜名、圖片、價格、描述、所屬分類、狀態(tài)啟售/停售?？谖侗韉ish_flavor很多菜品需要選辣度、規(guī)格一對多。套餐表setmeal包含套餐價格、分類、狀態(tài)。套餐與菜品關聯(lián)表setmeal_dish多對多關系。用戶表user微信端用戶信息openid模擬、昵稱、手機號。地址簿表address_book收貨人、手機號、詳細地址、標簽家/公司。購物車表shopping_cart其實可以用Redis但落庫版本能把購物車持久化到MySQL表里存用戶ID、菜品ID、口味JSON、數(shù)量、金額。訂單表orders訂單號、用戶ID、地址快照、金額明細、狀態(tài)、下單時間、支付時間、預計送達時間。訂單明細表order_detail一個訂單對應多個菜品記錄菜品快照信息。工作臺相關統(tǒng)計表一般實時計算不單獨建表。這里想強調兩個容易被忽略的設計點。第一訂單表里一定要存地址快照和菜品快照而不是通過外鍵去關聯(lián)用戶地址表和菜品表。否則用戶以后改了地址或者菜品下架改名歷史訂單的數(shù)據(jù)就全部亂掉了。第二金額字段要用decimal(10,2)不能用float或double這個面試里踩中概率極高——二進制浮點數(shù)在累加時會出現(xiàn)0.10.2不等于0.3的問題訂單金額錯了可沒法交代。2.2 訂單狀態(tài)流轉與關聯(lián)設計訂單是這個系統(tǒng)的核心我們把狀態(tài)機設計為狀態(tài)值含義對應的用戶操作1待付款用戶下單后未支付2待接單已支付等待商家確認3已接單商家已接受制作中4配送中騎手正在配送5已完成用戶確認或自動完成6已取消用戶取消或超時取消7退款售后狀態(tài)模擬狀態(tài)之間絕不能亂跳比如待付款狀態(tài)下是不能直接改成配送中的。我代碼里在Service層寫了一個統(tǒng)一的狀態(tài)校驗方法不允許非法狀態(tài)躍遷。在訂單表里還設置了一個字段區(qū)分是用戶取消、商家拒單還是超時取消便于后續(xù)統(tǒng)計取消原因。和訂單關聯(lián)最緊密的就是明細表。明細表不需要和菜品表做強關聯(lián)因為菜品表字段可以隨便改但明細要保留當時的價格。如果你在管理端改了菜品價格然后回頭查歷史訂單發(fā)現(xiàn)金額變了那就是關聯(lián)設計出了問題。這是我實際開發(fā)中遇到的真實問題所以快照思路要嚴格執(zhí)行。2.3 數(shù)據(jù)庫設計的幾個坑第一個坑是時間字段的時區(qū)問題。MySQL里如果連接參數(shù)沒有設置serverTimezoneAsia/Shanghai入庫的時間會和本地時間差8小時。訂單的統(tǒng)計是按天來的時區(qū)一亂營業(yè)額統(tǒng)計就大概率偏移。第二個坑是邏輯刪除。很多表都加了deleted字段但查詢時稍不注意就把已刪除的分類也查出來了。我采取的方案是MyBatis配置全局的邏輯刪除字段并在業(yè)務層通過構造查詢條件強制過濾。第三個坑是索引設計。訂單表數(shù)據(jù)量一旦上來如果沒對user_id和status建聯(lián)合索引按用戶查歷史訂單、按狀態(tài)列訂單都會走全表掃描。我的建議是order_no做唯一索引user_idstatus做聯(lián)合索引訂單創(chuàng)建時間的范圍查詢也要考慮到。3. 核心功能實現(xiàn)與實操要點3.1 用戶登錄與JWT鑒權流程外賣項目的用戶端登錄一般走微信登錄真實場景需要調用微信的code2session接口換取openid。做模擬項目的時候不需要真實的AppID所以我在項目里封裝了一個類似的登錄服務前端把模擬的code傳過來后端通過固定的配置類生成一個openid真實場景就是請求微信接口獲取再根據(jù)openid查用戶表不存在則自動注冊新用戶最后生成JWT返回給前端。代碼層面JWT我用的是jjwt庫核心操作就是三塊生成Token、解析Token、校驗過期時間。實際項目中我會自定義一個攔截器或者HandlerInterceptor對所有除登錄接口之外的路徑進行校驗。攔截器里從Header中取token解析成功就把用戶ID放到ThreadLocal或RequestContext里后續(xù)Controller直接取。這里有個關鍵點ThreadLocal用完后一定要remove否則線程池復用時會帶來數(shù)據(jù)串臺的隱患。我踩過的坑是第一次設計Header字段時叫“Authorization”但管理端和用戶端用了同一個攔截器導致用戶Token被當成管理員Token用。后來我給兩個端分別定義了不同的鑒權攔截器且路徑前綴區(qū)分開/admin/**走管理端校驗/user/**走用戶端校驗。這個設計影響到后面所有模塊的聯(lián)調提前理清很有必要。3.2 購物車與下單鏈路購物車是這個系統(tǒng)中“高頻寫”的代表。用戶加購時前端把菜品ID和口味組合傳給后端后端先判斷Redis里有沒有對應數(shù)據(jù)如果有數(shù)量加一如果沒有初始化一個新的購物車條目。用Hash結構存儲時key可以用userIdfield用“菜品id_口味hash”這樣同一個菜加不同辣度可以分開計數(shù)也方便前端回顯購物車列表時聚合。下單鏈路我更想強調“一致性”。下單涉及的操作包括校驗購物車非空、計算總金額、校驗余額或模擬支付結果、生成訂單主表和明細表、清空購物車、扣減庫存如果做了庫存。這些操作必須放在同一個事務中否則一旦中途異常訂單表和庫存表就出現(xiàn)不一致。我在做庫存扣減時一開始用的是先查庫存再更新結果并發(fā)下單時出現(xiàn)超賣問題。后來改了SQL直接通過UPDATE語句“庫存購買數(shù)量”這個條件來扣減update dish set stock stock - #{num} where id #{id} and stock #{num}。受影響行數(shù)為0說明庫存不足需要回滾。這是我在實際項目中記憶很深刻的一個教訓雖然蒼穹這套項目有些版本沒有做庫存字段但加上這個點會讓項目含金量更高。3.3 訂單狀態(tài)變更與消息推送訂單狀態(tài)變化之后用戶端需要實時看到。這里我沒有引入MQ做異步推送而是用WebSocket建立一個長連接商戶或管理端修改訂單狀態(tài)后服務端主動把最新狀態(tài)推送給對應的用戶端連接。實現(xiàn)步驟大致是后端引入WebSocket依賴編寫一個WebSocketServer的單例管理所有在線連接當用戶登錄成功后前端通過握手請求把token傳上來服務端解析出userId后把Session映射到userId的Map中訂單狀態(tài)變更時根據(jù)訂單里的userId找到對應連接并推送JSON消息比如推送訂單號、最新狀態(tài)、預計送達時間。如果不想引入WebSocket也可以前端定時輪詢訂單接口但這樣實時性差且壓力大。WebSocket的難度主要在于連接管理和心跳?；?。我在本地測試時發(fā)現(xiàn)瀏覽器和服務器之間存在網(wǎng)絡代理時會自動斷開連接所以寫了Ping/Pong心跳機制每30秒發(fā)一次心跳包維持連接。這個機制如果你不做線上環(huán)境很容易出現(xiàn)用戶那邊已經斷開了服務端還不知道的情況。3.4 管理端數(shù)據(jù)統(tǒng)計與報表管理端有一個比較亮眼的功能是數(shù)據(jù)統(tǒng)計按時間區(qū)間展示營業(yè)額、訂單量、平均客單價、新增用戶數(shù)同時畫出訂單趨勢曲線。這里不需要額外引入復雜的BI工具用SQL聚合即可。我以營業(yè)額為例說明思路篩選條件包括訂單狀態(tài)已完成的訂單才計算營業(yè)額不能把待付款和已取消算進去然后根據(jù)下單時間或支付時間所在日期進行分組按天求出訂單金額總額。注意MySQL的DATE_FORMAT函數(shù)可以把datetime轉成yyyy-MM-dd的字符串再配合GROUP BY就能得到每日的營業(yè)額列表。類似的訂單趨勢統(tǒng)計是按天統(tǒng)計訂單數(shù)新增用戶數(shù)是按用戶表create_time日期分組訪問趨勢可能涉及UV/PV統(tǒng)計這時候Redis的HyperLogLog就派上用場了PFADD和PFCOUNT可以非常省內存地去重計數(shù)。當然如果只是為了演示效果用SQL直接做也行但你能說出HyperLogLog的原理面試官對你的工程認知會明顯加分。4. 部署與環(huán)境搭建實錄4.1 本地開發(fā)環(huán)境準備我先說本地跑起來的必要環(huán)境配置。JDK建議用Java 8或11Maven用3.6以上MySQL用5.7或8.0都可Redis用5.0以上。如果你的電腦還沒裝這些我建議用Docker一鍵跑MySQL和Redis可以省去很多環(huán)境變量的煩惱。比如執(zhí)行docker run -p 3306:3306 --name mysql -e MYSQL_ROOT_PASSWORD123456 -d mysql:5.7Windows上記得檢查端口占用本地開發(fā)時3306端口很容易被另一個殘留MySQL進程占著連接不上時先netstat查一下。項目配置文件中需要修改的核心項是數(shù)據(jù)源和Redis地址。Spring Boot里我傾向于用application.yml統(tǒng)一管理。需要注意的一點是密碼和敏感信息不要寫死在git里至少應該通過環(huán)境變量引用spring.redis.host${REDIS_HOST:localhost}這樣既方便本地跑也方便上線時用環(huán)境變量注入。4.2 前后端聯(lián)調中的協(xié)議約定這個項目涉及到小程序端和管理端前后端聯(lián)調是重頭戲。聯(lián)調之前必須先統(tǒng)一數(shù)據(jù)格式。我用的統(tǒng)一響應結構是{ code: 1, msg: success, data: {} }code為1表示成功0表示失敗。有人喜歡用200/500這種HTTP狀態(tài)碼來代表業(yè)務成功與否但我不太建議因為HTTP狀態(tài)碼應該表達傳輸層狀態(tài)而業(yè)務層狀態(tài)需要code字段來細分。前端拿到res.code后判斷是否等于1再決定拉取data還是彈出錯誤信息。另外一個非常容易踩雷的是日期格式。后端返回的LocalDateTime默認是一長串帶T的格式小程序端直接展示很難看。我在全局配置里加了Jackson的日期格式化統(tǒng)一為“yyyy-MM-dd HH:mm:ss”。還有金額字段返回時要小心精度丟失不能轉成double再傳給前端而是要保留字符串或整數(shù)形式比如以元為單位保留兩位小數(shù)或者前端用整數(shù)分單位解析避免浮點數(shù)精度問題。4.3 打包部署的常見問題本地運行成功后要把后端打成jar包部署到Linux服務器。執(zhí)行mvn clean package后在target目錄下生成xxx.jar。部署時我用的是systemd服務或者直接nohup java -jar xxx.jar logs/log.log 21 。最常見的三個問題第一打包時test報錯導致打包失敗可以在pom中跳過測試spring-boot-maven-plugin配置maven.test.skiptrue或者命令行加-Dmaven.test.skiptrue。第二端口沒開服務器安全組或防火墻擋住了8080端口導致前端請求連接超時檢查firewalld或者iptables規(guī)則。第三靜態(tài)資源路徑問題。管理端打包后的dist文件一般放在Nginx里Nginx配置api反向代理到后端的8080端口前端和后端之間不會跨域但如果你前端直接用devServer代理本地跑時也要確認proxy表配置正確。5. 問題排查與避坑指南5.1 常見異常速查表我在做這個項目時整理過一張異常排錯表現(xiàn)在直接分享出來異常表現(xiàn)常見原因解決方案登錄接口返回401JWT過期或簽名不匹配檢查token是否帶Bearer前綴再確認攔截器排除路徑是否配錯MySQL連接報CommunicationsException數(shù)據(jù)庫地址/端口/賬號錯誤或連接池耗盡檢查yml配置注意時區(qū)參數(shù)重啟時確認服務已啟動Redis連接失敗Redis未啟動或密碼錯誤本地執(zhí)行ping檢查生產環(huán)境用redis-cli -a 密碼 ping驗證中文亂碼數(shù)據(jù)庫連接字符集未配置UTF-8URL加useUnicodetruecharacterEncodingutf-8金額對不上使用了float/double全面改為BigDecimal并配置保留兩位小數(shù)前端報跨域后端未允許跨域或代理配置錯誤開發(fā)環(huán)境用async的proxy線上用Nginx同源解決定時任務沒執(zhí)行未啟用EnableScheduling或cron表達式錯誤檢查啟動類注解和Cron表達式注意6位還是7位最隱蔽的問題是數(shù)據(jù)庫連接池連接泄露。如果有長連接查詢特別慢或者偶發(fā)無法獲取連接多半是事務沒提交或者連接未歸還。我會在yml里配置連接池監(jiān)控參數(shù)例如maximum-pool-size20minimum-idle5并開啟日志排查的時候能看清誰拿了連接不還。5.2 我踩過的幾個坑第一個坑是事務失效。在同一個類里調用帶Transactional的public方法時事務不會生效因為Spring的代理對象調用的是this方法而不是代理方法。解決辦法是把需要事務的邏輯拆到另一個Service類中或者通過注入自身的代理對象調用。為了排查這種問題我會在配置里加上事務日志輸出到控制臺觀察異常后是否有rollback記錄。第二個坑是JSON序列化循環(huán)引用。菜品類里包含分類對象分類對象又包含菜品列表結果返回JSON時直接棧溢出。后來把關聯(lián)屬性用JsonIgnore或設置DTO只返回需要的字段。經驗就是實體類不要直接作為API響應體一定要轉VO/DTO這既安全又靈活。第三個坑是MyBatis的動態(tài)SQL字段里出現(xiàn)了下劃線映射問題。表字段是create_time實體屬性是createTime如果沒開啟mapUnderscoreToCamelCase查詢字段時為null。在配置文件里加上mybatis.configuration.map-underscore-to-camel-casetrue即可這個點能幫你省半小時。5.3 性能優(yōu)化與后續(xù)擴展方向項目基本跑通后我又做了幾個方向上的優(yōu)化讓整個項目的完成度更高。緩存優(yōu)化方面店鋪營業(yè)狀態(tài)、分類列表這些讀多寫少的數(shù)據(jù)可以在每次查詢后寫入Redis并設置合理的過期時間例如5到10分鐘。新增或修改時主動刪除對應緩存保證緩存與數(shù)據(jù)庫最終一致。頁面端會出現(xiàn)數(shù)據(jù)短暫延遲但通常可以接受。接口優(yōu)化方面菜品分頁查詢時如果數(shù)據(jù)量大可以考慮用PageHelper分頁或者在SQL里做limit分頁。管理端訂單列表查詢使用了比較多的時間范圍篩選我建立了復合索引避免臨時文件排序。擴展方向上可以給項目加入MQ來處理訂單超時消息比如用延遲隊列實現(xiàn)下單后15分鐘未支付自動取消。還可以引入Elasticsearch做菜品搜索提高分類和菜品的查詢速度?，F(xiàn)在很多微服務架構把蒼穹項目拆分成多個模塊比如認證服務、訂單服務、商品服務這其實也是很好的學習路徑但先把單體項目吃透更重要。一點私人總結做完這個項目之后我最大的收獲是建立了對完整業(yè)務系統(tǒng)的認知閉環(huán)。以前寫CRUD只是照著接口文檔填方法體而蒼穹外賣讓我真正思考了訂單在什么時機生成、購物車數(shù)據(jù)放在哪里、什么時候要加鎖、什么時候要用快照。從數(shù)據(jù)庫設計到鑒權攔截再到WebSocket推送鏈路完整每個環(huán)節(jié)都不是孤立的。如果你正在動手做這個項目我建議你不要只滿足于“能跑起來”。把每一個狀態(tài)變更的日志打出來把每一次調用鏈路梳理清楚甚至可以自己畫一張時序圖。只要你把訂單主流程的所有細節(jié)都吃透了下次再去接觸分布式事務、消息隊列、微服務拆分這些主題會發(fā)現(xiàn)基礎已經打好了。最后再分享一個小經驗這個項目做完記得用真實體驗的心態(tài)去測試每一個按鈕你自己就是最好的測試人員。