SpringCloud微服务架构下的校园心理健康系统设计与部署复盘

这套校园学生心理健康系统，我年初开始设计，最近总算完成了私有化部署。项目本身不算多么前沿，但挂上“SpringBoot + Vue + SpringCloud微服务分布式”这几个词之后，难度就完全不是单体应用能比的。而且心理健康数据和普通教务数据不一样，敏感度高、权限控制复杂，稍微处理不当就容易出问题。我写这篇复盘文章，把完整的架构思路、服务拆分逻辑、核心业务实现以及部署过程中踩过的坑都梳理一遍，给准备做类似校园信息化项目的同学一个参照。

整个系统的业务范围其实不小：学生心理测评、咨询师排班与预约、危机预警与干预、心理健康教育资源、数据统计大屏，还要对接学校统一的认证体系。最开始我也想过用单体应用快速交付，但在实际需求推演和并发评估之后，还是决定用微服务架构。原因很简单，这个系统未来会接第三方数据源、会面临开学季的集中预约流量、会不断叠加新模块，单体架构扛不住这种演进节奏。

下面直接进正题，从立项背景说起。

1. 立项背景：为什么一个校园心理系统要上微服务

1.1 单体方案下我看到的三个真实问题

很多人会问：一个校园心理系统，真有必要微服务吗？我的回答是，看场景。如果你只是给一个年级做个小问卷，单体绰绰有余；但当你面对的是全校范围、多个角色、高敏感数据、还要持续迭代的系统，单体很快就会成为瓶颈。

第一个问题是并发冲击。心理咨询预约在每个学期初会出现明显的流量尖峰，尤其是新生入校后集中做心理普查的时候，几千人同时在线答题。单体应用在数据库连接池和线程池上很容易被打满，答到一半系统卡死，学生体验极差。

第二个问题是模块耦合。测评、预约、预警、资源、报表这些功能，表面上看都在一个系统里，实际上它们的变更频率完全不同。测评模块要不断加量表，预约模块要对接咨询师排班，预警模块要处理规则引擎。如果全部塞在一个工程里，每次改动都要重新发一整个包，风险面被无限放大。有一次我改一个量表导出功能，结果把预约模块拖崩了，这种耦合的代价在心理系统这种高敏感场景下是不可接受的。

第三个问题是数据隔离。心理健康数据不能像普通成绩一样被随意查看。校领导需要看的是统计报表而不是学生个人作答，辅导员只能看到自己班级的预警名单而看不到具体答案，心理中心老师才有权限看完整档案。单体架构做权限模型当然也行，但代码层面很容易出现漏判，一旦越权就是事故。

1.2 业务全景与微服务化的收益边界

既然决定微服务，就要先盘清楚业务。我把这个系统拆成了六个核心模块：

• 学生心理档案：一生一档，沉淀历次测评、咨询记录、干预记录
• 测评中心：发布量表、在线作答、自动生成报告
• 咨询预约：咨询师排班、学生抢约、取消改约
• 预警干预：规则引擎触发预警、生成干预工单、闭环管理
• 教育资源：心理课程视频、文章、自助训练工具
• 统计报表：面向不同角色的数据分析与可视化

整个系统的使用方包括学生、辅导员、心理中心老师、咨询师、院系管理员和校级管理员。每个角色的数据可见范围完全不同，后面我会详细讲权限模型。

微服务化的收益不是免费的，它意味着更高的运维成本、更复杂的链路排查。所以拆分粒度必须克制。我的原则是：按业务域拆，而不是按数据表拆。六到七个服务足够支撑这个系统的未来三年演进，再多就是自找麻烦。

2. 服务拆分与技术选型：不能只按数据表来拆

2.1 拆成哪几个服务

经过需求梳理，我最终把系统拆成了七个服务模块，端口规划和职责如下表：

这里有一个设计原则想强调：预警服务不直接消费测评数据，而是通过事件消息解耦。测评完成之后，assessment-server 发布一个“测评完成”事件，warning-server 订阅事件并跑规则。这样即使预警规则调整，也不需要重新上线测评模块，两个服务的生命周期完全独立。

2.2 为什么是SpringCloud Alibaba而不是纯SpringCloud

技术选型上，我几乎没有犹豫就选了SpringCloud Alibaba全家桶。认证与注册中心用Nacos，熔断限流用Sentinel，服务间调用用OpenFeign，分布式配置也用Nacos Config。

