企业官网建设流程全解析

毕设选“基于微服务架构的招聘平台的设计与实现”这个题目，是我当年翻了两天选题列表之后才定下来的。招聘平台这个业务域足够完整，求职者、招聘者、企业、职位、简历、投递、面试通知这些环节串起来就是一条真实业务链路，不像图书管理、商城那样容易做得“一眼假”；而微服务架构这个关键词本身又是评审时最能集中提问的技术加分项。这篇文章就把整个项目从选题逻辑、服务拆分、核心链路设计到部署排错、源码整理的完整过程写出来，配套源码也按工程化方式整理了目录，给正在做类似题目的同学一个能直接参考的版本。

1. 这个毕业设计的选题逻辑：招聘平台为什么适合微服务架构

1.1 招聘业务天然就是多角色、多模块的长链路场景

先看平台里有哪些角色：求职者要注册账号、维护简历、搜索职位、投递简历、接收面试邀请；招聘者要维护企业资料、发布职位、筛选简历、发起面试；平台管理员要审核企业、管理职位分类、查看运营数据。这个角色矩阵决定了系统最少要有三套对外入口，而每套入口背后的数据模型和业务逻辑差异都很大。

这正好是微服务的理想土壤。微服务强调的“围绕业务能力组织服务”，在招聘平台上特别直观：用户服务管账号和身份，企业服务管公司信息，职位服务管岗位上下线，简历服务管履历数据，投递服务管一次应聘行为的完整生命周期。各模块虽然存在依赖关系，但边界比一般管理系统清晰得多，拆开之后每个服务都能独立讲清楚自己做了什么，论文里的架构图也不会画得云里雾里。

我当时最实际的看法是：选题要选一个“业务能拆开、技术能展开、演示能出效果”的场景。招聘平台三条用户链路都有独立页面、独立接口、独立数据，天然适合用多服务去承载。如果换成新闻管理系统或宿舍管理系统，硬拆微服务更像为了做微服务而做微服务，答辩时第一个追问“你这里为什么必须拆？”就会很难答。

1.2 单体系统也能实现，但技术上的“可讲性”差很多

并不是说单体做不了这个平台。用 Spring Boot 写一个大工程，目录分 controller、service、mapper，照样能把求职者和招聘者的功能全部跑通，甚至开发效率更高、部署更省事。但作为毕业设计，要回答的不只是“系统能用”，还要回答“你掌握了哪些技术、解决了哪些问题”。

单体唯一的讨论空间是代码分层是否清晰、表结构是否合理，这些问题的深度有限。而微服务架构能把以下问题全部带出来：服务如何注册发现、网关如何统一路由、多个服务之间怎么远程调用、跨服务的数据一致性怎么保证、分布式环境下登录态怎么处理、海量职位数据怎么搜索。这些问题每一个对应一套成熟的中间件或解决方案，写在论文里自然显得充实，答辩时也容易展开。

用生活里的类比来说，单体好比一间小饭馆，所有菜都在一个厨房里做，简单直接；微服务则是美食广场，每个档口独立排烟、独立下水，但是共享广场的客流和统一管理。代价是消防、排水、招商这些基础设施问题全都冒出来了——对毕设而言，这些“基础设施问题”恰恰是加分项。

1.3 技术栈选型与版本匹配的硬核现实

技术选型我建议直接走国内用得最多的那一套，就业市场熟悉、社区资料多、答辩时老师也听得懂：后端 Java + Spring Boot + Spring Cloud Alibaba，服务注册与配置中心用 Nacos，远程调用用 OpenFeign，网关用 Spring Cloud Gateway，数据库 MySQL，缓存 Redis，消息队列 RabbitMQ，搜索 Elasticsearch，文件存储用 MinIO，前端 Vue + Element UI。

这套组合最大的坑是版本兼容。Spring Boot、Spring Cloud、Spring Cloud Alibaba 三者对版本有严格要求，不匹配时启动会报一堆莫名其妙的错。我当时定的版本组合如下，已经跑通：

提示：先确定 Spring Boot 版本，再去查 Spring Cloud 的 Release Train 对应关系，最后根据 spring-cloud-alibaba 的版本说明选 Alibaba 那一层。三层版本一定要一起锁定，不要单独升级其中一个。

2. 服务拆分与数据库设计：避免做成“分布式单体”的踩坑记录

2.1 九个核心服务的职责划分与数据库归属

