HSK学习平台微服务架构实战：SpringBoot+Vue+Spring Cloud

搞HSK汉语等级考试学习平台这个项目，要说清楚为什么最终选了SpringBoot+Vue+Spring Cloud这套组合，得先聊聊实际场景里的痛。

很多人一听“汉语等级考试系统”就觉得，不就是个在线做题的网站吗，单体应用一把梭，题库塞进MySQL，页面用Vue渲染一下，考试时后台算个分，完事。但真正把这个平台跑起来才知道，HSK学习和普通刷题软件有本质区别。它有六级递进的等级体系，听力和阅读题的素材文件巨大，用户画像从初学者到高级考生跨度很大，高峰期集中在考试报名、模拟考试、成绩查询这几个节点。再加上题库要随时更新、课程视频要按权限播放、成绩数据要按等级维度出分析报表，每个业务模块对资源的需求是截然不同的。

所以这个项目的核心不是“考试功能怎么写”，而是“服务怎么拆、分布式场景下怎么保证一致性、高并发时系统怎么不崩”。这篇文章就按我实际动手做下来的顺序，把微服务架构设计、SpringBoot/Spring Cloud核心实践、Vue前端联调、分布式锁/事务踩坑经验一次讲透。适合准备做Java微服务项目的人参考，也适合正在搞在线教育类平台的同学直接抄作业。

1. 项目整体设计与微服务拆分思路

1.1 先说清楚HSK平台到底包含哪些业务

HSK考试大纲一般分一级到六级，题型涵盖听力、阅读、书写。那一个学习平台至少要覆盖学习、练习、测评、反馈这条闭环。我最终拆出了这几个核心模块：用户认证中心、课程学习模块、题库管理模块、考试测评模块、成绩分析模块、错题与笔记模块、以及素材资源存储模块。

单就考试测评这一块，就有试卷生成、定时交卷、题目判分、成绩归档这些动作。高并发点集中在考试提交那一瞬间，所有人都要把答题结果写进系统，如果只有一台服务器一个数据库，光锁表和连接池就能把服务拖死。另外听力素材是音频文件，课程视频是视频文件，这类大文件不能直接塞进应用服务器磁盘，要单独接对象存储。所以从业务流来看，天然就有一堆可以独立伸缩的东西。

1.2 单体应用在什么情况下会顶不住

先说结论，如果只是给几百个内部学员用，单体真的没问题。我之前做过类似的项目，一个SpringBoot工程包打天下，数据库三张表，部署在一台2C4G的服务器上，跑得很稳。但HSK学习平台面向的是公开用户，注册量上来之后，各类问题就暴露了。

题库模块的更新会影响考试模块的发布，课程视频大文件上传会把应用进程IO占满，导致考试接口响应变慢。最典型的场景是模拟考试高峰期，某个学员交卷时判分接口跑几秒没关系，但如果同时来上千个交卷请求，判分逻辑里的随机抽题、结果比对、成绩写入全挤在一个进程里，数据库连接池瞬间被打满，其他模块也跟着瘫痪。单体应用没法按模块独立扩容，这是它最尴尬的地方。

微服务在做这种项目时价值就体现出来了，可以把考试服务单独拎出来，高峰期给它开三个实例，其他服务保持一个实例就行。每个服务独立进程、独立数据库，互不拖累，这就是微服务拆分的根本理由。

1.3 服务怎么拆才不后悔

我的拆分原则很简单，按业务域拆，不按技术层拆。一个业务用例有关联的操作尽量放一个服务里，跨服务调用越少越好。

我最终拆成下面这几个服务：

• gateway网关服务：统一入口，负责路由转发、跨域处理、Token鉴权
• user-service用户服务：注册登录、用户资料、JWT签发
• learn-service学习服务：课程管理、学习进度、词汇练习
• exam-service考试服务：试卷生成、考试会话、自动判分
• question-service题库服务：题目CRUD、按等级/题型检索
• analysis-service分析服务：成绩统计、错题聚合、学习报告
• common公共模块：工具类、统一返回体、日志配置

