一、总体思路
远期目标是构建一个以 IM 为交互外壳、融合工作流、计划调度、文档增量同步的 EPC 协同平台。
近期只做第一阶段：PC 客户端登录 + 自动采集并上传资产指纹。
核心原则：
- 近期做薄：只实现 HTTP 短连接、请求-响应模式，不引入 Flare-core。
- 远期可扩展：用户体系、设备标识、认证方式、事件模型、Service 层全部为后续 IM、流程、计划、同步预留接口。
- 服务边界清晰：近期是单体 Axum 服务，远期可拆分为 HTTP API、IM 网关、工作流引擎、计划调度器、文档同步服务。
- 数据模型统一：用户、设备、事件三张核心表贯穿远期。
二、近期架构总览
～～～text
┌──────────────────────────────────────────────────────┐
│ PC 客户端 │
│ 登录模块 | 指纹采集模块 | 资产信息读取模块 | 上报模块 │
└───────────────────────┬──────────────────────────────┘
│ HTTPS / JSON
│ Authorization: Bearer
┌───────────────────────▼──────────────────────────────┐
│ Axum HTTP 服务（近期单体） │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────────┐ │
│ │ 认证模块 │ │ 设备指纹接收│ │ 资产信息存储 │ │
│ │ /api/login │ │ /api/device│ │ /api/assets │ │
│ └────────────┘ └────────────┘ └────────────────┘ │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────────┐ │
│ │ 设备管理 │ │ 审计日志 │ │ 配置管理 │ │
│ └────────────┘ └────────────┘ └────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ Service 业务层 │ │
│ │ 认证服务 | 设备服务 | 资产服务 | 事件服务 │ │
│ └────────────────────────────────────────────────┘ │
└───────────────────────┬──────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ SQLite │ │ 本地文件存储 │ │ tracing 日志 │
│ sqlx 连接池 │ │ 配置文件/备份 │ │ 审计输出 │
└──────────────┘ └──────────────┘ └──────────────┘
～～～
远期扩展时，在现有 Axum HTTP 服务旁并列增加：
～～～text
┌──────────────────────────────────────────────────────┐
│ 远期服务群 │
│ Flare-core IM 网关 | 工作流引擎 | 计划调度器 │
│ 文档增量同步服务 | 消息队列 Kafka | Redis 缓存 │
└───────────────────────┬──────────────────────────────┘
│ 共享用户、设备、事件模型
┌───────────────────────▼──────────────────────────────┐
│ PostgreSQL / MinIO / Redis / Kafka │
└──────────────────────────────────────────────────────┘
～～～
三、近期模块划分
1. 认证模块
- 接口：
POST /api/login - 职责：验证用户名/密码，签发 JWT。
- 技术：
axum提供路由；argon2做密码哈希；jsonwebtoken签发和校验 JWT；- JWT 中携带
user_id、device_id、exp。
- 中间件：基于 Axum Extractor 实现 JWT 提取器，保护后续接口。
2. 设备指纹接收模块
- 接口：
POST /api/device/report - 职责：接收 PC 客户端上报的设备指纹和资产信息。
- 技术：
serde/serde_json反序列化；- 设备指纹由客户端生成，服务器只做校验和去重；
- 单次上报数据量小，无需分块上传。
- 关键字段：
- 设备指纹：Machine GUID + CPU ID 的 SHA-256；
- 资产信息：23 列中实际可读取字段，如 CPU 型号、核数、频率、内存、磁盘、主板序列号、OS 版本等。
3. 资产信息存储模块
- 职责：持久化设备与资产数据，支持查询和版本记录。
- 技术：
- 起步用
SQLite + sqlx； - 连接池
SqlitePoolOptions； - 通过 sqlx 迁移管理表结构。
- 起步用
- 表设计：
users：用户账户；devices：设备注册与最后上线；asset_info：资产详情；audit_log：操作审计；events：预留统一事件表。
4. 设备管理模块
- 职责：
- 设备首次上报自动注册；
- 记录最后上线时间；
- 支持按用户、部门查询设备列表。
- 远期衔接：
device_id将成为 IM 消息发送者、流程参与者、计划执行者的标识。
5. 审计与日志模块
- 技术：
tracing+tracing-subscriber。 - 记录：
- 登录成功/失败；
- 设备上报；
- 资产变更；
- 配置下发。
- 审计日志写入
audit_log表，包含操作者、时间、类型、变更前后哈希。
6. 配置管理模块
- 技术：
config-rs或figment。 - 支持：
- 环境变量；
- 配置文件；
- 默认值分层。
- 管理服务器自身配置，也为远期客户端配置下发预留结构。
四、近期数据模型
～～～sql
– 用户表
CREATE TABLE users (
id INTEGER PRIMARY KEY AUTOINCREMENT,
username TEXT NOT NULL UNIQUE,
password_hash TEXT NOT NULL,
display_name TEXT,
department TEXT,
created_at TEXT NOT NULL DEFAULT (datetime(‘now’))
);
– 设备表
CREATE TABLE devices (
id INTEGER PRIMARY KEY AUTOINCREMENT,
user_id INTEGER NOT NULL,
device_fingerprint TEXT NOT NULL UNIQUE,
hostname TEXT,
last_seen_at TEXT,
created_at TEXT NOT NULL DEFAULT (datetime(‘now’)),
FOREIGN KEY (user_id) REFERENCES users(id)
);
– 资产信息表
CREATE TABLE asset_info (
id INTEGER PRIMARY KEY AUTOINCREMENT,
device_id INTEGER NOT NULL UNIQUE,
cpu_model TEXT,
cpu_physical_cores INTEGER,
cpu_logical_cores INTEGER,
cpu_frequency_mhz INTEGER,
memory_total_gb REAL,
disk_total_gb REAL,
disk_serial TEXT,
board_serial TEXT,
os_name TEXT,
os_version TEXT,
hostname TEXT,
reported_at TEXT NOT NULL DEFAULT (datetime(‘now’)),
FOREIGN KEY (device_id) REFERENCES devices(id)
);
– 审计日志表
CREATE TABLE audit_log (
id INTEGER PRIMARY KEY AUTOINCREMENT,
user_id INTEGER,
device_id INTEGER,
action TEXT NOT NULL,
detail TEXT,
created_at TEXT NOT NULL DEFAULT (datetime(‘now’))
);
– 预留统一事件表
CREATE TABLE events (
id INTEGER PRIMARY KEY AUTOINCREMENT,
event_type TEXT NOT NULL,
source_id TEXT,
target_id TEXT,
payload TEXT,
created_at TEXT NOT NULL DEFAULT (datetime(‘now’))
);
～～～
五、客户端采集与上报
- 采集库：
sysinfo：CPU、内存、磁盘、OS、主机名；device-fingerprint：Windows Machine GUID + CPU 特征，生成 SHA-256 指纹。
- 上报流程：
～～～text
PC 客户端 服务器
│ │
│── POST /api/login ──────────────────→│
│←── { token, user_id, device_id } ────│
│ │
│ 本地采集指纹 + 资产信息 │
│ │
│── POST /api/device/report ──────────→│
│ Authorization: Bearer │
│←── { status: “ok” } ─────────────────│
～～～
- 数据量：单次 JSON 通常几 KB，无需消息队列或后台任务。
六、近期接口清单
| 方法 | 路径 | 说明 | 认证 |
|---|---|---|---|
| POST | /api/login | 用户登录，签发 JWT | 否 |
| POST | /api/device/report | 上报设备指纹与资产 | 是 |
| GET | /api/devices/me | 查询当前用户设备列表 | 是 |
| GET | /api/assets/:device_id | 查询指定设备资产 | 是 |
| GET | /api/health | 健康检查 | 否 |
七、与远期目标的衔接
1. 用户与设备标识统一
users.id、devices.id、device_fingerprint从第一阶段就稳定。- 远期 Flare-core 的
HttpHookTokenValidator可直接调用现有认证接口。 - IM 消息中的
sender_id、device_id直接复用。
2. 认证体系复用
- 近期 JWT 由 Axum 签发。
- 远期 Flare-core IM 网关可校验同一套 JWT。
- 无需重建用户体系。
3. Service 层解耦
- 资产上报逻辑写在独立 Service 中。
- Axum Handler 只做参数提取和调用 Service。
- 远期 Flare-core 扩展点、工作流回调、计划任务可直接调用同一 Service。
4. 事件模型预留
events表可扩展为：- 聊天消息事件；
- 流程节点事件；
- 计划触发事件；
- 文档同步完成事件。
- 近期只写入资产上报事件，远期平滑扩展。
5. 存储演进
- 近期：SQLite + 本地文件。
- 远期：迁移到 PostgreSQL + MinIO + Redis + Kafka。
- sqlx 支持多数据库，迁移成本可控。
6. 服务拆分路径
～～～text
近期：
Axum HTTP 单体
├── 认证
├── 设备
├── 资产
└── 审计
远期：
Axum HTTP API Flare-core IM 网关
工作流引擎 计划调度器
文档增量同步服务 消息队列 / 缓存
～～～
八、部署形态
- 近期：
- 单个 Rust 二进制；
- SQLite 文件随服务部署；
- systemd 或 Docker 运行；
- 可选 Nginx/Caddy 反向代理并启用 HTTPS。
- 远期：
- HTTP API、IM 网关、工作流、调度器、同步服务独立部署；
- 共享 PostgreSQL、Redis、MinIO、Kafka；
- 按需水平扩展。
九、近期不启用 Flare-core 的理由
- 当前是 HTTP 短连接，不需要 WebSocket/QUIC 长连接。
- Flare-core 的价值在 IM 阶段：心跳、重连、消息路由、扩展点。
- 过早引入会增加调试成本和框架锁定风险。
- 远期在文字聊天开始时，将 Flare-core 作为独立 IM 网关引入，与现有 Axum 服务并列。
十、演进路线
- 第一阶段：PC 登录 + 资产指纹上报 + SQLite 存储。
- 第二阶段：设备管理、配置下发、审计完善。
- 第三阶段：引入 Flare-core，实现文字聊天与实时通知。
- 第四阶段：接入工作流引擎，流程即特殊聊天。
- 第五阶段：计划调度器驱动多流程定时发生。
- 第六阶段：文档增量同步后台管道，小时级同步。
十一、关键注意点
- 不要在第一阶段引入 Flare-core。
- 认证、用户、设备、事件模型要一次设计好。
- Service 层与 Axum 解耦，为远期扩展点复用。
- 数据库从 SQLite 起步，但 SQL 尽量保持 PostgreSQL 兼容。
- 所有上报行为写入审计日志，满足企业资产追溯要求。
