JobRadar 架构设计

设计原则

JobRadar 第一阶段采用模块化单体架构。Django 负责业务模型、管理后台、自定义页面和任务入口；耗时的浏览器采集、企业信息补全和 AI 分析由异步 Worker 执行。各业务模块在代码层隔离，但共享 PostgreSQL 数据库，避免在个人项目初期引入微服务通信和部署成本。

目标架构

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、组织机构、岗位角色和审批授权模型。
默认由管理员创建账号并关闭公开注册；开放注册属于后续独立功能。

即使初期实际只有一个账号，数据模型仍保留用户归属，避免未来增加账号时重新改造所有核心表。

处理链路

用户配置目标网站、关键词、地区、硬性条件和评分权重。
调度器创建采集批次，站点适配器获取并保存原始岗位记录。
标准化模块统一岗位、公司、薪资、经验和地点字段。
去重模块根据来源岗位编号、内容指纹和标准化字段建立岗位关系。
筛选模块先执行可确定判断的硬规则，并记录通过、淘汰或待确认原因。
企业补全模块查询可信来源，保存企业主体、性质、证据和置信度。
AI 模块对通过初筛的岗位进行技能、职责、风险和匹配度分析。
评分模块根据固定公式生成最终分数，并保存评分配置版本。
用户在岗位工作台中收藏、忽略或更新投递状态。

模块边界

采集模块

优先使用网站允许访问的接口或普通 HTTP 请求，动态页面才使用 Playwright。
每个网站独立实现适配器，并输出统一的原始岗位数据对象。
负责限流、超时、重试和采集状态，不负责岗位评分。
页面变更导致解析失败时，应保留错误证据并暂停对应适配器。

标准化与去重模块

原始数据只追加或生成新版本，不被标准化结果覆盖。
同站唯一键建议为“站点编号 + 来源岗位编号”。
跨站重复判断结合公司标准名、岗位名、地点、薪资和内容指纹。
跨站重复岗位建立关联，不直接物理删除来源记录。

企业补全模块

按企业标准名称或统一社会信用代码识别主体。
结论至少保存来源地址、证据摘要、获取时间和置信度。
多来源冲突、主体不明确或置信度不足时进入人工复核。
人工确认结果优先级高于自动判断，但不得删除历史证据。

AI 分析模块

输入为标准化岗位、个人画像和必要证据，不直接使用未经清洗的整页内容。
输出必须通过结构化模型校验，不接受无法解析的自由文本作为业务结果。
记录模型名称、提示词版本、输入摘要和分析时间。
相同内容与同一分析版本应优先复用缓存结果。

评分模块

硬性条件和最终加权公式由确定性代码执行。
每个评分维度保留原始分、权重、加权分和判断依据。
权重或规则变化时创建新版本，历史结果仍可回溯。
风险扣分与正向评分分开保存，避免结果无法解释。

数据边界

第一阶段核心实体包括：

招聘网站及站点配置
搜索任务与采集批次
原始岗位记录与标准化岗位
企业主体与企业证据
筛选规则、规则版本和筛选结果
评分配置、评分结果和 AI 分析记录
收藏、忽略、投递和面试状态
任务日志与人工复核记录

具体字段应在首个目标网站和筛选规则明确后再落地，避免提前设计大量无法验证的字段。

部署边界

系统目标部署到公网。目标运行单元为：

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 来源、登录限流、密钥注入、日志审计和数据库备份。

5.2 KiB Raw Permalink Blame History Unescape Escape