这种拆分方式的好处是，每个服务的职责一眼就能看懂。考试服务和题库服务虽然关系紧密，但题库是管理端用的，考试是用户端用的，扩展方向不一样，拆开之后互不影响。学习服务和考试服务共享用户数据，但通过OpenFeign远程调用而不是直连数据库，保证了数据查询入口的统一。

提示：做微服务拆分时别拍脑袋。最靠谱的做法是把模块间的调用频率和变化频率都列出来，调用频率高但变化频率低的可以用共享库，变化频率高的必须走服务化独立部署。我就是用这个方法筛掉了两个不该拆的模块。

2. 关键技术选型与搭建前必做的准备

2.1 SpringBoot和Spring Cloud版本别乱配

微服务项目第一道坎不是写业务代码，而是版本兼容。这一栏我踩过不少坑，先说一个我验证过比较稳的组合，JDK8对应SpringBoot 2.7.18、Spring Cloud 2021.0.8、Spring Cloud Alibaba 2021.0.4.0，搭配Nacos 2.2.3和Gateway。这套组合在Java 8环境下跑得很顺，Maven依赖也不容易冲突。

如果你用的是SpringBoot 3.x，那就必须搭配JDK17，Spring Cloud也得换到2023.x的版本线。虽然新版本性能有提升，但对环境和旧代码的兼容性要求高，我在这个项目里选择稳字当头，用成熟稳定的老版本。做过生产环境的兄弟都懂，技术栈新不新不重要，能24小时不宕机才重要。

Maven工程建议用多模块管理，父POM里统一管理Spring Boot和Spring Cloud以及Alibaba组件的版本号。子模块只引入实际用到的依赖，比如user-service引入security、jwt，exam-service引入redis、openfeign。这样制作出来的工程结构清晰，启动也不会出现一堆类冲突。

2.2 Vue前端环境与项目初始化

前端我选的是Vue3加Vite，配合vue-router做路由管理，pinia做状态管理。安装过程本身不复杂，关键是Node.js版本要选对，我用的Node 18 LTS版本，npm install时习惯性加--registry=https://registry.npmmirror.com参数，下载依赖速度会快得多。

Vite开发环境的代理配置是前后端联调的关键。因为前端跑在5173端口，后端网关跑在8080端口，直接请求必然跨域。我的做法是在vite.config.js里配置好代理指向网关的地址，同时网关本身也允许CORS跨域。注意这两个地方别同时配出重复的跨域头，否则浏览器会报"CORS error"。

// vite.config.js 关键配置 server: { host: '0.0.0.0', port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } }

前端调用统一以/api开头，网关把请求转发到具体服务。这种设计让前端开发时完全不需要关心后端服务部署在哪台机器上，联调体验很好。

2.3 Minio、Redis这些基础设施怎么接

课程视频和听力题素材不能放服务器本地磁盘，我用Minio做对象存储。SpringBoot接入Minio其实不复杂，先通过Java SDK创建连接，再封装一个上传下载的工具类。上传文件时设置bucket按业务划分，比如course-videos和exam-audio两个bucket。权限上，私有bucket用临时访问凭证，公开资源直接生成公开链接，对于考试听力题来说，不能让所有登录用户都能拿到答题音频的永久链接，否则题库素材就泄露了。

Redis在这个项目里承担了缓存和分布式锁两层职责。页面上的等级词汇列表、考试题目配置，这些读多写少的数据全部缓存到Redis，配合Spring Cache注解使用，代码侵入性很小。分布式锁是另一个大话题，我放到后面第3.4节单独讲。缓存穿透场景也遇到过，就是热门考题被频繁读取时，如果有人恶意用不存在的题目ID请求，会让请求直接打到数据库。我加了一道布隆过滤器拦截不存在的ID，不过一般在Redis里缓存一个空值也能解决，具体看并发压力。

2.4 Spring Boot的多环境配置

开发环境、测试环境、生产环境的数据库地址、Redis地址、Minio配置都不一样，不能用一套配置走天下。SpringBoot默认的application.yml可以拆出application-dev.yml、application-test.yml、application-prod.yml，再通过启动参数spring.profiles.active=prod激活对应环境。