很多教程还在讲Eureka加Ribbon那套老SpringCloud，但在校园私有化部署场景下，Eureka的维护体验很一般，控制台功能也简陋。Nacos把注册中心和配置中心合并成一个组件，自带可视化后台，部署和排查都省事得多。Sentinel的流量监控和熔断规则可以在控制台上动态调整，对于运维人力紧张的学校来说非常友好。

版本方面我选的是SpringBoot 2.7.18 + SpringCloud 2021.0.8 + SpringCloudAlibaba 2021.0.5.0 + JDK8。为什么没有用SpringBoot 3.x？等会儿在踩坑章节细说，那句“springboot版本太高”的热搜词背后是很多人的血泪。

2.3 服务间调用链路的约定

微服务最怕的不是服务多，而是调用链路乱。我定了几条死规矩：

第一，调用方向严格分层。gateway负责入口，业务服务之间可以互相调用，但业务服务不能反向调用gateway。第二，服务间的用户身份必须透传。用户先登录拿到JWT，请求到gateway之后，gateway把Token解析出来放在请求头往下传；服务间用OpenFeign调用时，我写了一个Feign拦截器，把上游请求中的用户Header自动透传到下游，防止服务内部接口被人直接绕过网关调用。第三，每个服务只允许访问自己的数据表。学生表在auth服务里，就不要让assessment服务直接去查询，必须通过Feign接口获取。

这套约定看起来死板，但在排查越权漏洞的时候会非常省心。只要链路是单向的、身份是透传的，任何一个接口的权限问题都能快速定位到具体服务的具体代码。

3. 心理健康数据的隐私防线：权限模型与脱敏方案

3.1 按角色分级的数据可见性

心理健康数据的敏感程度，业内普遍认为是和医疗健康数据同一级别的。它不像考试成绩那样可以按班级公开排名，一个学生的测评报告如果被不该看到的人看到，轻则引发投诉，重则可能影响学生的心理状态，造成严重后果。

我设计的权限模型是“RBAC基础角色 + 数据范围双重控制”。基础角色解决的是“能不能进这个页面”的问题，数据范围解决的是“进了页面能看到哪些数据”的问题。

这里特别要说明辅导员和数据查看的逻辑。辅导员是接触学生最密切的人，也是预警干预链条里第一个响应环节，但如果把测评的具体答案和因子得分全部放开给辅导员看，学生会产生很大的心理负担，甚至影响作答的真实性。所以辅导员端只展示“谁需要关注、什么级别关注、建议做什么”，不展示“为什么是这个分数”，这是基于心理学伦理考量的设计。

3.2 脱敏展示与操作审计

除了权限分级，数据在展示层还需要二次脱敏。测评结果列表在心理中心老师的默认视图下，学生姓名只显示姓氏加星号，点击详情并填写查看理由之后，系统记录审计日志，再展示完整报告。

审计日志记录了四要素：谁、在什么时间、通过哪个服务、查看了哪条数据。我用Filter拦截器统一处理审计埋点，避免在业务代码里到处手写日志。

另外，测评答案落库时做了AES加密存储，主数据表不保存明文答案。查询详情时服务端解密，前端拿到后只在内存中渲染，不做本地缓存。这样一来，即使数据库被导出，攻击者拿到的也只是一堆密文。密钥单独放在配置中心，与数据库隔离管理。

关于这个加密方案，我要多说一句：不是所有字段都需要加密，加密是会损失查询能力的。测评答案这种只需要“读全文”的数据适合加密，而测评分数这种需要拿来聚合统计的数据，不能加密，否则SQL没法做AVG和分组。所以我的做法是分数字段明文存储，原始答案密文存储，两个字段分开管理。

4. 测评与预警：全系统最核心的一条业务链路

4.1 量表配置化与动态表单

测评模块是整个系统的业务核心。学校里常用的量表包括SCL-90症状自评量表、SDS抑郁自评量表、SAS焦虑自评量表、UPI大学生人格问卷等，这些都是标准化工具，题目和计分规则都是公开的，直接做成可配置数据就行。

我把量表设计成了四张表：量表主表、维度表、题目表、题目选项表。一个量表包含若干维度，一个维度包含若干题目，每个题目有几个选项，每个选项对应不同分值。管理员在后台配置完这些数据，前端就能通过通用渲染引擎动态渲染出一份测评问卷，不需要为每个量表单独开发页面。

