簡介一套基于SpringCloud微服務(wù)架構(gòu)的在線教育系統(tǒng)完整項(xiàng)目面向Java初中級(jí)開發(fā)者、畢業(yè)設(shè)計(jì)選題學(xué)生及需要微服務(wù)實(shí)戰(zhàn)經(jīng)驗(yàn)的程序員。系統(tǒng)分為前臺(tái)用戶網(wǎng)站和后臺(tái)運(yùn)營平臺(tái)兩部分前臺(tái)包含課程、問答、文章三大核心模塊后端采用SpringBoot、SpringCloud、MyBatis-Plus、MySQL、Docker等主流技術(shù)前端基于Node.js和Vue.js構(gòu)建并整合Redis、ActiveMQ、阿里云OSS與視頻點(diǎn)播同時(shí)使用ECharts實(shí)現(xiàn)圖表展示POI完成用戶批量上傳注冊(cè)JWT實(shí)現(xiàn)分布式單點(diǎn)登錄。壓縮包大小約198KB內(nèi)容以項(xiàng)目源碼、數(shù)據(jù)庫腳本與說明文檔為主可幫助讀者快速理解前后端分離的微服務(wù)項(xiàng)目結(jié)構(gòu)。目前已有1154人學(xué)習(xí)下載適合參考其架構(gòu)設(shè)計(jì)、接口文檔生成及分布式組件集成方式用于個(gè)人項(xiàng)目練手或畢業(yè)設(shè)計(jì)二次開發(fā)。1. 從單體撐不住到 online_edu 微服務(wù)改造這個(gè)在線教育系統(tǒng)到底在解決什么在線教育系統(tǒng) online_edu 的典型痛點(diǎn)不在“寫接口”而在“拆模塊”。前臺(tái)用戶要刷課程、發(fā)問答、看文章后臺(tái)運(yùn)營要傳視頻、導(dǎo)報(bào)表、盯數(shù)據(jù)面板如果全部揉在一個(gè) SpringBoot 單體里熱部署慢、并發(fā)扛不住、運(yùn)營活動(dòng)一上線就得整個(gè)重啟。所以這類系統(tǒng)最常見的落地方案是SpringBoot SpringCloud 做微服務(wù)底座MyBatis-Plus 做數(shù)據(jù)訪問Vue.js 做前后端分離MySQL 存業(yè)務(wù)數(shù)據(jù)Redis 扛熱點(diǎn)ActiveMQ 解耦異步任務(wù)OSS 和視頻點(diǎn)播管文件ECharts 出圖表POI 導(dǎo) Excel。這套技術(shù)組合在 2026 年的今天依然是中小團(tuán)隊(duì)搭建在線教育平臺(tái)的主流選型因?yàn)槊恳粚佣加谐墒焐鷳B(tài)招人容易、排錯(cuò)資料多、踩坑成本低。這篇文章適合兩類人一是正在做畢業(yè)設(shè)計(jì)或課程設(shè)計(jì)、需要從零跑通一個(gè)完整微服務(wù)項(xiàng)目的學(xué)生二是公司要自建在線教育平臺(tái)、想用現(xiàn)成方案避免從頭造輪子的后端開發(fā)。我會(huì)按“怎么拆服務(wù)、怎么寫業(yè)務(wù)、怎么部署、怎么避坑”的順序把這套系統(tǒng)從骨架到上線講透。先說明一點(diǎn)微服務(wù)不是越拆越好online_edu 這種體量拆 3 到 4 個(gè)核心服務(wù)就夠拆多了反而被分布式事務(wù)拖死。2. SpringCloud 微服務(wù)骨架搭建從 Maven 多模塊到 Nacos 注冊(cè)中心2.1 服務(wù)拆分的判斷標(biāo)準(zhǔn)online_edu 為什么拆成這四個(gè)服務(wù)很多初學(xué)者拿到“微服務(wù)架構(gòu)”這個(gè)要求就慌不知道拆幾個(gè)服務(wù)、按什么拆。我的經(jīng)驗(yàn)是按“獨(dú)立部署 獨(dú)立數(shù)據(jù)域 獨(dú)立伸縮”三個(gè)標(biāo)準(zhǔn)來判斷。online_edu 的前臺(tái)系統(tǒng)包含課程、問答、文章三大部分這三塊業(yè)務(wù)的數(shù)據(jù)表互不重疊、訪問頻率差異大——課程是高頻讀問答是寫多讀少文章是內(nèi)容管理為主。把它們拆成三個(gè)服務(wù)再加上一個(gè)管文件上傳、視頻點(diǎn)播和后臺(tái)報(bào)表的后臺(tái)服務(wù)正好四個(gè)不多不少。拆服務(wù)的時(shí)候有一個(gè)常見誤用把“微服務(wù)”理解成“每個(gè) Controller 一個(gè)服務(wù)”結(jié)果一個(gè)查詢要跨五次 HTTP 調(diào)用延遲直接爆炸。我一般會(huì)這樣判斷——如果兩個(gè)功能要頻繁聯(lián)查同幾張表它們就應(yīng)該在同一個(gè)服務(wù)里如果只是偶爾通過 ID 互相引一下才值得拆開。課程服務(wù)要查講師信息和視頻播放地址這些表天然在一塊硬拆反而不是微服務(wù)是給自己上刑。服務(wù)拆完每個(gè)服務(wù)獨(dú)立一個(gè)數(shù)據(jù)庫至少做到邏輯隔離。online_edu 這種規(guī)模不需要分庫分表但四個(gè)數(shù)據(jù)庫是底線。MySQL 5.7 和 8.0 都能跑建議直接上 8.05.7 的官方支持已經(jīng)走到盡頭新項(xiàng)目沒必要為難自己。2.2 用 Maven 多模塊搭建項(xiàng)目骨架父 POM 鎖定依賴版本微服務(wù)項(xiàng)目第一步是建 Maven 多模塊工程。父 POM 管依賴版本子模塊管具體實(shí)現(xiàn)。這一步的坑主要在版本兼容SpringBoot 和 SpringCloud 的版本號(hào)不是隨便配的SpringCloud 的每個(gè)大版本對(duì)應(yīng)一個(gè) SpringBoot 版本配錯(cuò)了啟動(dòng)直接報(bào) NoSuchMethodError而且是啟動(dòng)到一半才爆查起來非常惡心。我一般用 SpringBoot 2.6.x 配 SpringCloud 2021.x這套組合在 2026 年依然大量運(yùn)行在生產(chǎn)環(huán)境資料最多、坑基本都被踩平了。SpringBoot 3.x 配 SpringCloud 2022 當(dāng)然更好但對(duì) MyBatis-Plus 和 ActiveMQ 的兼容性要求更高學(xué)生項(xiàng)目和老系統(tǒng)升級(jí)沒必要賭這個(gè)。!-- 父 POM 關(guān)鍵配置片段 -- parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.6.13/version relativePath/ /parent properties spring-cloud.version2021.0.5/spring-cloud.version mybatis-plus.version3.5.3.1/mybatis-plus.version mysql.version8.0.33/mysql.version /properties dependencyManagement dependencies dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-dependencies/artifactId version${spring-cloud.version}/version typepom/type scopeimport/scope /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version${mybatis-plus.version}/version /dependency /dependencies /dependencyManagement這段配置的邏輯是SpringBoot 父 POM 統(tǒng)一管理 Spring 全家桶的版本SpringCloud 的 dependencyManagement 統(tǒng)一管微服務(wù)組件Nacos、Gateway、OpenFeign 等的版本MyBatis-Plus 和 MySQL 驅(qū)動(dòng)單獨(dú)鎖版本。這樣每個(gè)子模塊只需要聲明用到了什么不需要寫版本號(hào)避免子模塊之間依賴版本漂移。注意 SpringCloud 的版本號(hào)是倫敦地鐵站名命名的2021.0.x 對(duì)應(yīng) Jubilee不要寫錯(cuò)。2.3 Nacos 注冊(cè)中心與 Gateway 網(wǎng)關(guān)配置服務(wù)發(fā)現(xiàn)是微服務(wù)的地基服務(wù)拆完之后服務(wù)之間要互相找到對(duì)方這就需要注冊(cè)中心。Nacos 是當(dāng)前 SpringCloud 生態(tài)里用得最多的注冊(cè)中心比 Eureka 多了配置中心功能而且控制臺(tái)是中文的排查問題方便很多。online_edu 的四個(gè)服務(wù)全部注冊(cè)到 Nacos前臺(tái)請(qǐng)求統(tǒng)一走 Gateway 網(wǎng)關(guān)轉(zhuǎn)發(fā)不直接調(diào)服務(wù)地址。# 每個(gè)微服務(wù)模塊的 application.yml 關(guān)鍵配置 server: port: 8101 # 不同服務(wù)用不同端口 spring: application: name: service-course # 服務(wù)名網(wǎng)關(guān)和 Feign 都靠這個(gè)名字路由 cloud: nacos: discovery: server-addr: 192.168.1.10:8848 namespace: online-edu-dev # 區(qū)分環(huán)境用dev/prod 隔離# Gateway 網(wǎng)關(guān)模塊路由配置 spring: cloud: gateway: routes: - id: course-route uri: lb://service-course predicates: - Path/api/course/** - id: qa-route uri: lb://service-qa predicates: - Path/api/qa/**注冊(cè)中心這一段邏輯是服務(wù)啟動(dòng)時(shí)向 Nacos 上報(bào)自己的 IP 和端口網(wǎng)關(guān)從 Nacos 拉取服務(wù)列表根據(jù)請(qǐng)求路徑的前綴把請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)服務(wù)。lb://前綴表示走負(fù)載均衡Gateway 會(huì)輪詢分發(fā)到服務(wù)實(shí)例。我在配置里加了namespace字段開發(fā)環(huán)境和生產(chǎn)環(huán)境用同一個(gè) Nacos 但不同命名空間防止聯(lián)調(diào)的時(shí)候服務(wù)串了。這里有個(gè)參數(shù)值得注意spring.application.name是微服務(wù)里的“身份證”所有注冊(cè)、發(fā)現(xiàn)、配置管理都靠這個(gè)名字。如果你把服務(wù)名寫錯(cuò)了Nacos 控制臺(tái)里能看到服務(wù)但網(wǎng)關(guān)路由永遠(yuǎn)轉(zhuǎn)發(fā)不過去日志里只會(huì)報(bào) 503非常隱蔽。3. 前臺(tái)用戶系統(tǒng)落地課程、問答、文章三大模塊的代碼實(shí)現(xiàn)3.1 課程模塊MyBatis-Plus 分頁查詢與視頻點(diǎn)播的配合課程模塊是 online_edu 的前臺(tái)核心用戶需要按分類瀏覽課程、搜索課程、查看課程詳情、播放視頻。數(shù)據(jù)庫設(shè)計(jì)上課程表、課程分類表、講師表、課程視頻表四張表就夠了不需要過度設(shè)計(jì)。課程列表頁的典型接口是分頁查詢這里直接用 MyBatis-Plus 的 Page 對(duì)象避免手寫 LIMIT 分頁的邊界判斷。MyBatis-Plus 的 BaseMapper 已經(jīng)封裝了大部分單表 CRUD寫代碼的核心就變成“怎么組合條件”。// 課程分頁查詢接口實(shí)現(xiàn) Service public class CourseServiceImpl implements CourseService { Autowired private CourseMapper courseMapper; Override public PageCourse pageCourses(Integer current, Integer size, CourseQueryDTO query) { // 1. 創(chuàng)建分頁對(duì)象current 從 1 開始 PageCourse page new Page(current, size); // 2. 構(gòu)建查詢條件LambdaQueryWrapper 避免硬編碼列名 LambdaQueryWrapperCourse wrapper Wrappers.lambdaQuery(); wrapper.like(StringUtils.hasText(query.getTitle()), Course::getTitle, query.getTitle()) .eq(query.getCategoryId() ! null, Course::getCategoryId, query.getCategoryId()) .eq(Course::getStatus, 1) // 只查上架的課程 .orderByDesc(Course::getPublishTime); // 3. 執(zhí)行分頁查詢MyBatis-Plus 會(huì)自動(dòng)生成 COUNT 查詢 return courseMapper.selectPage(page, wrapper); } }這段代碼的關(guān)鍵邏輯是LambdaQueryWrapper它用方法引用的方式指定列名編譯期就能發(fā)現(xiàn)字段名拼寫錯(cuò)誤不用等運(yùn)行期報(bào) SQL 異常。like和eq第一個(gè)參數(shù)是布爾條件為 true 才拼接這個(gè)條件這樣查詢參數(shù)為空的時(shí)候不會(huì)生成多余 WHERE 子句。selectPage會(huì)自動(dòng)執(zhí)行一條 COUNT 查詢和一條分頁查詢返回的 Page 對(duì)象里帶總條數(shù)和頁數(shù)前端直接拿來渲染分頁組件。課程詳情頁要展示視頻播放地址這就涉及阿里云視頻點(diǎn)播的接入。常見做法是后端調(diào)用視頻點(diǎn)播的接口獲取播放憑證PlayAuth返回給前端前端配合視頻播放器 SDK 播放。播放憑證有過期時(shí)間一般是 100 秒所以不能緩存必須每次進(jìn)入播放頁時(shí)實(shí)時(shí)獲取。這里有個(gè)小坑憑證獲取接口要加防盜鏈配置否則播放地址泄露出去別人可以直接扒流。3.2 問答模塊Redis 緩存熱點(diǎn)問題與 ActiveMQ 異步通知問答模塊的業(yè)務(wù)特征是用戶提問、其他用戶回答、提問者采納答案。這個(gè)模塊的并發(fā)模型和課程模塊不一樣——一個(gè)熱門問題可能在短時(shí)間內(nèi)被大量瀏覽但回答數(shù)遠(yuǎn)小于瀏覽數(shù)。所以問答模塊的緩存策略是題目詳情頁用 Redis 緩存回答列表也緩存用戶提交新回答時(shí)先更新數(shù)據(jù)庫再刪除緩存等下次查詢時(shí)重建。這里我用的是“先更新數(shù)據(jù)庫再刪除緩存”的模式而不是“先刪緩存再更新數(shù)據(jù)庫”。原因很簡單先刪緩存的話更新數(shù)據(jù)庫那段時(shí)間內(nèi)來了請(qǐng)求緩存沒有會(huì)直接去打數(shù)據(jù)庫如果請(qǐng)求量大的話數(shù)據(jù)庫瞬間被壓垮這就是緩存擊穿。先更新庫再刪緩存雖然極端條件下會(huì)有幾百毫秒的臟讀但對(duì)問答場景完全可接受。// 回答問題的異步處理邏輯 Service public class AnswerServiceImpl implements AnswerService { Autowired private StringRedisTemplate redisTemplate; Autowired private JmsTemplate jmsTemplate; Override public void submitAnswer(Answer answer) { // 1. 保存回答到數(shù)據(jù)庫 answerMapper.insert(answer); // 2. 刪除問題詳情的緩存下次查詢時(shí)自動(dòng)重建 redisTemplate.delete(qa:question:detail: answer.getQuestionId()); // 3. 發(fā)送異步消息通知提問者 jmsTemplate.convertAndSend(edu.qa.answer, JSON.toJSONString(answer)); } }ActiveMQ 在這里的作用是解耦把“新回答通知”這個(gè)非關(guān)鍵路徑剝離出去。如果不用消息隊(duì)列用戶提交回答后要同步調(diào)郵件或短信服務(wù)一旦短信服務(wù)掛了回答就提交失敗。用 ActiveMQ 之后回答只要存進(jìn)庫里就算成功通知失敗可以重試互不影響。上面代碼里convertAndSend是 JmsTemplate 最簡單的用法消息體直接傳 JSON 字符串消費(fèi)者那邊用JmsListener注解接消息就行。Redis 緩存這里還有一層設(shè)計(jì)熱門的瀏覽計(jì)數(shù)也不直接寫數(shù)據(jù)庫而是先寫 Redis再定時(shí)批量同步到 MySQL。不然用戶每打開一次問題詳情頁就 UPDATE 一次數(shù)據(jù)庫問答這種讀多寫少的場景也能把數(shù)據(jù)庫打滿。3.3 文章模塊富文本編輯與靜態(tài)化方案的取舍文章模塊相對(duì)簡單核心就是兩類頁面文章列表和文章詳情。文章詳情如果每次請(qǐng)求都從數(shù)據(jù)庫查、再用模板渲染數(shù)據(jù)庫壓力大不說響應(yīng)速度也慢。常見做法是文章發(fā)布時(shí)生成靜態(tài) HTML 頁面存到 OSS 或者本地磁盤前臺(tái)詳情頁直接返回靜態(tài)文件。我做過一個(gè)簡化版本前端用 Vue.js 的vue-quill-editor做富文本編輯器文章正文以 HTML 片段存進(jìn) MySQL。詳情頁請(qǐng)求時(shí)后端把 HTML 片段拼進(jìn) Vue 組件里渲染。這個(gè)方案的優(yōu)點(diǎn)是改動(dòng)少、好維護(hù)缺點(diǎn)是首屏加載慢一點(diǎn)但對(duì)文章這種非實(shí)時(shí)性內(nèi)容用戶完全感知不到區(qū)別。// Vue.js 前端文章列表頁的分頁邏輯 export default { data() { return { articleList: [], current: 1, size: 10, total: 0 } }, methods: { async fetchArticles() { const res await axios.get(/api/article/list, { params: { current: this.current, size: this.size, category: this.categoryId } }) // 后端返回結(jié)構(gòu): { records: [], total: 100 } this.articleList res.data.records this.total res.data.total } } }這里要說一個(gè)很多人忽略的細(xì)節(jié)分頁接口返回的records是文章列表但列表里不應(yīng)該包含文章正文這個(gè)字段。文章正文可能幾十 KB列表頁一次性拉 10 篇就是幾百 KB移動(dòng)端網(wǎng)絡(luò)扛不住。正確做法是列表接口只返回 ID、標(biāo)題、摘要、封面圖、發(fā)布時(shí)間詳情頁再單獨(dú)查正文。這個(gè)字段裁剪邏輯要看 SQL 里 select 了哪些列MyBatis-Plus 里用select(Course::getId, Course::getTitle, ...)指定就好。4. 后臺(tái)運(yùn)營平臺(tái)ECharts 看板與 POI 報(bào)表導(dǎo)出的實(shí)現(xiàn)細(xì)節(jié)4.1 運(yùn)營后臺(tái)的數(shù)據(jù)面板ECharts 圖表接口怎么設(shè)計(jì)才不卡后臺(tái)運(yùn)營平臺(tái)要展示課程銷售趨勢、用戶增長曲線、問答活躍度這些圖表。ECharts 渲染本身是純前端的事后端的工作是提供聚合好的數(shù)據(jù)接口。最容易犯的錯(cuò)誤是后端直接返回明細(xì)數(shù)據(jù)讓前端去聚合。用戶量大了以后報(bào)表接口一次返回幾萬條記錄前端渲染直接卡死而且圖表數(shù)據(jù)不需要那么細(xì)的粒度后端聚合完只返回十幾個(gè)點(diǎn)的坐標(biāo)就夠了。我的做法是后端按時(shí)間粒度聚合。按天、按周、按月給聚合接口前端拿到的是[{date: 2026-01-01, count: 32}, ...]這種結(jié)構(gòu)ECharts 塞進(jìn)去直接渲染。// 后臺(tái)數(shù)據(jù)面板的聚合查詢 RestController RequestMapping(/admin/stats) public class StatsController { Autowired private JdbcTemplate jdbcTemplate; GetMapping(/course-publish-trend) public ListMapString, Object coursePublishTrend( RequestParam String startDate, RequestParam String endDate) { String sql SELECT DATE(publish_time) AS date, COUNT(*) AS count FROM course WHERE publish_time BETWEEN ? AND ? GROUP BY DATE(publish_time) ORDER BY date; return jdbcTemplate.queryForList(sql, startDate, endDate); } }這個(gè)接口的邏輯是MySQL 的 GROUP BY 按天聚合課程上架數(shù)量返回的 Map 列表就是圖表的數(shù)據(jù)源。這里能用 JdbcTemplate 直接寫 SQL是因?yàn)榫酆喜樵兺嵌啾?JOIN 加復(fù)雜條件用 MyBatis-Plus 的 Wrapper 反而難寫。一個(gè)項(xiàng)目里別只用一種數(shù)據(jù)訪問方式聚合報(bào)表類和業(yè)務(wù) CRUD 類用不同工具很正常。圖表數(shù)據(jù)接口的響應(yīng)速度一般要求 200ms 以內(nèi)超過這個(gè)時(shí)間前端就能感知到卡頓。如果聚合查詢超過 1 秒優(yōu)先加聯(lián)合索引只要 WHERE 條件和 GROUP BY 的字段在同一個(gè)索引里性能通常能提升一個(gè)數(shù)量級(jí)。4.2 POI 實(shí)現(xiàn) Excel 導(dǎo)出百萬行數(shù)據(jù)的正確導(dǎo)出姿勢后臺(tái)運(yùn)營平臺(tái)離不開導(dǎo)出功能課程清單、學(xué)員信息、問答列表都要導(dǎo)成 Excel。POI 是最常用的庫但很多人只會(huì)用XSSFWorkbook數(shù)據(jù)量一超過幾萬行就內(nèi)存溢出。POI 有 SXSSFWorkbook 專門處理大文件導(dǎo)出用內(nèi)存和磁盤交換的方式避免 OOM百萬行數(shù)據(jù)毫無壓力。// POI 導(dǎo)出課程列表數(shù)據(jù)量大時(shí)使用 SXSSFWorkbook public void exportCourses(ListCourse courses, HttpServletResponse response) { // 1. 用 SXSSFWorkbook1000 行刷一次盤避免內(nèi)存堆積 SXSSFWorkbook workbook new SXSSFWorkbook(1000); Sheet sheet workbook.createSheet(課程列表); // 2. 設(shè)置表頭樣式 CellStyle headerStyle workbook.createCellStyle(); headerStyle.setAlignment(HorizontalAlignment.CENTER); Font headerFont workbook.createFont(); headerFont.setBold(true); headerStyle.setFont(headerFont); // 3. 寫表頭 String[] headers {課程ID, 課程名稱, 講師, 價(jià)格, 上架狀態(tài)}; Row headerRow sheet.createRow(0); for (int i 0; i headers.length; i) { Cell cell headerRow.createCell(i); cell.setCellValue(headers[i]); cell.setCellStyle(headerStyle); } // 4. 寫數(shù)據(jù)行 int rowIndex 1; for (Course course : courses) { Row row sheet.createRow(rowIndex); row.createCell(0).setCellValue(course.getId()); row.createCell(1).setCellValue(course.getTitle()); row.createCell(2).setCellValue(course.getTeacherName()); row.createCell(3).setCellValue(course.getPrice().doubleValue()); row.createCell(4).setCellValue(course.getStatus() 1 ? 上架 : 下架); } // 5. 寫響應(yīng)流 response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet); response.setHeader(Content-Disposition, attachment; filenamecourses.xlsx); workbook.write(response.getOutputStream()); workbook.dispose(); // SXSSFWorkbook 用完必須調(diào) dispose 清理臨時(shí)文件 }這段代碼的要點(diǎn)是new SXSSFWorkbook(1000)這行的參數(shù)1000 表示內(nèi)存里最多保留 1000 行超過的行會(huì)刷到磁盤臨時(shí)文件。dispose()必須調(diào)用否則臨時(shí)文件會(huì)留在磁盤上一次導(dǎo)出清不干凈時(shí)間長了磁盤被占滿。數(shù)據(jù)量大導(dǎo)出耗時(shí)超過幾秒時(shí)前端要配合 loading 狀態(tài)不然用戶會(huì)以為界面卡死了。POI 導(dǎo)出還有一個(gè)常見的亂碼坑文件名里的中文如果直接拼在Content-Disposition里瀏覽器會(huì)變成下劃線。需要做 URL 編碼URLEncoder.encode(課程列表.xlsx, UTF-8)這樣 Chrome、Edge、Safari 都不會(huì)亂。4.3 運(yùn)營后臺(tái)的權(quán)限處理為什么把權(quán)限判斷放在網(wǎng)關(guān)層后臺(tái)運(yùn)營平臺(tái)不允許普通用戶訪問管理員和運(yùn)營人員要分開角色。微服務(wù)架構(gòu)下權(quán)限有網(wǎng)關(guān)層攔截和服務(wù)層校驗(yàn)兩層。網(wǎng)關(guān)層做粗粒度校驗(yàn)判斷請(qǐng)求路徑是否要求登錄、用戶有沒有這個(gè)角色的訪問權(quán)限服務(wù)層做細(xì)粒度校驗(yàn)判斷用戶對(duì)某條數(shù)據(jù)有沒有操作權(quán)。SpringCloud Gateway 的全局過濾器可以統(tǒng)一做登錄態(tài)校驗(yàn)和角色判斷這樣四個(gè)服務(wù)不用每個(gè)都寫一遍權(quán)限邏輯。token 用 JWT 格式網(wǎng)關(guān)解析出用戶 ID 和角色 ID 后通過 Header 傳給下游服務(wù)。這里有個(gè)坑下游服務(wù)直接信任網(wǎng)關(guān)傳來的 Header 有安全風(fēng)險(xiǎn)要加一個(gè)內(nèi)部密鑰校驗(yàn)防止服務(wù)端口暴露時(shí)被繞過網(wǎng)關(guān)直接調(diào)用。5. 避坑與排查online_edu 從開發(fā)到部署的 6 個(gè)真實(shí)踩坑記錄5.1 MySQL 連接報(bào)錯(cuò)SSL 連接錯(cuò)誤和時(shí)區(qū)問題一起出現(xiàn)現(xiàn)象SpringBoot 項(xiàng)目啟動(dòng)時(shí)控制臺(tái)報(bào)Cannot create PoolableConnectionFactory具體原因里有The server time zone value й? is unrecognized和SSL connection error兩個(gè)問題同時(shí)出現(xiàn)。原因MySQL 8.0 默認(rèn)啟用 SSL 連接而且時(shí)區(qū)配置從SYSTEM改成了需要明確指定。JDBC 連接串里既沒配useSSLfalse也沒配serverTimezoneAsia/Shanghai導(dǎo)致驅(qū)動(dòng)校驗(yàn)時(shí)區(qū)失敗整個(gè)連接池創(chuàng)建失敗。解決JDBC 連接串改成這樣jdbc:mysql://localhost:3306/online_edu?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue。其中allowPublicKeyRetrievaltrue是 MySQL 8.0 的另一個(gè)坑不配它連接時(shí)可能報(bào)Public Key Retrieval is not allowed。這行參數(shù)建議直接寫進(jìn)每個(gè)微服務(wù)的配置文件里不要漏。5.2 Docker 安裝 MySQL 失敗鏡像拉不下來和容器起不來現(xiàn)象用 Docker 部署環(huán)境時(shí)docker pull mysql:8.0卡住不動(dòng)或者docker run之后容器秒退docker logs看報(bào)錯(cuò)是權(quán)限不足。原因拉鏡像卡住通常是網(wǎng)絡(luò)問題容器秒退則是 MySQL 初始化時(shí)往宿主機(jī)掛載目錄寫文件沒有權(quán)限。很多教程讓你掛載/my/own/datadir:/var/lib/mysql但這個(gè)目錄如果宿主機(jī)上沒有合適的權(quán)限MySQL 的mysqld進(jìn)程無法寫入數(shù)據(jù)。解決掛載數(shù)據(jù)目錄時(shí)先建目錄再調(diào)整權(quán)限mkdir -p /data/mysql chmod -R 777 /data/mysql。然后啟動(dòng)時(shí)加上--usermysql參數(shù)運(yùn)行命令是docker run -d --name mysql8 -p 3306:3306 -e MYSQL_ROOT_PASSWORDroot123 -v /data/mysql:/var/lib/mysql mysql:8.0 --character-set-serverutf8mb4 --collation-serverutf8mb4_unicode_ci。--character-set-serverutf8mb4這個(gè)參數(shù)很重要MySQL 默認(rèn)的latin1編碼存不了中文不配的話建表時(shí)必須每個(gè)表單獨(dú)指定字符集非常麻煩。5.3 微服務(wù)之間調(diào)用超時(shí)HttpClient 連接池耗盡現(xiàn)象商城或問答服務(wù)調(diào)用課程服務(wù)時(shí)偶爾報(bào)Connection pool timeout高峰時(shí)段特別頻繁。原因online_edu 的服務(wù)間調(diào)用用了 HttpClient而很多人的 HttpClient 配置是默認(rèn)的。默認(rèn)最大連接數(shù)只有 20而且連接空閑 60 秒后會(huì)被回收。一旦課程服務(wù)響應(yīng)變慢調(diào)用方積壓的請(qǐng)求占滿全部連接后續(xù)請(qǐng)求全部排隊(duì)等連接超時(shí)時(shí)間一到就報(bào)錯(cuò)。解決給 HttpClient 設(shè)置更大的連接池和合理的超時(shí)時(shí)間。PoolingHttpClientConnectionManager的setMaxTotal(200)和setDefaultMaxPerRoute(100)RequestConfig里的connectTimeout(5000)需要 5 秒socketTimeout(10000)是 10 秒。同時(shí)開啟evictExpiredConnections()和evictIdleConnections(60, TimeUnit.SECONDS)定期清理空閑連接避免連接池被死連接占滿。5.4 Vue 打包放進(jìn) SpringBoot 之后的刷新 404 問題現(xiàn)象前端 Vue.js 項(xiàng)目打包后的 dist 目錄放到 SpringBoot 的static目錄下訪問首頁沒問題但點(diǎn)擊前端路由跳轉(zhuǎn)到/course/1這種路徑后按 F5 刷新就報(bào) 404。原因Vue 是單頁應(yīng)用路由用的 history 模式刷新時(shí)瀏覽器向服務(wù)器請(qǐng)求/course/1這個(gè)路徑但 SpringBoot 里沒有對(duì)應(yīng)的靜態(tài)文件后端直接返回 404。開發(fā)環(huán)境沒有這個(gè)問題是 vite 或 webpack 的 dev server 做了 history 回退。解決后端加一個(gè)轉(zhuǎn)發(fā)規(guī)則把非接口路徑的請(qǐng)求都轉(zhuǎn)發(fā)到首頁。寫一個(gè)配置類實(shí)現(xiàn)WebMvcConfigurer添加一個(gè) ViewController 把錯(cuò)誤路徑轉(zhuǎn)發(fā)到index.html。但是要注意/api/**和/admin/**這些接口路徑不能轉(zhuǎn)否則請(qǐng)求后端接口會(huì)被錯(cuò)誤地返回 HTML排查起來更迷惑。5.5 阿里云 OSS 視頻上傳失敗STS 臨時(shí)憑證失效現(xiàn)象后臺(tái)運(yùn)營在管理臺(tái)上傳課程視頻時(shí)偶爾上傳到一半報(bào)InvalidAccessKeyId特別是上傳大視頻時(shí)幾乎必現(xiàn)。原因視頻點(diǎn)播和 OSS 的臨時(shí)憑證 STS 默認(rèn)有效期是一個(gè)小時(shí)但視頻上傳不是一次性的前端分片上傳大文件可能超過憑證有效期。憑證過期后后續(xù)分片攜帶舊憑證請(qǐng)求 OSS服務(wù)端直接拒絕。解決不要在前端固定一個(gè) STS 憑證上傳所有文件。每次開始上傳時(shí)后端重新頒發(fā) STS前端檢測到上傳失敗時(shí)捕獲InvalidAccessKeyId錯(cuò)誤后重新獲取憑證并重試當(dāng)前分片。同時(shí)在服務(wù)端把 STS 的有效期適當(dāng)延長比如 3 個(gè)小時(shí)但不要超過 12 小時(shí)安全性和體驗(yàn)要權(quán)衡。5.6 ActiveMQ 消息堆積消費(fèi)速度跟不上生產(chǎn)速度現(xiàn)象問答模塊的異步通知越來越多ActiveMQ 控制臺(tái)看到某個(gè)隊(duì)列的PendingMessage數(shù)量持續(xù)上漲用戶反饋收不到回答通知。原因消費(fèi)者處理每條消息的邏輯里有調(diào)用遠(yuǎn)程接口的操作比如發(fā)送郵件或短信這個(gè)遠(yuǎn)程操作慢導(dǎo)致消費(fèi)吞吐量遠(yuǎn)低于生產(chǎn)量。解決先看消費(fèi)者日志確認(rèn)是遠(yuǎn)程調(diào)用慢然后改消費(fèi)者邏輯把發(fā)郵件的操作改成先入庫、再異步批量發(fā)送。同時(shí)給JmsListener配置并發(fā)消費(fèi)者concurrency 5-10讓 5 到 10 個(gè)線程同時(shí)消費(fèi)。這里要提醒一下消息的消費(fèi)冪等性一定要做否則消費(fèi)者重啟時(shí)重復(fù)消費(fèi)用戶會(huì)收到兩條重復(fù)通知。在數(shù)據(jù)庫里加一個(gè)message_id唯一索引消費(fèi)前先嘗試插入插入沖突說明處理過了直接跳過。6. 進(jìn)階驗(yàn)證用 Docker Compose 一鍵部署 壓測確認(rèn)系統(tǒng)能上線項(xiàng)目開發(fā)完本地能跑通不等于能上線。我習(xí)慣把所有中間件編排進(jìn) Docker Compose在測試環(huán)境一鍵拉起然后立刻做一輪簡單的壓測確認(rèn)瓶頸不在基礎(chǔ)設(shè)施層。Docker 的部署方案分兩層中間件層用 Docker Compose 管應(yīng)用層用 Dockerfile 打包鏡像。先看中間件編排version: 3.8 services: mysql: image: mysql:8.0 container_name: edu-mysql environment: MYSQL_ROOT_PASSWORD: root123 TZ: Asia/Shanghai ports: - 3306:3306 volumes: - /data/mysql:/var/lib/mysql command: --character-set-serverutf8mb4 redis: image: redis:7.0 container_name: edu-redis ports: - 6379:6379 command: redis-server --appendonly yes activemq: image: rmohr/activemq:5.15.9 container_name: edu-activemq ports: - 61616:61616 - 8161:8161中間件的參數(shù)說明TZ: Asia/Shanghai同時(shí)設(shè)置了容器的時(shí)區(qū)和 MySQL 的時(shí)區(qū)解決 5.1 提到的 serverTimezone 報(bào)錯(cuò)Redis 加了appendonly yes開啟持久化避免容器重啟后緩存數(shù)據(jù)全部丟失ActiveMQ 映射了 61616服務(wù)端口和 8161控制臺(tái)端口控制臺(tái)可以用來排查消息堆積。應(yīng)用服務(wù)編排進(jìn)同一個(gè) Compose 文件里用 depends_on 指定依賴順序。網(wǎng)關(guān)服務(wù)對(duì)外暴露 8080其余服務(wù)只暴露給內(nèi)部容器網(wǎng)絡(luò)不映射宿主機(jī)端口這樣外部只能走網(wǎng)關(guān)服務(wù)端口不會(huì)被直接打穿。部署之后驗(yàn)證系統(tǒng)能不能扛住基本流量我用一個(gè)很簡單的方法用ab壓測網(wǎng)關(guān)接口看吞吐量和錯(cuò)誤率。# 壓測課程列表接口模擬 200 個(gè)并發(fā)每個(gè)并發(fā)發(fā) 1000 個(gè)請(qǐng)求 ab -n 200000 -c 200 -k \ -H token: your-test-token \ http://localhost:8080/api/course/list # 壓測結(jié)果重點(diǎn)看這 3 個(gè)指標(biāo) # Time per request: 平均每個(gè)請(qǐng)求耗時(shí)應(yīng)小于 200ms # Failed requests: 應(yīng)接近 0 # Requests per second: 吞吐量單機(jī)網(wǎng)關(guān)應(yīng)超過 500壓測結(jié)果如果 Failed requests 不為零先用dmesg看是不是端口隊(duì)列滿了再逐個(gè)排查是 MySQL 慢查詢還是 Redis 連接數(shù)不夠。我的經(jīng)驗(yàn)是online_edu 這種體量的系統(tǒng)先確認(rèn)基礎(chǔ)設(shè)施沒選錯(cuò)型號(hào)再談業(yè)務(wù)優(yōu)化。做 docker compose 部署和壓測這件事我吃了不少虧。以前圖省事本地直接把服務(wù)跑起來就給測試看結(jié)果每次環(huán)境不一致要么 MySQL 配置不一樣要么 Redis 版本不同測試報(bào) bug 我本地又復(fù)現(xiàn)不了最后發(fā)現(xiàn)是環(huán)境差異。用 Docker Compose 之后整個(gè)團(tuán)隊(duì)的環(huán)境完全一致這個(gè)“在我電腦上能跑”的玄學(xué)問題算是徹底根治了。最后的習(xí)慣是每次改完代碼先跑一遍壓測接口確認(rèn)響應(yīng)時(shí)間沒有明顯劣化再提交合并。壓測腳本放在項(xiàng)目的script目錄下隨手就能執(zhí)行不用臨時(shí)敲命令。希望這些步驟和踩坑記錄能幫你少走一段彎路把 online_edu 從本機(jī)跑通做到真正敢上線。本文還有配套的精品資源點(diǎn)擊獲取