微服务数量多了以后，每个服务都要配置这些环境信息，那就要把配置统一交给Nacos配置中心管理。我操作的时候直接把含Nacos地址、命名空间的基础配置放到bootstrap.yml里，业务相关的配置全部依赖spring.config.import=nacos:xxx动态拉取。这个方案的好处是，改数据库密码不用赶着重新打包发布服务，直接在Nacos控制台改，服务热刷新。

3. 核心模块实现与微服务落地细节

3.1 用户认证中心的JWT与网关鉴权链路

HSK平台有普通用户、管理员、阅卷老师三种角色，权限控制从登录开始就要设计好。

我用Spring Security做用户口令验证，密码加密从MD5换成BCrypt，BCrypt会自动加盐，即使是相同密码每次加密结果也不同，数据库泄露了也无法反查。用户登录成功后，服务端生成Access Token和Refresh Token两种JWT令牌，Access Token有效期设半小时，Refresh Token有效期设七天。前端存储用localStorage或者HttpOnly Cookie都有利弊，考虑安全我选择HttpOnly Cookie存Refresh Token，Access Token放内存或sessionStorage，降低XSS风险。

JWT的核心优势在于无状态，服务端不需要维护Session。但这也带来一个问题，如果某个用户被拉黑或退出登录，只要Token没过期就还能访问系统。我的解决方案很简单，Redis里维护一个Token黑名单，退出登录或异常操作时把Token加入黑名单直到过期。这个实现不复杂，但非常实用。

网关鉴权是整个链路最关键的环节。我在Gateway里实现了一个GlobalFilter，对所有进入的请求做统一处理。放行登录接口和白名单接口，其余请求从请求头取出Token，解析成功后把userId拼到请求头里传给下游服务。下游服务不重复校验Token，只信任网关传递的userId，这样既保证了安全性，也符合微服务架构里的"统一出入口"原则。

// 网关过滤器的核心逻辑伪代码 String token = getTokenFromRequest(exchange); if (isWhiteList(exchange.getRequest().getPath())) return chain.filter(exchange); Claims claims = JwtUtil.parseToken(token); if (claims == null) return unauthorizedResponse(exchange); exchange = exchange.mutate() .request(builder -> builder.header("X-User-Id", claims.get("userId"))) .build(); return chain.filter(exchange);

3.2 题库服务与试卷生成的分布式挑战

题库是考试服务的弹药库，题目字段包括题型、题干、选项、正确答案、所属等级、知识点标签。HSK的听力题还要挂一段音频地址，阅读题素材可能是一篇文章，结构化存储时要设计出题组的概念：一篇阅读带若干题，一段听力带若干题。

试卷生成是我最开始容易想简单的地方。如果只是根据HSK等级随机抽题，SQL写个ORDER BY RAND()就够了，但用户连续两次抽到同一批题目，考试体验非常差。我的做法是：先用布隆过滤器或Redis记录该用户最近一小时已抽题目ID，抽题时排除已抽的集合。如果符合条件的题目不够，再降级为全量随机，同时重置历史记录。这里的并发难点在于多个用户同时抽题，我使用Redis分布式锁锁住抽题key，避免重复生成同一份试卷结构。

试卷数据本身要存两份：一份是模板结构（包含题型分配比例），一份是考生实际的试卷（包含具体的题目哈希列表）。档案解析下来的分数、答案存储采用JSON列，方便灵活扩展评分细节，不用频繁改表结构。

3.3 考试会话与自动判分设计

考试会话是整个系统里状态最复杂的部分。HSK考试有严格的时长限制，听力播放一段后不能回跳，阅读部分可以自由答题。前端倒计时到期会自动交卷，但为了防止用户恶意修改本地时间，后端设计了一道时间校验逻辑，发起考试的时候就记录开始时间戳，交卷时校验服务端时间和会话时长，超时则强制标记超时交卷。

判分是考试服务里CPU占用最大的操作。选择题可以用题目答案哈希直接比对，复杂度O(n)。书写题和HSK的口语表达题不能完全自动化，我分两步走，主观题先交给规则引擎捞关键词得分，再由阅卷老师人工复核打分。这个设计取舍让系统的自动化判分率达到80%左右，同时保证最终成绩的可信度。

