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