计算逻辑上，SDS抑郁自评量表这类工具的核心算法是：先根据各题目选项累加出粗分，再乘以1.25取整数得到标准分，最后按标准分区间做分级判定。这套算法全部用Groovy脚本配置在规则库里，以后如果要换成PHQ-9等其他量表，只改脚本和新量表数据就行，计算服务代码一行都不用动。

4.2 危机预警规则引擎

预警规则引擎放在warning-server中，通过订阅测评完成事件来触发。我这里要讲清楚一个工程细节，事件触发后不是立刻同步出结果，而是先把事件写入本地事件表，然后由定时任务拉取并处理。为什么不直接用消息队列？因为在学校这种场景，我不想额外引入一套RabbitMQ或者Kafka的运维负担，本地事件表加定时任务足够支撑校级规模的并发，而且上了MQ反而让问题排查变得更复杂。

预警规则分为三类：

• 阈值类：某量表标准分超过临界值，比如SDS标准分大于等于70判定为重度预警
• 趋势类：同一学生两次测评得分上升幅度超过设定值，比如抑郁因子得分半个月升高20%
• 异常行为类：连续N天情绪打卡得分低于设定阈值

规则命中后，系统会根据严重程度生成黄色、橙色、红色三级预警工单。黄色预警推送给辅导员关注，橙色预警推送给心理中心并建议两周内访谈，红色预警必须当天人工介入。整个过程从测评完成到预警工单生成，我实测平均耗时两分钟，这个延迟在业务上完全可接受。

4.3 用不用分布式事务，我的选择

这是很多微服务项目绕不开的决策点。测评和预警这一条链路，涉及assessment-server写作答记录、warning-server生成预警工单，分布在不同服务里。如果按教科书方案，应该上Seata做分布式事务，保证两个服务要么同时成功要么同时回滚。

我的选择是不用。理由很实际：学生提交测评后，系统只要保证“作答记录已保存”这一件事的强一致即可，预警工单晚两分钟生成、甚至失败后重试，对学生没有任何感知。预警这种场景天然容忍异步，硬生生套一个分布式事务，反而让提交接口的响应时间从200毫秒变成600毫秒甚至更久，还会引入额外的中间件运维成本。

所以落地时我用了“本地事务 + 事件表 + 定时任务重试”方案。测评答案和本地事件表在同一个数据库事务里写入，定时任务把未处理的事件推给warning-server，失败自动重试，重试三次仍然失败就告警人工介入。这个方案的可靠性完全符合业务需要，还省掉了Seata的部署和调优。

5. 咨询预约的并发冲突：从数据库约束到分布式锁

5.1 咨询时段冲突的真实现场

如果说测评是入口，那咨询预约就是整个系统里并发压力最大、最容易发生数据竞争的场景。咨询师的排班是按周维护的，比如每周二下午2点到4点开放两个咨询时段，全校几百个学生同时抢这两个名额，而且没有分学院错峰。这还是我特意和咨询中心确认过的真实场景，一到开放预约的时间点，服务器压力瞬间拉满。

最初的版本我天真地用了数据库乐观锁，也就是在update时段状态时加上version条件，期望通过更新失败重试来解决并发。实际测试发现，在几十人同时抢同一个时段的情况下，数据库中段状态更新冲突率非常高，大量请求的数据库重试导致连接池被打满，然后出现连锁超时。

5.2 Redis分布式锁从原理到代码

后来我引入了Redis分布式锁。锁的Key设计很讲究，不是锁全局，而是按“时段ID”加锁，也就是每个咨询时段一把锁。我用的Redisson客户端，它的tryLock实现底层是Lua脚本，能保证加锁和释放的原子性，比手写SETNX加EXPIRE两个命令靠谱得多。

核心代码大概是这个样子：

java复制@Autowired
private RedissonClient redissonClient;

