簡介本資源是一套基于Spring Boot開發(fā)的校園閑置物品交易系統(tǒng)完整源碼面向Java后端初學(xué)者、高校課程設(shè)計學(xué)生及Web全棧學(xué)習(xí)者旨在解決校園內(nèi)書籍、電子設(shè)備等閑置物品流通效率低、信息不對稱的問題。壓縮包共1565個文件33.16MB涵蓋106個核心Java業(yè)務(wù)邏輯與控制器類、84個Vue前端組件如IndexHeader.vue、BreadCrumbs.vue等、306個JS交互腳本、88個CSS/SCSS樣式文件、98個JPG/PNG圖片及SVG圖標(biāo)資源以及MyBatis映射XML、Spring Boot配置YML、SQL建表語句等關(guān)鍵工程文件結(jié)構(gòu)清晰、模塊解耦便于理解MVC分層與前后端分離實(shí)踐。已有90人下載學(xué)習(xí)可直接導(dǎo)入IDE運(yùn)行完整包含用戶認(rèn)證、商品發(fā)布瀏覽、在線聊天協(xié)商、交易評價及后臺管理等閉環(huán)功能附帶Lombok簡化、RESTful接口設(shè)計、密碼哈希存儲等工程化實(shí)踐細(xì)節(jié)是掌握Spring Boot企業(yè)級開發(fā)流程的優(yōu)質(zhì)參考項(xiàng)目。1. 項(xiàng)目概述與核心價值最近在整理硬盤翻出來一個幾年前在學(xué)校時做的項(xiàng)目源碼包名字就叫“基于Spring Boot的校園閑置物品交易系統(tǒng)代碼.zip”。當(dāng)時為了畢業(yè)設(shè)計和積累實(shí)戰(zhàn)經(jīng)驗(yàn)吭哧吭哧搞了小半年從需求分析、技術(shù)選型到編碼部署踩了不少坑也攢下不少心得。這個系統(tǒng)本質(zhì)上是一個服務(wù)于校園內(nèi)師生的C2C二手交易平臺核心目標(biāo)就是解決“宿舍里東西越堆越多畢業(yè)時一堆帶不走又舍不得扔”的痛點(diǎn)。你想一本九成新的專業(yè)教材、一個只用過幾次的健身器材、一張閑置的校園卡對原主人可能是負(fù)擔(dān)但對學(xué)弟學(xué)妹可能就是寶貝。這個系統(tǒng)就是為這種高頻、小額、基于信任的校內(nèi)交易場景而生的。為什么用Spring Boot現(xiàn)在回頭看這個選擇依然非常正確。對于當(dāng)時還是學(xué)生、開發(fā)資源和時間都有限的我們來說Spring Boot那種“開箱即用”的特性簡直是救命稻草。它把Spring生態(tài)里那些繁瑣的XML配置、依賴管理、服務(wù)器部署都簡化了讓我們能把精力集中在業(yè)務(wù)邏輯本身而不是在環(huán)境搭建上折騰一周。這個項(xiàng)目麻雀雖小五臟俱全涵蓋了用戶管理、商品發(fā)布、搜索瀏覽、在線聊天、訂單交易、后臺管理等完整模塊是一個非常好的全棧實(shí)踐樣本。無論你是想學(xué)習(xí)Spring Boot如何在實(shí)際項(xiàng)目中落地還是想了解一個交易系統(tǒng)的核心架構(gòu)設(shè)計甚至是打算自己動手做一個類似的校園應(yīng)用這份代碼和背后的思考過程或許都能給你一些直接的參考。2. 系統(tǒng)整體架構(gòu)與核心設(shè)計思路2.1 為什么選擇單體分層架構(gòu)打開項(xiàng)目代碼你會發(fā)現(xiàn)它采用的是經(jīng)典的MVC分層架構(gòu)并且是單體應(yīng)用。這在當(dāng)時是經(jīng)過權(quán)衡的。很多同學(xué)可能會問現(xiàn)在不是都流行微服務(wù)嗎為什么不用這里就涉及到技術(shù)選型的一個核心原則合適優(yōu)于時髦。對于一個校園內(nèi)的閑置物品交易系統(tǒng)它的典型特征包括用戶規(guī)模有限通常在一所學(xué)校內(nèi)幾千到幾萬用戶、業(yè)務(wù)邏輯相對直接、并發(fā)峰值可預(yù)測例如開學(xué)季、畢業(yè)季、開發(fā)和運(yùn)維團(tuán)隊(duì)極小甚至就1-2個人。在這種情況下引入微服務(wù)帶來的服務(wù)拆分、獨(dú)立部署、分布式事務(wù)、鏈路監(jiān)控等復(fù)雜度是得不償失的。它會讓開發(fā)、測試和部署的成本呈指數(shù)級上升。因此我們采用了單體分層架構(gòu)清晰劃分了職責(zé)控制層Controller接收前端HTTP請求進(jìn)行參數(shù)校驗(yàn)和基本格式化然后調(diào)用服務(wù)層最后返回JSON數(shù)據(jù)。這一層要盡量薄不做業(yè)務(wù)邏輯。服務(wù)層Service這是業(yè)務(wù)邏輯的核心所在地。所有與交易、用戶、商品相關(guān)的規(guī)則比如發(fā)布商品的條件、下單時的庫存檢查、聊天權(quán)限驗(yàn)證等都在這里實(shí)現(xiàn)。數(shù)據(jù)訪問層Repository/Mapper負(fù)責(zé)與數(shù)據(jù)庫對話使用MyBatis或Spring Data JPA來執(zhí)行CRUD操作。這一層要保證高效和純凈只關(guān)心數(shù)據(jù)的存取。實(shí)體層Entity/Domain定義與數(shù)據(jù)庫表映射的Java對象是數(shù)據(jù)流動的載體。這種架構(gòu)的好處是結(jié)構(gòu)清晰、開發(fā)簡單、易于調(diào)試并且對于這個量級的應(yīng)用性能完全足夠。所有的代碼都在一個工程里用Maven或Gradle就能構(gòu)建扔到一臺服務(wù)器上就能跑起來非常適合快速迭代和初期驗(yàn)證。2.2 技術(shù)棧選型背后的邏輯技術(shù)選型不是堆砌最火的技術(shù)而是為業(yè)務(wù)目標(biāo)選擇最合適的工具。這個項(xiàng)目的技術(shù)棧是這么考慮的核心框架Spring Boot 2.1.x選擇2.1.x這個當(dāng)時穩(wěn)定的版本而非最新的快照版是為了避免踩坑。Spring Boot的自動配置、內(nèi)嵌Tomcat、Starter依賴管理是基礎(chǔ)。我們特別用到了它的spring-boot-starter-webWeb開發(fā)、spring-boot-starter-data-jpa數(shù)據(jù)訪問、spring-boot-starter-security安全初期簡單用后期可擴(kuò)展和spring-boot-starter-websocket實(shí)現(xiàn)實(shí)時聊天。持久層Spring Data JPA Hibernate為什么用JPA而不是更靈活的MyBatis對于這個業(yè)務(wù)模型相對穩(wěn)定、以對象操作為主的項(xiàng)目JPA的ORM對象關(guān)系映射能力可以極大減少編寫重復(fù)的SQL代碼。通過定義實(shí)體類如User,Product,Order和Repository接口就能完成大部分?jǐn)?shù)據(jù)操作。OneToMany、ManyToOne這些注解能清晰地表達(dá)用戶和商品、訂單之間的關(guān)系。當(dāng)然對于復(fù)雜的統(tǒng)計查詢我們也會在Repository中使用Query注解寫原生SQL兼顧靈活與便捷。數(shù)據(jù)庫MySQL 5.7關(guān)系型數(shù)據(jù)庫是交易類系統(tǒng)的基石ACID特性對于保證交易數(shù)據(jù)的一致性至關(guān)重要。MySQL成熟、穩(wěn)定、社區(qū)資源豐富是毫無懸念的選擇。我們設(shè)計了大概十幾張表核心包括用戶表、商品表、商品分類表、訂單表、聊天消息表、收藏表等。前端技術(shù)Thymeleaf模板引擎 Bootstrap jQuery考慮到項(xiàng)目初期需要快速出原型并且團(tuán)隊(duì)成員后端背景更強(qiáng)我們沒有采用前后端分離的Vue/React而是用了Spring Boot天然集成的Thymeleaf模板引擎來渲染頁面。這樣做的好處是開發(fā)速度快前后端耦合在同一個項(xiàng)目里調(diào)試方便。頁面樣式用Bootstrap框架能快速搭建出美觀、響應(yīng)式的界面。交互邏輯用jQuery補(bǔ)充。這雖然看起來“不現(xiàn)代”但對于一個MVP最小可行產(chǎn)品來說是最高效的方式。如果項(xiàng)目發(fā)展壯大完全可以重構(gòu)為前后端分離。緩存與搜索初期未引入但預(yù)留了設(shè)計在最初的版本中考慮到校園用戶量和商品量我們沒有引入Redis或Elasticsearch。但我們在設(shè)計時做了預(yù)留。例如商品服務(wù)查詢熱門分類的方法上我們加了Cacheable注解的注釋說明未來可以接入Spring Cache抽象層用Redis做后端緩存。對于商品搜索我們使用了數(shù)據(jù)庫的LIKE查詢這顯然效率不高在代碼注釋中明確指出了這是性能瓶頸優(yōu)化方案是接入Elasticsearch進(jìn)行全文檢索。注意技術(shù)選型文檔化非常重要。我們在項(xiàng)目的README.md和一個專門的DESIGN.md文件里記錄了為什么做這些選擇以及未來可能的演進(jìn)方向。這不僅是給隊(duì)友看的更是給幾個月后的自己看的。3. 核心業(yè)務(wù)模塊拆解與實(shí)現(xiàn)細(xì)節(jié)3.1 用戶系統(tǒng)不僅僅是注冊登錄用戶模塊是起點(diǎn)但絕不僅僅是/register和/login兩個接口。實(shí)體設(shè)計Entity public class User { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private String username; // 學(xué)號/工號唯一標(biāo)識 private String password; // 加密存儲 private String nickname; private String avatarUrl; // 頭像存儲OSS鏈接或相對路徑 private String phone; private String email; private String dormitory; // 宿舍樓信息便于線下交易 Enumerated(EnumType.STRING) private UserRole role; // 枚舉USER, ADMIN private Integer creditScore; // 信用分初始為100 private Boolean isActive; private LocalDateTime createTime; // 省略 getter/setter }這里有幾個關(guān)鍵點(diǎn)1. 用學(xué)號/工號作為用戶名保證了校內(nèi)身份的真實(shí)性基礎(chǔ)。2.password字段必須加密存儲我們用的是Spring Security的BCryptPasswordEncoder。3. 引入了creditScore信用分這是構(gòu)建信任體系的關(guān)鍵。信用分會根據(jù)交易完成情況、評價好壞而增減。注冊流程的坑 注冊時前端會發(fā)送驗(yàn)證碼到用戶郵箱校內(nèi)郵箱驗(yàn)證是提升真實(shí)性的好方法。我們遇到過的一個典型問題是并發(fā)注冊導(dǎo)致用戶名重復(fù)。即使數(shù)據(jù)庫對username字段設(shè)置了唯一索引在高并發(fā)下兩個請求可能同時通過“用戶名是否存在”的檢查然后都去插入導(dǎo)致其中一個失敗。我們的解決方案是在Service層方法上加Transactional注解并在檢查用戶名后立即執(zhí)行插入利用數(shù)據(jù)庫的事務(wù)隔離級別來防止這種情況。更嚴(yán)謹(jǐn)?shù)淖龇ㄊ鞘褂梅植际芥i但在這個場景下數(shù)據(jù)庫唯一索引結(jié)合事務(wù)已足夠。會話管理 我們沒有采用傳統(tǒng)的Session而是使用了JWTJSON Web Token。用戶登錄成功后服務(wù)端生成一個包含用戶ID和角色的JWT令牌返回給前端。前端后續(xù)請求都在HTTP Header的Authorization中攜帶這個Token。這樣做的好處是無狀態(tài)便于擴(kuò)展也適合未來可能的前后端分離部署。我們使用jjwt這個庫來生成和解析Token。3.2 商品發(fā)布與管理系統(tǒng)這是系統(tǒng)的核心商品信息是否清晰、檢索是否方便直接影響用戶體驗(yàn)。商品實(shí)體與狀態(tài)機(jī)Entity public class Product { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private String title; Lob // 大文本字段 private String description; private BigDecimal price; private String mainImageUrl; // 主圖 ElementCollection // 存儲多張圖片URL的集合 private ListString imageUrls; Enumerated(EnumType.STRING) private ProductStatus status; // 狀態(tài)AUDITING審核中、ON_SALE出售中、SOLD已售出、OFF_SHELF已下架 Enumerated(EnumType.STRING) private ProductCondition condition; // 成色NEW, LIKE_NEW, GOOD, USED ManyToOne JoinColumn(name category_id) private Category category; // 關(guān)聯(lián)分類 ManyToOne JoinColumn(name seller_id) private User seller; // 關(guān)聯(lián)賣家 private Integer viewCount 0; private LocalDateTime createTime; private LocalDateTime updateTime; }狀態(tài)設(shè)計是精髓ProductStatus這個枚舉定義了商品的生命周期。一個新商品發(fā)布后狀態(tài)是AUDITING審核中這是為了防止不良信息。管理員審核通過后變?yōu)镺N_SALE。被下單后并非立即改變狀態(tài)交易完成時變?yōu)镾OLD。賣家也可以手動OFF_SHELF。這個狀態(tài)流轉(zhuǎn)必須嚴(yán)謹(jǐn)比如已售出的商品不能再被下單。圖片上傳的處理 這是文件操作的典型場景。我們沒有把圖片以二進(jìn)制形式存到數(shù)據(jù)庫而是使用了“對象存儲數(shù)據(jù)庫存路徑”的方式。前端通過input typefile上傳圖片。后端FileUploadController接收到MultipartFile對象。我們對文件進(jìn)行校驗(yàn)大小如5MB、類型僅限jpg, png、以及簡單的病毒掃描調(diào)用簡單的工具類。生成一個唯一的文件名如UUID 時間戳 后綴防止覆蓋。將文件上傳到阿里云OSS或騰訊云COS、七牛云等。在校園內(nèi)網(wǎng)環(huán)境下如果追求極致速度和零成本也可以自建一個簡單的文件服務(wù)器用Nginx做靜態(tài)資源服務(wù)但OSS省心、可靠、有CDN加速。將上傳成功后返回的公開訪問URL如https://your-bucket.oss-cn-hangzhou.aliyuncs.com/images/uuid.jpg存入數(shù)據(jù)庫的imageUrls字段。實(shí)操心得圖片上傳一定要做異步處理或至少提供進(jìn)度提示。我們最初是同步上傳大圖片導(dǎo)致接口超時。后來改用了前端分片上傳后端異步接收的方式用戶體驗(yàn)好了很多。同時一定要在OSS上設(shè)置生命周期規(guī)則定期清理那些上傳了但最終沒有關(guān)聯(lián)到任何商品的“僵尸圖片”。3.3 實(shí)時聊天功能的實(shí)現(xiàn)二手交易溝通是關(guān)鍵。站內(nèi)信太慢我們實(shí)現(xiàn)了基于WebSocket的實(shí)時一對一聊天。技術(shù)方案Spring WebSocket STOMP我們選擇了STOMP作為WebSocket的子協(xié)議因?yàn)樗峁┝讼裣⒛康牡谼estination、訂閱Subscribe這樣的高級抽象比裸的WebSocket更易用。后端配置Configuration EnableWebSocketMessageBroker public class WebSocketConfig implements WebSocketMessageBrokerConfigurer { Override public void registerStompEndpoints(StompEndpointRegistry registry) { // 前端通過 ws://your-domain/ws 建立連接 registry.addEndpoint(/ws).setAllowedOriginPatterns(*).withSockJS(); } Override public void configureMessageBroker(MessageBrokerRegistry registry) { // 客戶端訂閱消息的前綴例如 /topic, /user registry.enableSimpleBroker(/topic, /queue); // 客戶端發(fā)送消息到服務(wù)端的前綴 registry.setApplicationDestinationPrefixes(/app); // 點(diǎn)對點(diǎn)消息前綴默認(rèn)是 /user registry.setUserDestinationPrefix(/user); } }核心業(yè)務(wù)邏輯連接與認(rèn)證前端建立WebSocket連接時需要攜帶JWT Token。我們通過實(shí)現(xiàn)HandshakeInterceptor接口在握手階段驗(yàn)證Token并將用戶信息存入Session。消息路由我們設(shè)計了兩個主要的消息目的地。/app/chat.sendPrivateMessage用于接收前端發(fā)送的私聊消息。消息體包含recipientId接收者ID和content。/user/{userId}/queue/messages這是STOMP提供的用戶專屬隊(duì)列。服務(wù)端可以通過SimpMessagingTemplate.convertAndSendToUser()方法將消息精準(zhǔn)推送給指定用戶。這樣就實(shí)現(xiàn)了一對一聊天。消息持久化所有聊天消息都需要存入數(shù)據(jù)庫的chat_message表包含發(fā)送者、接收者、內(nèi)容、時間、是否已讀等字段。這樣用戶離線再上線也能拉取歷史記錄。未讀消息計數(shù)這是一個提升體驗(yàn)的關(guān)鍵點(diǎn)。當(dāng)消息被接收并存儲后如果接收者不在線即沒有對應(yīng)的WebSocket Session我們會在Redis或數(shù)據(jù)庫里增加他的未讀計數(shù)。當(dāng)用戶上線建立連接后主動查詢未讀計數(shù)并推送。當(dāng)用戶打開聊天窗口就將與對應(yīng)賣家的未讀消息標(biāo)記為已讀。踩過的坑連接斷開與重連網(wǎng)絡(luò)不穩(wěn)定會導(dǎo)致連接斷開。我們前端使用了SockJS客戶端它支持多種傳輸方式降級并自帶重連機(jī)制。后端需要處理好在SessionDisconnectEvent事件中清理用戶會話信息。集群部署問題如果未來應(yīng)用部署在多臺服務(wù)器上簡單的SimpMessagingTemplate無法跨服務(wù)器推送消息。解決方案是引入消息中間件如RabbitMQ、Redis Pub/Sub作為外部的消息代理Broker讓所有服務(wù)器實(shí)例連接到同一個Broker。這就是為什么配置中用的是enableSimpleBroker內(nèi)存代理未來可以換成enableStompBrokerRelay。3.4 交易與訂單流程設(shè)計這是最需要保證數(shù)據(jù)一致性和安全性的部分。下單流程簡化版前置校驗(yàn)用戶點(diǎn)擊“立即購買”或“加入購物車”我們系統(tǒng)是直接購買未做購物車。請求到達(dá)OrderController.createOrder。生成訂單在Service層方法上添加Transactional注解開啟事務(wù)。檢查商品是否存在且狀態(tài)為ON_SALE。檢查賣家不是自己不能買自己的東西。可選檢查庫存對于閑置品我們通常設(shè)置庫存為1。創(chuàng)建訂單對象Order狀態(tài)設(shè)為UNPAID待支付。訂單號使用“時間戳隨機(jī)數(shù)”生成確保唯一。將商品狀態(tài)更新為RESERVED已預(yù)訂或保持ON_SALE但關(guān)聯(lián)訂單ID。我們選擇了后者避免引入過多狀態(tài)。保存訂單到數(shù)據(jù)庫。支付由于是校園內(nèi)部系統(tǒng)我們實(shí)現(xiàn)了一個簡化的“模擬支付”。實(shí)際上只是調(diào)用一個支付接口改變訂單狀態(tài)為PAID已支付并記錄支付時間。真實(shí)的支付需要接入支付寶或微信的當(dāng)面付、小程序支付等。發(fā)貨與確認(rèn)賣家標(biāo)記發(fā)貨填寫線下交易地點(diǎn)或快遞單號訂單狀態(tài)變?yōu)镾HIPPED已發(fā)貨。買家確認(rèn)收貨后狀態(tài)變?yōu)镃OMPLETED已完成。此時觸發(fā)一系列后續(xù)操作商品狀態(tài)正式變?yōu)镾OLD。買賣雙方互相評價。根據(jù)評價結(jié)果更新雙方的creditScore信用分。事務(wù)與并發(fā)控制 在“創(chuàng)建訂單”這一步存在“超賣”風(fēng)險。即同一件商品被兩個用戶同時下單。我們通過數(shù)據(jù)庫的樂觀鎖機(jī)制來解決。在商品實(shí)體中增加一個版本號字段version用Version注解。Entity public class Product { // ... 其他字段 Version private Integer version; }在更新商品狀態(tài)或庫存時SQL語句會帶上where id? and version?。如果兩個請求同時讀到同一個version第一個更新成功后version會1第二個請求再去更新時匹配不到記錄就會拋出ObjectOptimisticLockingFailureException。我們在Service層捕獲這個異常然后返回給前端“商品信息已變化請刷新重試”的友好提示。重要提醒對于交易核心鏈路所有關(guān)鍵操作下單、支付、收貨都必須有完整的日志記錄。我們?yōu)镺rder表設(shè)計了詳細(xì)的日志子表order_log記錄狀態(tài)變更的時間、操作人、原因。這在出現(xiàn)糾紛時是至關(guān)重要的證據(jù)。4. 后臺管理系統(tǒng)的關(guān)鍵實(shí)現(xiàn)后臺管理是平臺有序運(yùn)行的保障主要給管理員使用。我們單獨(dú)做了一個管理后臺通過/admin/**的URL路徑進(jìn)行攔截并通過用戶角色UserRole.ADMIN進(jìn)行權(quán)限控制。使用Spring Security進(jìn)行權(quán)限控制Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers(/admin/**).hasRole(ADMIN) // 管理員路徑需要ADMIN角色 .antMatchers(/user/**).hasAnyRole(USER, ADMIN) .antMatchers(/, /public/**).permitAll() .and() .formLogin() .loginPage(/login) // 自定義登錄頁 .permitAll() .and() .logout() .permitAll(); // 禁用CSRF以方便API測試生產(chǎn)環(huán)境應(yīng)開啟并妥善處理 http.csrf().disable(); } }核心管理功能商品審核管理員查看狀態(tài)為AUDITING的商品列表可以查看詳情然后進(jìn)行“通過”或“拒絕”操作。拒絕時需要填寫理由系統(tǒng)會通過站內(nèi)信或WebSocket通知賣家。用戶管理查看用戶列表可以對違規(guī)用戶進(jìn)行“禁言”禁止發(fā)布商品或“封禁”禁止登錄操作。操作同樣需要記錄理由。數(shù)據(jù)統(tǒng)計簡單的數(shù)據(jù)看板展示每日新增用戶數(shù)、商品發(fā)布數(shù)、成交訂單數(shù)、熱門商品分類等。這些數(shù)據(jù)通過編寫復(fù)雜的SQL查詢語句或使用JPA的Query注解從數(shù)據(jù)庫聚合得到。如果數(shù)據(jù)量大這些統(tǒng)計查詢應(yīng)移到定時任務(wù)中計算好后存入統(tǒng)計表管理員查詢時直接讀統(tǒng)計表避免拖慢運(yùn)營數(shù)據(jù)庫。操作日志記錄所有管理員的關(guān)鍵操作如審核商品、管理用戶等做到有跡可循。后臺的前端我們同樣使用Thymeleaf渲染但套用了一個開源的AdminLTE后臺模板快速搭建出了帶有側(cè)邊欄、圖表、表格的友好界面。5. 系統(tǒng)部署、監(jiān)控與性能考量5.1 從開發(fā)到上線的部署流程項(xiàng)目開發(fā)完成后如何讓同學(xué)們訪問我們經(jīng)歷了從本地跑到服務(wù)器部署的過程。打包使用Spring Boot Maven插件打成可執(zhí)行的JAR包。mvn clean package -DskipTests生成的target/*.jar文件包含了所有依賴和嵌入的Tomcat服務(wù)器。服務(wù)器環(huán)境我們申請了一臺學(xué)校機(jī)房的Linux服務(wù)器CentOS 7?；A(chǔ)環(huán)境包括JDK 8或11與本地開發(fā)環(huán)境一致。MySQL數(shù)據(jù)庫并創(chuàng)建了對應(yīng)的數(shù)據(jù)庫和用戶導(dǎo)入初始數(shù)據(jù)如商品分類。可選Redis如果未來要加緩存或做Session共享。部署腳本我們寫了一個簡單的Shell腳本deploy.sh來做自動化部署。#!/bin/bash APP_NAMEsecondhand-trade JAR_PATH/path/to/your/project/target/*.jar BACKUP_PATH/path/to/backup/ LOG_PATH/path/to/logs/ # 1. 停止舊進(jìn)程 echo Stopping old application... pkill -f $APP_NAME || true sleep 5 # 2. 備份舊JAR包可選 cp $JAR_PATH $BACKUP_PATH/$APP_NAME-$(date %Y%m%d%H%M%S).jar # 3. 啟動新應(yīng)用 echo Starting new application... nohup java -jar $JAR_PATH --spring.profiles.activeprod $LOG_PATH/app.log 21 echo Application started. PID: $!這個腳本做了進(jìn)程停止、備份和啟動。更成熟的做法是使用Docker容器化部署用Docker Compose管理應(yīng)用、MySQL、Redis等服務(wù)實(shí)現(xiàn)環(huán)境隔離和一鍵啟動。配置分離我們使用Spring Boot的application-{profile}.properties功能。開發(fā)時用application-dev.properties連接本地數(shù)據(jù)庫生產(chǎn)環(huán)境用application-prod.properties連接服務(wù)器數(shù)據(jù)庫配置更嚴(yán)格的日志級別等。通過--spring.profiles.activeprod啟動參數(shù)來激活生產(chǎn)配置。5.2 基礎(chǔ)監(jiān)控與日志排查系統(tǒng)跑起來后怎么知道它是否健康健康檢查Spring Boot Actuator是神器。我們引入了spring-boot-starter-actuator依賴并做了一些安全配置只暴露必要的端點(diǎn)。這樣我們就可以通過訪問/actuator/health來查看應(yīng)用健康狀態(tài)數(shù)據(jù)庫連接等通過/actuator/metrics查看一些基礎(chǔ)指標(biāo)。日志管理我們使用Logback作為日志框架在logback-spring.xml中配置了日志格式、輸出級別生產(chǎn)環(huán)境用INFO問題排查時臨時改為DEBUG以及按天和大小滾動歸檔的策略避免日志文件撐滿磁盤。appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender file${LOG_PATH}/app.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePattern${LOG_PATH}/app.%d{yyyy-MM-dd}.%i.log/fileNamePattern maxHistory30/maxHistory timeBasedFileNamingAndTriggeringPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedFNATP maxFileSize100MB/maxFileSize /timeBasedFileNamingAndTriggeringPolicy /rollingPolicy encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern /encoder /appender關(guān)鍵日志點(diǎn)我們在所有Controller的入口、Service層的重要方法尤其是交易相關(guān)、異常捕獲處都打印了日志包含用戶ID、操作類型、關(guān)鍵參數(shù)等信息。這樣當(dāng)用戶反饋“下單失敗了”我們可以根據(jù)他的用戶ID和時間點(diǎn)快速定位到相關(guān)日志進(jìn)行排查。5.3 性能優(yōu)化點(diǎn)分析雖然初期數(shù)據(jù)量不大但我們在設(shè)計時考慮了一些常見的性能瓶頸和優(yōu)化方向數(shù)據(jù)庫層面索引在Product表的category_id,status,create_time用于按時間排序等查詢頻繁的字段上建立了索引。在Order表的buyer_id,seller_id,status上也建立了索引。慢查詢監(jiān)控開啟MySQL的慢查詢?nèi)罩径ㄆ诜治鰧?zhí)行時間過長的SQL進(jìn)行優(yōu)化比如重構(gòu)查詢、增加索引。連接池使用HikariCP作為數(shù)據(jù)庫連接池這是Spring Boot 2.x的默認(rèn)選擇性能非常好。我們在application-prod.properties中調(diào)整了連接池參數(shù)如最大連接數(shù)、最小空閑連接、連接超時時間等以適應(yīng)生產(chǎn)環(huán)境的并發(fā)需求。應(yīng)用層面DTO與懶加載在查詢商品列表時我們不會返回完整的Product實(shí)體它關(guān)聯(lián)了賣家User對象User又有其他關(guān)聯(lián)...而是定義了一個ProductSummaryDTO只包含列表頁需要的字段標(biāo)題、價格、主圖等。這避免了Hibernate的N1查詢問題。對于必須加載的關(guān)聯(lián)對象在Repository查詢方法上使用EntityGraph或?qū)慗OIN FETCH的JPQL來一次性加載避免多次查詢。緩存如前所述熱門分類、用戶基本信息等變化不頻繁的數(shù)據(jù)是引入Redis緩存的首要目標(biāo)。使用Spring Cache抽象可以輕松地通過注解如Cacheable,CacheEvict來管理緩存。前端層面圖片懶加載與壓縮商品列表圖片很多我們讓前端實(shí)現(xiàn)圖片懶加載當(dāng)圖片進(jìn)入視口時才加載。同時要求用戶上傳的圖片在后端或OSS處理時進(jìn)行適當(dāng)壓縮減少傳輸體積。靜態(tài)資源CDN將CSS、JS、圖片等靜態(tài)資源放到CDN上加速訪問。6. 常見問題排查與實(shí)戰(zhàn)技巧在實(shí)際開發(fā)和運(yùn)行中我們遇到了各種各樣的問題這里總結(jié)幾個典型的6.1 數(shù)據(jù)庫連接超時或中斷現(xiàn)象應(yīng)用運(yùn)行一段時間后控制臺偶爾會報出Communications link failure或Connection is not available的錯誤。排查與解決檢查連接池配置可能是連接池的最大空閑時間idleTimeout設(shè)置小于數(shù)據(jù)庫的wait_timeout。當(dāng)連接空閑時間超過數(shù)據(jù)庫的wait_timeout數(shù)據(jù)庫會主動斷開連接而連接池并不知道再次使用這個失效連接就會報錯。確保HikariCP的idleTimeout略小于MySQL的wait_timeout。檢查網(wǎng)絡(luò)與防火墻服務(wù)器和數(shù)據(jù)庫服務(wù)器之間的網(wǎng)絡(luò)是否穩(wěn)定防火墻是否會在長時間無通信后斷開連接啟用連接?；钤贖ikariCP配置中可以設(shè)置connectionTestQuery如SELECT 1和keepaliveTime讓連接池定期測試連接的有效性。6.2 事務(wù)失效問題現(xiàn)象在Service方法里拋出了異常但數(shù)據(jù)還是被部分保存了事務(wù)沒有回滾。原因與解決異常類型不對Spring事務(wù)默認(rèn)只對RuntimeException和Error進(jìn)行回滾。如果你在方法里拋出了一個Exception事務(wù)是不會回滾的。需要在Transactional注解里明確指定rollbackFor Exception.class。方法訪問權(quán)限Transactional是基于AOP代理實(shí)現(xiàn)的如果方法不是public代理可能無法生效。自調(diào)用問題在同一個類中一個沒有Transactional注解的方法A調(diào)用了同一個類中有Transactional注解的方法B事務(wù)是不會生效的。因?yàn)榇韺ο笳{(diào)用方法B時走的是類內(nèi)部調(diào)用而不是通過代理。解決方法是把方法B放到另一個Service中或者使用AopContext.currentProxy()來獲取當(dāng)前類的代理對象再調(diào)用。6.3 圖片上傳失敗或訪問慢現(xiàn)象用戶上傳圖片時前端長時間等待然后報錯或者圖片上傳成功了但頁面加載非常慢。排查文件大小限制檢查Spring Boot的multipart.maxFileSize和maxRequestSize配置確保它們大于用戶上傳的圖片大小。OSS配置與網(wǎng)絡(luò)檢查OSS的Bucket權(quán)限是否為公共讀如果是存儲公開圖片。檢查服務(wù)器到OSS外網(wǎng)域名的網(wǎng)絡(luò)是否通暢?？梢試L試在服務(wù)器上用curl或wget測試上傳和下載速度。前端超時設(shè)置增加前端上傳組件的超時時間。CDN加速如果圖片訪問慢可以為OSS Bucket開啟CDN加速這樣圖片會被緩存到離用戶更近的節(jié)點(diǎn)。6.4 實(shí)時聊天消息丟失或重復(fù)現(xiàn)象用戶反映有時收不到消息或者同一條消息收到了兩次。排查消息持久化與發(fā)送的原子性確保“消息存入數(shù)據(jù)庫”和“通過WebSocket發(fā)送”這兩個操作在一個事務(wù)里。如果先發(fā)送后存儲發(fā)送成功后系統(tǒng)崩潰消息就丟了。如果先存儲后發(fā)送存儲成功后發(fā)送前崩潰消息狀態(tài)會不一致。我們采用的方式是先存儲狀態(tài)為“發(fā)送中”然后嘗試發(fā)送發(fā)送成功后更新消息狀態(tài)為“已發(fā)送”如果發(fā)送失敗捕獲異常則記錄日志并可能加入重試隊(duì)列?？蛻舳讼⑷ブ貫槊織l消息生成一個唯一的ID如UUID前端在收到消息后檢查本地是否已存在該ID如果存在則丟棄。這可以解決網(wǎng)絡(luò)延遲導(dǎo)致的消息重復(fù)接收問題。離線消息處理用戶離線時消息應(yīng)持久化到數(shù)據(jù)庫。當(dāng)用戶上線后需要主動拉取所有未讀消息。這個“拉取”的時機(jī)很重要應(yīng)該在WebSocket連接成功建立、并且用戶身份認(rèn)證完成后立即進(jìn)行。這個校園閑置物品交易系統(tǒng)的項(xiàng)目雖然從技術(shù)上看用的都是主流、成熟的框架組合但真正把它從零到一跑通并且能穩(wěn)定支撐幾百上千人的日常使用其中涉及的細(xì)節(jié)和思考遠(yuǎn)比單純學(xué)習(xí)框架API要復(fù)雜。它考驗(yàn)的是你將技術(shù)組合起來解決實(shí)際問題的能力包括需求分析、架構(gòu)設(shè)計、數(shù)據(jù)庫建模、業(yè)務(wù)邏輯編碼、異常處理、性能調(diào)優(yōu)乃至簡單的運(yùn)維部署?；剡^頭看這段經(jīng)歷最大的收獲不是學(xué)會了某個注解怎么用而是建立了一套完整的、從問題到代碼的工程化思維。如果你正在學(xué)習(xí)Spring Boot強(qiáng)烈建議不要只停留在跑通Demo試著用它去構(gòu)思并實(shí)現(xiàn)一個能解決你身邊實(shí)際問題的完整應(yīng)用這個過程會讓你對技術(shù)的理解深入一個層次。代碼就在那里關(guān)鍵是你如何去理解和改造它讓它為你所用。本文還有配套的精品資源點(diǎn)擊獲取