成绩归档是一个分布式调用的典型场景。考试服务判完分，要把成绩发给analysis-service做统计。这个场景没有使用同步OpenFeign调用，而是通过消息队列异步通知，因为我们分析报告的需求允许几分钟的延迟，没必要因为分析服务的抖动把主流程拖垮。这里的最终一致性通过消息可靠投递加幂等消费来保证，分析服务收到成绩消息时用成绩单ID做幂等校验，防止重复消费导致统计数据翻倍。

3.4 分布式事务与分布式锁的实际应用

微服务绕不开分布式问题，我在这个项目里用了两把“锁”和一套事务方案。

第一把锁是Redis分布式锁，用Redisson框架实现。Redisson默认的锁机制是watch dog自动续期，锁超时默认30秒，每10秒续一次，防止业务还没跑完锁就自动过期。我遇到最经典的问题是：用户重复提交交卷请求，前端按钮禁用只挡得住老实人，恶意用户用脚本连续POST，如果没有锁保护，同一份试卷会被判两次分，成绩写入重复记录。在判分入口用userId加试卷编号作为锁key，就能保证同一时间只有一个判分线程在处理这一份试卷。

// 使用Redisson分布式锁防止重复判分 RLock lock = redissonClient.getLock("exam:submit:" + userId + ":" + examPaperId); boolean locked = lock.tryLock(3, 30, TimeUnit.SECONDS); if (!locked) { return "您提交的试卷正在处理中，请勿重复提交"; } try { // 执行判分逻辑 } finally { lock.unlock(); }

第二把锁是数据库层面的幂等约束。分布式锁是动态的，万一节点宕机锁自然释放了，但业务没执行完，用户重试就会产生重复数据。所以我在成绩表、学习记录表都加上了userId+examPaperId的唯一索引，数据库兜底挡住重复插入。锁和DB约束双保险，实测效果稳。

分布式事务这里，我的取舍是能不用的地方尽量不用。真正的分布式事务只在"扣除考试次数+创建考试记录"这两个操作之间出现，这两个动作跨了user-service和exam-service。最重的方案是引入Seata做AT模式，但带来的性能开销和部署复杂度明显。在实际落地中，我使用本地消息表方案，考试服务创建本地事务时同时写一条待确认消息，由定时任务逐步推送消息并确认是否已扣减次数，最终达到一致性。这个方案的RPO容忍度在秒级，对考试系统来说完全够用。

注意：分布式事务没有银弹。AT模式适合并发量不大但对一致性要求极高的财务操作；异步消息加幂等保护适合大多数业务场景。别因为面试常问分布式事务，就一股脑把Seata塞进项目里，过度设计才是微服务项目最容易被吐槽的地方。

3.5 学习服务与课程内容管理

学习模块相对考试模块简单，但有一个坑值得说。HSK词汇表按等级划分，每个等级大概500到2500词不等，这些词需要分词和词性标注。我直接用HanLP分词工具做中文分词和拼音转换，在SpringBoot里封装了一个词典服务，课程内容里出现的高频词汇自动关联到对应等级词汇表。这样用户在阅读课文时，系统就能提示“这个词汇是HSK四级必考词”，学习体验会好很多。

视频课程播放用m3u8分片流，Media文件来自Minio，前端从后端获取播放凭证后调用hls.js拉流。这里需要后端处理好Minio的bucket跨域规则，以及临时访问凭证的过期时间。视频文件的切片上传没做太复杂，大文件分片上传、小文件直接上传，实际上这两个场景都遇到过，接口设计里统一用MultipartFile接收，再按大小走不同处理分支即可。

4. Vue前端实现：路由、状态管理和考试交互

4.1 动态路由与角色权限控制

前端和网关都得做权限控制，但两者关注点不同。网关管的是接口访问层面，“未登录的请求全部拦截”；前端管的是页面展示层面，“不同角色只显示自己有权限的菜单”。