很多同学把微服务做成“分布式单体”的原因只有一个：按代码分层拆，不按业务拆。比如拆出 controller 模块、service 模块、mapper 模块，这等于把单体换了个壳，服务之间交叉调用极其混乱。正确做法是按业务领域拆，每个服务内部自己再走 controller-service-mapper 分层。

我最终拆成九个服务，每个服务配独立数据库，表和服务的对应关系如下：

加上最外层的 gateway 和公共服务 common/api 模块，整个仓库的顶层结构是platform-server聚合工程，下面平铺十个子模块。为什么把求职者个人信息和简历内容拆成两个服务？因为简历内容是一个可以多次编辑的附属复杂实体，而用户基本信息被认证、收藏等其他服务频繁引用，拆开之后可以避免简历表的大字段拖慢用户服务的常规操作。

2.2 独立库之后的关联查询难题：聚合由接口来完成

拆库最明显的感受是：以前一条 SQL 通过 JOIN 就能查出的列表，现在查不出来了。举我开发时真实的一个例子：管理后台需要显示“某职位下的投递列表”，期望列包括职位名、求职者姓名、简历完成度、投递时间。

在单体时代这就是application表 JOINjob表和user表。拆库之后没有跨库 JOIN 可用，我的做法是三步走：第一步由 application-service 按职位 ID 分页查出投递记录；第二步从记录里取出 user_id 集合，批量调用 user-service 的一个聚合接口拿到姓名和简历完成度；第三步再从 job-service 查出职位名。前端看到的是一个接口，后端实际由三个服务配合完成。

这个“批量调用后再内存拼接”的模式是整个项目的核心套路。它比 N+1 查询好一点的地方在于：两次远程调用都是批量传 ID、批量返回结果，而不是每条记录调一次接口；否则列表 50 条数据会触发 100 次网络请求，测试时直接卡死。为了减少冗余调用，我还给 user-service 的“用户基础信息批量查询”接口加了本地缓存，5 分钟内同一个用户集合不会二次查库。

2.3 公共约定：统一响应、Feign API 模块与异常处理

服务一多，各写各的返回格式会让联调变成灾难。我一开始没定约定，结果 user-service 返回{code:200, data:...}，job-service 返回{success:true, result:...}，网关层做统一封装时差点改疯。后来把所有跨服务响应统一成Result<T>结构，包含 code、message、data 三个字段，分页统一用PageResult<T>，里面固定是 list、total、pageNum、pageSize。

Feign 客户端也不直接写在业务服务里，而是单独拆一个 api 模块，每个服务自己的 Feign 接口和 DTO 放在对应包下。这样做的好处是：比如 application-service 想调 job-service 的接口，只需要在 api 模块里定义一个 JobClient 接口并加上@FeignClient(name = "job-service")，两个服务同时依赖这个 api 模块即可。服务提供方实现 Controller，服务消费方调 Feign 接口，两边不产生循环依赖，接口变更也会因为 DTO 共用而第一时间在编译期暴露。

3. 最关键的一环：简历投递链路里的分布式事务与数据一致性

3.1 一次投递操作实际触达了哪些服务

这是整个项目里我最花心思的业务。用户在前端点“投递简历”时，并不仅仅在 application-service 里插一条记录。正常流程下，它要同时做四件事：创建投递记录、更新 job-service 中该职位的投递次数、给招聘者生成一条站内通知、如果该用户此前收藏过这个职位则把收藏状态置为已投递。

四个动作分属四个服务，任意一个失败都会造成数据对不上。我第一次设计时天真地直接在 application-service 的本地事务里用 Feign 依次调用另外三个服务，结果其中一个调用超时就会导致投递记录和通知状态不一致。

3.2 果断放弃强一致：本地消息表 + 事件通知

我没有使用重量级的 Seata，原因是演示环境下搭建成本高，而且这种业务场景可以接受短暂不一致。最终采用的是“本地消息表 + 事件通知”的最终一致性方案，思路如下。

application-service 在本地数据库中，除了投递主表，还有一张 outbox 事件表。用户投递时我在同一个本地事务里做两件事：插入投递记录，插入一条状态为“待发送”的事件记录。本地事务保证这两条数据要么都成功要么都失败，不会出现投递成功却没发通知的情况。业务主流程执行完后，一个定时任务轮询 outbox 表中“待发送”的数据，把事件投递到 RabbitMQ 的交换机，同时将本地状态改为“已发送”。

