每年九月的秋招季就业办的老师一边催企业上传岗位一边被学生追着问宣讲会时间。校园招聘网这个系统表面上是个信息发布平台真正做起来才会发现它要同时服务学生、企业HR和就业办管理员还得扛住宣讲会抢座、热门职位集中投递的瞬时流量。我做的这套大学校园招聘网求职系统技术路线就是 SpringBoot Vue SpringCloud 微服务分布式。系统把学生端、企业端、管理端拆成多个独立服务入口统一走 Gateway 网关Nacos 管注册中心和配置中心服务之间用 OpenFeign 通信投递链路用 Redis 分布式锁和本地消息表做一致性兜底前端用 Vue3 全家桶完整实现。这篇文章是落地复盘从业务拆分、组件选型、代码实现到踩坑记录都会讲到。不管你是拿它做毕设、项目实战还是想找一个业务完整且能讲出设计亮点的微服务例子都能找到直接可抄的部分。1. 为什么校园招聘要拆微服务先想清楚业务边界1.1 从业务场景倒推服务拆分的依据校园招聘系统的用户有三方学生、企业HR、就业办管理员。学生关心的是有没有好企业、怎么投简历、面试安排是什么企业HR关心的是职位发布、简历筛选、面试预约就业办关心的是企业资质审核、招聘进度报表、政策信息推送。这三方的操作路径完全不同数据访问模式也差得很远。如果你把所有功能塞到一个 SpringBoot 单体里前期开发确实快但跑一段时间就会发现问题。热门职位投递高峰和学生资料编辑同时发生时数据库表锁竞争激烈学生模块改一行代码整个系统要重新打包部署学生、企业、管理员的所有方法堆在一个工程里稍不注意就出现“管理员权限接口被学生调通”这类事故。这些痛点倒逼我按业务边界拆服务auth-service负责登录、注册、Token 签发、短信验证码user-service学生、企业、管理员基础资料维护job-service职位发布、职位搜索、宣讲会管理、职位收藏resume-service简历信息维护、简历附件索引application-service投递记录、投递状态流转、批量导出简历notification-service站内信、邮件、短信通知file-service文件上传、下载、签名 URL 生成gateway统一入口、全局鉴权、路由转发、限流拆的时候要时刻提醒自己不要为了拆而拆。比如“职位收藏”本质上是投递之前的轻量动作把它放进 job-service 没问题没必要单独抽一个 collect-service。微服务的第一原则是“按业务变化频率和团队协作边界拆”不是“按名词拆”。边界拆得太碎服务数量翻一倍运维和联调成本也跟着翻一倍。1.2 单体与微服务的取舍以及分布式引入的真实成本这里说点实在话。校园招聘这个场景真实并发量不算高普通高校一天 PV 也就几万到几十万单机完全能扛。那为什么还要上微服务我认为有两个原因值得写进项目介绍第一它给你提供一个展示“问题处理能力”的载体分布式锁、分布式事务、服务容错这些知识需要一套真实业务来承载第二校园招聘存在几个“突刺型”并发点宣讲会抢座、热门职位集中投递、企业批量导出简历这些场景用分布式方案能很好地横向扩展。但微服务不是免费午餐。它的成本有三块运维成本、事务成本、调试成本。服务多了部署、监控、日志系统都是负担跨服务调用时数据的一致性处理复杂一个请求经过四五个服务某个环节报错定位问题要翻好几套日志。所以我的建议是“单体先行接口驱动逐步拆分”。先用一个完整工程把所有功能跑通数据表和接口约定好再按服务边界把代码搬走。每拆一步都有测试数据做回归不会改崩。这个思路写进面试自我介绍里比“我会用微服务”更有说服力。2. 服务边界与核心链路设计从一次简历投递说起2.1 用户的四种角色与权限模型设计权限模型我用的是经典 RBAC角色有四类学生、企业HR、就业办管理员、系统管理员。数据库里就五张核心权限表sys_user、sys_role、sys_user_role、sys_menu、sys_role_menu。用户和角色是多对多角色和菜单也是多对多这样扩展新角色时不用改代码只在库里配菜单就行。登录成功后auth-service 负责签发 JWTtoken 里只放必要信息userId、roleCode、过期时间。像用户姓名、手机号、邮箱这些敏感信息一律不放 token需要时服务间调用去 user-service 取。gateway 层做统一鉴权校验 JWT 签名后把 userId 和 roleCode 放到请求头 X-User-Id、X-User-Role 里传给下游服务。下游服务不解析 token只从请求头里拿用户身份。这个设计有一个实际好处服务间调用时Feign 拦截器只需要透传请求头不需要重新解析 token。如果每个服务都引入一套 JWT 解析逻辑代码重复不说拿着 A 服务签的 secret 去验 B 服务签的 token还会验签失败。我在项目里把所有 token 解析逻辑收敛在 auth-service 和 gateway 两层其他地方完全屏蔽 JWT 细节。网关做鉴权时要维护一个公开接口白名单。登录、注册、图片验证码、公开的招聘公告下载这些接口不校验 token。白名单我放在 Nacos 配置中心里用一组路由正则动态更新每加一个公开接口不需要重新发版部署。2.2 一次简历投递背后涉及的服务链路用户从职位详情页点“立即投递”后前端先请求 gatewaygateway 路由到 application-service。application-service 要依次做四件事第一判断该用户是否已投递过该职位。这里我用 Redis 分布式锁加数据库唯一索引双重校验防止用户在 1 秒内连点两次投递生成重复记录。第二调用 resume-service 获取该学生的默认简历信息。这里用 OpenFeign 同步调用加上 Sentinel 兜底如果简历服务慢或挂了投递接口快速返回提示不让用户一直转圈。第三插入投递记录状态为“已投递”同时往本地消息表写入一条“待发送”通知消息。第四由定时任务异步调 notification-service 发站内信和邮件给学生发投递成功回执给企业 HR 发新简历提醒。第四步如果你用同步调用的思路去实现就掉坑里了。发送通知慢用户点击“投递”就卡死通知服务一挂投递记录直接报错。我在最初版本就是这么写的结果企业邮箱服务抖动一次整个投递入口瘫痪半小时。改成本地消息表之后投递接口只操作本地数据库通知消息进入消息表就算成功返回速度稳定在 200ms 以内。这就是分布式事务里“最终一致性”的典型应用场景。2.3 宣讲会名额与投递抖动的并发处理宣讲会抢座是校园招聘系统里最像“秒杀”的场景。一个宣讲会放 200 个名额学生在就业群里收到消息后同时点进来报名。如果在 application-service 里用 synchronized 锁那么这个锁只作用于单个实例服务起了两个副本锁就不互通200 个名额可能被抢出 400 个人。我的方案是宣讲会名额提前写入 Rediskey 为 lecture:{id}:count抢座时用 Lua 脚本完成“判断库存-扣减-记录报名用户”三个步骤原子性由 Redis 保证。数据库层面再放一个乐观锁兜底update lecture set remain remain - 1 where id ? and remain 0防止预热失败或 Redis 数据错乱时超卖。这个组合方案逻辑清晰也适合写进项目介绍当亮点。热点数据要不要做分片取决于单场宣讲会的并发峰值。我实测下来普通高校一场宣讲会同时报名人数很少超过 5000单 key 的 Redis 完全扛得住。所以分片方案我只在方案设计文档里留了扩展思路没有真做。做工程最忌讳的是一上手就把方案复杂度拉满能用简单方案解决的并发问题不要用分片、Mq、多级缓存去硬撑。3. 微服务基础设施选型与落地Nacos、Gateway、OpenFeign 的组合3.1 组件选型SpringCloud Alibaba 还是 SpringCloud 官方这个项目里的微服务基础设施我选的是 Nacos Gateway OpenFeign Sentinel也就是 SpringCloud Alibaba 体系。理由很简单Nacos 同时提供注册中心和配置中心省去再部署一套 Eureka 和 Config ServerSentinel 的可视化控制台做限流规则调试比较直观SpringCloud Alibaba 社区活跃中文文档多遇到问题好搜。很多教学项目上来就全组件堆齐Nacos、Gateway、OpenFeign、Ribbon、Hystrix、Sentinel、Seata、Sleuth、SkyWalking 全部挂上。我劝你冷静一下。这个系统真正高频用到的组件就四个Nacos 注册和配置、Gateway 路由和鉴权、OpenFeign 服务间调用、Sentinel 限流和兜底。Seata 没必要上因为校园招聘的大多数跨服务写操作是最终一致本地消息表已经覆盖Ribbon 和 Hystrix 都进入维护期SpringCloud 2021 起官方主推 OpenFeign这种迁移迭代太频繁的历史包袱别全背上。版本管理是这个项目最容易卡壳的地方。Spring Boot 和 Spring Cloud 的版本必须严格对应不然启动时各种类找不到。我实测可用的组合如下直接抄组件版本Spring Boot2.7.14Spring Cloud2021.0.5Spring Cloud Alibaba2021.0.5.0Nacos Server2.2.0Redisson3.20.1Vue3.3Vite4.4Element Plus2.4如果你用的是 Spring Boot 3那需要换 Spring Cloud 2022 和 Spring Cloud Alibaba 2022 的对应版本。没把握就直接用上表我验证过这套配下来 Nacos、Gateway、Sentinel 都能正常工作。3.2 注册中心与配置中心Nacos 的配置细节Nacos 一鱼两吃既是注册中心又是配置中心。服务启动时将实例信息注册到 Nacos其他服务通过服务名就能找到它不用关心 IP 变化。每个服务的 bootstrap.yml 里指定 Nacos 地址和 dataid配置项按“环境差异化”原则拆分数据库连接、Redis 连接、业务开关放进去pom 依赖版本这种和部署环境无关的不放。用 Nacos 做配置中心的最大价值是热更新。企业资质审核模式从人工审核临时改成“系统自动审核人工抽查”我只需要在 Nacos 里改一个配置项业务代码通过 RefreshScope 注解立即拿到新值不用重新发版。第一次用这个功能时确实很爽但要记住一个教训不要在配置中心里放太多低价值配置不然每次刷新Nacos 的长轮询会让所有服务都感知一遍造成不必要的资源消耗。本地开发时服务实例多需要关注内存分配。我给每个服务设置 JVM 堆内存 128MB启动 7 个微服务大概占 1 到 1.5GB开发机 16GB 内存完全跑得动。如果你把所有服务都默认用 512MB 堆内存启动开 5 个服务内存就报警了。3.3 网关层认证、限流与路由配置Gateway 是微服务的统一入口。前端不再直连某个具体微服务所有请求都打到网关由网关按路径前缀转发。路由配置可以直接用 yml不需要写代码spring: cloud: gateway: routes: - id: auth-service uri: lb://auth-service predicates: - Path/api/auth/** - id: job-service uri: lb://job-service predicates: - Path/api/job/**这里 uri 写的是 lb://服务名不是 IP 地址。lb 是 LoadBalancer 的缩写Gateway 通过负载均衡器从 Nacos 获取实例列表再转发。这也就是为什么服务实例扩容缩容前端完全无感知。网关的全局过滤器里我实现了 token 校验和用户信息透传。从 Authorization 请求头取出 JWT解析出 userId 和角色再放到请求头传给下游。如果 token 剩余有效期小于半小时响应头里返回一个刷新后的新 token前端接住后自动替换本地存储用户就不会在秋招季浏览职位时突然被弹回登录页。4. 关键难点实战分布式事务、分布式锁与文件存储4.1 分布式事务本地消息表与 Seata 的适用边界校园招聘系统里最典型的跨服务写操作是投递简历同一个用户动作同时涉及投递记录、简历读取、企业通知。很多微服务教学项目一上来就扛着 Seata 到处跑全局事务开启后本地测试看着挺正常一部署多实例就遇到各种回滚问题。我的结论是这个场景根本不需要 Seata它需要的是最终一致性。实现思路是本地消息表。投递数据插入 t_application 后在同一个数据库事务里往 t_message_record 插一条“待发送”的消息。定时任务每 5 秒扫描一次未发送消息调用 notification-service 的发送接口发送成功就把消息状态改成“已发送”。连续失败超过 5 次的状态标记为“死信”人工介入排查。我把这个流程画成文字版投递接口开启数据库事务插入投递记录 插入待发送消息事务提交定时任务扫描待发送消息调用通知服务发送成功则更新状态失败重试投递接口本身只依赖本地事务返回速度快这套方案让我在遇到企业邮箱接口偶发超时时只需要调整重试间隔和重试次数不用动投递主链路。面试时如果被问到“分布式事务怎么解决”能把“业务能接受最终一致吗能就不用 Seata不能才用”说清楚比背一堆 Seata 原理更让面试官认可。4.2 Redis 分布式锁用 Redisson 落地投递防重分布式锁是这个项目最值得写的高光点。我直接用 Redisson 而不是手写 setnx原因很简单Redisson 自带看门狗自动续期、可重入锁、公平锁手写 setnx 还要自己处理过期时间续期和释放锁的原子性问题很容易出 bug。来看投递防重的核心代码我做了简化Autowired private RedissonClient redissonClient; public boolean submit(String userId, String jobId) { String lockKey application:submit: userId : jobId; RLock lock redissonClient.getLock(lockKey); boolean locked false; try { locked lock.tryLock(3, 30, TimeUnit.SECONDS); if (!locked) { return false; } // 双重校验数据库唯一索引再次检查 if (applicationRepository.existsByUserIdAndJobId(userId, jobId)) { return false; } // 执行投递记录插入 本地消息写入 // ... return true; } finally { if (locked) { lock.unlock(); } } }这里有两个坑。第一个lock.unlock() 只能在拿到锁的线程里执行所以 finally 里必须判断 locked 状态否则 Redisson 会抛出“attempt to unlock lock, not locked by current thread”异常。第二个锁的 key 一定要带业务语义粒度尽量小。能锁 userId:jobId 就不要锁全表能锁单用户就不要锁全局。锁粒度直接决定系统并发度这是我在压测中体会最深的一点。我把分布式锁还用在另一个场景企业批量导出简历。同一家企业 HR 同时点两次导出文件服务会被重复请求拖垮。给导出操作加上以企业 ID 为粒度的锁保证同一时间只有一个导出任务在跑其余请求直接返回“正在生成中”的提示。4.3 简历附件与文件服务的处理简历附件用 MinIO 做对象存储。MinIO 单机部署简单api 兼容 S3以后要迁移到云对象存储服务时改配置就行。有的同学在项目简介里写“接入了 HDFS 分布式文件系统”实际上校园招聘系统的简历附件都属于小文件实时读写的场景HDFS 更适合离线批量处理大文件比如学校整仓导入历年毕业生简历做就业分析。把 HDFS 硬塞进在线投递链路里只会徒增架构复杂度。file-service 单独抽出来主要处理三个问题。第一上传限制简历附件最大 10MB前端和后端都做校验后端校验 Content-Type 和扩展名白名单只放行 pdf、doc、docx、图片格式。第二文件名安全存储时重新生成 UUID 文件名避免上传“张三简历.pdf”这种中文名在文件系统里出现编码问题。第三下载安全不给外部暴露永久直链生成签名 URL有效期设 10 分钟防止学生隐私被批量爬取。5. 前端工程化与联调避坑Vue3 实战记录5.1 Vue3 项目搭建与环境配置前端技术栈是 Vue3 Vite Element Plus Pinia Vue Router。Vite 的启动速度比 webpack 快很多但 Vite 对 node 版本有要求最好用 node 16.19 或 18 LTS。安装依赖时先把 npm 镜像切到国内源不然第一次安装能把人急死实测命令是 npm config set registry https://registry.npmmirror.com。项目结构我按“业务域分目录”不按“文件类型分目录”。src/api 下每个微服务对应一个 js 文件src/views 下按学生端、企业端、管理端分成三个一级目录store 里只放登录状态和用户信息。路由用动态路由方案登录后根据角色从后端菜单接口拿数据再用 router.addRoute 动态添加路由。这个做法从根源上解决了“学生登录后手动输入企业管理页面地址进不去”的权限问题。很多 Vue 新手卡在环境配置这一步。vue devtools 插件装不上很多浏览器插件商店都找不到。正确的做法是去 vue-devtools 的 GitHub 发布页下载对应浏览器版本然后以开发者模式加载已解压的扩展程序。调试组件状态、路由跳转、Pinia 数据变更没有这一套工具你会多花一倍时间在 console.log 上。5.2 请求封装、Token 注入与 404 问题定位axios 二次封装时我在 request 拦截器里统一加 Authorization 请求头从 localStorage 取 token。response 拦截器做两件事接口返回 401 时清掉本地登录信息跳转登录页业务 code 非 0 时统一提示错误信息不用每个页面都写重复的 try-catch。前后端联调的跨域问题我的方案是网关统一处理 CORS前端不配跨域。开发环境下用 Vite 的 server.proxy把 /api 转发到网关地址server: { proxy: { /api: { target: http://localhost:8000, changeOrigin: true } } }打包部署后刷新页面出现 404这个问题几乎每个 Vue 项目都会碰到。原因就是用 history 路由模式刷新时nginx 不知道把 /job/list 这种路径交给前端还是后端直接返回 404。nginx 里加上一行配置就解决location / { try_files $uri $uri/ /index.html; }踩过几次这个坑之后我把这段配置直接固化在部署文档里团队里再没有人因为刷新 404 来问我。6. 常见问题速查与踩坑记录6.1 启动顺序与服务发现失败排查微服务有依赖关系启动顺序不对会出现访问失败。我的建议顺序先启动 Nacos再启动 Redis、MinIO然后启动 auth-service再启动其他业务服务最后启动 gateway。如果你先启动 gateway网关注册到 Nacos 了但路由的目标服务还没注册访问任何接口都会返回 503。服务发现失败是微服务排障中最常见的问题排查三板斧Nacos 控制台里服务列表有没有出现对应服务名客户端是否正确配置 spring.cloud.nacos.discovery.server-addr服务实例是否还在正常心跳没有的话检查网络端口和防火墙最有迷惑性的一种情况是Nacos 里明明能看到服务实例Feign 调用却报“找不到服务”。十有八九是调用方把地址写成了 IP而不是服务名。在微服务架构里服务间调用只能用服务名IP 变化时由注册中心动态通知这是整个架构能横向扩展的基础。6.2 接口404、跨域、Feign 调用失败这三座大山网关返回 404 时先分清是哪一层的问题。看网关日志如果请求路径根本没有匹配到路由说明路径写错或路由没配置如果匹配到路由但目标服务返回 404说明目标服务里没有这个接口或者服务没注册进来。跨域问题记住一条原则网关统一处理一次前端不要在 axios 里再配跨域两头都配反而会因为预检请求处理不一致出怪问题。OpenFeign 调用失败最常见的坑是超时时间太短。默认连接超时 10 秒、读取超时 60 秒对于一个内部要查数据库、调下游、做数据汇总的接口来说可能不够。合理调整策略ribbon: ConnectTimeout: 3000 ReadTimeout: 10000还有一个隐蔽的坑服务间调用时 token 不会自动透传。下游服务拿不到用户身份接口直接报 401。我写了一个 Feign 拦截器从 RequestContextHolder 里取出当前请求的 header把 X-User-Id、X-User-Role 传给下游服务。这个拦截器是整个项目里不起眼但价值很高的组件。6.3 面试视角微服务项目的加分点与常见追问做这种项目面试官会围绕几个点反复问为什么拆这些服务分布式事务怎么解决分布式锁怎么实现网关有没有做限流服务之间怎么通信我在项目里给自己准备了几个核心答案拆服务是看业务变化频率和团队边界不是看功能模块分布式事务优先本地消息表因为大部分业务是最终一致性只有资金类强一致场景才考虑 Seata分布式锁用 Redisson锁粒度按业务语义设计投递防重用 userId:jobId 粒度Gateway 统一鉴权JWT 只在校验时解析一次下游服务通过请求头透传用户信息Sentinel 限流主要配置在宣讲会报名、职位搜索、简历导出三个热点接口上这些答案的核心不是背概念而是每一个都有对应的真实故障或优化记录支撑。面试官追问细节时你能把当时的问题现象、排查过程、最终方案讲清楚比任何八股文都更有说服力。我个人做完这个项目最大的体会是SpringCloud 组件本身不难学难的是理解“什么时候该拆、什么时候不该拆什么时候该用强一致、什么时候用最终一致”。这套系统里真正值钱的不是微服务壳子而是你在一次次的故障和优化中形成的技术判断力。最后分享一个实用小技巧本地开发时用 docker-compose 把 Nacos、Redis、MinIO 一次性启动Windows 和 macOS 上都不用额外安装环境。这可以让别人拿到项目后半小时内跑起来不管是作为毕设展示还是开源传播都非常加分。