public boolean tryLockAppointment(Long scheduleId, Long studentId) {
    String lockKey = "appointment:lock:" + scheduleId;
    RLock lock = redissonClient.getLock(lockKey);
    try {
        boolean locked = lock.tryLock(2, 10, TimeUnit.SECONDS);
        if (!locked) {
            return false;
        }
        return appointmentService.createAppointment(scheduleId, studentId);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        return false;
    } finally {
        if (lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
}

这里有两个参数值得单独解释。waitTime我设了2秒，意思是拿不到锁最多等2秒，避免大量请求同时阻塞在锁上把线程池耗尽；leaseTime设了10秒，是锁的自动过期时间。为什么不是一直持有直到业务结束？因为如果服务宕机释放不了锁，其他请求就会被永远卡死。10秒的过期时间类似于一个兜底机制，确保最坏情况下锁也能自动消失。当然这么做有一个副作用：如果业务执行真的超过了10秒，锁提前过期，后到的请求也能拿到锁进来了。这就引出下一节的双保险策略。

5.3 锁之外的兜底策略

分布式锁不能取代数据库层面的最终约束，这两者配合才是完整方案。锁负责挡住99%的并发冲突，数据库负责守住最后一条防线，防止极端情况下锁提前过期导致的超额预约。

我在预约表的业务设计上加了两个约束。第一个是数据库唯一索引，字段组合是“咨询师ID + 时段日期 + 时段开始时间 + 预约状态”，同一时段同一咨询师只能生成一条有效预约记录。第二个是更新时段状态时的CAS条件，更新SQL里带上“当前状态 = 可预约”这个条件，如果影响行数为0就说明时段已经被抢走。

实际跑下来的效果，加了分布式锁之后，Redis的争抢压力明显下降，数据库层几乎没有再出现过超卖，之前那个连接池被打爆的问题也就顺带消失了。所以我的经验是：锁只是性能手段，数据库约束才是正确性底线。

6. 视频资源模块：MinIO私有化存储与m3u8点播

6.1 为什么用MinIO而不是OSS

心理健康教育资源模块里有大量的视频内容，比如心理科普短视频、放松训练音频、咨询技巧课程。学校的网络环境通常不允许直连外部公有云存储，而且每年要传的教学视频量不算小，长期走OSS流量费也是一笔开销。所以存储选型我直接定了MinIO，这玩意儿是私有化部署，兼容S3协议，内网访问速度快，运维起来也就是一个二进制文件加配置文件的事。

MinIO接入SpringBoot的方式也很清爽。引入MinIO Java SDK，然后通过预签名URL机制实现上传。简单解释一下预签名URL：后端根据AccessKey和SecretKey生成一个带过期时间的上传地址，前端直接拿这个地址把文件PUT到MinIO，文件不经过业务服务器中转，避免了大文件上传占满网关带宽的问题。上传完成后前端再回调后端登记文件元数据，整个流程就闭环了。

视频切片这块我用的是ffmpeg。原始视频直接播放会有两个问题，一是文件体积大首屏加载慢，二是iPhone的Safari对MP4格式支持有各种兼容细节。所以我统一把源的视频转成HLS格式：

bash复制ffmpeg -i input.mp4 -c:v h264 -c:a aac -f hls -hls_time 6 -hls_list_size 0 -hls_segment_filename output_%04d.ts output.m3u8

转完之后会生成一个m3u8索引文件和若干ts分片文件，直接传到MinIO对应的桶里就完成了发布。

6.2 Vue端播放m3u8免安装方案

前端播放这一块，Vue项目里如果用原生video标签直接播放m3u8，在Chrome和Firefox上是没用的，因为浏览器原生不支持HLS协议。只有iOS的Safari自带HLS播放能力。所以我在Vue里引入了hls.js，这个库其实就是把m3u8的ts分片拉下来，实时转成MP4喂给video标签，不需要用户安装任何插件。

核心播放逻辑如下：

javascript复制import Hls from "hls.js";

function playM3u8(videoElement, m3u8Url) {
  if (Hls.isSupported()) {
    const hls = new Hls();
    hls.loadSource(m3u8Url);
    hls.attachMedia(videoElement);
    hls.on(Hls.Events.MANIFEST_PARSED, () => videoElement.play());
  } else if (videoElement.canPlayType("application/vnd.apple.mpegurl")) {
    videoElement.src = m3u8Url;
  }
}

这段代码兼容了大部分端，加上一个统一的错误提示，基本不需要再写第二套逻辑。

这里有一个容易踩的坑，就是播放防盗链。m3u8文件和ts分片如果直接暴露在MinIO的公开桶里，就等于告诉别人你能下载全部课程视频。我的做法是每次播放请求都从后端换取一个带过期时间的预签名URL，学生拿到的链接有效期只有20分钟，浏览器每次请求分片时都会自动携带签名参数，到期需要重新获取，这样既保证播放流畅又不至于把整个目录裸奔出去。

6.3 前端路由权限与菜单的动态生成

顺便提一下前端Vue层的设计。前端用的是Vue 3加Element Plus，菜单和路由是动态生成的。登录成功后，后端返回当前用户的角色和可见菜单，前端根据这个配置动态添加路由。Vue Router提供了addRoute方法，可以运行时注册路由表，这一点比传统静态路由灵活很多。

涉及页面权限之后，要注意一个问题：动态路由的页面刷新之后会丢失，因为Vue是单页应用，刷新后js重新加载，路由表是空的。我加了一层全局守卫，每次路由跳转前先检查当前路由表是否已经加载完成，如果没有就先向用户服务重新拉取权限配置，等路由挂载完再继续跳转。这个兜底逻辑一定要写，否则学生按F5刷新之后会被踢回登录页，体验很糟糕。

7. 部署交付与踩坑复盘：从JDK版本到前端放行

7.1 开发环境到私有化部署的版本矩阵

系统开发完，进入部署阶段才是真正检验架构设计的时候。学校通常有自己的机房和运维老师，但运维水平参差不齐，所以我的准则是：能少一个组件就少一个组件，能统一一个版本就统一一个版本。

最终交付的版本矩阵如下：

为什么Redis锁用Redisson而不是自研？因为Redisson的Lock实现经过大规模生产验证，而且它的看门狗机制能自动续期，可以避免锁过期时间设置不合理导致的业务中断。自研分布式锁的坑太多了，建议不要重复造轮子。

7.2 版本太高引发的一连串问题

这里专门聊聊热搜词里那句“springboot版本太高”。我一开始真的踩过这个坑。SpringBoot 3.x正式发布后，很多教程都在推新版本，我也顺手试了一下。结果遇到的问题一个接一个：SpringBoot 3强制要求JDK17，但学校的应用服务器上装的全是JDK8；SpringCloud 2022版本和SpringBoot 3绑定，之前很多中间件客户端的自动配置类因为Jakarta命名空间迁移全部失效；连MyBatis-Plus的旧版本分页插件都不兼容，需要升级到新版本，而新版本又会有其他依赖冲突。

折腾了两天之后我做了个果断的决定：全部回退，采用上面表格里的版本组合。这是整套系统里我做得最正确的一次“减法”。在校园项目里，稳定永远比新版本重要。技术选型不是赶时髦，而是要为后面接手的人降低维护门槛。

7.3 前端打包放行的几种方式

前端构建完成后，产物怎么部署也是一个学问。最常见的做法是用Nginx托管前端静态文件，然后反向代理/api到后端网关。Nginx配置我给一个关键片段：

nginx复制server {
    listen 80;
    server_name mindcare.example.edu.cn;

    root /data/www/mindcare;
    index index.html;

    location / {
        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;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

那个try_files配置是给Vue Router的history模式用的。如果缺失，用户直接访问某个子路由刷新时会出现404，排查起来费时间，这个问题我一开始就吃了亏。

如果你的场景是单体部署、不想单独部署Nginx，也可以把Vue打包产物直接放进SpringBoot的src/main/resources/static目录。但我要说清楚，在微服务架构下并不推荐这种“vue打包放进springboot”的做法：前端和后端耦合在一起，没法单独更新，也没法充分利用Nginx的静态文件缓存能力。除非是给上级演示的Demo环境求快，否则生产环境一定要走前后端分离部署。

7.4 给后来接手这个系统的人几句实在话

复盘这个项目，最深的体会是把架构选择建立在真实业务约束上，而不是技术时髦度上。微服务不是万能解药，它解决的是模块独立性和伸缩性问题，同时引入了链路复杂性和部署成本，你要先确认自己是不是真的需要这些。

做校园心理健康系统，首要排序永远是数据安全、稳定性、可维护性。测评答案漏给不该看的人看一眼，比功能少做一个模块严重得多。所以权限模型、审计日志、脱敏展示这些“不产生新功能”的模块，应该放在一开始就设计，而不是上线前再补。

另外，部署文档中一定要写清楚每个服务的启动顺序：先启Nacos和MySQL、Redis，再启业务服务，最后启gateway。如果顺序反了，业务服务启动时会因为连不上Nacos而反复重试，看起来像启动失败，其实只是依赖没就绪。部署脚本里我加了一个简单的等待依赖就绪的逻辑，这一条在外面查任何教程都不容易查到，算是吃了几次亏换来的经验。

这套系统后续的扩展空间也明确：微信公众号对接、校级统一身份认证单点登录、心理数据大屏实时展示、API开放平台，都已经预留在路由层面和数据模型层面了，后面谁接手，按这些方向去加模块就行，不用推翻现有架构。