管理系統(tǒng)實(shí)戰(zhàn))
做在線教育平臺(tái)管理系統(tǒng)這個(gè)項(xiàng)目是我把SpringBootVue這套前后端分離架構(gòu)完整跑通的一次實(shí)戰(zhàn)。整套代碼覆蓋了在線教育后臺(tái)最核心的幾條業(yè)務(wù)鏈課程管理、講師信息維護(hù)、學(xué)員學(xué)習(xí)記錄、后臺(tái)賬號(hào)權(quán)限、訂單報(bào)名數(shù)據(jù)。技術(shù)棧很固定SpringBoot做后端服務(wù)MyBatis負(fù)責(zé)持久層SQLMySQL存業(yè)務(wù)數(shù)據(jù)前端用Vue寫管理界面。這篇文章不打算寫那種面面俱到的官方文檔而是從實(shí)際落地角度把架構(gòu)拆分、數(shù)據(jù)庫設(shè)計(jì)、核心接口實(shí)現(xiàn)、踩坑記錄這幾塊講透。適合正在做畢業(yè)設(shè)計(jì)、準(zhǔn)備面試項(xiàng)目、或者想從零把一套在線教育后臺(tái)跑起來的開發(fā)者參考。1. 項(xiàng)目到底解決了什么問題1.1 在線教育系統(tǒng)的核心需求拆解很多人第一次拿到在線教育平臺(tái)這種需求第一反應(yīng)是“不就是課程列表加個(gè)播放器嗎”。真做起來就發(fā)現(xiàn)后臺(tái)管理系統(tǒng)的復(fù)雜度遠(yuǎn)高于前臺(tái)展示頁。在線教育平臺(tái)的管理后臺(tái)至少需要覆蓋這幾個(gè)角色和場(chǎng)景管理員要能夠維護(hù)課程上下架、審核講師入駐、查看平臺(tái)運(yùn)營數(shù)據(jù)。講師需要上傳課程章節(jié)、管理題庫、布置作業(yè)、查看自己負(fù)責(zé)班級(jí)的學(xué)習(xí)情況。學(xué)員則需要查看已購課程、記錄學(xué)習(xí)進(jìn)度、完成章節(jié)測(cè)試。如果再往復(fù)雜了說還有優(yōu)惠券、直播課、班級(jí)分組、多校區(qū)權(quán)限但最核心的底座永遠(yuǎn)是課程和用戶兩條線。我做的這個(gè)系統(tǒng)核心定位是后臺(tái)管理端加簡(jiǎn)單的學(xué)員端查詢能力。把“課程維護(hù)—講師管理—學(xué)員管理—學(xué)習(xí)記錄”這條主鏈路打通。為什么要先做后臺(tái)而不是前臺(tái)因?yàn)樵诰€教育平臺(tái)的真實(shí)瓶頸幾乎都出在內(nèi)容維護(hù)和權(quán)限控制上。前臺(tái)頁面再花哨后臺(tái)如果連課程上下架、講師角色權(quán)限都理不清楚業(yè)務(wù)根本跑不起來。需求梳理階段我習(xí)慣把功能拆成“必須要有”和“有了更好”兩類。必須有的用戶登錄注冊(cè)、角色權(quán)限、課程分類、課程與章節(jié)管理、講師資料維護(hù)、學(xué)員學(xué)習(xí)進(jìn)度記錄。可以后補(bǔ)的直播互動(dòng)、課程評(píng)論、積分系統(tǒng)、數(shù)據(jù)報(bào)表大屏。這套系統(tǒng)在初版把“必須有”的做扎實(shí)后續(xù)擴(kuò)展時(shí)再往上面加模塊結(jié)構(gòu)不會(huì)亂。1.2 為什么選SpringBootVueMyBatis這套組合說句實(shí)在話在線教育管理系統(tǒng)這種CRUD密集型業(yè)務(wù)用很多技術(shù)棧都能做。但選SpringBootVueMyBatisMySQL不是跟風(fēng)而是這套組合在“開發(fā)效率、維護(hù)成本、上手難度”三個(gè)維度上非常均衡。SpringBoot解決的是后端基礎(chǔ)設(shè)施的繁瑣問題。以前用Spring MVC搭項(xiàng)目要寫一堆XML配置現(xiàn)在SpringBoot通過自動(dòng)配置和Starter機(jī)制把大部分常見場(chǎng)景都預(yù)設(shè)好了。你只需要引入依賴寫少量配置就能把Web服務(wù)跑起來。對(duì)于以業(yè)務(wù)邏輯為主的系統(tǒng)這種“開箱即用”的體驗(yàn)非常舒服。Vue在前端的優(yōu)勢(shì)是組件化開發(fā)。后臺(tái)管理界面有大量重復(fù)的表格、表單、彈窗場(chǎng)景用組件封裝之后寫一個(gè)新頁面就是組合幾個(gè)組件的事。Vue的響應(yīng)式數(shù)據(jù)綁定也讓表單交互和列表篩選省了很多精力不需要手動(dòng)操作DOM。MyBatis經(jīng)常被拿來和JPA對(duì)比。我的個(gè)人觀點(diǎn)是在線教育系統(tǒng)里面高級(jí)查詢和統(tǒng)計(jì)SQL特別多比如“查詢某講師名下所有課程的學(xué)員完成率”用MyBatis寫SQL可以精確控制語句排查問題也直觀。JPA雖然寫簡(jiǎn)單CRUD很爽但一旦遇到復(fù)雜動(dòng)態(tài)SQL調(diào)試成本會(huì)明顯上升。MyBatis的靈活性和可控性在這個(gè)場(chǎng)景里更值得選。MySQL就更不用多說了成熟的社區(qū)生態(tài)、豐富的文檔、對(duì)事務(wù)的支持足夠支撐在線教育平臺(tái)這個(gè)體量的數(shù)據(jù)。真正要關(guān)心的是表結(jié)構(gòu)設(shè)計(jì)和索引優(yōu)化這個(gè)放到后面數(shù)據(jù)庫部分詳細(xì)講。2. 系統(tǒng)整體架構(gòu)與模塊設(shè)計(jì)2.1 前后端分離的整體思路這套系統(tǒng)的架構(gòu)不復(fù)雜就是標(biāo)準(zhǔn)的前后端分離Vue前端通過HTTP請(qǐng)求訪問SpringBoot后端的RESTful接口后端操作MySQL數(shù)據(jù)庫。前后端分別開發(fā)、分別部署前端打包成靜態(tài)文件丟到Nginx后端打成Jar包運(yùn)行在服務(wù)器上。項(xiàng)目根目錄下一般會(huì)分成兩個(gè)部分frontend目錄Vue項(xiàng)目包含管理后臺(tái)的頁面、路由、狀態(tài)管理、API請(qǐng)求封裝。backend目錄SpringBoot項(xiàng)目包含Controller、Service、Mapper、實(shí)體類、配置類。這種結(jié)構(gòu)最大的好處是團(tuán)隊(duì)協(xié)作時(shí)可以并行開發(fā)。前端根據(jù)接口文檔定義Mock數(shù)據(jù)后端把接口實(shí)現(xiàn)好之后聯(lián)調(diào)即可。即便一個(gè)人開發(fā)分開寫也能讓思維更清晰不會(huì)在改前端樣式的時(shí)候被后端代碼干擾。后端內(nèi)部我做了一層嚴(yán)格的分層Controller只負(fù)責(zé)參數(shù)接收和結(jié)果返回Service負(fù)責(zé)業(yè)務(wù)邏輯Mapper負(fù)責(zé)數(shù)據(jù)庫操作。舉個(gè)例子課程上下架這個(gè)操作Controller接收課程IDService層做狀態(tài)校驗(yàn)和數(shù)據(jù)更新Mapper層執(zhí)行更新SQL。這樣做的好處是業(yè)務(wù)邏輯可以復(fù)用后面再加一個(gè)“批量上下架”的接口只需要在Service層加方法不用重寫SQL。接口設(shè)計(jì)遵循RESTful風(fēng)格資源用名詞表示動(dòng)作用HTTP方法表達(dá)請(qǐng)求方法路徑作用POST/api/auth/login登錄GET/api/courses課程列表POST/api/courses新增課程PUT/api/courses/{id}更新課程DELETE/api/courses/{id}刪除課程GET/api/courses/{id}/chapters課程章節(jié)列表GET/api/users/{id}/learning-records用戶學(xué)習(xí)記錄統(tǒng)一返回結(jié)構(gòu)也是前后端分離項(xiàng)目必須處理的。我習(xí)慣用Result對(duì)象包裝所有接口返回值包含code、message、data三個(gè)字段。code為200表示成功非200表示失敗。這樣前端攔截器可以統(tǒng)一處理錯(cuò)誤提示和登錄失效不用每個(gè)接口單獨(dú)判斷。2.2 數(shù)據(jù)庫怎么設(shè)計(jì)才扛得住真實(shí)業(yè)務(wù)數(shù)據(jù)庫設(shè)計(jì)是我在這個(gè)項(xiàng)目里花時(shí)間最多的地方也是最能體現(xiàn)功力的部分。在線教育系統(tǒng)的核心表我梳理出來大概有這幾張用戶表、角色表、用戶角色關(guān)聯(lián)表、課程分類表、課程表、章節(jié)表、學(xué)習(xí)記錄表、訂單表。用戶表要區(qū)分管理員、講師、學(xué)員但我不建議在用戶表里直接用type字段走天下。更合理的做法是做好角色關(guān)聯(lián)一個(gè)用戶可能既是講師也是某個(gè)課程的學(xué)員。我用的方案是獨(dú)立的用戶表加用戶角色關(guān)聯(lián)表用戶表存基礎(chǔ)賬號(hào)信息角色表存角色定義中間表把兩者關(guān)聯(lián)起來。這樣后續(xù)要擴(kuò)展角色權(quán)限不需要改表結(jié)構(gòu)。課程表是業(yè)務(wù)的中心字段上除了課程名稱、封面圖、簡(jiǎn)介、價(jià)格這些基礎(chǔ)信息還有幾個(gè)關(guān)鍵字段需要特別設(shè)計(jì)status課程狀態(tài)草稿、已上架、已下架。用數(shù)字表示避免字符串在不同地方寫法不一致。teacher_id歸屬講師的用戶ID。這里建議存普通索引不要建外鍵約束在線教育系統(tǒng)查詢頻繁外鍵約束會(huì)影響插入和刪除性能。category_id課程分類ID。分類一般是樹形結(jié)構(gòu)為了簡(jiǎn)化處理第一版可以只做一級(jí)分類后續(xù)再擴(kuò)展父子關(guān)系。publish_time上架時(shí)間用于列表排序和運(yùn)營數(shù)據(jù)分析。章節(jié)表要掛在課程下面包含章節(jié)標(biāo)題、排序號(hào)、視頻地址、是否免費(fèi)試看。排序號(hào)非常重要章節(jié)本來就是有序的不能依賴創(chuàng)建時(shí)間排序必須顯式維護(hù)sort字段。免費(fèi)試看字段在課程詳情頁和試看邏輯中都會(huì)用到。學(xué)習(xí)記錄表是我特別想強(qiáng)調(diào)的。真實(shí)場(chǎng)景中學(xué)員學(xué)習(xí)課程會(huì)產(chǎn)生大量記錄這張表需要同時(shí)關(guān)聯(lián)用戶、章節(jié)、課程再用一個(gè)watch_time記錄看到第幾秒用status標(biāo)記是否完成。每次前端上報(bào)學(xué)習(xí)進(jìn)度都會(huì)更新這張表所以它是全系統(tǒng)寫入頻率最高的表之一要建聯(lián)合索引(user_id, chapter_id)避免查詢時(shí)全表掃描。訂單表在初版可以做成簡(jiǎn)單的報(bào)名記錄表包含用戶ID、課程ID、支付金額、訂單狀態(tài)。純后臺(tái)管理場(chǎng)景下重點(diǎn)是把“用戶買了哪些課程”這個(gè)關(guān)系查清楚方便做學(xué)習(xí)記錄的權(quán)限校驗(yàn)。支付流程的復(fù)雜度可以放到第二階段再考慮。所有業(yè)務(wù)表我都保留了三個(gè)通用字段create_time、update_time、deleted。邏輯刪除用0和1表示而不是物理刪除數(shù)據(jù)。在線教育后臺(tái)誤刪操作的場(chǎng)景不少比如課程下架時(shí)如果物理刪了運(yùn)營想恢復(fù)就麻煩了。邏輯刪除讓數(shù)據(jù)始終可追溯查詢時(shí)統(tǒng)一加WHERE deleted 0條件即可。2.3 模塊劃分與核心業(yè)務(wù)流程整個(gè)系統(tǒng)的模塊劃分我按業(yè)務(wù)域來拆不按技術(shù)層拆。每個(gè)模塊是一個(gè)獨(dú)立的包結(jié)構(gòu)包含自己的Controller、Service、Mapper。主要有這幾個(gè)模塊認(rèn)證授權(quán)模塊登錄、JWT生成與校驗(yàn)、權(quán)限注解。用戶管理模塊用戶CRUD、角色分配、講師審核。課程管理模塊課程、章節(jié)、分類的維護(hù)。學(xué)習(xí)模塊學(xué)習(xí)記錄上報(bào)、課程進(jìn)度查詢。統(tǒng)計(jì)模塊簡(jiǎn)單的數(shù)據(jù)統(tǒng)計(jì)接口比如課程報(bào)名人數(shù)、學(xué)員完成率。核心業(yè)務(wù)流程里最值得理清楚的一條是“學(xué)員學(xué)習(xí)課程”。學(xué)員登錄后獲取自己的課程列表進(jìn)入課程詳情查看章節(jié)列表。前端在視頻播放時(shí)每隔一段時(shí)間上報(bào)學(xué)習(xí)進(jìn)度后端收到請(qǐng)求后更新學(xué)習(xí)記錄表。如果某章節(jié)已經(jīng)達(dá)到完成閾值就把狀態(tài)標(biāo)記為已完成。課程總體進(jìn)度在列表頁通過匯總該課程下已完成章節(jié)數(shù)除以總章節(jié)數(shù)來計(jì)算。這個(gè)流程看起來簡(jiǎn)單但里面涉及并發(fā)和冪等的問題如果前端一秒上報(bào)一次后端怎么做去重如果用戶斷網(wǎng)重連學(xué)習(xí)記錄會(huì)不會(huì)重復(fù)插入我后面在踩坑部分會(huì)詳細(xì)說解決辦法。這里先記住一個(gè)原則學(xué)習(xí)記錄表不能無腦每次插入新數(shù)據(jù)而是先查再更新最好用唯一索引兜底。3. 核心功能實(shí)操從0到1跑起來3.1 環(huán)境準(zhǔn)備與項(xiàng)目初始化先把環(huán)境準(zhǔn)備好。后端需要JDK 8或11、Maven 3.6以上版本、MySQL 5.7或8.0。前端需要Node.js 14以上npm 6以上。如果機(jī)器上裝的是新版本比如JDK 17也沒問題只要對(duì)應(yīng)SpringBoot版本支持。我這邊用的SpringBoot 2.7.x兼容JDK 8到17穩(wěn)一點(diǎn)。后端項(xiàng)目初始化推薦直接在IDEA里新建Spring Initializr項(xiàng)目選好JDK版本和依賴。需要引入的依賴有spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-java、lombok、spring-boot-starter-validation、jjwt。application.yml配置是最開始就要寫對(duì)的server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/edu_platform?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.edu.entity configuration: map-underscore-to-camel-case: truemap-underscore-to-camel-case這個(gè)配置很容易被忽略但它非常關(guān)鍵。數(shù)據(jù)庫字段是create_time這種下劃線風(fēng)格Java實(shí)體類是createTime這種駝峰風(fēng)格開啟這個(gè)配置后MyBatis會(huì)自動(dòng)映射。否則你就要在每條SQL里寫別名非常痛苦。前端項(xiàng)目初始化用Vue CLI或Vite都可以。我的建議是直接用Vue CLI創(chuàng)建生態(tài)穩(wěn)定模板工程對(duì)后臺(tái)管理系統(tǒng)非常友好。創(chuàng)建命令npm install -g vue/cli vue create edu-frontend創(chuàng)建時(shí)選手動(dòng)配置勾選Vue Router、Vuex和Axios。進(jìn)入項(xiàng)目后先安裝Element UI作為后臺(tái)管理界面的組件庫npm install element-ui npm install axiosElement UI的表格、表單、彈窗、分頁組件都非常成熟做管理后臺(tái)幾乎不用自己造輪子。3.2 后端核心模塊JWT認(rèn)證與攔截管理后臺(tái)的安全控制是第一優(yōu)先級(jí)。這套系統(tǒng)用的是JWT方案用戶登錄成功后后端生成一個(gè)帶過期時(shí)間的Token返回給前端前端每次請(qǐng)求都把這個(gè)Token放在HTTP請(qǐng)求頭里后端攔截器校驗(yàn)Token的合法性并解析出用戶信息。先定義一個(gè)簡(jiǎn)單的JWT工具類Component public class JwtUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expire}) private Long expire; public String generateToken(Integer userId, String username) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() expire)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); } }登錄接口的Service層邏輯根據(jù)用戶名查到用戶校驗(yàn)密碼是否一致校驗(yàn)通過就生成Token返回。密碼存儲(chǔ)不能是明文至少要用MD5加鹽或者BCrypt加密。我在項(xiàng)目里用的是BCryptSpring Security的加密工具類可以直接調(diào)比自寫MD5穩(wěn)妥得多。攔截器是JWT校驗(yàn)的核心。我寫了一個(gè)AuthInterceptor在請(qǐng)求進(jìn)入Controller之前攔截public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equals(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); } try { Claims claims JwtUtil.parseToken(token); request.setAttribute(userId, claims.get(userId)); return true; } catch (Exception e) { response.setStatus(401); response.setContentType(application/json); response.getWriter().write({\code\:401,\message\:\登錄已過期\}); return false; } } }這里有兩個(gè)容易踩的坑第一OPTIONS預(yù)檢請(qǐng)求必須放行否則前端跨域請(qǐng)求會(huì)被攔截器擋掉。第二攔截器里校驗(yàn)失敗時(shí)要直接返回JSON而不是讓Spring再走異常處理流程避免前端拿到一堆HTML錯(cuò)誤頁面。權(quán)限控制方面我用了自定義注解RequireRole標(biāo)注在Controller方法上比如講師管理接口只允許ROLE_ADMIN訪問。攔截器解析Token后拿到用戶ID再查一次數(shù)據(jù)庫得到角色信息校驗(yàn)是否符合注解要求。這個(gè)方法雖然每請(qǐng)求多查一次數(shù)據(jù)庫但勝在實(shí)現(xiàn)簡(jiǎn)單清晰對(duì)于后端管理系統(tǒng)的并發(fā)量來說完全夠用。3.3 前端頁面對(duì)接與接口聯(lián)調(diào)前端的核心是把請(qǐng)求封裝好后續(xù)頁面調(diào)用時(shí)不用重復(fù)處理Token和錯(cuò)誤提示。我在src目錄下建了一個(gè)api文件夾統(tǒng)一封裝axios實(shí)例import axios from axios import { Message } from element-ui import router from ../router const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message || 請(qǐng)求失敗) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { router.push(/login) } Message.error(error.message) return Promise.reject(error) } ) export default serviceVue頁面開發(fā)時(shí)最常用的是表格加彈窗表單的組合。以課程管理頁面為例頁面加載時(shí)調(diào)用GET /api/courses獲取列表點(diǎn)擊新增按鈕彈出表單對(duì)話框提交時(shí)調(diào)用POST /api/courses。這種模式幾乎覆蓋了后臺(tái)管理系統(tǒng)80%的頁面?？缬騿栴}是前后端分離聯(lián)調(diào)時(shí)最常見的問題。開發(fā)環(huán)境下Vue項(xiàng)目默認(rèn)跑在8080端口后端跑在8080端口這兩者之間就是跨域請(qǐng)求。我用的解決辦法是在后端加CORS配置 java Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .maxAge(3600); } }生產(chǎn)環(huán)境會(huì)更好處理前端打包成靜態(tài)文件后由Nginx提供服務(wù)然后用反向代理把/api路徑轉(zhuǎn)發(fā)到后端服務(wù)。這樣瀏覽器看到的始終是同源請(qǐng)求不需要后端處理跨域。開發(fā)環(huán)境用CORS配置生產(chǎn)環(huán)境用Nginx反向代理這是比較標(biāo)準(zhǔn)的做法。3.4 學(xué)習(xí)進(jìn)度上報(bào)接口的實(shí)現(xiàn)細(xì)節(jié)學(xué)習(xí)進(jìn)度接口是整個(gè)系統(tǒng)里最貼近真實(shí)使用場(chǎng)景的一個(gè)功能值得單獨(dú)拿出來講。前端在視頻播放時(shí)每隔15秒調(diào)一次上報(bào)接口傳遞userId、chapterId、watchTime、duration。后端收到請(qǐng)求后先查詢是否已經(jīng)有這條學(xué)習(xí)記錄沒有就插入有就更新watchTime。學(xué)習(xí)記錄完成狀態(tài)的判定不能死板。我的做法是當(dāng)watchTime大于等于duration的90%或者當(dāng)前端主動(dòng)標(biāo)記manualFinish為true時(shí)把status改為完成。為什么是90%而不是100%因?yàn)橛脩艉芸赡芴^結(jié)尾演職人員表或者視頻最后幾秒網(wǎng)絡(luò)卡頓強(qiáng)制要求100%反而會(huì)讓用戶覺得系統(tǒng)很死板。事務(wù)在這里要注意先查再插再更新整體操作要加Transactional防止插入記錄和更新狀態(tài)之間出現(xiàn)異常導(dǎo)致數(shù)據(jù)不一致。具體代碼邏輯大概是Transactional public void reportLearningProgress(ProgressRequest request) { LearningRecord record learningRecordMapper.selectByUserAndChapter( request.getUserId(), request.getChapterId()); if (record null) { record new LearningRecord(); record.setUserId(request.getUserId()); record.setChapterId(request.getChapterId()); record.setWatchTime(request.getWatchTime()); record.setStatus(0); learningRecordMapper.insert(record); } else { record.setWatchTime(request.getWatchTime()); if (request.getWatchTime() request.getDuration() * 0.9) { record.setStatus(1); } learningRecordMapper.update(record); } }并發(fā)上報(bào)時(shí)如果我第一次請(qǐng)求和第二次請(qǐng)求幾乎同時(shí)到達(dá)可能會(huì)插入兩條記錄。更穩(wěn)妥的做法是在數(shù)據(jù)庫層面給(user_id, chapter_id)加上聯(lián)合唯一索引讓數(shù)據(jù)庫幫你兜底重復(fù)插入直接報(bào)錯(cuò)代碼里再捕獲異常做更新處理。算法層面的冪等控制永遠(yuǎn)沒有數(shù)據(jù)庫約束可靠這個(gè)是我實(shí)際測(cè)試出來的教訓(xùn)。4. 真實(shí)開發(fā)中踩過的坑與排查技巧4.1 事務(wù)失效和數(shù)據(jù)一致性問題在線教育系統(tǒng)里事務(wù)用得多但很多人寫事務(wù)時(shí)都會(huì)忽略幾個(gè)讓人頭疼的場(chǎng)景。最典型的在同一個(gè)類里A方法調(diào)用B方法B方法上面標(biāo)了Transactional但是事務(wù)不生效。原因很簡(jiǎn)單Spring的事務(wù)是通過AOP代理實(shí)現(xiàn)的類內(nèi)部的方法調(diào)用走的是this不會(huì)經(jīng)過代理對(duì)象事務(wù)注解就被跳過了。解決辦法是把需要事務(wù)的方法放到另一個(gè)Service類里或者自己從容器中獲取代理對(duì)象再調(diào)用。另一個(gè)常見問題是事務(wù)內(nèi)做遠(yuǎn)程調(diào)用。比如學(xué)習(xí)進(jìn)度上報(bào)時(shí)如果先是更新學(xué)習(xí)記錄再調(diào)用短信服務(wù)通知用戶短信服務(wù)響應(yīng)很慢事務(wù)會(huì)一直持有數(shù)據(jù)庫連接不釋放最終導(dǎo)致連接池耗盡。我的處理原則是事務(wù)里只做數(shù)據(jù)庫操作遠(yuǎn)程調(diào)用放到事務(wù)提交之后通過事件或異步方式處理。數(shù)據(jù)一致性還體現(xiàn)在課程狀態(tài)上。課程刪除時(shí)如果直接把課程表里的記錄刪除那么學(xué)員的學(xué)習(xí)記錄表里就有大量懸空數(shù)據(jù)課程列表查詢也會(huì)出問題。這就是為什么我在前面強(qiáng)調(diào)邏輯刪除字段。課程下架的時(shí)候只更新deleted1學(xué)習(xí)記錄表里的數(shù)據(jù)還能正常關(guān)聯(lián)到課程歷史快照信息。4.2 接口性能瓶頸與優(yōu)化這套系統(tǒng)在數(shù)據(jù)量小的時(shí)候跑起來很順暢一旦數(shù)據(jù)庫里課程、用戶、學(xué)習(xí)記錄都到了幾十萬條性能問題就會(huì)暴露。最讓我印象深刻的場(chǎng)景是課程列表頁每次查詢課程列表都要統(tǒng)計(jì)報(bào)名人數(shù)和章節(jié)數(shù)如果使用寫死的SQL把所有數(shù)據(jù)都拆出來N1查詢問題馬上就來了。N1查詢的意思是先用一條SQL查出課程列表再對(duì)每個(gè)課程循環(huán)查詢學(xué)員數(shù)量。課程越多查詢次數(shù)越多接口響應(yīng)時(shí)間直線上升。解決辦法是用聯(lián)表查詢或子查詢一次拿到所有需要的數(shù)據(jù)。MyBatis里寫一個(gè)聚合SQL就能解決比如SELECT c.id, c.title, (SELECT COUNT(*) FROM orders o WHERE o.course_id c.id) AS student_count FROM course c WHERE c.deleted 0分頁查詢的深度分頁問題也要注意。當(dāng)使用LIMIT 100000, 20這種查詢時(shí)MySQL還是要掃描前100000條記錄效率很低。優(yōu)化思路有兩種一是使用WHERE id lastId的方式做游標(biāo)分頁適合移動(dòng)端無限滾動(dòng)場(chǎng)景二是給排序字段和篩選條件建立聯(lián)合索引讓數(shù)據(jù)庫盡量走索引覆蓋。后臺(tái)表格用普通分頁就好前端一覽式的數(shù)據(jù)列表建議用游標(biāo)分頁。學(xué)習(xí)記錄表寫入頻繁建議按用戶維度做緩存。用戶打開課程列表時(shí)不需要實(shí)時(shí)統(tǒng)計(jì)每個(gè)課程的學(xué)習(xí)進(jìn)度可以把進(jìn)度數(shù)據(jù)緩存到Redis里設(shè)置5分鐘過期。用戶每次上報(bào)進(jìn)度時(shí)更新一次Redis頁面展示時(shí)讀緩存只有管理員看統(tǒng)計(jì)報(bào)表時(shí)才查數(shù)據(jù)庫。這樣可以顯著降低數(shù)據(jù)庫壓力。4.3 部署上線時(shí)的細(xì)節(jié)處理本地開發(fā)跑通了部署又是半個(gè)坑。SpringBoot后端打包時(shí)要特別注意配置文件。開發(fā)環(huán)境連的是本地?cái)?shù)據(jù)庫服務(wù)器上用的是云數(shù)據(jù)庫不能把本地?cái)?shù)據(jù)庫地址直接打包進(jìn)去。我建議把a(bǔ)pplication.yml拆成三個(gè)環(huán)境application-dev.yml、application-test.yml、application-prod.yml。打包時(shí)通過spring.profiles.active指定環(huán)境部署命令類似java -jar edu-backend.jar --spring.profiles.activeprod前端部署要處理的是路由模式。Vue Router如果用了history模式Nginx需要配置try_files把請(qǐng)求都重定向到index.html。否則前端頁面一刷新Nginx就會(huì)報(bào)404這個(gè)問題太經(jīng)典了。Nginx配置大概長這樣location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }生產(chǎn)環(huán)境還有一個(gè)容易忽略的點(diǎn)MySQL的時(shí)區(qū)問題。如果后端配置了serverTimezoneAsia/Shanghai但MySQL服務(wù)器用的是UTC查出來直接更新到數(shù)據(jù)庫你會(huì)發(fā)現(xiàn)時(shí)間晚了8小時(shí)。最好的辦法是把MySQL的全局時(shí)區(qū)也設(shè)置為東八區(qū)同時(shí)在后端配置里保持一致雙重確認(rèn)。4.4 前端聯(lián)調(diào)中的常見問題速查我在聯(lián)調(diào)階段遇到過不少前端問題整理成一張表現(xiàn)象原因解決辦法請(qǐng)求返回401但登錄頁沒跳攔截器里處理的是response error但HTTP狀態(tài)碼可能被axios攔了檢查response攔截器的error分支表格數(shù)據(jù)不顯示后端返回的字段和前端表頭字段不一致統(tǒng)一使用駝峰命名開啟MyBatis駝峰映射表單提交后列表不刷新提交成功后沒有重新調(diào)用列表接口在成功回調(diào)里重新查詢當(dāng)前頁數(shù)據(jù)上傳圖片失敗跨域請(qǐng)求被Nginx或CORS配置攔截檢查Nginx的client_max_body_sizeToken過期后頁面卡死401后沒有清理本地存儲(chǔ)和跳轉(zhuǎn)攔截器里清空localStorage后跳登錄頁聯(lián)調(diào)是前后端項(xiàng)目里最容易扯皮也最容易拖時(shí)間的環(huán)節(jié)。我的習(xí)慣是先在前端Mock數(shù)據(jù)把頁面寫完所有字段類型和接口路徑都按真實(shí)約定來后端接口出了之后把Mock地址切到真實(shí)地址沖突就會(huì)少很多。5. 從能用做到好用擴(kuò)展與經(jīng)驗(yàn)沉淀5.1 演示項(xiàng)目到線上項(xiàng)目差在哪很多開發(fā)者做的在線教育系統(tǒng)功能看著都有但離真正上線還有一段距離。最大的差距在容錯(cuò)和可觀測(cè)性。演示項(xiàng)目里接口掛了只會(huì)刷新重來線上系統(tǒng)要求的是接口異常時(shí)有日志、有告警、有兜底數(shù)據(jù)。我在后期給這套系統(tǒng)加了全局異常處理類統(tǒng)一捕獲業(yè)務(wù)異常和未知異常記錄日志并返回友好提示。加上操作日志模塊后臺(tái)管理員每次上下架課程、修改用戶信息都會(huì)記錄操作者和時(shí)間出了問題能追溯到人。數(shù)據(jù)層面線上系統(tǒng)還要求備份策略。MySQL備份不只是mysqldump命令而是要有全量備份加增量日志。我建議至少每天全量備份一次同時(shí)開啟binlog。這樣即使誤操作刪了數(shù)據(jù)也能恢復(fù)到指定的時(shí)間點(diǎn)對(duì)在線教育這種運(yùn)營人員直接操作系統(tǒng)的情況非常關(guān)鍵。5.2 個(gè)人調(diào)試效率技巧幾個(gè)能明顯提升開發(fā)效率的小習(xí)慣。后端接口測(cè)試與其頻繁起一個(gè)前端頁面去點(diǎn)不如直接用接口測(cè)試工具把所有接口集合保存下來。后端改完接口跑一遍集合就能知道有沒有破壞已有功能。前端調(diào)試時(shí)多用瀏覽器的Network面板看接口耗時(shí)和響應(yīng)體比反復(fù)加console快得多。SQL排查我習(xí)慣在MyBatis的XML里寫注釋把業(yè)務(wù)背景和參數(shù)含義寫明。半年后自己回頭維護(hù)代碼或者讓另一個(gè)同事接手這些注釋的價(jià)值遠(yuǎn)大于代碼層的注釋。遇到過太多次寫的SQL自己都看不懂的情況。聯(lián)調(diào)時(shí)前端報(bào)錯(cuò)第一反應(yīng)不是去懷疑后端邏輯而是先打開瀏覽器控制臺(tái)把Full Request URL復(fù)制出來直接在接口工具里重放一遍。如果接口工具返回正常那就是前端傳參問題如果接口工具也報(bào)錯(cuò)再往后端查。這個(gè)排除法能省下大量溝通成本。5.3 后續(xù)可以怎么擴(kuò)展這套系統(tǒng)留了幾個(gè)明確的擴(kuò)展點(diǎn)。課程播放頁面可以接入真正的前端視頻播放器配合學(xué)習(xí)記錄接口做續(xù)播功能。權(quán)限方面可以把方法級(jí)別的注解權(quán)限升級(jí)成細(xì)粒度按鈕權(quán)限前端根據(jù)用戶權(quán)限動(dòng)態(tài)渲染按鈕。統(tǒng)計(jì)報(bào)表可以引入定時(shí)任務(wù)每天早上匯總前一天的學(xué)員活躍、課程報(bào)名數(shù)據(jù)生成運(yùn)營日?qǐng)?bào)。如果后續(xù)還需要支持多人同時(shí)觀看直播課那就要考慮引入消息推送和WebRTC相關(guān)技術(shù)這部分和當(dāng)前管理后臺(tái)是相對(duì)獨(dú)立的模塊。架構(gòu)上保持模塊清晰技術(shù)升級(jí)不會(huì)影響已有功能?；仡^再看這個(gè)項(xiàng)目的價(jià)值不只是把SpringBootVue這套技術(shù)棧跑通而是通過在線教育這個(gè)真實(shí)業(yè)務(wù)場(chǎng)景把權(quán)限、事務(wù)、性能、部署這些后端開發(fā)的硬骨頭都過了一遍。我在實(shí)際調(diào)試過程中最大的體會(huì)是很多問題都是到數(shù)據(jù)量上去之后才暴露出來的單純寫單測(cè)或者跑小樣本數(shù)據(jù)根本發(fā)現(xiàn)不了。所以做這類管理系統(tǒng)一定在一開始就按真實(shí)數(shù)據(jù)量去設(shè)計(jì)表結(jié)構(gòu)和索引不要等線上卡死才回頭改模型。最后分享一個(gè)小技巧課程表和學(xué)習(xí)記錄表這種高頻訪問的表主鍵不要用UUID字符串用自增整型主鍵就好。SQL里做JOIN時(shí)整型主鍵的索引效率和存儲(chǔ)空間都遠(yuǎn)優(yōu)于字符串。一套字段設(shè)計(jì)要經(jīng)得起未來幾年的數(shù)據(jù)增長這才是后端開發(fā)的核心功底。 SpringBoot+Vue前后端分離在線教育平臺(tái)管理系統(tǒng)實(shí)戰(zhàn)
做在線教育平臺(tái)管理系統(tǒng)這個(gè)項(xiàng)目是我把SpringBootVue這套前后端分離架構(gòu)完整跑通的一次實(shí)戰(zhàn)。整套代碼覆蓋了在線教育后臺(tái)最核心的幾條業(yè)務(wù)鏈課程管理、講師信息維護(hù)、學(xué)員學(xué)習(xí)記錄、后臺(tái)賬號(hào)權(quán)限、訂單報(bào)名數(shù)據(jù)。技術(shù)棧很固定SpringBoot做后端服務(wù)MyBatis負(fù)責(zé)持久層SQLMySQL存業(yè)務(wù)數(shù)據(jù)前端用Vue寫管理界面。這篇文章不打算寫那種面面俱到的官方文檔而是從實(shí)際落地角度把架構(gòu)拆分、數(shù)據(jù)庫設(shè)計(jì)、核心接口實(shí)現(xiàn)、踩坑記錄這幾塊講透。適合正在做畢業(yè)設(shè)計(jì)、準(zhǔn)備面試項(xiàng)目、或者想從零把一套在線教育后臺(tái)跑起來的開發(fā)者參考。1. 項(xiàng)目到底解決了什么問題1.1 在線教育系統(tǒng)的核心需求拆解很多人第一次拿到在線教育平臺(tái)這種需求第一反應(yīng)是“不就是課程列表加個(gè)播放器嗎”。真做起來就發(fā)現(xiàn)后臺(tái)管理系統(tǒng)的復(fù)雜度遠(yuǎn)高于前臺(tái)展示頁。在線教育平臺(tái)的管理后臺(tái)至少需要覆蓋這幾個(gè)角色和場(chǎng)景管理員要能夠維護(hù)課程上下架、審核講師入駐、查看平臺(tái)運(yùn)營數(shù)據(jù)。講師需要上傳課程章節(jié)、管理題庫、布置作業(yè)、查看自己負(fù)責(zé)班級(jí)的學(xué)習(xí)情況。學(xué)員則需要查看已購課程、記錄學(xué)習(xí)進(jìn)度、完成章節(jié)測(cè)試。如果再往復(fù)雜了說還有優(yōu)惠券、直播課、班級(jí)分組、多校區(qū)權(quán)限但最核心的底座永遠(yuǎn)是課程和用戶兩條線。我做的這個(gè)系統(tǒng)核心定位是后臺(tái)管理端加簡(jiǎn)單的學(xué)員端查詢能力。把“課程維護(hù)—講師管理—學(xué)員管理—學(xué)習(xí)記錄”這條主鏈路打通。為什么要先做后臺(tái)而不是前臺(tái)因?yàn)樵诰€教育平臺(tái)的真實(shí)瓶頸幾乎都出在內(nèi)容維護(hù)和權(quán)限控制上。前臺(tái)頁面再花哨后臺(tái)如果連課程上下架、講師角色權(quán)限都理不清楚業(yè)務(wù)根本跑不起來。需求梳理階段我習(xí)慣把功能拆成“必須要有”和“有了更好”兩類。必須有的用戶登錄注冊(cè)、角色權(quán)限、課程分類、課程與章節(jié)管理、講師資料維護(hù)、學(xué)員學(xué)習(xí)進(jìn)度記錄。可以后補(bǔ)的直播互動(dòng)、課程評(píng)論、積分系統(tǒng)、數(shù)據(jù)報(bào)表大屏。這套系統(tǒng)在初版把“必須有”的做扎實(shí)后續(xù)擴(kuò)展時(shí)再往上面加模塊結(jié)構(gòu)不會(huì)亂。1.2 為什么選SpringBootVueMyBatis這套組合說句實(shí)在話在線教育管理系統(tǒng)這種CRUD密集型業(yè)務(wù)用很多技術(shù)棧都能做。但選SpringBootVueMyBatisMySQL不是跟風(fēng)而是這套組合在“開發(fā)效率、維護(hù)成本、上手難度”三個(gè)維度上非常均衡。SpringBoot解決的是后端基礎(chǔ)設(shè)施的繁瑣問題。以前用Spring MVC搭項(xiàng)目要寫一堆XML配置現(xiàn)在SpringBoot通過自動(dòng)配置和Starter機(jī)制把大部分常見場(chǎng)景都預(yù)設(shè)好了。你只需要引入依賴寫少量配置就能把Web服務(wù)跑起來。對(duì)于以業(yè)務(wù)邏輯為主的系統(tǒng)這種“開箱即用”的體驗(yàn)非常舒服。Vue在前端的優(yōu)勢(shì)是組件化開發(fā)。后臺(tái)管理界面有大量重復(fù)的表格、表單、彈窗場(chǎng)景用組件封裝之后寫一個(gè)新頁面就是組合幾個(gè)組件的事。Vue的響應(yīng)式數(shù)據(jù)綁定也讓表單交互和列表篩選省了很多精力不需要手動(dòng)操作DOM。MyBatis經(jīng)常被拿來和JPA對(duì)比。我的個(gè)人觀點(diǎn)是在線教育系統(tǒng)里面高級(jí)查詢和統(tǒng)計(jì)SQL特別多比如“查詢某講師名下所有課程的學(xué)員完成率”用MyBatis寫SQL可以精確控制語句排查問題也直觀。JPA雖然寫簡(jiǎn)單CRUD很爽但一旦遇到復(fù)雜動(dòng)態(tài)SQL調(diào)試成本會(huì)明顯上升。MyBatis的靈活性和可控性在這個(gè)場(chǎng)景里更值得選。MySQL就更不用多說了成熟的社區(qū)生態(tài)、豐富的文檔、對(duì)事務(wù)的支持足夠支撐在線教育平臺(tái)這個(gè)體量的數(shù)據(jù)。真正要關(guān)心的是表結(jié)構(gòu)設(shè)計(jì)和索引優(yōu)化這個(gè)放到后面數(shù)據(jù)庫部分詳細(xì)講。2. 系統(tǒng)整體架構(gòu)與模塊設(shè)計(jì)2.1 前后端分離的整體思路這套系統(tǒng)的架構(gòu)不復(fù)雜就是標(biāo)準(zhǔn)的前后端分離Vue前端通過HTTP請(qǐng)求訪問SpringBoot后端的RESTful接口后端操作MySQL數(shù)據(jù)庫。前后端分別開發(fā)、分別部署前端打包成靜態(tài)文件丟到Nginx后端打成Jar包運(yùn)行在服務(wù)器上。項(xiàng)目根目錄下一般會(huì)分成兩個(gè)部分frontend目錄Vue項(xiàng)目包含管理后臺(tái)的頁面、路由、狀態(tài)管理、API請(qǐng)求封裝。backend目錄SpringBoot項(xiàng)目包含Controller、Service、Mapper、實(shí)體類、配置類。這種結(jié)構(gòu)最大的好處是團(tuán)隊(duì)協(xié)作時(shí)可以并行開發(fā)。前端根據(jù)接口文檔定義Mock數(shù)據(jù)后端把接口實(shí)現(xiàn)好之后聯(lián)調(diào)即可。即便一個(gè)人開發(fā)分開寫也能讓思維更清晰不會(huì)在改前端樣式的時(shí)候被后端代碼干擾。后端內(nèi)部我做了一層嚴(yán)格的分層Controller只負(fù)責(zé)參數(shù)接收和結(jié)果返回Service負(fù)責(zé)業(yè)務(wù)邏輯Mapper負(fù)責(zé)數(shù)據(jù)庫操作。舉個(gè)例子課程上下架這個(gè)操作Controller接收課程IDService層做狀態(tài)校驗(yàn)和數(shù)據(jù)更新Mapper層執(zhí)行更新SQL。這樣做的好處是業(yè)務(wù)邏輯可以復(fù)用后面再加一個(gè)“批量上下架”的接口只需要在Service層加方法不用重寫SQL。接口設(shè)計(jì)遵循RESTful風(fēng)格資源用名詞表示動(dòng)作用HTTP方法表達(dá)請(qǐng)求方法路徑作用POST/api/auth/login登錄GET/api/courses課程列表POST/api/courses新增課程PUT/api/courses/{id}更新課程DELETE/api/courses/{id}刪除課程GET/api/courses/{id}/chapters課程章節(jié)列表GET/api/users/{id}/learning-records用戶學(xué)習(xí)記錄統(tǒng)一返回結(jié)構(gòu)也是前后端分離項(xiàng)目必須處理的。我習(xí)慣用Result對(duì)象包裝所有接口返回值包含code、message、data三個(gè)字段。code為200表示成功非200表示失敗。這樣前端攔截器可以統(tǒng)一處理錯(cuò)誤提示和登錄失效不用每個(gè)接口單獨(dú)判斷。2.2 數(shù)據(jù)庫怎么設(shè)計(jì)才扛得住真實(shí)業(yè)務(wù)數(shù)據(jù)庫設(shè)計(jì)是我在這個(gè)項(xiàng)目里花時(shí)間最多的地方也是最能體現(xiàn)功力的部分。在線教育系統(tǒng)的核心表我梳理出來大概有這幾張用戶表、角色表、用戶角色關(guān)聯(lián)表、課程分類表、課程表、章節(jié)表、學(xué)習(xí)記錄表、訂單表。用戶表要區(qū)分管理員、講師、學(xué)員但我不建議在用戶表里直接用type字段走天下。更合理的做法是做好角色關(guān)聯(lián)一個(gè)用戶可能既是講師也是某個(gè)課程的學(xué)員。我用的方案是獨(dú)立的用戶表加用戶角色關(guān)聯(lián)表用戶表存基礎(chǔ)賬號(hào)信息角色表存角色定義中間表把兩者關(guān)聯(lián)起來。這樣后續(xù)要擴(kuò)展角色權(quán)限不需要改表結(jié)構(gòu)。課程表是業(yè)務(wù)的中心字段上除了課程名稱、封面圖、簡(jiǎn)介、價(jià)格這些基礎(chǔ)信息還有幾個(gè)關(guān)鍵字段需要特別設(shè)計(jì)status課程狀態(tài)草稿、已上架、已下架。用數(shù)字表示避免字符串在不同地方寫法不一致。teacher_id歸屬講師的用戶ID。這里建議存普通索引不要建外鍵約束在線教育系統(tǒng)查詢頻繁外鍵約束會(huì)影響插入和刪除性能。category_id課程分類ID。分類一般是樹形結(jié)構(gòu)為了簡(jiǎn)化處理第一版可以只做一級(jí)分類后續(xù)再擴(kuò)展父子關(guān)系。publish_time上架時(shí)間用于列表排序和運(yùn)營數(shù)據(jù)分析。章節(jié)表要掛在課程下面包含章節(jié)標(biāo)題、排序號(hào)、視頻地址、是否免費(fèi)試看。排序號(hào)非常重要章節(jié)本來就是有序的不能依賴創(chuàng)建時(shí)間排序必須顯式維護(hù)sort字段。免費(fèi)試看字段在課程詳情頁和試看邏輯中都會(huì)用到。學(xué)習(xí)記錄表是我特別想強(qiáng)調(diào)的。真實(shí)場(chǎng)景中學(xué)員學(xué)習(xí)課程會(huì)產(chǎn)生大量記錄這張表需要同時(shí)關(guān)聯(lián)用戶、章節(jié)、課程再用一個(gè)watch_time記錄看到第幾秒用status標(biāo)記是否完成。每次前端上報(bào)學(xué)習(xí)進(jìn)度都會(huì)更新這張表所以它是全系統(tǒng)寫入頻率最高的表之一要建聯(lián)合索引(user_id, chapter_id)避免查詢時(shí)全表掃描。訂單表在初版可以做成簡(jiǎn)單的報(bào)名記錄表包含用戶ID、課程ID、支付金額、訂單狀態(tài)。純后臺(tái)管理場(chǎng)景下重點(diǎn)是把“用戶買了哪些課程”這個(gè)關(guān)系查清楚方便做學(xué)習(xí)記錄的權(quán)限校驗(yàn)。支付流程的復(fù)雜度可以放到第二階段再考慮。所有業(yè)務(wù)表我都保留了三個(gè)通用字段create_time、update_time、deleted。邏輯刪除用0和1表示而不是物理刪除數(shù)據(jù)。在線教育后臺(tái)誤刪操作的場(chǎng)景不少比如課程下架時(shí)如果物理刪了運(yùn)營想恢復(fù)就麻煩了。邏輯刪除讓數(shù)據(jù)始終可追溯查詢時(shí)統(tǒng)一加WHERE deleted 0條件即可。2.3 模塊劃分與核心業(yè)務(wù)流程整個(gè)系統(tǒng)的模塊劃分我按業(yè)務(wù)域來拆不按技術(shù)層拆。每個(gè)模塊是一個(gè)獨(dú)立的包結(jié)構(gòu)包含自己的Controller、Service、Mapper。主要有這幾個(gè)模塊認(rèn)證授權(quán)模塊登錄、JWT生成與校驗(yàn)、權(quán)限注解。用戶管理模塊用戶CRUD、角色分配、講師審核。課程管理模塊課程、章節(jié)、分類的維護(hù)。學(xué)習(xí)模塊學(xué)習(xí)記錄上報(bào)、課程進(jìn)度查詢。統(tǒng)計(jì)模塊簡(jiǎn)單的數(shù)據(jù)統(tǒng)計(jì)接口比如課程報(bào)名人數(shù)、學(xué)員完成率。核心業(yè)務(wù)流程里最值得理清楚的一條是“學(xué)員學(xué)習(xí)課程”。學(xué)員登錄后獲取自己的課程列表進(jìn)入課程詳情查看章節(jié)列表。前端在視頻播放時(shí)每隔一段時(shí)間上報(bào)學(xué)習(xí)進(jìn)度后端收到請(qǐng)求后更新學(xué)習(xí)記錄表。如果某章節(jié)已經(jīng)達(dá)到完成閾值就把狀態(tài)標(biāo)記為已完成。課程總體進(jìn)度在列表頁通過匯總該課程下已完成章節(jié)數(shù)除以總章節(jié)數(shù)來計(jì)算。這個(gè)流程看起來簡(jiǎn)單但里面涉及并發(fā)和冪等的問題如果前端一秒上報(bào)一次后端怎么做去重如果用戶斷網(wǎng)重連學(xué)習(xí)記錄會(huì)不會(huì)重復(fù)插入我后面在踩坑部分會(huì)詳細(xì)說解決辦法。這里先記住一個(gè)原則學(xué)習(xí)記錄表不能無腦每次插入新數(shù)據(jù)而是先查再更新最好用唯一索引兜底。3. 核心功能實(shí)操從0到1跑起來3.1 環(huán)境準(zhǔn)備與項(xiàng)目初始化先把環(huán)境準(zhǔn)備好。后端需要JDK 8或11、Maven 3.6以上版本、MySQL 5.7或8.0。前端需要Node.js 14以上npm 6以上。如果機(jī)器上裝的是新版本比如JDK 17也沒問題只要對(duì)應(yīng)SpringBoot版本支持。我這邊用的SpringBoot 2.7.x兼容JDK 8到17穩(wěn)一點(diǎn)。后端項(xiàng)目初始化推薦直接在IDEA里新建Spring Initializr項(xiàng)目選好JDK版本和依賴。需要引入的依賴有spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-java、lombok、spring-boot-starter-validation、jjwt。application.yml配置是最開始就要寫對(duì)的server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/edu_platform?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.edu.entity configuration: map-underscore-to-camel-case: truemap-underscore-to-camel-case這個(gè)配置很容易被忽略但它非常關(guān)鍵。數(shù)據(jù)庫字段是create_time這種下劃線風(fēng)格Java實(shí)體類是createTime這種駝峰風(fēng)格開啟這個(gè)配置后MyBatis會(huì)自動(dòng)映射。否則你就要在每條SQL里寫別名非常痛苦。前端項(xiàng)目初始化用Vue CLI或Vite都可以。我的建議是直接用Vue CLI創(chuàng)建生態(tài)穩(wěn)定模板工程對(duì)后臺(tái)管理系統(tǒng)非常友好。創(chuàng)建命令npm install -g vue/cli vue create edu-frontend創(chuàng)建時(shí)選手動(dòng)配置勾選Vue Router、Vuex和Axios。進(jìn)入項(xiàng)目后先安裝Element UI作為后臺(tái)管理界面的組件庫npm install element-ui npm install axiosElement UI的表格、表單、彈窗、分頁組件都非常成熟做管理后臺(tái)幾乎不用自己造輪子。3.2 后端核心模塊JWT認(rèn)證與攔截管理后臺(tái)的安全控制是第一優(yōu)先級(jí)。這套系統(tǒng)用的是JWT方案用戶登錄成功后后端生成一個(gè)帶過期時(shí)間的Token返回給前端前端每次請(qǐng)求都把這個(gè)Token放在HTTP請(qǐng)求頭里后端攔截器校驗(yàn)Token的合法性并解析出用戶信息。先定義一個(gè)簡(jiǎn)單的JWT工具類Component public class JwtUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expire}) private Long expire; public String generateToken(Integer userId, String username) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() expire)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); } }登錄接口的Service層邏輯根據(jù)用戶名查到用戶校驗(yàn)密碼是否一致校驗(yàn)通過就生成Token返回。密碼存儲(chǔ)不能是明文至少要用MD5加鹽或者BCrypt加密。我在項(xiàng)目里用的是BCryptSpring Security的加密工具類可以直接調(diào)比自寫MD5穩(wěn)妥得多。攔截器是JWT校驗(yàn)的核心。我寫了一個(gè)AuthInterceptor在請(qǐng)求進(jìn)入Controller之前攔截public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equals(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); } try { Claims claims JwtUtil.parseToken(token); request.setAttribute(userId, claims.get(userId)); return true; } catch (Exception e) { response.setStatus(401); response.setContentType(application/json); response.getWriter().write({\code\:401,\message\:\登錄已過期\}); return false; } } }這里有兩個(gè)容易踩的坑第一OPTIONS預(yù)檢請(qǐng)求必須放行否則前端跨域請(qǐng)求會(huì)被攔截器擋掉。第二攔截器里校驗(yàn)失敗時(shí)要直接返回JSON而不是讓Spring再走異常處理流程避免前端拿到一堆HTML錯(cuò)誤頁面。權(quán)限控制方面我用了自定義注解RequireRole標(biāo)注在Controller方法上比如講師管理接口只允許ROLE_ADMIN訪問。攔截器解析Token后拿到用戶ID再查一次數(shù)據(jù)庫得到角色信息校驗(yàn)是否符合注解要求。這個(gè)方法雖然每請(qǐng)求多查一次數(shù)據(jù)庫但勝在實(shí)現(xiàn)簡(jiǎn)單清晰對(duì)于后端管理系統(tǒng)的并發(fā)量來說完全夠用。3.3 前端頁面對(duì)接與接口聯(lián)調(diào)前端的核心是把請(qǐng)求封裝好后續(xù)頁面調(diào)用時(shí)不用重復(fù)處理Token和錯(cuò)誤提示。我在src目錄下建了一個(gè)api文件夾統(tǒng)一封裝axios實(shí)例import axios from axios import { Message } from element-ui import router from ../router const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message || 請(qǐng)求失敗) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { router.push(/login) } Message.error(error.message) return Promise.reject(error) } ) export default serviceVue頁面開發(fā)時(shí)最常用的是表格加彈窗表單的組合。以課程管理頁面為例頁面加載時(shí)調(diào)用GET /api/courses獲取列表點(diǎn)擊新增按鈕彈出表單對(duì)話框提交時(shí)調(diào)用POST /api/courses。這種模式幾乎覆蓋了后臺(tái)管理系統(tǒng)80%的頁面?？缬騿栴}是前后端分離聯(lián)調(diào)時(shí)最常見的問題。開發(fā)環(huán)境下Vue項(xiàng)目默認(rèn)跑在8080端口后端跑在8080端口這兩者之間就是跨域請(qǐng)求。我用的解決辦法是在后端加CORS配置 java Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .maxAge(3600); } }生產(chǎn)環(huán)境會(huì)更好處理前端打包成靜態(tài)文件后由Nginx提供服務(wù)然后用反向代理把/api路徑轉(zhuǎn)發(fā)到后端服務(wù)。這樣瀏覽器看到的始終是同源請(qǐng)求不需要后端處理跨域。開發(fā)環(huán)境用CORS配置生產(chǎn)環(huán)境用Nginx反向代理這是比較標(biāo)準(zhǔn)的做法。3.4 學(xué)習(xí)進(jìn)度上報(bào)接口的實(shí)現(xiàn)細(xì)節(jié)學(xué)習(xí)進(jìn)度接口是整個(gè)系統(tǒng)里最貼近真實(shí)使用場(chǎng)景的一個(gè)功能值得單獨(dú)拿出來講。前端在視頻播放時(shí)每隔15秒調(diào)一次上報(bào)接口傳遞userId、chapterId、watchTime、duration。后端收到請(qǐng)求后先查詢是否已經(jīng)有這條學(xué)習(xí)記錄沒有就插入有就更新watchTime。學(xué)習(xí)記錄完成狀態(tài)的判定不能死板。我的做法是當(dāng)watchTime大于等于duration的90%或者當(dāng)前端主動(dòng)標(biāo)記manualFinish為true時(shí)把status改為完成。為什么是90%而不是100%因?yàn)橛脩艉芸赡芴^結(jié)尾演職人員表或者視頻最后幾秒網(wǎng)絡(luò)卡頓強(qiáng)制要求100%反而會(huì)讓用戶覺得系統(tǒng)很死板。事務(wù)在這里要注意先查再插再更新整體操作要加Transactional防止插入記錄和更新狀態(tài)之間出現(xiàn)異常導(dǎo)致數(shù)據(jù)不一致。具體代碼邏輯大概是Transactional public void reportLearningProgress(ProgressRequest request) { LearningRecord record learningRecordMapper.selectByUserAndChapter( request.getUserId(), request.getChapterId()); if (record null) { record new LearningRecord(); record.setUserId(request.getUserId()); record.setChapterId(request.getChapterId()); record.setWatchTime(request.getWatchTime()); record.setStatus(0); learningRecordMapper.insert(record); } else { record.setWatchTime(request.getWatchTime()); if (request.getWatchTime() request.getDuration() * 0.9) { record.setStatus(1); } learningRecordMapper.update(record); } }并發(fā)上報(bào)時(shí)如果我第一次請(qǐng)求和第二次請(qǐng)求幾乎同時(shí)到達(dá)可能會(huì)插入兩條記錄。更穩(wěn)妥的做法是在數(shù)據(jù)庫層面給(user_id, chapter_id)加上聯(lián)合唯一索引讓數(shù)據(jù)庫幫你兜底重復(fù)插入直接報(bào)錯(cuò)代碼里再捕獲異常做更新處理。算法層面的冪等控制永遠(yuǎn)沒有數(shù)據(jù)庫約束可靠這個(gè)是我實(shí)際測(cè)試出來的教訓(xùn)。4. 真實(shí)開發(fā)中踩過的坑與排查技巧4.1 事務(wù)失效和數(shù)據(jù)一致性問題在線教育系統(tǒng)里事務(wù)用得多但很多人寫事務(wù)時(shí)都會(huì)忽略幾個(gè)讓人頭疼的場(chǎng)景。最典型的在同一個(gè)類里A方法調(diào)用B方法B方法上面標(biāo)了Transactional但是事務(wù)不生效。原因很簡(jiǎn)單Spring的事務(wù)是通過AOP代理實(shí)現(xiàn)的類內(nèi)部的方法調(diào)用走的是this不會(huì)經(jīng)過代理對(duì)象事務(wù)注解就被跳過了。解決辦法是把需要事務(wù)的方法放到另一個(gè)Service類里或者自己從容器中獲取代理對(duì)象再調(diào)用。另一個(gè)常見問題是事務(wù)內(nèi)做遠(yuǎn)程調(diào)用。比如學(xué)習(xí)進(jìn)度上報(bào)時(shí)如果先是更新學(xué)習(xí)記錄再調(diào)用短信服務(wù)通知用戶短信服務(wù)響應(yīng)很慢事務(wù)會(huì)一直持有數(shù)據(jù)庫連接不釋放最終導(dǎo)致連接池耗盡。我的處理原則是事務(wù)里只做數(shù)據(jù)庫操作遠(yuǎn)程調(diào)用放到事務(wù)提交之后通過事件或異步方式處理。數(shù)據(jù)一致性還體現(xiàn)在課程狀態(tài)上。課程刪除時(shí)如果直接把課程表里的記錄刪除那么學(xué)員的學(xué)習(xí)記錄表里就有大量懸空數(shù)據(jù)課程列表查詢也會(huì)出問題。這就是為什么我在前面強(qiáng)調(diào)邏輯刪除字段。課程下架的時(shí)候只更新deleted1學(xué)習(xí)記錄表里的數(shù)據(jù)還能正常關(guān)聯(lián)到課程歷史快照信息。4.2 接口性能瓶頸與優(yōu)化這套系統(tǒng)在數(shù)據(jù)量小的時(shí)候跑起來很順暢一旦數(shù)據(jù)庫里課程、用戶、學(xué)習(xí)記錄都到了幾十萬條性能問題就會(huì)暴露。最讓我印象深刻的場(chǎng)景是課程列表頁每次查詢課程列表都要統(tǒng)計(jì)報(bào)名人數(shù)和章節(jié)數(shù)如果使用寫死的SQL把所有數(shù)據(jù)都拆出來N1查詢問題馬上就來了。N1查詢的意思是先用一條SQL查出課程列表再對(duì)每個(gè)課程循環(huán)查詢學(xué)員數(shù)量。課程越多查詢次數(shù)越多接口響應(yīng)時(shí)間直線上升。解決辦法是用聯(lián)表查詢或子查詢一次拿到所有需要的數(shù)據(jù)。MyBatis里寫一個(gè)聚合SQL就能解決比如SELECT c.id, c.title, (SELECT COUNT(*) FROM orders o WHERE o.course_id c.id) AS student_count FROM course c WHERE c.deleted 0分頁查詢的深度分頁問題也要注意。當(dāng)使用LIMIT 100000, 20這種查詢時(shí)MySQL還是要掃描前100000條記錄效率很低。優(yōu)化思路有兩種一是使用WHERE id lastId的方式做游標(biāo)分頁適合移動(dòng)端無限滾動(dòng)場(chǎng)景二是給排序字段和篩選條件建立聯(lián)合索引讓數(shù)據(jù)庫盡量走索引覆蓋。后臺(tái)表格用普通分頁就好前端一覽式的數(shù)據(jù)列表建議用游標(biāo)分頁。學(xué)習(xí)記錄表寫入頻繁建議按用戶維度做緩存。用戶打開課程列表時(shí)不需要實(shí)時(shí)統(tǒng)計(jì)每個(gè)課程的學(xué)習(xí)進(jìn)度可以把進(jìn)度數(shù)據(jù)緩存到Redis里設(shè)置5分鐘過期。用戶每次上報(bào)進(jìn)度時(shí)更新一次Redis頁面展示時(shí)讀緩存只有管理員看統(tǒng)計(jì)報(bào)表時(shí)才查數(shù)據(jù)庫。這樣可以顯著降低數(shù)據(jù)庫壓力。4.3 部署上線時(shí)的細(xì)節(jié)處理本地開發(fā)跑通了部署又是半個(gè)坑。SpringBoot后端打包時(shí)要特別注意配置文件。開發(fā)環(huán)境連的是本地?cái)?shù)據(jù)庫服務(wù)器上用的是云數(shù)據(jù)庫不能把本地?cái)?shù)據(jù)庫地址直接打包進(jìn)去。我建議把a(bǔ)pplication.yml拆成三個(gè)環(huán)境application-dev.yml、application-test.yml、application-prod.yml。打包時(shí)通過spring.profiles.active指定環(huán)境部署命令類似java -jar edu-backend.jar --spring.profiles.activeprod前端部署要處理的是路由模式。Vue Router如果用了history模式Nginx需要配置try_files把請(qǐng)求都重定向到index.html。否則前端頁面一刷新Nginx就會(huì)報(bào)404這個(gè)問題太經(jīng)典了。Nginx配置大概長這樣location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }生產(chǎn)環(huán)境還有一個(gè)容易忽略的點(diǎn)MySQL的時(shí)區(qū)問題。如果后端配置了serverTimezoneAsia/Shanghai但MySQL服務(wù)器用的是UTC查出來直接更新到數(shù)據(jù)庫你會(huì)發(fā)現(xiàn)時(shí)間晚了8小時(shí)。最好的辦法是把MySQL的全局時(shí)區(qū)也設(shè)置為東八區(qū)同時(shí)在后端配置里保持一致雙重確認(rèn)。4.4 前端聯(lián)調(diào)中的常見問題速查我在聯(lián)調(diào)階段遇到過不少前端問題整理成一張表現(xiàn)象原因解決辦法請(qǐng)求返回401但登錄頁沒跳攔截器里處理的是response error但HTTP狀態(tài)碼可能被axios攔了檢查response攔截器的error分支表格數(shù)據(jù)不顯示后端返回的字段和前端表頭字段不一致統(tǒng)一使用駝峰命名開啟MyBatis駝峰映射表單提交后列表不刷新提交成功后沒有重新調(diào)用列表接口在成功回調(diào)里重新查詢當(dāng)前頁數(shù)據(jù)上傳圖片失敗跨域請(qǐng)求被Nginx或CORS配置攔截檢查Nginx的client_max_body_sizeToken過期后頁面卡死401后沒有清理本地存儲(chǔ)和跳轉(zhuǎn)攔截器里清空localStorage后跳登錄頁聯(lián)調(diào)是前后端項(xiàng)目里最容易扯皮也最容易拖時(shí)間的環(huán)節(jié)。我的習(xí)慣是先在前端Mock數(shù)據(jù)把頁面寫完所有字段類型和接口路徑都按真實(shí)約定來后端接口出了之后把Mock地址切到真實(shí)地址沖突就會(huì)少很多。5. 從能用做到好用擴(kuò)展與經(jīng)驗(yàn)沉淀5.1 演示項(xiàng)目到線上項(xiàng)目差在哪很多開發(fā)者做的在線教育系統(tǒng)功能看著都有但離真正上線還有一段距離。最大的差距在容錯(cuò)和可觀測(cè)性。演示項(xiàng)目里接口掛了只會(huì)刷新重來線上系統(tǒng)要求的是接口異常時(shí)有日志、有告警、有兜底數(shù)據(jù)。我在后期給這套系統(tǒng)加了全局異常處理類統(tǒng)一捕獲業(yè)務(wù)異常和未知異常記錄日志并返回友好提示。加上操作日志模塊后臺(tái)管理員每次上下架課程、修改用戶信息都會(huì)記錄操作者和時(shí)間出了問題能追溯到人。數(shù)據(jù)層面線上系統(tǒng)還要求備份策略。MySQL備份不只是mysqldump命令而是要有全量備份加增量日志。我建議至少每天全量備份一次同時(shí)開啟binlog。這樣即使誤操作刪了數(shù)據(jù)也能恢復(fù)到指定的時(shí)間點(diǎn)對(duì)在線教育這種運(yùn)營人員直接操作系統(tǒng)的情況非常關(guān)鍵。5.2 個(gè)人調(diào)試效率技巧幾個(gè)能明顯提升開發(fā)效率的小習(xí)慣。后端接口測(cè)試與其頻繁起一個(gè)前端頁面去點(diǎn)不如直接用接口測(cè)試工具把所有接口集合保存下來。后端改完接口跑一遍集合就能知道有沒有破壞已有功能。前端調(diào)試時(shí)多用瀏覽器的Network面板看接口耗時(shí)和響應(yīng)體比反復(fù)加console快得多。SQL排查我習(xí)慣在MyBatis的XML里寫注釋把業(yè)務(wù)背景和參數(shù)含義寫明。半年后自己回頭維護(hù)代碼或者讓另一個(gè)同事接手這些注釋的價(jià)值遠(yuǎn)大于代碼層的注釋。遇到過太多次寫的SQL自己都看不懂的情況。聯(lián)調(diào)時(shí)前端報(bào)錯(cuò)第一反應(yīng)不是去懷疑后端邏輯而是先打開瀏覽器控制臺(tái)把Full Request URL復(fù)制出來直接在接口工具里重放一遍。如果接口工具返回正常那就是前端傳參問題如果接口工具也報(bào)錯(cuò)再往后端查。這個(gè)排除法能省下大量溝通成本。5.3 后續(xù)可以怎么擴(kuò)展這套系統(tǒng)留了幾個(gè)明確的擴(kuò)展點(diǎn)。課程播放頁面可以接入真正的前端視頻播放器配合學(xué)習(xí)記錄接口做續(xù)播功能。權(quán)限方面可以把方法級(jí)別的注解權(quán)限升級(jí)成細(xì)粒度按鈕權(quán)限前端根據(jù)用戶權(quán)限動(dòng)態(tài)渲染按鈕。統(tǒng)計(jì)報(bào)表可以引入定時(shí)任務(wù)每天早上匯總前一天的學(xué)員活躍、課程報(bào)名數(shù)據(jù)生成運(yùn)營日?qǐng)?bào)。如果后續(xù)還需要支持多人同時(shí)觀看直播課那就要考慮引入消息推送和WebRTC相關(guān)技術(shù)這部分和當(dāng)前管理后臺(tái)是相對(duì)獨(dú)立的模塊。架構(gòu)上保持模塊清晰技術(shù)升級(jí)不會(huì)影響已有功能?；仡^再看這個(gè)項(xiàng)目的價(jià)值不只是把SpringBootVue這套技術(shù)棧跑通而是通過在線教育這個(gè)真實(shí)業(yè)務(wù)場(chǎng)景把權(quán)限、事務(wù)、性能、部署這些后端開發(fā)的硬骨頭都過了一遍。我在實(shí)際調(diào)試過程中最大的體會(huì)是很多問題都是到數(shù)據(jù)量上去之后才暴露出來的單純寫單測(cè)或者跑小樣本數(shù)據(jù)根本發(fā)現(xiàn)不了。所以做這類管理系統(tǒng)一定在一開始就按真實(shí)數(shù)據(jù)量去設(shè)計(jì)表結(jié)構(gòu)和索引不要等線上卡死才回頭改模型。最后分享一個(gè)小技巧課程表和學(xué)習(xí)記錄表這種高頻訪問的表主鍵不要用UUID字符串用自增整型主鍵就好。SQL里做JOIN時(shí)整型主鍵的索引效率和存儲(chǔ)空間都遠(yuǎn)優(yōu)于字符串。一套字段設(shè)計(jì)要經(jīng)得起未來幾年的數(shù)據(jù)增長這才是后端開發(fā)的核心功底。