job-service、notification-service、user-service 各写一个消息监听器，分别消费对应的事件去更新投递次数、发送站内信、更新收藏状态。主流程不用等待这些结果，所以接口响应非常快；万一某些消费者处理失败，消息进入重试队列，重试一定次数后进入死信队列，由人工检查或定时补偿处理。

3.3 幂等消费与补偿机制：测试中反复出现的重复消息

引入消息之后就面临重复消费问题。RabbitMQ 的自动确认机制是消息一旦被收到就确认，如果消费者处理完业务逻辑之后崩溃了，消息不会重新投递；如果改成手动确认，又可能因为网络原因出现同一消息被投递两次。不管怎样，消费端必须做幂等。

我在每个消费者入口都先查一次本地业务表：job-service 里更新投递次数前，先根据事件内的 applicationId 查询“次数变更记录表”，如果已经存在就直接 ACK 并返回；notification-service 发送站内信前同样按 applicationId 查自己的“通知流水表”。配合数据库对该流水号建唯一索引，双保险避免重复通知。

测试时我故意对 job-service 的监听器做了一次线程阻断，重启服务后消息重新入队，结果同一事件被消费了两次，但计数表中的记录只插入了一条，投递次数只加了一次。这个演示动作很能说明“最终一致性 + 幂等设计”的价值，答辩时可以作为一个实际验证点讲给评委听。

3.4 投递状态机：把业务节点的每一步都变成可见数据

投递状态我设计成一个状态机，枚举值包括：待处理、已查看、已邀约、已录用、已拒绝、已取消。状态变化规则明确写在 application-service 里：只有高校招聘者端根据操作触发，用户端取消只在“待处理/已查看”阶段允许，录用必须从“已邀约”状态流转。

状态变更都会往 state_record 表写入一条流水，记录旧状态、新状态、操作人、时间。这个表的直接价值是：前端时间轴组件能展示简历从投递到录用每一步的轨迹，后台也能按状态速度统计每个职位的平均处理时长。其实这一步已经不单单是功能，还为论文里的数据分析部分提供了数据来源。我在论文里放了几张状态分布饼图和漏斗图，答辩时明显比纯页面截图更有说服力。

4. 网关、认证与前端联调：让用户感觉是“一个平台”的幕后工作

4.1 JWT 在网关的统一校验与用户上下文透传

微服务拆分之后，登录状态不能再像单体那样依赖服务端 Session，因为用户请求可能第一次到 application-service，第二次到 resume-service，两个服务没有共享的 Session 存储。我当时直接用 JWT + Redis 的组合：用户登录成功后，auth-service 签发 token 并下发；网关的全局过滤器拦截所有请求，校验签名和有效期，并根据用户请求头中的 token 解析出用户 id 和角色。

校验通过后，网关向转发目标请求中追加两个自定义请求头：X-User-Id和X-User-Role。各个业务服务不自己解析 token，只需要从请求头取用户 id 即可。这一步省去了每个服务引入 JWT 解析库的麻烦，也保证了密钥只在网关层维护。

服务间调用时有一个很容易忽略的点：Feign 默认不会自动传递请求头。application-service 调 job-service 时，如果目标接口需要用户 id，我就在 Feign 的请求拦截器里把当前的X-User-Id头转发过去。否则目标服务拿不到调用者身份，审计日志里所有跨服务操作都会变成未知用户。

4.2 文件服务独立部署与附件简历上传路径

简历附件、企业 logo、职位图片都是文件，数量不大但类型多。我没有把文件存在业务服务本地磁盘，而是单独上了 file-service + MinIO。理由很简单：业务服务可能部署多个实例，文件落本地会导致 A 实例上传的文件在 B 实例上访问不到；独立文件服务能把存储和业务彻底解耦。

前端上传的流程是：先请求 file-service 获取一个预签名上传地址，然后直接把文件 PUT 到 MinIO，业务提交时携带返回的文件 id 和 URL。预签名的好处是上传流量不经过后端服务，服务端只管理元数据，演示时用大附件也不会拖垮网关。

这里还藏着一个坑：如果不设置网关的请求体大小限制，上传会得到 413 错误。我在 gateway 的配置里对以/api/file开头的路由单独设置了更大的限制参数，同时 Nginx 层也同步调整，实测 10MB 以内的简历附件都能稳定传输。

4.3 前端联调阶段最耗时的三个真实问题

