docs(project): 完善项目说明与实施规划
This commit is contained in:
116
docs/architecture.md
Normal file
116
docs/architecture.md
Normal file
@@ -0,0 +1,116 @@
|
||||
# JobRadar 架构设计
|
||||
|
||||
## 设计原则
|
||||
|
||||
JobRadar 第一阶段采用模块化单体架构。Django 负责业务模型、管理后台、自定义页面和任务入口;耗时的浏览器采集、企业信息补全和 AI 分析由异步 Worker 执行。各业务模块在代码层隔离,但共享 PostgreSQL 数据库,避免在个人项目初期引入微服务通信和部署成本。
|
||||
|
||||
## 目标架构
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
USER["公网用户"] --> PROXY["Nginx / Caddy 与 HTTPS"]
|
||||
PROXY --> WEB["Django 登录、Admin 与岗位工作台"]
|
||||
WEB --> APP["Django 业务应用"]
|
||||
APP --> DB[("PostgreSQL")]
|
||||
APP --> REDIS["Redis"]
|
||||
BEAT["Celery Beat"] --> REDIS
|
||||
REDIS --> WORKER["Celery Worker"]
|
||||
WORKER --> COLLECT["Playwright / HTTPX 采集"]
|
||||
WORKER --> ENRICH["企业信息联网补全"]
|
||||
WORKER --> AI["LLM 结构化分析"]
|
||||
COLLECT --> DB
|
||||
ENRICH --> DB
|
||||
AI --> DB
|
||||
```
|
||||
|
||||
## 用户与权限边界
|
||||
|
||||
系统支持公网访问,第一阶段采用简化的用户体系:
|
||||
|
||||
- 直接使用 Django 内置用户、认证、Session 和密码管理能力。
|
||||
- 普通用户拥有个人画像、搜索任务、筛选规则、评分配置和岗位操作记录。
|
||||
- 所有用户私有业务表通过所属用户字段隔离,服务层和查询层统一限制当前用户的数据范围。
|
||||
- 管理员通过 Django Admin 维护全局站点配置、采集状态和异常数据。
|
||||
- 第一阶段仅区分普通用户与管理员,不建设 RBAC、组织机构、岗位角色和审批授权模型。
|
||||
- 默认由管理员创建账号并关闭公开注册;开放注册属于后续独立功能。
|
||||
|
||||
即使初期实际只有一个账号,数据模型仍保留用户归属,避免未来增加账号时重新改造所有核心表。
|
||||
|
||||
## 处理链路
|
||||
|
||||
1. 用户配置目标网站、关键词、地区、硬性条件和评分权重。
|
||||
2. 调度器创建采集批次,站点适配器获取并保存原始岗位记录。
|
||||
3. 标准化模块统一岗位、公司、薪资、经验和地点字段。
|
||||
4. 去重模块根据来源岗位编号、内容指纹和标准化字段建立岗位关系。
|
||||
5. 筛选模块先执行可确定判断的硬规则,并记录通过、淘汰或待确认原因。
|
||||
6. 企业补全模块查询可信来源,保存企业主体、性质、证据和置信度。
|
||||
7. AI 模块对通过初筛的岗位进行技能、职责、风险和匹配度分析。
|
||||
8. 评分模块根据固定公式生成最终分数,并保存评分配置版本。
|
||||
9. 用户在岗位工作台中收藏、忽略或更新投递状态。
|
||||
|
||||
## 模块边界
|
||||
|
||||
### 采集模块
|
||||
|
||||
- 优先使用网站允许访问的接口或普通 HTTP 请求,动态页面才使用 Playwright。
|
||||
- 每个网站独立实现适配器,并输出统一的原始岗位数据对象。
|
||||
- 负责限流、超时、重试和采集状态,不负责岗位评分。
|
||||
- 页面变更导致解析失败时,应保留错误证据并暂停对应适配器。
|
||||
|
||||
### 标准化与去重模块
|
||||
|
||||
- 原始数据只追加或生成新版本,不被标准化结果覆盖。
|
||||
- 同站唯一键建议为“站点编号 + 来源岗位编号”。
|
||||
- 跨站重复判断结合公司标准名、岗位名、地点、薪资和内容指纹。
|
||||
- 跨站重复岗位建立关联,不直接物理删除来源记录。
|
||||
|
||||
### 企业补全模块
|
||||
|
||||
- 按企业标准名称或统一社会信用代码识别主体。
|
||||
- 结论至少保存来源地址、证据摘要、获取时间和置信度。
|
||||
- 多来源冲突、主体不明确或置信度不足时进入人工复核。
|
||||
- 人工确认结果优先级高于自动判断,但不得删除历史证据。
|
||||
|
||||
### AI 分析模块
|
||||
|
||||
- 输入为标准化岗位、个人画像和必要证据,不直接使用未经清洗的整页内容。
|
||||
- 输出必须通过结构化模型校验,不接受无法解析的自由文本作为业务结果。
|
||||
- 记录模型名称、提示词版本、输入摘要和分析时间。
|
||||
- 相同内容与同一分析版本应优先复用缓存结果。
|
||||
|
||||
### 评分模块
|
||||
|
||||
- 硬性条件和最终加权公式由确定性代码执行。
|
||||
- 每个评分维度保留原始分、权重、加权分和判断依据。
|
||||
- 权重或规则变化时创建新版本,历史结果仍可回溯。
|
||||
- 风险扣分与正向评分分开保存,避免结果无法解释。
|
||||
|
||||
## 数据边界
|
||||
|
||||
第一阶段核心实体包括:
|
||||
|
||||
- 招聘网站及站点配置
|
||||
- 搜索任务与采集批次
|
||||
- 原始岗位记录与标准化岗位
|
||||
- 企业主体与企业证据
|
||||
- 筛选规则、规则版本和筛选结果
|
||||
- 评分配置、评分结果和 AI 分析记录
|
||||
- 收藏、忽略、投递和面试状态
|
||||
- 任务日志与人工复核记录
|
||||
|
||||
具体字段应在首个目标网站和筛选规则明确后再落地,避免提前设计大量无法验证的字段。
|
||||
|
||||
## 部署边界
|
||||
|
||||
系统目标部署到公网。目标运行单元为:
|
||||
|
||||
```text
|
||||
web Django Web 服务
|
||||
worker Celery Worker
|
||||
beat Celery 定时调度
|
||||
postgres PostgreSQL
|
||||
redis Redis
|
||||
proxy Nginx 或 Caddy 反向代理及 HTTPS 终止
|
||||
```
|
||||
|
||||
公网只开放反向代理的 HTTP/HTTPS 端口。Django、PostgreSQL 和 Redis 位于容器私有网络;Django 使用生产级 WSGI/ASGI 服务运行,不使用开发服务器对外提供服务。部署时必须配置 HTTPS、安全 Cookie、`ALLOWED_HOSTS`、可信 CSRF 来源、登录限流、密钥注入、日志审计和数据库备份。
|
||||
Reference in New Issue
Block a user