做過幾個(gè)高校信息化項(xiàng)目的老人都知道選課系統(tǒng)是最能檢驗(yàn)一套架構(gòu)是否過關(guān)的試金石。這篇文章要聊的就是一個(gè)基于SpringBoot Vue SpringCloud微服務(wù)架構(gòu)的高校教學(xué)選課管理系統(tǒng)。它解決的問題很具體——教務(wù)排課、學(xué)生選課、成績(jī)管理這些高校剛需業(yè)務(wù)要扛得住開學(xué)選課那幾分鐘的流量洪峰又不能讓代碼爛成一鍋粥。無論你是拿它做畢業(yè)設(shè)計(jì)還是工作中要接手類似的教務(wù)系統(tǒng)這套拆分思路和落地細(xì)節(jié)應(yīng)該都能給你一點(diǎn)參考。我盡量把整個(gè)項(xiàng)目從設(shè)計(jì)到實(shí)現(xiàn)到踩坑的過程都攤開講包含服務(wù)劃分、選課并發(fā)控制、分布式鎖、事務(wù)處理、前后端聯(lián)調(diào)、部署運(yùn)維這些環(huán)節(jié)。有的地方會(huì)放代碼有的地方只講思路因?yàn)橛行┛硬皇谴a能寫明白的。1. 選課系統(tǒng)為什么需要微服務(wù)業(yè)務(wù)痛點(diǎn)與技術(shù)選型1.1 高校選課的真實(shí)業(yè)務(wù)場(chǎng)景先說業(yè)務(wù)。高校選課和電商秒殺看著像實(shí)際有區(qū)別。電商秒殺是有限庫(kù)存搶購(gòu)選課系統(tǒng)除了要處理并發(fā)還在背后涉及培養(yǎng)方案、課程池、預(yù)選、正選、退補(bǔ)選、課程沖突檢測(cè)、學(xué)分上限、教師錄入成績(jī)等多個(gè)狀態(tài)流轉(zhuǎn)。傳統(tǒng)單體系統(tǒng)把所有邏輯塞進(jìn)一個(gè)工程里學(xué)期初選課高峰期一到數(shù)據(jù)庫(kù)連接池被打滿接口響應(yīng)從200毫秒變成20秒全校學(xué)生一起卡死在提交中頁(yè)面。我見過不少學(xué)校的做法是在選課前一周讓各班班長(zhǎng)手動(dòng)統(tǒng)計(jì)再錄入系統(tǒng)本質(zhì)上是為了繞開并發(fā)。這種方案治標(biāo)不治本。以某普通本科院校為例一個(gè)年級(jí)四五千人熱門課程就二三百個(gè)名額開放選課后的前10秒內(nèi)查詢請(qǐng)求可能沖到每秒五千以上。單體服務(wù)加一臺(tái)MySQL很難撐住這種瞬時(shí)壓力。于是微服務(wù)就成了一個(gè)順理成章的選項(xiàng)。不是說微服務(wù)能憑空增加性能而是它能把選課這條鏈路里的各個(gè)模塊拆開獨(dú)立部署、獨(dú)立擴(kuò)縮容。課程列表服務(wù)頂不住了就多開兩個(gè)實(shí)例成績(jī)服務(wù)平時(shí)沒什么流量保持單實(shí)例就行。資源用在刀刃上系統(tǒng)的穩(wěn)定性上限就高了。1.2 技術(shù)選型為什么是SpringCloud SpringBoot Vue這套組合已經(jīng)是國(guó)內(nèi)Java后端圈子的事實(shí)標(biāo)準(zhǔn)。SpringBoot負(fù)責(zé)快速構(gòu)建業(yè)務(wù)服務(wù)SpringCloud提供微服務(wù)治理能力Vue負(fù)責(zé)前端頁(yè)面的交互與展示。具體到組件我的選擇如下組件選型理由注冊(cè)中心 / 配置中心Nacos同時(shí)解決服務(wù)發(fā)現(xiàn)和配置管理中文文檔全社區(qū)活躍網(wǎng)關(guān)Spring Cloud Gateway統(tǒng)一入口做路由、鑒權(quán)、限流遠(yuǎn)程調(diào)用OpenFeign聲明式HTTP客戶端使用體驗(yàn)接近本地方法調(diào)用服務(wù)保護(hù)Sentinel限流、降級(jí)、熔斷三合一控制臺(tái)可視化認(rèn)證JWT OAuth2資源服務(wù)器無狀態(tài)網(wǎng)關(guān)統(tǒng)一校驗(yàn)緩存 / 分布式鎖Redis Redisson緩存課程信息鎖選課操作前端Vue3 Element Plus Vite生態(tài)成熟組件豐富后臺(tái)管理系統(tǒng)夠用數(shù)據(jù)庫(kù)MySQL 8 MyBatis-Plus關(guān)系型數(shù)據(jù)庫(kù)適合教務(wù)數(shù)據(jù)插件減少重復(fù)SQL這里有個(gè)容易踩的坑SpringCloud版本和SpringBoot版本必須嚴(yán)格對(duì)應(yīng)。SpringCloud 2022.0.x對(duì)應(yīng)SpringBoot 3.xSpringCloud 2021.0.x對(duì)應(yīng)SpringBoot 2.6.x。如果直接在網(wǎng)上找一個(gè)SpringBoot 2.3的教程配SpringCloud Alibaba 2022大概率啟動(dòng)就報(bào)錯(cuò)。用IDEA創(chuàng)建項(xiàng)目的時(shí)候最好到Spring Initializr官網(wǎng)選好版本再導(dǎo)進(jìn)來。選這套架構(gòu)還有一個(gè)實(shí)際考量招聘市場(chǎng)上會(huì)SpringBoot和Vue的人多后續(xù)接手維護(hù)不需要太高的門檻。技術(shù)棧不夠炫但足夠穩(wěn)。2. 服務(wù)拆分與數(shù)據(jù)邊界設(shè)計(jì)模塊怎么分才不亂2.1 按業(yè)務(wù)域拆分的六個(gè)服務(wù)很多第一次做微服務(wù)的人最容易犯的毛病是把Controller拆開當(dāng)成微服務(wù)。比如一個(gè)項(xiàng)目里按userController、courseController、selectionController分成三個(gè)模塊但是數(shù)據(jù)庫(kù)還是同一個(gè)事務(wù)還是靠Spring本地事務(wù)管那就只是換了個(gè)皮的分布式單體該卡還是卡該崩還是崩。正確的拆分方式是按業(yè)務(wù)域拆分每個(gè)服務(wù)擁有獨(dú)立的數(shù)據(jù)庫(kù)獨(dú)立部署通過接口通信。這個(gè)項(xiàng)目我拆成了六個(gè)服務(wù)gateway-server網(wǎng)關(guān)服務(wù)負(fù)責(zé)路由轉(zhuǎn)發(fā)、統(tǒng)一鑒權(quán)、限流不寫業(yè)務(wù)代碼。auth-server認(rèn)證授權(quán)服務(wù)負(fù)責(zé)登錄、JWT簽發(fā)、驗(yàn)證碼、密碼加密是用戶的入口。system-server系統(tǒng)管理服務(wù)負(fù)責(zé)學(xué)生、教師、管理員的基礎(chǔ)信息維護(hù)也處理院系列表、班級(jí)列表這類公共數(shù)據(jù)。course-server課程服務(wù)負(fù)責(zé)課程庫(kù)、開課計(jì)劃、教師開課信息是選課的數(shù)據(jù)源頭。selection-server選課服務(wù)核心業(yè)務(wù)服務(wù)負(fù)責(zé)選課、退課、選課結(jié)果查詢、沖突校驗(yàn)、容量控制。這個(gè)服務(wù)是流量的主要沖擊點(diǎn)需要重點(diǎn)關(guān)注。grade-server成績(jī)服務(wù)負(fù)責(zé)成績(jī)錄入、成績(jī)查詢、學(xué)分統(tǒng)計(jì)。注意成績(jī)服務(wù)與選課服務(wù)的數(shù)據(jù)需要最終一致但不要求強(qiáng)一致。服務(wù)邊界劃分的原則是一個(gè)服務(wù)內(nèi)的修改不影響其他服務(wù)服務(wù)之間通過API通信不直接共享數(shù)據(jù)庫(kù)表。選課服務(wù)需要知道課程的容量信息但課程表在course服務(wù)庫(kù)里所以course服務(wù)必須提供查詢課程剩余容量的接口或者選課服務(wù)在本地冗余一份課程容量的緩存。實(shí)際項(xiàng)目中我選擇了緩存方案后面細(xì)說。2.2 數(shù)據(jù)庫(kù)獨(dú)立與核心表設(shè)計(jì)每個(gè)服務(wù)獨(dú)占一個(gè)數(shù)據(jù)庫(kù)這是微服務(wù)和單體在數(shù)據(jù)層最大的區(qū)別。以選課服務(wù)為例核心表如下selection_record選課記錄表字段包括id、student_id、course_id、course_name、teacher_name、class_time、credit、semester、status、create_time。關(guān)鍵設(shè)計(jì)是聯(lián)合唯一索引uk_student_course(student_id, course_id)這是防止同一學(xué)生重復(fù)選同一門課的最后一道防線。course_stock課程容量表存儲(chǔ)課程的總?cè)萘亢鸵堰x人數(shù)字段為id、course_id、total_capacity、selected_count、version。這個(gè)表會(huì)頻繁更新并發(fā)高時(shí)容易產(chǎn)生熱點(diǎn)行更新問題。drop_record退課記錄表用于審計(jì)。課程服務(wù)那邊還有course_info課程基本信息、teacher_course教師開課關(guān)聯(lián)、semester_plan學(xué)期開課計(jì)劃等表這里不逐一展開。特別強(qiáng)調(diào)一下容量控制。選課服務(wù)里不能用先查剩余容量再判斷是否大于0最后插入選課記錄這種三步走的流程因?yàn)椴l(fā)時(shí)多個(gè)請(qǐng)求同時(shí)查到容量還剩1同時(shí)通過校驗(yàn)最后超出容量。正確做法是把容量扣減放在選課記錄插入的同一個(gè)事務(wù)里用帶條件的UPDATE原子操作UPDATE course_stock SET selected_count selected_count 1 WHERE course_id #{courseId} AND selected_count total_capacity;如果影響行數(shù)為0說明容量已滿直接返回課程已選滿。這個(gè)SQL是原子性的不需要額外加鎖也是防超賣的基礎(chǔ)。再加上前面說的唯一索引雙保險(xiǎn)兜底。2.3 接口設(shè)計(jì)與服務(wù)間調(diào)用的坑服務(wù)間調(diào)用我用OpenFeign。比如selection-server需要查詢課程的基本信息不可能直接訪問course-server的數(shù)據(jù)庫(kù)只能是course-server暴露一個(gè)GET /api/course/info/{courseId}接口selection-server寫一個(gè)Feign Client調(diào)用。有個(gè)實(shí)際的坑Feign調(diào)用默認(rèn)會(huì)繼承請(qǐng)求頭但如果你用了JWT網(wǎng)關(guān)已經(jīng)把用戶信息解析出來了轉(zhuǎn)發(fā)到具體服務(wù)時(shí)服務(wù)并不知道當(dāng)前用戶是誰。我的做法是在網(wǎng)關(guān)層面把用戶ID放入請(qǐng)求頭比如X-User-Id然后在Feign調(diào)用時(shí)通過RequestInterceptor把這個(gè)header透?jìng)鞯较乱粋€(gè)服務(wù)。否則選課服務(wù)根本不知道是誰在選課。Feign配置示例Configuration public class FeignConfig { Bean public RequestInterceptor requestInterceptor() { return requestTemplate - { ServletRequestAttributes attrs (ServletRequestAttributes) RequestContextHolder.getRequestAttributes(); if (attrs ! null) { HttpServletRequest request attrs.getRequest(); requestTemplate.header(X-User-Id, request.getHeader(X-User-Id)); requestTemplate.header(X-User-Role, request.getHeader(X-User-Role)); } }; } }新人也容易忽略跨服務(wù)的異常處理不能只靠HTTP狀態(tài)碼。Feign調(diào)用失敗時(shí)拋的是FeignException如果你的業(yè)務(wù)接口返回了200但body里帶上錯(cuò)誤碼調(diào)用方很難判斷成功還是失敗。我的建議是設(shè)計(jì)一個(gè)統(tǒng)一的響應(yīng)體結(jié)構(gòu)ResultT包含code、message、data三個(gè)字段Feign調(diào)用時(shí)先判斷code是否為200才算真正成功。3. 核心功能實(shí)現(xiàn)認(rèn)證、選課、前端聯(lián)動(dòng)3.1 登錄認(rèn)證與網(wǎng)關(guān)鑒權(quán)鏈路整個(gè)認(rèn)證閉環(huán)是這樣的學(xué)生或教師在瀏覽器輸入賬號(hào)密碼請(qǐng)求打到Gateway路由到auth-serverauth-server校驗(yàn)賬號(hào)密碼后生成JWT返回。前端把JWT存到localStorage或pinia里的state后續(xù)每個(gè)請(qǐng)求都在Authorization頭帶著這個(gè)Token。Gateway有兩個(gè)活兒要干。第一是鑒權(quán)攔截請(qǐng)求判斷白名單外的路徑都要攜帶合法JWT。白名單包括登錄接口、驗(yàn)證碼接口、課程查詢接口未登錄時(shí)可瀏覽。第二是轉(zhuǎn)發(fā)把帶Token的請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)的微服務(wù)同時(shí)把解析出的用戶信息放入請(qǐng)求頭。網(wǎng)關(guān)鑒權(quán)不能只做有沒有Token的判斷還要校驗(yàn)Token是否過期、簽名是否正確。我用了Spring Cloud Gateway的GlobalFilter加JWT解析Component public class AuthGlobalFilter implements GlobalFilter, Ordered { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request exchange.getRequest(); String path request.getPath().value(); // 白名單直接放行 if (isWhiteList(path)) { return chain.filter(exchange); } String token getTokenFromRequest(request); // 解析JWT失敗則返回401 Claims claims JwtUtil.parseToken(token); if (claims null) { return unauthorized(exchange); } // 把用戶信息放入后續(xù)請(qǐng)求頭 ServerHttpRequest newRequest request.mutate() .header(X-User-Id, claims.get(userId).toString()) .header(X-User-Role, claims.get(role).toString()) .build(); return chain.filter(exchange.mutate().request(newRequest).build()); } }這里有個(gè)細(xì)節(jié)網(wǎng)關(guān)采用的是WebFlux響應(yīng)式編程模型不能直接用Servlet API的HttpServletRequest要用ServerHttpRequest。很多從單體轉(zhuǎn)過來的開發(fā)者在這個(gè)地方卡很久。3.2 選課核心流程與分布式鎖實(shí)踐選課是系統(tǒng)的心臟我把它的完整流程拆開講。學(xué)生提交選課請(qǐng)求帶上課程ID和學(xué)期。selection-server先校驗(yàn)這個(gè)課程在當(dāng)前學(xué)期是否開放選課——開放時(shí)間是由教務(wù)在后臺(tái)配置的不在開放時(shí)間窗口內(nèi)的請(qǐng)求直接拒絕。這個(gè)校驗(yàn)不能只靠前端倒計(jì)時(shí)因?yàn)榭梢岳@過前端直接打接口。接著做沖突檢測(cè)。一門課有固定上課時(shí)間比如周一3-4節(jié)另一門課也是周一3-4節(jié)兩門都選就沖突了。這個(gè)邏輯需要在選課服務(wù)里完成查詢學(xué)生的已選課程列表逐個(gè)對(duì)比上課時(shí)間?？紤]到性能學(xué)生當(dāng)前學(xué)期的已選課程數(shù)量一般不超過30門直接內(nèi)存循環(huán)比較開銷可以接受。容量扣減用前面說的原子UPDATE。這一步和插入選課記錄需要在一個(gè)本地事務(wù)里完成但如果選課服務(wù)有多個(gè)實(shí)例普通的本地事務(wù)只能保證單個(gè)實(shí)例內(nèi)部的一致性兩個(gè)學(xué)生同時(shí)選同一門容量只剩1的課時(shí)光靠SQL條件更新還不夠——因?yàn)橐粋€(gè)請(qǐng)求可能在實(shí)例A扣減成功另一個(gè)在實(shí)例B扣減時(shí)鎖等待或超時(shí)。這時(shí)候就需要分布式鎖。我使用Redisson實(shí)現(xiàn)分布式鎖鎖的粒度是課程ID而不是學(xué)生ID。為什么要鎖課程因?yàn)槠款i在課程容量只要同一門課程的選課請(qǐng)求被串行化處理就不會(huì)出現(xiàn)超賣。鎖學(xué)生ID沒有意義因?yàn)椴煌瑢W(xué)生選同一門課互不沖突關(guān)鍵競(jìng)爭(zhēng)點(diǎn)是課程容量。Autowired private RedissonClient redissonClient; public Boolean selectCourse(Long studentId, Long courseId, String semester) { String lockKey SELECT_LOCK: courseId; RLock lock redissonClient.getLock(lockKey); boolean acquired false; try { // 嘗試等待2秒鎖自動(dòng)過期10秒 acquired lock.tryLock(2, 10, TimeUnit.SECONDS); if (!acquired) { return false; // 當(dāng)前課程操作繁忙請(qǐng)重試 } // 這里執(zhí)行容量扣減 插入選課記錄 沖突檢測(cè) return doSelectCourse(studentId, courseId, semester); } catch (Exception e) { log.error(選課失敗, e); return false; } finally { if (acquired lock.isHeldByCurrentThread()) { lock.unlock(); } } }鎖的時(shí)間設(shè)置有個(gè)學(xué)問。選課操作的業(yè)務(wù)邏輯通常幾十毫秒就執(zhí)行完了為什么不設(shè)置成1秒甚至更短因?yàn)楦叻迤诳赡艹霈F(xiàn)線程排隊(duì)一個(gè)請(qǐng)求在鎖里跑得慢后面的請(qǐng)求都卡在tryLock等待如果鎖自動(dòng)過期時(shí)間太短前一個(gè)線程還沒跑完鎖就釋放了后面的線程拿鎖進(jìn)入又會(huì)造成并發(fā)覆蓋。10秒是我在測(cè)試環(huán)境壓出來的一個(gè)比較穩(wěn)的值實(shí)際部署時(shí)可以根據(jù)接口耗時(shí)調(diào)整。鎖粒度這里我再啰嗦一句不要把整個(gè)選課接口用一把全局鎖比如SELECT_LOCK:ALL。那樣的話不同課程之間也會(huì)互相阻塞系統(tǒng)吞吐量會(huì)直線下降。按課程ID加鎖不同課程互不影響才是分布式鎖的正確打開方式。3.3 Vue前端動(dòng)態(tài)路由與選課頁(yè)面的交互細(xì)節(jié)前端用的是Vue3加Element Plus。管理端頁(yè)面包括課程管理、學(xué)生管理、教師管理、選課規(guī)則配置、成績(jī)錄入等模塊學(xué)生端頁(yè)面包括選課大廳、我的課表、成績(jī)查詢、個(gè)人中心。動(dòng)態(tài)路由是前端的核心難點(diǎn)之一。不同角色登錄后能看到的路由不同。我的做法不是把路由表寫死在代碼里而是登錄之后根據(jù)用戶角色動(dòng)態(tài)生成。具體實(shí)現(xiàn)用戶信息從auth-server返回時(shí)帶一個(gè)role字段student/teacher/admin前端拿到后遍歷一份角色與路由的映射表用router.addRoute()動(dòng)態(tài)添加可訪問的頁(yè)面路由。這樣學(xué)生訪問管理端頁(yè)面的URL時(shí)由于路由根本不存在會(huì)直接落到404頁(yè)面比單純靠按鈕隱藏更安全。選課大廳頁(yè)面的交互有一個(gè)高頻問題選課按鈕點(diǎn)擊后的狀態(tài)反饋。選課接口是異步的后端處理需要時(shí)間如果用戶連續(xù)點(diǎn)擊三次就會(huì)發(fā)出三個(gè)相同請(qǐng)求雖然后端有分布式鎖和唯一索引兜底但用戶體驗(yàn)會(huì)很差還會(huì)白白消耗服務(wù)器資源。我建議在按鈕點(diǎn)擊后立即置為loading狀態(tài)并禁用el-button typeprimary :loadingselectingMap[course.id] :disabledselectedSet.has(course.id) clickhandleSelect(course) {{ selectedSet.has(course.id) ? 已選 : 選課 }} /el-buttonVue中處理這類防重復(fù)提交還可以在handleSelect方法里用狀態(tài)位攔截而不是依賴后端的鎖。前端做一層攔截后端做一層兜底雙保險(xiǎn)。課程余量刷新我用的是輪詢每30秒請(qǐng)求一次剩余容量接口。高峰期可以把間隔縮短到5秒但要注意別把接口打爆。更好的方案是WebSocket推送但考慮成本和復(fù)雜度輪詢對(duì)選課系統(tǒng)已經(jīng)夠用了。3.4 教務(wù)管理與教師端的功能拆解除了核心的選課流程系統(tǒng)還有教務(wù)排課和教師成績(jī)管理兩大塊。教務(wù)管理員登錄后在課程服務(wù)里維護(hù)開課計(jì)劃選擇學(xué)期、課程、授課教師、上課時(shí)間、上課地點(diǎn)、容量上限。開課計(jì)劃發(fā)布后進(jìn)入選課服務(wù)的course_stock表生成對(duì)應(yīng)課程的容量記錄初始selected_count為0。這個(gè)同步動(dòng)作我在course-server發(fā)布開課計(jì)劃后直接調(diào)用selection-server的接口完成但這里就引出跨服務(wù)數(shù)據(jù)一致性的問題接下來專門講。教師端功能相對(duì)簡(jiǎn)單查看自己名下的課程和選課學(xué)生列表、錄入成績(jī)、導(dǎo)出成績(jī)單。成績(jī)錄入完成后數(shù)據(jù)落在grade-server學(xué)生端在我的成績(jī)頁(yè)面通過調(diào)用grade-server的查詢接口展示成績(jī)。這里有個(gè)業(yè)務(wù)規(guī)則需要處理成績(jī)是否對(duì)所有人可見還是只對(duì)本人可見出于隱私考慮查詢成績(jī)接口只允許學(xué)生本人訪問教師只能看自己教的課程的學(xué)生成績(jī)這些在網(wǎng)關(guān)鑒權(quán)和接口參數(shù)校驗(yàn)里都要做。4. 分布式架構(gòu)的幾個(gè)硬骨頭事務(wù)、限流與冪等4.1 跨服務(wù)事務(wù)別一上來就Seata選課系統(tǒng)里跨服務(wù)操作的場(chǎng)景不少開課計(jì)劃發(fā)布要同時(shí)寫入course庫(kù)和selection庫(kù)教師錄入成績(jī)要寫grade庫(kù)還要更新學(xué)生的已修學(xué)分匯總。單體系統(tǒng)里一個(gè)Transactional就搞定了微服務(wù)里就麻煩了。很多人一聽到分布式事務(wù)就想到Seata然后把系統(tǒng)搞得很復(fù)雜。我的經(jīng)驗(yàn)是能不引入分布式事務(wù)框架就不引入優(yōu)先通過業(yè)務(wù)設(shè)計(jì)規(guī)避。什么叫規(guī)避開課計(jì)劃發(fā)布后selection服務(wù)需要生成容量記錄這個(gè)可以做成補(bǔ)償式course-server發(fā)布成功后發(fā)一條消息到RabbitMQselection-server消費(fèi)消息生成容量記錄。如果生成失敗通過定時(shí)的對(duì)賬任務(wù)掃描course表和selection表發(fā)現(xiàn)缺失就自動(dòng)補(bǔ)齊。這樣做的代價(jià)是最終一致而不是實(shí)時(shí)一致?？紤]到容量記錄晚幾秒生成對(duì)選課沒有實(shí)質(zhì)影響這個(gè)方案完全成立。如果業(yè)務(wù)確實(shí)強(qiáng)一致再考慮Seata。Seata的AT模式對(duì)代碼侵入小但要注意它依賴全局鎖在高并發(fā)場(chǎng)景下會(huì)把性能拖垮。選課服務(wù)里我不用Seata因?yàn)槿萘靠蹨p和選課記錄插入本來就在同一庫(kù)的同一個(gè)事務(wù)里不需要分布式事務(wù)。4.2 高并發(fā)下的限流與降級(jí)選課高峰期不能讓請(qǐng)求無限量涌進(jìn)系統(tǒng)。網(wǎng)關(guān)層面我用Sentinel做限流規(guī)則是每個(gè)用戶每秒鐘最多請(qǐng)求選課接口10次整體選課接口每秒最多5000次。超出閾值的請(qǐng)求直接返回系統(tǒng)繁忙請(qǐng)稍后重試。Sentinel也可以按來源限流比如某條熱門課程的選課接口單課程QPS限制200防止熱點(diǎn)請(qǐng)求壓垮數(shù)據(jù)庫(kù)。配置方式支持控制臺(tái)可視化操作也支持在代碼里硬編碼PostMapping(/select) SentinelResource(value selectCourse, blockHandler selectCourseBlockHandler) public ResultString select(RequestParam Long courseId) { // 選課處理邏輯 } public ResultString selectCourseBlockHandler(Long courseId, BlockException e) { return Result.error(選課人數(shù)過多請(qǐng)稍后重試); }還有一層降級(jí)策略course-server查詢課程列表時(shí)依賴數(shù)據(jù)庫(kù)一旦數(shù)據(jù)庫(kù)壓力過大直接降級(jí)返回緩存里的課程信息。Redis里緩存一份課程列表有效期30秒哪怕數(shù)據(jù)庫(kù)短暫不可用學(xué)生也能看到課程列表只是可能不及時(shí)。4.3 選課接口的冪等設(shè)計(jì)選課的冪等性好多人忽略。用戶在極端情況下可能重復(fù)提交選課請(qǐng)求網(wǎng)絡(luò)超時(shí)也會(huì)導(dǎo)致前端重試。后端冪等設(shè)計(jì)有兩個(gè)維度。第一層已經(jīng)講過了選課記錄表的聯(lián)合唯一索引同一學(xué)生同一課程只要插入一次重復(fù)插入會(huì)報(bào)DuplicateKeyException。我在代碼里捕獲這個(gè)異常直接返回您已選擇該課程。第二層是請(qǐng)求級(jí)別的冪等前端在發(fā)起選課請(qǐng)求時(shí)生成一個(gè)requestId后端收到請(qǐng)求先查Redis里有沒有這個(gè)requestId的標(biāo)記有說明已經(jīng)處理過直接返回上次結(jié)果沒有才繼續(xù)處理。這個(gè)機(jī)制能防止網(wǎng)絡(luò)重試導(dǎo)致的重復(fù)扣減容量。public ResultString selectWithIdempotent(String requestId, Long studentId, Long courseId) { String idempotentKey IDEMPOTENT: requestId; // SETNX若返回false說明已處理過 Boolean first redisTemplate.opsForValue() .setIfAbsent(idempotentKey, courseId.toString(), 30, TimeUnit.MINUTES); if (!Boolean.TRUE.equals(first)) { return Result.success(選課請(qǐng)求已處理請(qǐng)勿重復(fù)提交); } // 走正常選課流程 return doSelectCourse(studentId, courseId); }這里的key有效期設(shè)置30分鐘足夠了選課接口的響應(yīng)時(shí)間通常不超過幾百毫秒30分鐘內(nèi)不會(huì)有人用同一個(gè)requestId再次請(qǐng)求。就算有也是業(yè)務(wù)上的異常情況。5. 項(xiàng)目環(huán)境搭建與部署實(shí)操5.1 本地開發(fā)環(huán)境Nacos、Redis、MySQL的初始化這個(gè)項(xiàng)目本地跑起來需要Nacos、Redis、MySQL三個(gè)中間件。我給新人的建議是別一個(gè)個(gè)手動(dòng)下載安裝用Docker Compose一把梭。項(xiàng)目根目錄放一個(gè)docker-compose.ymlversion: 3.8 services: mysql: image: mysql:8.0 container_name: edu-mysql environment: MYSQL_ROOT_PASSWORD: root123 ports: - 3306:3306 volumes: - ./db:/docker-entrypoint-initdb.d:ro redis: image: redis:7.0 container_name: edu-redis ports: - 6379:6379 nacos: image: nacos/nacos-server:v2.2.3 container_name: edu-nacos environment: MODE: standalone NACOS_AUTH_ENABLE: false ports: - 8848:8848 - 9848:9848啟動(dòng)命令就一條docker compose up -d。Nacos默認(rèn)占用88489848是gRPC端口2021年之后的Nacos版本一定要映射這個(gè)端口不然后端的服務(wù)注冊(cè)心跳會(huì)報(bào)錯(cuò)。運(yùn)行微服務(wù)工程時(shí)有個(gè)每人都要踩一遍的坑服務(wù)啟動(dòng)順序。如果你還沒啟動(dòng)Nacos就把a(bǔ)uth-server啟動(dòng)了服務(wù)會(huì)反復(fù)重試連接Nacos然后報(bào)錯(cuò)。正確順序是先啟動(dòng)Nacos再啟動(dòng)業(yè)務(wù)服務(wù)最后啟動(dòng)Gateway。業(yè)務(wù)服務(wù)之間互相調(diào)用時(shí)只要注冊(cè)中心是通的Feign會(huì)自動(dòng)找到目標(biāo)服務(wù)實(shí)例不要求服務(wù)啟動(dòng)順序。5.2 SpringBoot服務(wù)的端口規(guī)劃六個(gè)服務(wù)端口如果不規(guī)劃好啟動(dòng)時(shí)會(huì)沖突。我的約定如下服務(wù)端口說明gateway-server8080對(duì)外統(tǒng)一入口auth-server8081認(rèn)證授權(quán)system-server8082用戶與基礎(chǔ)數(shù)據(jù)course-server8083課程服務(wù)selection-server8084選課核心服務(wù)grade-server8085成績(jī)服務(wù)每個(gè)服務(wù)在application.yml里配置各自的server.port同時(shí)配置Nacos地址和數(shù)據(jù)庫(kù)連接。需要注意Nacos上配置的數(shù)據(jù)庫(kù)地址不能寫成localhost如果你用的是Docker起的MySQL要從宿主機(jī)訪問地址應(yīng)該是你本機(jī)局域網(wǎng)IP或者直接用mysql這個(gè)容器服務(wù)名前提是SpringBoot服務(wù)也在同一個(gè)Docker網(wǎng)絡(luò)里。5.3 前端打包與Nginx部署Vue前端開發(fā)模式跑起來很容易npm run dev就行。但生產(chǎn)環(huán)境要打包成靜態(tài)文件然后扔到Nginx里。打包之前有件事必須做配置生產(chǎn)環(huán)境的后端接口地址。我在開發(fā)環(huán)境用Vite的代理解決跨域請(qǐng)求/api代理到http://localhost:8080。生產(chǎn)環(huán)境沒有Vite幫忙Nginx得配置反向代理server { listen 80; server_name your-domain.com; # 前端靜態(tài)文件 location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } # 后端接口代理 location /api/ { proxy_pass http://gateway-server:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }這里有個(gè)最常見的部署事故SPA路由模式下的刷新404問題。因?yàn)榍岸耸莌istory路由直接訪問/student/course時(shí)Nginx找不到這個(gè)路徑對(duì)應(yīng)的物理文件。上面的配置已經(jīng)寫了try_files $uri $uri/ /index.html意思是找不到文件就回退到index.html由前端JS接管路由。這一行沒寫刷新頁(yè)面必白屏。5.4 Docker Compose整合部署完整項(xiàng)目部署時(shí)我建議用Docker Compose把所有服務(wù)編排在一個(gè)網(wǎng)絡(luò)里包括前端Nginx、后端六個(gè)服務(wù)、Nacos、Redis、MySQL。后端每個(gè)微服務(wù)的Dockerfile很簡(jiǎn)單基礎(chǔ)鏡像用eclipse-temurin對(duì)應(yīng)JDK版本然后把打包好的jar復(fù)制進(jìn)去FROM eclipse-temurin:17-jre WORKDIR /app COPY target/*.jar app.jar EXPOSE 8084 ENTRYPOINT [java, -jar, app.jar]然后用docker-compose.yml里按順序定義服務(wù)并設(shè)置依賴關(guān)系。注意JVM內(nèi)存參數(shù)每個(gè)服務(wù)默認(rèn)堆內(nèi)存可能吃掉幾百兆服務(wù)器內(nèi)存不夠會(huì)直接OOM。我在啟動(dòng)命令里加-Xms128m -Xmx256m限制內(nèi)存六個(gè)服務(wù)加起來占1.5G左右2G內(nèi)存的服務(wù)器勉強(qiáng)能跑4G比較穩(wěn)。6. 常見問題與排查技巧實(shí)錄6.1 選課超賣問題這是選課系統(tǒng)最核心的問題即使做了分布式鎖和原子UPDATE仍然可能出問題的點(diǎn)在于鎖的時(shí)間太短導(dǎo)致提前釋放。我遇到過一次真實(shí)故障Redisson的鎖過期時(shí)間設(shè)置成5秒但某次數(shù)據(jù)庫(kù)慢查詢導(dǎo)致鎖內(nèi)業(yè)務(wù)邏輯跑了6秒。鎖在第5秒自動(dòng)釋放另一個(gè)線程拿到鎖進(jìn)來開始扣減兩個(gè)線程同時(shí)操作同一課程的容量最終selected_count超出total_capacity。排查時(shí)發(fā)現(xiàn)數(shù)據(jù)庫(kù)的慢查詢?nèi)罩纠镉幸粭l全表掃描的SQL原因是course_stock表少了索引。解決辦法除了延長(zhǎng)鎖過期時(shí)間更要緊的是優(yōu)化鎖內(nèi)代碼。鎖內(nèi)不要查數(shù)據(jù)庫(kù)查兩次以上盡量在鎖外把前置條件全部準(zhǔn)備好。還有個(gè)辦法是使用Redisson的看門狗機(jī)制默認(rèn)情況下鎖會(huì)自動(dòng)續(xù)期每10秒檢查一次只要線程還在執(zhí)行就延長(zhǎng)鎖時(shí)間。配置RLock lock redissonClient.getLock(lockKey); lock.lock(); // 不指定過期時(shí)間使用默認(rèn)看門狗續(xù)期 try { // 業(yè)務(wù)邏輯 } finally { lock.unlock(); }6.2 網(wǎng)關(guān)鑒權(quán)后Feign調(diào)用丟失用戶信息現(xiàn)象學(xué)生選課成功但選課記錄里student_id是空的。排查鏈路Gateway把用戶ID放進(jìn)了X-User-Id請(qǐng)求頭轉(zhuǎn)發(fā)到selection-server的Controller后Controller能通過RequestHeader拿到。但Controller內(nèi)部又通過Feign調(diào)用了selection-server下游的某個(gè)服務(wù)此時(shí)請(qǐng)求頭丟了。原因Feign的默認(rèn)配置不傳遞所有請(qǐng)求頭。解決辦法就是前面寫的RequestInterceptor把當(dāng)前請(qǐng)求上下文里的X-User-Id和X-User-Role取出來手動(dòng)加到Feign請(qǐng)求上。這里還有一個(gè)隱藏問題如果用了Spring Boot 2.x與Feign獲取HttpServletRequest時(shí)如果請(qǐng)求不是從網(wǎng)關(guān)轉(zhuǎn)發(fā)過來的而是內(nèi)部定時(shí)任務(wù)觸發(fā)的Feign調(diào)用RequestContextHolder.getRequestAttributes()會(huì)返回null。我的RequestInterceptor代碼里做了null判斷但網(wǎng)絡(luò)上很多教程沒有新人cv過去直接空指針。6.3 Nacos服務(wù)注冊(cè)失敗現(xiàn)象服務(wù)啟動(dòng)不報(bào)錯(cuò)但過一會(huì)兒GPU的日志里能看到ServiceRegistError。最可能的原因是網(wǎng)絡(luò)服務(wù)器防火Q沒有開放9848端口。Nacos 2.x的客戶端使用gRPC通信除了8848還會(huì)連9848只開8848會(huì)導(dǎo)致注冊(cè)失敗。這個(gè)坑在云服務(wù)器上尤其常見安全組規(guī)則里必須同時(shí)放行8848和9848。另一個(gè)可能Nacos運(yùn)行在單機(jī)standalone模式時(shí)如果機(jī)器內(nèi)存不足Nacos服務(wù)本身宕機(jī)客戶端日志全是Connection refused。建議Nacos部署時(shí)給足內(nèi)存至少512M堆內(nèi)存或者在docker-compose里加上JVM參數(shù)限制。6.4 Vue打包后頁(yè)面白屏打包部署后打開頁(yè)面控制臺(tái)報(bào)Failed to fetch dynamically imported module這是Vite打包時(shí)生成的動(dòng)態(tài)路由文件路徑問題。解決方案在vite.config.js里設(shè)置base: ./讓資源引用改為相對(duì)路徑不然所有資源都會(huì)指向根路徑/assets/放在Nginx子路徑下就全部404。6.5 常見問題速查表問題排查要點(diǎn)快速解決方案服務(wù)啟動(dòng)報(bào)端口占用檢查端口規(guī)劃是否沖突關(guān)閉無關(guān)進(jìn)程或改端口Feign調(diào)用報(bào)500看目標(biāo)服務(wù)日志和本地異常堆棧檢查RequestBody序列化兼容Redis連接超時(shí)確認(rèn)密碼/端口/網(wǎng)絡(luò)本機(jī)測(cè)試ping和telnet選課慢定位是鎖等待還是數(shù)據(jù)庫(kù)慢打開慢查詢?nèi)罩竞虯rthas前端跨域網(wǎng)關(guān)未開啟CORS配置Gateway配置全局CorsFilter接口401JWT過期或簽名不匹配確認(rèn)JWT密鑰一致刷新Token7. 收尾前最后分享幾個(gè)實(shí)際經(jīng)驗(yàn)這套系統(tǒng)從前到后做下來我最大的體感是微服務(wù)的復(fù)雜度不在技術(shù)框架本身而在邊界管理。服務(wù)拆分不清事務(wù)補(bǔ)償邏輯就會(huì)變成一團(tuán)亂麻接口設(shè)計(jì)不約束聯(lián)調(diào)時(shí)大家各自為政后端改一個(gè)字段前端就要跟著改三天。如果讓我再做一遍我會(huì)優(yōu)先把選課鏈路的數(shù)據(jù)模型和接口契約在需求階段就固定下來因?yàn)檫@是全系統(tǒng)最敏感的部分。其余的管理功能模塊哪怕服務(wù)多一點(diǎn)復(fù)雜度也遠(yuǎn)低于選課這條鏈路。另外要提一句看到這里的朋友如果是要做畢業(yè)設(shè)計(jì)不建議把服務(wù)拆得太碎。六個(gè)服務(wù)是合理上限拆到十幾個(gè)Nacos上密密麻麻全是服務(wù)列表本地開發(fā)機(jī)器跑起來內(nèi)存直接爆掉。微服務(wù)的首要目標(biāo)是解決問題不是為了指標(biāo)好看。最后一個(gè)小技巧把每個(gè)服務(wù)的啟動(dòng)命令寫成一個(gè)shell腳本或Makefile比如./start.sh all、./start.sh gateway。這樣每次本地聯(lián)調(diào)不用在IDEA里一個(gè)一個(gè)點(diǎn)啟動(dòng)按鈕省下不少時(shí)間。這個(gè)習(xí)慣我延續(xù)到所有微服務(wù)項(xiàng)目里實(shí)測(cè)效率提升非常明顯。