我在Vue3中用动态路由方案。用户登录成功后，后端返回一个菜单列表，包含组件的路径和路由名称。前端使用router.addRoute()在运行时动态挂载路由表，Vue Router不再采用静态写死的路由配置。比如管理员多出“题库管理”“用户管理”两个页面，阅卷老师多出“待批改试卷”，普通用户只有“课程学习”“模拟考试”“成绩报告”。

路由守卫的作用也很关键。router.beforeEach里检查本地是否有Token，没Token一律跳到登录页。判断完善之后，我再调用后端提供的用户信息接口拉取角色，根据角色过滤路由表。这里的坑是刷新页面时动态路由会丢失，需要在守卫里做一个“路由已初始化”的判定，如果刷新后发现路由表是空的，重新拉取菜单并重新addRoute，最后再放行页面跳转。

4.2 考试页面的时间控制和交卷逻辑

考试页面是整个前端最需要细心的地方。倒计时用的是setInterval每秒递减，同时把截止时间戳存在本地，防止组件切换或浏览器休眠后计时不准。倒计时小于5分钟时，页面显著变色提醒，到最后10秒弹出交卷确认框。

自动交卷逻辑也不能全靠前端。后端有会话超时校验是保险，但用户体验上，前端在最后还剩1秒时发送交卷请求，网络延迟会导致请求还没到后端就已显示超时。我调了一个方案：倒计时归零后的3秒内仍然允许正常交卷请求，超过3秒后端按超时处理。这个缓冲窗口在真实考试里很重要，用户差几十毫秒没提交跟考了零分是完全两种心情。

听力题目的交互比较特殊，音频播放条和题目区域要联动。每一道听力题，音频播放不支持拖拽回放，听一遍就锁定答案，模拟真实HSK听力考试。前端在音频播放结束后自动高亮当前尚未作答的题目区域，用户无法手动重播已播过的音频，这个策略既保证了考试的真实性，又避免服务器流量被反复消耗。

4.3 axios封装、Vue播放m3u8和文件上传

axios封装是每个前端项目都要做的基础工程。请求拦截器统一注入Access Token，响应拦截器统一处理业务码和后端返回的错误信息。遇到401状态码时，用Refresh Token静默刷新再重试原请求，这个细节如果没做，用户考试途中Token过期就会被一脚踢回登录页，非常打击体验。

m3u8视频播放这里，很多人被卡住。Vue项目里想要免插件播放m3u8流，比较简洁的方案是引入hls.js库，在mounted生命周期里关联video元素。如果流是直播流且头部携带跨域限制，需要配置Ext-X-ALLOW-CACHE和跨域响应头。实测中，Minio对象存储搭配hls.js解决了95%的问题，剩下5%是浏览器兼容性，Safari原生支持HLS，Chrome需要依赖hls.js，这个逻辑前端要判断好。

文件上传界面我直接封装了一个拖拽上传组件，调用后端Minio接口时先获取STS临时凭证，然后通过签名URL直传。这样文件流不走应用服务器，减轻网关和后端的压力，大视频上传也不会卡死Tomcat线程。

4.4 数据可视化与成绩报告

成绩分析报表是HSK学习平台的加分项，我用ECharts在Vue3里做了三张核心图表：HSK等级雷达图，展示听说读写四项能力分布；历次模拟考试折线图，展示分数变化趋势；错题知识点柱状图，帮助用户发现薄弱环节。

图表组件的数据来源是analysis-service聚合后的JSON结构，前端在拿到数据后才加载ECharts实例。这里有个渲染时序的坑，图表容器必须处于显示状态才能初始化，所以要在nextTick回调里初始化图表，动态Tab切换时还要调用resize()方法重新计算尺寸，不然图表显示不全。

5. 服务治理与部署运维实录

5.1 Nacos注册中心与统一配置

微服务启动时的优先要务是把自己注册到Nacos上，服务消费者才能通过服务名找到提供方。我在实践中的配置大约是：user-service、learn-service、exam-service等所有服务在bootstrap.yml里配置了同一个Nacos命名空间，注册到同一个分组。网关路由配置里可以直接用服务名作为转发目标，例如lb://EXAM-SERVICE，这样实例扩容缩容后网关不需要改配置。

