10 KiB
10 KiB
tags, create time
| tags | create time | ||||||
|---|---|---|---|---|---|---|---|
|
2026-05-09 13:25 |
大作业·思维导图 — 双端 gRPC HR 系统
概述
本文档以思维导图和架构图表的形式,梳理全栈大作业的核心知识点与任务拆解。涵盖技术架构、前后端功能、数据流转、关键考点四大模块,帮助你快速建立全局认知并定位开发重点。
[!tip] 如何使用本笔记 建议先看「整体知识体系」建立全局观,再逐层深入每个分支的细节图表。遇到流程图时,思考:如果我是请求发起方,每一步数据会经历什么?
整体知识体系
mindmap
root((HR招聘系统<br/>全栈大作业))
技术架构
两层服务
Web网关(Gin)
Logic业务(gRPC)
通信协议:gRPC/Protobuf
前端双端
HR管理端
候选人用户端
数据存储
MySQL:结构化数据
私有OSS:简历文件
AI能力
Eino框架
Chat对话组件
上下文持久化
核心功能
HR管理端
JWT登录鉴权
岗位CRUD(本人范围)
投递候选人查看
AI智能对话
自然语言转数据查询
历史记录留存
候选人用户端
游客免登录浏览
注册登录(强校验)
结构化档案编辑
PDF/DOC/DOCX简历上传
签名URL直传OSS
关键考点
gRPC分层调用
禁止同工程直连
只允许跨服务调用
OSS签名URL
不落地缓存
严格格式白名单
Eino基础对接
不能裸写HTTP
数据到上下文到模型到回答
权限隔离
JWT统一签发
角色精准管控
提交要求
源码仓库
final_homework根目录
api/db/README文档齐全
演示视频
全链路实操录制
口述两大核心技术点
禁止剪辑拼接
拓展方案
answer.md设计思路
OpenClaw/Hermes集成
[!note] 图表阅读提示 这是整份作业的"导航图"——所有分支都来自项目要求文档。每个主分支下的二级节点对应一个开发阶段,三级节点是具体实现细节。
一、技术架构详解
1.1 两层微服务架构
[!question] 为什么不用传统单体架构? 如果所有逻辑写在一个 Gin 工程里,代码耦合严重、难以扩展。拆分成 Web + Logic 两层,职责清晰,也贴合真实生产环境的微服务实践。
flowchart LR
subgraph Frontend ["前端层"]
HR["HR管理端,独立路由页面"]
User["候选人用户端,独立路由页面"]
end
subgraph WebLayer ["Web网关层,Gin服务 web-gin-service"]
Route["路由分发"]
CORS["全局跨域处理"]
Auth["JWT统一鉴权"]
Validate["参数合法性校验"]
end
subgraph LogicLayer ["Logic业务层,gRPC服务 logic-grpc-service"]
UserMgmt["用户权限管控"]
JobBiz["岗位业务处理"]
OSSSign["OSS签名调度"]
DataRW["MySQL数据读写"]
EinoAI["Eino AI对话封装"]
end
subgraph Storage ["存储层"]
MySQL[(MySQL数据库)]
OSS[(私有OSS Bucket)]
end
HR -->|"HTTP REST"| WebLayer
User -->|"HTTP REST"| WebLayer
WebLayer -.->|"gRPC远程调用"| LogicLayer
LogicLayer --> MySQL
LogicLayer --> OSS
EinoAI -->|"查询MySQL,推送大模型,返回回答"| LogicLayer
style Frontend fill:#e1f5fe
style WebLayer fill:#fff3e0
style LogicLayer fill:#e8f5e9
style Storage fill:#fce4ec
1.2 请求处理全流程
[!example] 思考题 从候选人点击"投递简历"到文件安全存到 OSS,整个链路经过哪些组件?每个环节做了什么校验?尝试在脑中走一遍流程,这就是考试时需要口述的内容。
sequenceDiagram
participant U as U_CandidateFrontend
participant W as W_WebService
participant L as L_LogicService
participant M as M_MySQL
participant O as O_OSS
U->>W: "POST /api/profile,提交结构化档案"
W->>W: JWT校验加参数合法性校验
W->>L: gRPC UpdateProfile request
L->>M: UPDATE user_profile SET ...
M-->>L: 操作结果
L-->>W: RPC response
W-->>U: code 200 msg success
Note over W,O: 简历上传流程
U->>W: "POST /api/resume/upload,PDF DOC或DOCX"
W->>W: JWT校验加后缀加文件头白名单
W->>L: gRPC GenOssSign key ext
L-->>W: UploadURL DownloadURL Expiry
W-->>U: 签名URL信息
U->>O: PUT直接上传到OSS,不走服务端
O-->>U: 上传完成,本地零缓存
1.3 AI 对话链路
[!warning] 底线要求 必须使用 Eino 框架,禁止裸写 HTTP 接口直连大模型。Eino 只是轻量级封装,主要做两件事:拼接业务上下文 和 调用大模型。
flowchart TD
A["HR在AI窗口输入自然语言提问"] --> B{后端解析意图}
B --> C["提取查询条件,如岗位ID或筛选标签"]
C --> D["查询MySQL获取真实数据"]
D --> E["拼接标准模板"]
E --> F["Prompt = 业务上下文 + 原始问题"]
F --> G["Eino Chat推送大模型"]
G --> H{大模型返回}
H --> I["规范化自然语言回答"]
I --> J["存入对话历史表,绑定HR账号ID"]
J --> K["返回给前端展示"]
style A fill:#e1f5fe
style D fill:#fff3e0
style G fill:#e8f5e9
style I fill:#ce93d8
style J fill:#ffcdd2
二、前后端功能矩阵
2.1 HR 管理端
stateDiagram-v2
[*] --> Login: 游客状态
Login --> Dashboard: JWT校验通过
Dashboard --> JobCreate: 新建岗位
Dashboard --> JobEdit: 编辑下架个人岗位
Dashboard --> CandidateList: 查看岗位下候选人
CandidateList --> ProfileView: 查看结构化档案
ProfileView --> ResumeView: 查看OSS简历链接
Dashboard --> AIChat: 打开AI对话窗口
AIChat --> AIQuery: 自然语言提问
AIQuery --> AIResult: 返回统计回答
AIResult --> AIChat: 写入历史
state 权限边界 {
Dashboard: 只能操作自己发布的岗位
JobCreate: 发布时关联当前HR ID
JobEdit: 校验岗位创建者等于当前用户
}
2.2 候选人用户端
stateDiagram-v2
[*] --> BrowseJobs: 游客免登录浏览
BrowseJobs --> Register: 看到投递按钮才需登录
Register --> Login: 完成注册
Login --> ProfileSetup: 首次登录引导完善档案
ProfileSetup --> ResumeUpload: 上传合规简历
ResumeUpload --> ApplyJob: 满足条件才能投递
state 投递校验 {
ProfileSetup: 必填 姓名电话学历院校经历技能
ResumeUpload: 仅PDF DOC DOCX三种格式
ApplyJob: 未完善资料或无简历 拦截弹窗
}
ApplyJob --> [*]: 投递成功
BrowseJobs --> ApplyJob: 未登录直接投递 跳转登录
三、数据结构概览
3.1 核心实体关系
erDiagram
USER ||--o{ JOB : "发布"
JOB ||--o{ APPLICATION : "收到"
USER ||--o{ PROFILE : "拥有"
USER ||--o{ CHAT_RECORD : "发起"
PROFILE ||--|| RESUME : "包含"
USER {
uint64 id "PK"
string username "UK"
string password_hash
string role "hr / candidate"
datetime created_at
}
JOB {
uint64 id "PK"
uint64 creator_id "FK"
string title
string description
string status "on / off"
datetime created_at
}
APPLICATION {
uint64 id "PK"
uint64 job_id "FK"
uint64 candidate_id "FK"
datetime applied_at
}
PROFILE {
uint64 id "PK"
uint64 user_id "UK"
string name
string phone
string education
string school
text experience
string skills
}
CHAT_RECORD {
uint64 id "PK"
uint64 hr_id "FK"
text question
text ai_reply
datetime created_at
}
3.2 技术选型清单
| 层级 | 技术 | 用途 |
|---|---|---|
| 前端 × 2 | 任意(Vue/React均可) | HR管理端 + 候选人用户端 |
| Web 服务 | Go + Gin | HTTP 网关:路由、鉴权、校验 |
| 通信协议 | Protocol Buffers + gRPC | Web ↔ Logic 唯一通信方式 |
| Logic 服务 | Go + gRPC server | 业务逻辑:权限、岗位、OSS、AI、MySQL |
| 数据库 | MySQL | 用户、岗位、投递、档案、对话历史 |
| 对象存储 | 私有 OSS Bucket | 简历文件签名 URL 直传 |
| AI 框架 | Eino(基础 Chat) | 自然语言问答 + 上下文持久化 |
| 认证 | JWT | 双角色统一令牌签发与校验 |
四、关键考点速查
[!danger] 验收红线(必考) 以下条目是评分的关键依据,遗漏任何一项可能导致扣分:
- gRPC 分层:Web 与 Logic 之间必须是
gRPC远程调用,同工程函数直连 = 不符合架构要求 - OSS 签名 URL:文件不落地本地,客户端直传 OSS;严格后缀 + 文件头校验
- Eino 框架调用:不可裸写 HTTP 请求连接大模型,必须通过 Eino 封装
- 权限隔离:JWT 统一签发,HR 只能管理自己发布的岗位,候选人未完善资料不可投递
- AI 对话持久化:每条问答对入 MySQL,刷新页面自动加载历史上下文
五、提交 Checklist
[!example] 自查清单 在提交前逐项勾选,确保没有遗漏:
- 源码位于
final_homework/目录下 - 四个子目录完整:
hr-frontend、user-frontend、web-gin-service、logic-grpc-service api.md— 接口说明文档db.md— 数据库设计文档README.md— 启动部署指南 + 项目亮点- 演示视频:原生实操 + 口述两大核心技术点
- 视频命名:
姓名_学号_全栈大作业.mp4 answer.md— 拓展设计方案(OpenClaw/Hermes 集成思路).env/ config 文件中 key 等敏感信息已忽略提交
关联笔记
- 大作业项目要求 — 作业完整需求文档