联调阶段有大量时间消耗在三个问题和业务无关，但体验差异巨大。第一个是跨域。前端开发服务器跑在 8080 端口，请求走网关的 8888 端口，浏览器跨域拦截非常频繁。最终我没有在每个服务上配 CORS，而是在网关层统一配置跨域规则，前端只需要代理到网关地址即可。

第二个是 token 过期处理。JWT 有效时长我设为 2 小时，超过后请求返回 401。前端 axios 拦截器里对所有 401 做了统一处理：清除本地 token 并跳转登录页。如果不做这个统一处理，用户会在某个子功能页面突然卡住，要手动清缓存才能恢复。

第三个是接口路径前缀。九个服务有九套 Controller 路径，前端如果直接访问会出现大量杂乱调用，我让所有请求统一走网关前缀路由，例如/api/job/**转发到 job-service，/api/resume/**转发到 resume-service。前端 axios 的基础地址只配一个网关地址，业务代码里写相对路径即可。

5. 搜索与推荐模块：让毕设从“普通 CRUD”升级为“有点东西”

5.1 搜索方案演进：从 SQL LIKE 到 Elasticsearch 分词检索

前期为了快速跑通功能，职位搜索用的是 MySQL 的LIKE '%关键词%'。数据量几百条时感受不到问题，当我用脚本生成五千条职位数据后，一次搜索要 200 毫秒以上，而且“Java工程师”搜不到“Java开发工程师”，因为关键词完全匹配不上。这暴露了关系型数据库做全文搜索的两个天花板：性能瓶颈和中文分词能力不足。

后期引入 Elasticsearch 后，我在 job-service 发布和更新职位时通过 RabbitMQ 发送索引事件，search-service 消费后调用文档 API 写入索引。索引字段包括职位标题、职位描述、技能标签、城市、薪资范围。使用前需要安装 ik 分词插件，中文分词才能把“Java开发工程师”正确切分为“Java/开发/工程师”。

搜索接口的返回策略是：由 search-service 负责解析用户输入、执行查询、拿到职位 id 集合和命中分数，再批量调用 job-service 查询职位详情。这样搜索结果页上展示的职位信息仍然来自业务数据库，不会出现索引字段和数据库字段不一致的问题。

5.2 推荐模块如何做到“能讲原理又不过度复杂”

推荐功能是很多毕设的加分点，但一上来就写协同过滤和 Word2Vec 会把项目周期拖垮。我的落地方案是“基于标签匹配 + 热度加权”的内容推荐：给每个职位打技能标签（Java、Python、前端、算法等），简历填写时也让用户选择期望技能标签，系统按标签重合度计算初始得分，再叠加职位热度、发布时间新鲜度和收藏量做加权排序。

比如一个同时选了 Java 和 Spring Boot 标签的求职者，系统会把包含这两个标签的职位命中分数抬高，再优先展示新鲜发布的职位。逻辑上它不复杂，但在演示效果上非常自然：注册时选择标签、完善简历、浏览首页推荐，每一步数据都能呼应上。答辩时可以真诚地说这是一个轻量级内容推荐，如果数据量上来会换成 Embedding 向量检索，表明你了解演进路线，而不是不懂。

这个模块我还做了一个人工干预规则：如果求职者最近五天内浏览过某类职位，浏览记录会进入 Redis 缓存，推荐接口会把同类职位的权重再提高 15%。规则虽然简单，但足以在演示时制造“越用越精准”的观感。

5.3 构造测试数据与演示效果：别等答辩时才发现搜不出东西

推荐和搜索都需要数据量才能看出效果。我用 Python 脚本生成了一批模拟职位数据，包括职位标题、描述、标签、薪资、城市、发布时间；另一个脚本生成模拟求职者数据。总共构造了约 6000 个职位和 300 个用户，发布的职位按时间均匀分布，以避开“首页最新职位十页都翻不完”的情况。

建议：测试数据脚本要和源码一起放，并写清楚怎么重新生成。我见过很多同学手动造一百条数据，答辩前换台机器发现数据库是空的，当场手忙尾乱，有了脚本就可以一键复活演示环境。

演示串场顺序我当时也排练过：先在管理后台发布一个新职位，然后在求职端搜索刚才的关键词，接着用有标签偏好的用户登录首页看推荐，最后体验投递链路并到招聘者端收到站内信。整条链路从一个动作触发多个服务协作的效果一目了然，比反复切页面翻列表更有说服力。

6. 开发完成之后：源码整理、演示环境部署与答辩准备

6.1 源码目录结构与 README 的工程规范

项目做完，源码整理是很多同学忽略但评委一定会看的部分。合理的目录结构应该让一个陌生人打开仓库就能看懂入口在哪。我的工程结构大致如下。

platform-root ├── api # Feign 接口与跨服务 DTO ├── common # 统一返回、异常处理、工具类 ├── gateway # 网关服务 ├── auth-service # 认证服务 ├── user-service # 用户服务 ├── company-service # 企业服务 ├── job-service # 职位服务 ├── resume-service # 简历服务 ├── application-service # 投递服务 ├── notification-service # 通知服务 ├── search-service # 搜索服务 ├── file-service # 文件服务 ├── frontend # 前端工程 ├── sql # 初始化数据库脚本 ├── script # 测试数据生成脚本 └── docs # 架构设计文档、接口文档

README 里我建议固定写五块内容：项目简介与功能清单、架构图、环境要求与版本号、本地启动步骤、默认测试账号。启动步骤要写具体到先启动 Nacos，再启动网关，再按依赖顺序启动业务服务；很多老师会根据 README 在本地实际操作验证，写清楚就是隐性加分项。

6.2 演示环境部署踩过的坑：端口、内存、时区、分词器

这部分是实战频率最高的地方，我把沿路填平的坑列成一个印象深刻的清单。

第一个是 Nacos 的端口。Nacos 2.x 默认客户端通信除了 8848 还需要 9848 端口。我曾在防火墙只放行 8848 的机器上部署，所有服务反复注册失败，排查半天才发现是 9848 被挡。Nacos 的配置里不对齐新旧端口，服务就一直连不上注册中心。

第二个是服务内存不够。九个服务全部默认 JVM 启动参数的话，演示笔记本 16G 内存也会吃紧。我给每个服务的启动脚本统一加了-Xmx128m -Xms64m，网关和 auth-service 略高，内存占用降到 3G 以内，多开几个服务也不会卡死。记得在文档里写明这是因为节省演示资源而故意调低的内存参数，避免被误以为代码有泄漏。

第三个是 MySQL 连接串的时区。服务第一次连接 MySQL 8.0 时报时区错误，连接串加上serverTimezone=Asia/Shanghai就解决。第四个是 Elasticsearch 启动后没装 ik 分词插件就导入索引，中文职位名被切成一个个单字，搜“大数据”只匹配到“大”和“数据”两个孤立词，结果排序完全错乱。分词器这件事我记得特别深，因为效果差异直观到截图对比时不用解释一个字。

6.3 如果重新做一遍，我会优先优化的四个环节

整套系统开发、测试、演示下来，有些地方我认为还能更好。如果一个同学要以这个项目为基础继续改进，我最建议从四个环节下手。

第一个是引入服务熔断和限流。目前跨服务调用只是做了超时设置，没有引入 Sentinel 做熔断降级。如果投递服务调用通知服务持续超时，调用线程很快被堆积，整个服务都可能拖挂。加上熔断之后，通知服务异常时快速失败并返回提示，用户体验会好很多。

第二个是核心链路考虑分布式事务组件。本地消息表方案可靠但开发成本高，事务消息和服务状态散落各服务，排查链路需要打开很多日志。后期如果面向生产，我会把简历投递这个短链路改用 Seata 的 AT 模式直连交易，代码会简化很大一部分。

第三个是前端先 Mock 再联调。我一开始边写前端边等后端接口，两边经常互相拖进度。重新做的话，前端先按接口文档 Mock 数据把页面全部跑通，后端就绪后再把 Mock 切到真实网关，联调效率至少能提升三分之一。

第四个是引入统一日志链路追踪。服务调用链横跨多个服务时，出问题是靠日志里的请求 ID 手动串联查找的，非常痛苦。重新做的话我会在网关生成 traceId 并顺势传递到所有下游服务，集中收集到 ELK 里，定位问题时间可以从分钟级降到秒级。

说到底，毕业设计折腾几个月，最后拿到的不是一句“答辩通过”，而是对“一个完整系统是如何被设计出来的”有了身体记忆。微服务架构是加分项，但真正让你站稳的永远是那些亲手踩过的坑、亲手补上的边界。这个项目里的配套源码已经把上述绝大部分内容按工程标准整理好了，后续开发、二次扩展都有现成的起点，这也是我最初想把它做成毕业设计的原因。