Nacos还可以解决本地调试时的多环境问题。我建了三个namespace，开发环境和测试环境彻底隔离，避免开发同学调试时调用到测试环境的数据库和Redis。线上切换是很顺畅的，只需改spring.cloud.nacos.discovery.namespace一个参数。

5.2 网关路由与跨域配置最终版

Spring Cloud Gateway的配置是整个架构的咽喉。所有前端的API请求先到网关，网关根据路径前缀路由到不同服务。比如/api/user/**转到user-service、/api/exam/**转到exam-service。HSK项目最终的路由配置大概长这样：

spring: cloud: gateway: routes: - id: user-service uri: lb://USER-SERVICE predicates: - Path=/api/user/** filters: - StripPrefix=1 - id: exam-service uri: lb://EXAM-SERVICE predicates: - Path=/api/exam/** filters: - StripPrefix=1

跨域配置我只在网关层做了一份，这段配置里allowedOrigins写具体的前端地址，methods包含GET、POST、PUT、DELETE、OPTIONS，allowCredentials设为true。如果在开发环境vite代理也配置了跨域头，就可能导致重复CORS头，前端接口访问直接白屏，排查了大半天才定位到是重复头的问题。

5.3 Minio接入SpringBoot的完整封装

SpringBoot要操作Minio，先引入minio依赖，然后容器管理里创建MinioClientBean。封装工具类的上传接口时，需要指定bucket、objectName、inputStream和contentType。如果是公开课程视频，上传完成后调用getPresignedObjectUrl生成一个带有效期的访问链接，链接过期时间设置7天，适合课程点播场景。

首次接入时有一个小坑需要注意，Minio客户端和SpringBoot的OkHttp依赖版本较新，有可能与项目里自带的旧版OkHttp发生冲突。排查方式是在启动日志中找NoSuchMethodError或ClassNotFoundException，解决方法是在Minio依赖中排除旧版OkHttp，强制引入新版版本。实测这问题比率较高，我写进博客就是为了帮大家避开。

5.4 日志、监控和线上维护小工具

微服务实例一多，日志排查就让效率陡降。以前单机部署时一条命令tail -f就完事，微服务时代要查一条成绩异常的单，要跨user-service、exam-service、analysis-service三个节点的日志。我把logback输出格式改成了JSON行并写入该服务的日志目录，然后部署时用同一种模式配置集中采集工具。有条件的可以直接上Loki加Grafana，套件全家桶虽重，但用起来查日志极快。

简单一点的方案是给每个请求分配一个TraceId，网关生成后通过MDC写入日志，并向下游传递这个请求头。

logging: pattern: level: "%5p [%X{traceId}]"

线上DEBUG时，用TraceId一条命令就能把整条链路日志全捞出来，排查效率提升好几个台阶。这个习惯强烈建议从一开始就养成，不要等服务数量真正多起来之后再补，成本会高很多。

6. 常见问题与排查技巧实录

6.1 微服务版本兼容问题速查

版本类报错绝对是微服务项目的最大时间杀手。我整理了一些常见的兼容判断思路：

Spring Boot 3.x最大的坑是javax包名全部改成了jakarta，很多老代码复制过来直接编译不过。所以刚开始做新项目时，建议先确定JDK版本再定Spring Boot版本，这个顺序别反了。JDK8就只能用Spring Boot 2.x，JDK17用Spring Boot 3.x，这两个版本之间的差距不仅仅是数字，包名以及部分API都改了不少。

6.2 高频业务问题与解法

考试重复提交这个业务问题，我前面说要用分布式锁加数据库唯一索引双重保障，但还有一个隐藏场景，就是用户点了保存草稿再提交，中间走了两套逻辑。这里的解法是对提交接口设计一个唯一的submitToken，前端生成一次提交时向后端申请一个token，交卷时携带此token，后端用分布式锁和DB记录锁定该token，重复的token请求直接拒绝。token有效期只留30分钟，超时则重新申请。

m3u8视频播放跨域报错，多半不是前端问题，而是Minio的bucket跨域规则没配置CORS。Minio控制台需要为相关bucket添加跨域规则，允许来源设为前端域名（开发环境可以设为*），允许方法为GET和OPTIONS。

Vue播放m3u8遇到黑屏还有一个可能是个别服务器返回时Content-Type异常，hls.js无法识别分片格式。用开发者工具翻一下网络请求，确认content-type含application/vnd.apple.mpegurl，不是的话检查Minio里对象的Content-Type设置，上传时是否需要显式指定。

6.3 性能调优的三板斧

HSK平台压测时最先遇到瓶颈的是数据库连接池。默认HikariCP最大池大小是10，这个数值实在太小，考试高峰期几十个并发判分请求就把连接池打满了。我调成最大池大小50，最小空闲连接10，同时在调用数据库次数比较多的题库接口上对查询结果做Redis缓存，数据库压力骤降。

第二个瓶颈是对象存储的带宽。听力题音频和课程视频都从Minio拉流，高峰期会占满带宽。我用CDN加速分发公开课程视频，听力题文件是私有权限，不允许走CDN，就通过限制播放器预加载策略缓解压力。前端对听力题音频设置preload="metadata"，只为元数据做预加载，避免用户一进页面就把所有音频数据全部拉取，带宽节省非常明显。

第三个瓶颈是JVM内存设置。每个微服务默认堆内存是物理内存的1/4，如果一台8G服务器部署四个服务，刚好全部占满。我将每个服务的JVM参数统一设置为-Xms512m -Xmx512m，并对并发量大的exam-service单独拆到一台4G的机器上，分配2G堆内存。服务之间资源隔离比堆在一台机器上更稳定。

6.4 微服务面试向：这些细节别答错

其实这个类型的项目，技术演示是一方面，面试官更在意的是你听到下面几个问题时的应变能力：

• 为什么用微服务？这个此前已交代过，另外一个信号是项目规模和团队规模双增长时微服务才是合理决策。如果团队就两三个人，单体就是最合理的选择，硬上微服务反而不好维护。
• 分布式锁用的什么框架？不要只说Redis，要讲清楚为什么选Redisson而不是自己写SETNX。Redisson的watch dog自动续期机制比手写锁的核心可靠性高很多，还支持可重入和公平锁，这些细节值得在作答时提。
• 分布式事务怎么实现的？优先强调“不是所有地方都需要分布式事务”，再讲异步消息加幂等的方案，最后提Seata AT模式作为高一致性场景的备选，体现你就是认真权衡过。
• 网关层面做了什么？把全局过滤器、Token校验、路由转发、跨域处理串在一起，形成一条完整的链路去说，比孤立地背概念效果好得多。

7. 最后聊聊我做完这套系统的感受

这个项目前前后后花了小半年，中间推翻过两次数据库设计，一次是因为试卷快照的结构没设计好，一次是因为成绩统计分析维度不全。微服务架构带来的好处不是一开始就能感觉到的，等到第二次加功能，只改了question-service和exam-service，其他服务一个没碰，这种局部变更的爽快感在单体时代完全没有。

如果你准备用这套架构做自己的学习平台项目，我的建议是先把单体跑通，再拆微服务。千万别一开始就想着微服务，连HSK业务都还没想清楚，拆出来的服务边界一定很糟糕。我一开始也是直接按教科书拆服务，结果发现多个服务之间互相调用，反而比单体复杂多了。后来又并了两个服务，边界才清晰。

最后再分享一个小技巧：HSK这类题库系统，题目数据是核心竞争力，一定要把题库管理服务做好权限控制，管理员操作要有审计日志。我上线后被内部运营人员手滑改了一道题，直接导致考试判分错了几天，后来加了操作日志并且做了Redis缓存同步才解决。这种业务上的坑比技术上的坑更影响口碑。

后续如果还想扩展，可以往AI辅助学习方向走，比如根据用户错题数据生成个性化练习计划，或者用自然语言处理做写作题的自动评分。技术底座这套微服务架构已经铺好了，扩展一个智能分析服务不是难事。这个坑我还没踩完，将来踩完了再开一篇聊。