简介一份完整的前后端分离在线考试系统项目源码基于Vue与Spring Cloud微服务架构构建适合高校计算机专业学生、Java后端开发者深入学习微服务实战与细粒度权限设计。项目包含前端后台管理VueElementUI、在线考试前端Nuxt、Spring Cloud微服务工程Eureka、Zuul、Feign及MySQL数据库脚本通过JWTRSA无状态登录实现安全认证。资源共200个文件以Java源码115个、Vue组件18个、JavaScript18个为主辅以XML配置、YAML配置、JSON数据及SQL脚本等压缩包仅535KB结构紧凑、目录清晰便于按模块查阅。已有972人学习下载。借助这份资源可掌握Excel模板批量导入试题、自动抽题组卷、班级科目管理、用户角色权限三级控制及AOP操作日志记录等核心功能实现是一套适合二次开发与课程设计的完整参考方案。1. 在线考试系统为什么非要用 SpringCloud Vue拆开看才知道坑在哪我见过太多在线考试系统死在上线当天开考两分钟数据库连接池被打穿交卷瞬间成绩丢了倒计时结束前端自动交卷后端却因为服务器时间不一致拒绝接收。这些事故几乎和业务代码无关全在架构选型上。用 Vue 做前端、用 Spring Cloud 微服务架构做后端不是为了显得高级而是因为考试系统天然要面对高并发短时抢答和数据不允许丢这两个硬约束。这篇文章就是要把这个系统从服务拆分、表设计、前端倒计时、网关鉴权到压测排错完整讲一遍照着做能把一套在线考试系统稳稳落地。2. 从单体到微服务考试系统的服务拆分与核心表设计2.1 考试系统拆几个服务才合理按业务域拆而不是按代码拆在线考试系统最常见的拆分误区是把一个单体项目按 controller、service、mapper 拆成多个模块然后强行部署成多个微服务。这不是拆分是给自己找麻烦。真正的拆服务要按业务域走系统里有独立的用户、题库、考试、答卷四大域各自有独立的生命周期和扩容诉求。我通常会拆成四个服务用户服务user-service负责登录注册和考生档案题库服务question-service负责题目的增删改查和图片附件考试服务exam-service负责考试场次、考试时间、试卷组卷和考场规则答卷服务answer-service负责答题过程中的保存、交卷提交、自动判分和成绩查询。这样拆的理由很直接开考瞬间流量全打在答卷服务的提交接口上而题库和用户服务几乎没压力。如果把它们混在一个服务里压测时只能整套扩容成本高且回答卷的高并发请求还会拖累登录和题库读操作。拆开后答卷服务可以独立部署三四个实例题库和用户服务保持两个实例就好。服务间调用关系也要提前定好考生登录走用户服务进入考试时由前端通过网关调考试服务拉取试卷元数据答题保存走答卷服务交卷时由答卷服务异步调用考试服务校验考试时间、调用题库服务核对答案。这里的关键是考生答题产生的原始数据只归答卷服务管其他服务要拿数据就走接口或消息队列不能直接碰库。2.2 服务间调用与数据一致性题目、答卷、成绩怎么流转服务一旦拆开原来的本地事务就变成了分布式事务问题。在线考试系统里最典型的场景是交卷考生点击交卷后答卷服务要先把答卷状态改成已交卷然后调用题库服务逐题判分最后把成绩写回。如果判分期间题库服务网调超时答卷已经提交成功成绩却算不出来用户端看到的就是交了卷但没有分。对这种一致性要求我的做法是交卷接口只做提交动作的持久化也就是把 answer_sheet 状态更新为 1已交卷并记录 submit_time提交成功后立刻给前端返回成功同时把交卷事件写入本地消息表或投递到 RocketMQ。判分由另一个消费者任务处理它读取题目答案、计算得分、更新成绩。这样做的好处是交卷主链路不会被判分拖慢而且判分失败可以重试不会出现交卷失败这种不可挽回的错。同步调用的地方也要设好超时。用 OpenFeign 时我一般在配置文件里把 connectTimeout 设成 2000msreadTimeout 设成 5000ms并开启重试。注意重试只对 GET 这类幂等接口安全交卷这类写接口不能盲目重试否则会出现同一张答卷被重复提交两次。写接口的幂等性我会用请求幂等键解决这点最后一章会专门讲。服务间的数据流转路线可以这样归纳前端提交答案到答卷服务 - 答卷服务保存答题明细 - 交卷时把事件发到消息队列 - 判分消费者读取题目服务提供的标准答案 - 计算结果写回成绩表。整条链路上前端永远只跟网关对话不要让浏览器直接感知到后端有四个服务。2.3 核心数据库表设计考试、题目、答卷、成绩最少要这几张表微服务架构下每个服务应该有自己独立的数据库。但很多毕设或内部项目为了省事共用一个库。如果共用库也要在逻辑上做到谁的服务操作谁的表绝不允许在答卷服务里直接 delete 题目表的记录。下面这套表结构是我在项目里验证过的按标准范式设计同时保留 JSON 字段应对多选和客观题选项。-- 考试主表隶属考试服务 CREATE TABLE exam ( id BIGINT PRIMARY KEY AUTO_INCREMENT, exam_name VARCHAR(128) NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, duration INT NOT NULL COMMENT 考试时长(分钟), status TINYINT DEFAULT 0 COMMENT 0未开始 1进行中 2已结束, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 题目表隶属题库服务 CREATE TABLE question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, type TINYINT NOT NULL COMMENT 1单选 2多选 3判断 4简答, content TEXT NOT NULL, options TEXT COMMENT 选项JSON数组, 单选/多选用, answer VARCHAR(16) COMMENT 正确选项或判断答案, score INT NOT NULL, difficulty TINYINT DEFAULT 1, status TINYINT DEFAULT 1 COMMENT 0禁用 1正常 ); -- 考试与题目关联表隶属于考试服务生成试卷用 CREATE TABLE exam_question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, exam_id BIGINT NOT NULL, question_id BIGINT NOT NULL, sort_no INT DEFAULT 0, score INT NOT NULL COMMENT 该题在本次考试中的分值 ); -- 答卷表隶属答卷服务 CREATE TABLE answer_sheet ( id BIGINT PRIMARY KEY AUTO_INCREMENT, exam_id BIGINT NOT NULL, student_id BIGINT NOT NULL, start_time DATETIME NOT NULL, submit_time DATETIME, status TINYINT DEFAULT 0 COMMENT 0作答中 1已交卷, UNIQUE KEY uk_exam_student (exam_id, student_id) ); -- 答题明细表隶属答卷服务 CREATE TABLE answer_detail ( id BIGINT PRIMARY KEY AUTO_INCREMENT, sheet_id BIGINT NOT NULL, question_id BIGINT NOT NULL, user_answer VARCHAR(2048), is_correct TINYINT COMMENT NULL未判 1正确 0错误, score DECIMAL(5,1) DEFAULT 0 );这套设计的几个关键点考试和题目是多对多关系所以只要有 exam_question 关联表答案选项用 JSON 存适配单选和多选避免了为每种题型建一大堆列answer_sheet 里加了 exam_id student_id 的唯一索引从数据库层面保证一个考生对一场考试只能有一张答卷这是防止重复交卷的底线。还有个容易被忽略的字段是 answer_sheet 的 start_time。考试系统必须记录考生实际开始答题的时间不能只依赖考试场次的起止时间。后端在第一次保存答题时会写入 start_time之后每次续存都校验它是否在考试时间窗口内这样即使用户中途断网重连服务端也能知道他的作答区间不会让异常请求钻空子。3. 用 Vue3 Element Plus 搭考试前端路由、状态管理与答题倒计时3.1 前端项目初始化与 axios 封装指向 Gateway 而不是各微服务考试系统前端我用的技术栈是 Vue3 Vite Element Plus配合 Pinia 做状态管理。起步阶段先确认 vue 安装及环境配置Node.js 版本建议 16 以上然后用 Vite 初始化项目。之所以不用 Vue CLI是因为 Vite 的开发服务器启动更快编译考试这种模块较多的页面时体验更顺。npm create vitelatest exam-web -- --template vue cd exam-web npm install element-plus axios pinia vue-router初始化完后第一件事是封装 axios。前端的 baseURL 必须指向 Spring Cloud Gateway 的统一入口而不是各微服务地址。否则后端一拆多个服务前端就得跟着改一堆环境变量跨域问题也会此起彼伏。// src/utils/request.js import axios from axios const service axios.create({ // 统一走网关前端不直接碰各微服务地址 baseURL: http://localhost:8080/api, timeout: 30000 }) // 请求拦截器把登录成功后存的 token 带给后端 service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error)) // 响应拦截器统一处理 401 和业务错误码 service.interceptors.response.use(response { const res response.data if (res.code ! 0) { if (res.code 401) { window.location.href /login } return Promise.reject(new Error(res.msg)) } return res.data }, error Promise.reject(error)) export default service这里的逻辑说明请求拦截器负责把本地存储的 token 放到请求头采用 Bearer 格式后端网关的 JWT 过滤器就是靠这个格式识别身份的。响应拦截器做了统一拆包约定后端返回结构是{ code: 0, data: …, msg: ok }前端拿到的是 data 部分不用每个页面都重复做错误判断。参数说明timeout 为什么设 30 秒考试系统里保存答题、交卷这类接口偶发慢是正常的如果设成 10 秒网络抖动就会让考生丢失答案体验极差。30 秒是一个平衡值后续压测如果发现超时次数多优先查后端慢查询而不是调短前端超时。3.2 考试页的倒计时与自动交卷setInterval 的坑在线考试页面最核心的交互是倒计时和自动交卷。新手最容易想当然地写一个setInterval(() { seconds-- }, 1000)这在电脑上看着没问题但浏览器切到后台、CPU 休眠或页面卡顿后定时器会暂停等用户切回来时倒计时可能已经少了十几秒。更严重的后果是倒计时走得比柜头表慢前端以为还有时间后端却已经关闭提交。正确做法是以截止时间戳为准不用累减计数。考试开始后由后端返回考试结束的绝对时间戳前端每次 tick 都重新计算当前时间和 deadline 的差值再决定是否交卷。这样无论浏览器怎么休眠切回来时差值自动校正。// exam-page.vue 倒计时逻辑 const deadline ref(0) // 从后端接口返回考试截止时间戳 const remainSeconds ref(0) function startCountdown() { // 每次用当前时间重新计算避免 setInterval 挂起后时间漂移 remainSeconds.value Math.floor((deadline.value - Date.now()) / 1000) if (remainSeconds.value 0) { autoSubmit() return } setTimeout(startCountdown, 1000) }这段代码只做一件事每秒钟递归调用一次重新计算剩余秒数。用 setTimeout 而不是 setInterval是因为 setTimeout 每次都会在上一次执行完毕后重新计时不会出现回调堆积用 Date.now() 和 deadline 的时间戳差值保证了绝对时间的正确性。在答题状态管理上我用 Pinia 维护一个答案对象currentAnswers键是 questionId值是用户选择或输入的答案。考虑到考试中途断网的情况每次切换题目或停顿 5 秒就把答案序列化到 localStorage并在下次进入页面时做一次合并。这个手动后悔药我屡试不爽能救回不少因为浏览器崩溃丢失的答题数据。注意localStorage 里存的答案不能作为最终提交依据只是草稿提交一定以服务端收到的请求体为准。3.3 路由守卫实现按考试状态放行vue动态路由与路由参数在线考试系统的路由不能是死的考生能参加哪些考试取决于他是否被分配了考试、考试当前是否处于可作答时段。我一般用 vue动态路由来加载考生的考试列表并把 examId 作为路由参数传入答题页。// router/index.js import { getExamStatusById } from /api/exam router.beforeEach(async (to, from, next) { const token localStorage.getItem(token) if (!token) { if (to.path ! /login) { next({ path: /login, query: { redirect: to.fullPath } }) } else { next() } return } // 进入答题页前校验考试是否存在、是否在考试时间内、是否已交卷 if (to.name ExamDetail) { const examId to.params.examId const status await getExamStatusById(examId) // 返回 not_start / in_progress / ended / submitted if (status submitted) { next({ path: /result/${examId} }) // 已交卷则跳成绩页 } else if (status in_progress) { next() } else { next({ path: /exam-list }) // 未开始或已结束都回列表 } return } next() })这段守卫的逻辑关键点有两个。第一考试状态以后端返回为准前端只能做展示不能自行决定是否放行。第二路由参数to.params.examId的取值对应答题页 URL 形如/exam/detail/1024在组件里可以用useRoute().params.examId获取。这样可以避免考生手动改 URL 跳过考试列表直接进题。vue路由参数除了用来定位考试还承担了防串场的职责。我在答题页组件里 watchroute.params.examId一旦变化立即清空本地的 answers 和倒计时重新拉取新考试的数据避免上一个考场的残留答案出现在新考卷里。这个细节看着小却是真实用户误操作的高发地。4. SpringCloud Gateway 统一入口路由配置与 JWT 鉴权落地4.1 Gateway 路由配置把前端请求转发到具体微服务Spring Cloud 微服务架构里网关是整个系统的门面。前端所有的请求都先打到 Gateway再由 Gateway 根据路径转发到注册到 Nacos 的各个服务。拿在线考试系统来举例用户服务、题库服务、考试服务、答卷服务都要注册到 NacosGateway 的配置如下spring: application: name: gateway cloud: nacos: discovery: server-addr: 127.0.0.1:8848 gateway: routes: - id: user-service uri: lb://user-service predicates: - Path/api/user/** filters: - StripPrefix1 - id: exam-service uri: lb://exam-service predicates: - Path/api/exam/** filters: - StripPrefix1 - id: answer-service uri: lb://answer-service predicates: - Path/api/answer/** filters: - StripPrefix1 httpclient: connect-timeout: 5000 response-timeout: 30s这里要注意几个参数。lb://前缀表示负载均衡Gateway 会从 Nacos 拉取目标服务的实例列表按负载均衡策略分发StripPrefix1的含义是去掉 URL 的第一级前缀也就是把/api/user/login转成/user/login再转发给 user-service。如果忘记配置 StripPrefix服务端会收到/api/user/login这个路径而大多数服务的 controller 都映射在/user/login结果就是 404。响应超时设置成 30 秒是因为考试服务中组装试卷接口需要批量查题偶尔慢到几秒。connect-timeout 设 5 秒是合理的如果与某个服务连接建立都要 5 秒说明该服务大概率已经挂了再等下去没有意义。4.2 JWT 过滤器在网关做登录校验白名单写法在线考试系统要求考生必须先登录才能看到考卷而考试结束后还要拒绝交卷。所有用户态校验放网关做后端每个微服务就不用各自重复解析 token 了。我用的是自定义 GlobalFilter里面维护一个白名单数组白名单外的请求一律校验 JWT。Component public class AuthGlobalFilter implements GlobalFilter { private static final ListString WHITE_LIST Arrays.asList( /api/auth/login, /api/auth/register, /api/exam/list ); Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String path exchange.getRequest().getURI().getPath(); if (WHITE_LIST.contains(path)) { return chain.filter(exchange); } String token exchange.getRequest().getHeaders().getFirst(Authorization); if (token null || !token.startsWith(Bearer )) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } try { Claims claims Jwts.parser().setSigningKey(SECRET_KEY) .parseClaimsJws(token.replace(Bearer , )).getBody(); // 把当前用户id塞进header下游服务直接用 ServerWebRequest mutated exchange.getRequest() .mutate().header(X-User-Id, claims.get(uid).toString()).build(); return chain.filter(exchange.mutate().request(mutated).build()); } catch (Exception e) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } } }这段过滤器的逻辑说明白名单内的登录、注册、考试列表接口直接放行因为考试列表需要考生登录后看到自己的考试那为什么放行因为前端可能在登录态过期后拉列表给 401 处理。实际项目里/api/exam/list是登录后获取的所以不放行更合理这里看你的业务假设。但要注意白名单越短越安全我建议只放行登录和注册其余全部校验。JWT 解析关键点是 SECRET_KEY它必须和生成 token 的用户服务保持一致通常放在 Nacos 配置中心统一管理防止硬编码在代码里。解析通过后把用户 ID 放入请求头 X-User-Id转发给下游。下游服务从 header 中取当前用户不再需要解析 token这样减少了重复计算也避免了不同服务用不同 JWT 库带来的兼容性问题。4.3 跨域与超时配置前端联调必调的参数Vue3 开发服务器默认跑在 5173 端口Gateway 跑在 8080前后端不同源跨域问题是绕不开的。如果不用 Nginx 转发那就必须在 Gateway 配置全局 CORS。我见过有人在后端每个 controller 加 CrossOrigin虽然能用但网关层面统一配置才是正解。spring: cloud: gateway: globalcors: cors-configurations: [/**]: allowedOriginPatterns: - http://localhost:5173 - http://127.0.0.1:5173 allowedMethods: - GET - POST - PUT - DELETE - OPTIONS allowedHeaders: * allowCredentials: true参数说明allowedOriginPatterns 不能用*因为 allowCredentials 为 true 时响应头不能使用通配符OPTIONS 请求必须放行浏览器预检请求会先打过来不放行的话前端所有请求都会报跨域错。allowCredentials 为 true表示允许前端携带 cookie虽然本系统主要用 token但保留这个配置能兼容后续要用的会话类接口。网关超时配置前面已经提到过了这里再强调一个容易忽略的点Gateway 转发是异步的response-timeout: 30s指的是整个转发流程的总超时而不是单次连接超时。如果下行服务内部调用了另一个服务比如答卷服务判分时调题库服务总耗时会包含这两级调用超时设置必须比最长的服务调用链更长。5. 微服务架构在线考试系统的 6 个常见翻车点与排查路径5.1 现象交卷后成绩丢失前端显示已交卷后台查不到得分原因交卷接口是同步调用的前端发起 POST /answer/submit答卷服务先保存答卷然后调题库服务逐个判分。题库服务在高并发下变慢答卷服务的线程被阻塞最终 HTTP 请求超时。前端以为提交失败重试了两次而第一次提交实际上已经写入了 answer_sheet第二次重试就因唯一键冲突报错。更糟糕的情况是保存答卷成功判分调用失败整体事务回滚答卷被标记为未交卷。这个用户就彻底废了。解决把交卷链路改成保存即成功判分异步化。交卷接口只做两件事更新 answer_sheet 的 status 1写入一条 MQ 消息shet_id 交卷事件。判分消费者收到消息后从题库服务拉取题目答案计算分数更新 result。如果判分失败MQ 重试重试多次还失败就记录到人工补偿表。我还会在成绩页加一个重新判分按钮供管理员手动触发补偿这是最后的兜底。5.2 现象倒计时结束后前端自动交卷后端拒绝理由是不在考试时间内原因前后端时间不同步。考生电脑改了系统时间或者浏览器时间被 NTP 校正过前端倒计时以设备时间为准而后端以服务器时间为准。两者一错开就会出现前端显示还剩 30 秒、后端已经超过 end_time 的情况。解决考试时间和倒计时的唯一权威来源是后端。考试开始时前端调用开始考试接口拿到serverTime和endTime倒计时基于endTime - serverTime计算。前端不做任何时间预算。自动交卷触发时如果网络异常后端也要允许 30 秒的宽容窗口因为用户可能用的是弱网宽容窗口内收到提交标记为已交卷但记录为超时提交是否扣分由业务规则决定不能直接拒收。5.3 现象多人同时考试时数据库连接池被打满接口响应从 100ms 变成 5s原因HikariPool 的默认 maximum-pool-size 是 10微服务跑了三四个实例但每个服务都连同一个 MySQL 库。开考瞬间答卷服务 4 个实例每个只有 10 个连接总量 40却要扛 500 人的写入连接排队是必然的。解决答题明细写入不需要强事务可以批量提交一次请求保存 20 题而不是每题 insert 一次。连接池可以调大但不建议盲目调到 200因为 MySQL 默认 max_connections 通常是 151连接数超过数据库能力照样排队。合理组合是把连接池调到 50同时开启批量写和异步刷盘。答题过程中的明细不进主库先落 Redis交卷时一次性持久化这样数据库连接压力被大幅削平。5.4 现象Gateway 返回 503 Service Unavailable但服务明明还活着原因Nacos 的服务心跳默认每 5 秒一次15 秒未收到心跳就标记不健康30 秒才摘除。服务实例正在启动时还没有完成注册网关查不到实例列表就会报 503。另一种常见原因是服务偶发卡顿Nacos 已经把它标为不健康但请求还在源源不断过来。解决排查三步走。第一步去 Nacos 控制台看服务是否健康如果显示不健康先去该服务实例的日志里看心跳线程有没有报错第二步检查服务 CPU 是否满负荷如果 CPU 高导致心跳线程饥饿要优化业务线程池别让业务阻塞了心跳第三步Gateway 可以配置 RetryFilter但只对 GET 请求启用写接口不重试避免重复提交。5.5 现象前端路由刷新后出现白屏或提交试卷后回退到登录页原因Vue Router 使用 history 模式时URL 形如/exam/detail/1024刷新时浏览器会向服务器请求这个路径。如果网关没有把该路径的请求转发到前端静态资源服务而是抹给一个不存在的微服务就会 404 或返回空页面。解决如果是纯静态部署用 Nginx 时配置try_files $uri $uri/ /index.html;。如果还是走 Gateway则要在网关上增加一条兜底路由把非/api/的路径全部转发到前端服务。另外401 跳登录页时要用to.fullPath保存原地址重新登录后通过redirect参数跳回来否则用户交卷被踢出后再登录还得重新找考场。这个跳回原路径的细节直接影响考试系统的可用性。5.6 现象题目图片在开考瞬间集中加载把文件服务打爆白屏一堆原因考试开始的前 10 秒几百人同时请求同一批题目图片缓存全部 miss所有请求都打到 MinIO 或本地磁盘。如果图片没有设置 CDN也没有预热高峰期必然拥堵。解决图片服务可以选择 MinIO Nginx 做静态缓存Nginx 代理层设置proxy_cache_valid 200 1h。更可靠的做法是在考试前 5 分钟由一个预热任务把本次考试涉及的题目图片 URL 全部请求一遍把热点数据顶进缓存。还有一个隐性坑图片 URL 的签名时间不能太短如果 MinIO 用的是带过期时间的签名 URL过期后 Nginx 缓存就形同虚设考生看到的全是裂图。6. 压测与上线检查在线考试系统交付前必做的三轮验证第一轮验证是并发交卷压测。我用 JMeter 写一个线程组模拟 500 个考生同时点击交卷接口 URL 指向网关的/api/answer/submit。命令行模式跑起来jmeter -n -t exam_submit.jmx -l result.jtl -e -o reportJMeter 报告中重点看三组指标错误率必须为 0p95 响应时间低于 3 秒数据库连接池的 active 连接数峰值不要达到上限。如果错误率不为零优先看服务端日志里有没有Connection is not available, request timed out有就是连接池调太小。第二轮验证是配置热更新演练。考试系统经常要临时延长某场考试时间如果每次都重启网关和考试服务正在考试的考生会全被断开。我一般把考试结束时间放到 Nacos 配置中心考试服务里的RefreshScope类读取该配置改完配置用 Nacos 控制台发布服务无需重启。这个技巧在线上救过我好几次特别是那种开考后才发现结束时间设错了的尴尬场合。第三轮验证是幂等性测试。我习惯让前端每次交卷请求带上一个requestId生成规则是userId examId 时间戳后端在处理交卷前先查 Redis 里是否存在相同 requestId存在就直接返回上次结果不存在则加锁处理。这样可以彻底规避网络重试导致的重复答题记录。回看这几轮验证我最深的教训是在线考试系统真正比拼的不是业务功能的堆砌而是极端时刻的容错能力。把压测放在上线前一天做出了事故就只能改代码把验证放在开发中期做你才有余地把异步交卷、幂等控制、时间对齐这些基本功打牢。希望这篇笔记能帮你在做这类系统时少走一轮弯路愿你的考试系统开考那一刻是真的平稳的。本文还有配套的精品资源点击获取