admin/getDomain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

first

Browse Source
This commit is contained in:
Your Name
2026-04-16 21:35:47 +08:00
parent ff32aa50bf
commit ebf632e651
86 changed files with 14097 additions and 585 deletions
Download Patch File Download Diff File Expand all files Collapse all files

215
docs/13_domainCheck_Linux测试服交接文档.md
View File

@@ -23,17 +23,21 @@
- 交付包、验包、SHA256、最新交付指针已完成
- Linux 测试服数据库初始化问题已定位并修复
- Linux 测试服在“临时 API 进程 + 已初始化数据库”的模式下，`smoke test` 已通过
- Linux 测试服已经完成正式 `systemd` 服务化联调，`domaincheck-api` 与 `domaincheck-worker` 均已拉起
- 正式服务态下 `/health` 已确认 `worker_mode = linux-systemd`
- 正式服务态 `smoke test` 已通过
- 已补做一轮真实导入回归，确认“导入域名 -> 写入 `domains` -> 自动创建 `detect_tasks`”链路正常
### 2. 未完全完成
- Linux 测试服当前还不是最终正式部署形态
- 这次通过的是“临时启动 API 进程”的验证，不是正式 `systemd` 服务托管态
- `worker_mode` 当前仍表现为 `windows-local`
- `domaincheck-api` / `domaincheck-worker` 还没有按正式生产口径落成 Linux `systemd` 服务闭环
- Linux 测试服虽然已完成正式服务化联调，但仍属于“测试服验证通过”，不等于生产观察期已经完成
- Worker 当前通过 `QT_QPA_PLATFORM=offscreen` 运行，属于“无头 Qt 托管态”，后续仍建议继续观察稳定性
- 真实业务网络环境下的长时检测、代理池质量、Wayback 首次全量列表耗时，还需要继续压测和观察
- 当前数据库里仅导入了少量回归样本，不代表真实大批量数据已完成验收
一句话结论：
> 功能和数据库问题已经打通；正式 Linux 上线态还差最后一段服务化收口。
> 功能、数据库和正式服务化都已经打通；后续工作转入真实业务回归、稳定性观察和上线前优化。
## 三、这次 Linux 测试服已验证通过的内容
@@ -79,7 +83,7 @@ python init_database.py
- 库结构已正常
- 只是当前还没有正式业务数据导入
### 3. smoke test 已通过
### 3. 临时验证态 smoke test 已通过
新版 `smoke test` 结果：
@@ -96,7 +100,7 @@ python init_database.py
- Redis 连接可用
- 缺表问题已解除
### 4. 诊断包已导出
### 4. 临时验证态诊断包已导出
本次测试服诊断产物：
@@ -105,36 +109,95 @@ python init_database.py
可用于后续继续排障或归档。
## 四、当前测试服不是正式上线态的原因
## 四、正式服务态已补验证通过
虽然 `smoke test` 已通过，但当前仍不是正式上线态，原因如下：
在后续继续收口过程中，已经额外完成了正式 `systemd` 服务态验证，结果如下：
### 1. 当前通过的是临时 API 进程验证
### 1. 正式服务已落地
本次验证是通过“当前工作区里手动启动的 API 进程”完成的，不是通过正式服务方式完成的。
### 2. worker_mode 仍不是 Linux 正式模式
当前表现仍是：
- `worker_mode = windows-local`
这意味着：
- 运行中心、配置项、控制逻辑还没有真正切到 Linux 正式托管模式
- 当前仍属于“测试验证态”
### 3. systemd 服务还未正式落地闭环
还没有最终确认以下两项处于正式可用状态：
已安装并启用：
- `domaincheck-api`
- `domaincheck-worker`
也就是说：
并已确认两者为 `active (running)`。
- 现在能证明代码跑得通
- 但还没有证明“服务化部署后也稳定可用”
### 2. 运行模式已切换成功
正式服务态下接口返回已确认：
- `/health` 中 `worker_mode = linux-systemd`
- `/api/v1/runtime/preflight` 中 `worker_mode = linux-systemd`
- `/api/v1/runtime/status` 中：
- `api.service_name = domaincheck-api`
- `worker.service_name = domaincheck-worker`
- `worker.running = true`
- `process_count = 1`
### 3. 正式服务态 smoke test 已通过
正式服务态下再次执行：
```bash
python smoke_test.py --base-url http://127.0.0.1:8100
```
结果仍为：
```json
{
"ok": true
}
```
### 4. 正式服务态诊断包已导出
正式服务态诊断产物：
- 目录：`/opt/domaincheck/diagnostics/diag_20260416_134923`
- 压缩包：`/opt/domaincheck/diagnostics/diag_20260416_134923.tar.gz`
### 5. 正式服务态中已确认的兼容与权限问题
本轮继续联调还确认并处理了两类真实 Linux 问题：
- `detect/jucha.py`、`detect/juming.py` 中存在 Windows 专属 `subprocess.STARTUPINFO()` 写法，已改为跨平台兼容处理
- 若曾以 `root` 手工运行过 API/Worker，可能会留下 `root` 所有者的运行文件，导致正式 `systemd` 服务用户无法写入
其中已实际踩到并修复的权限点包括：
- `domain-api/runtime/` 目录权限
- `domainCheck/detect_worker.log` 文件权限
这个问题的表现是：
- `/api/v1/imports/upload` 因无法创建 `runtime/imports/` 返回 `500`
- Worker 因无法写 `detect_worker.log` 进入循环重启
### 6. 运行中心控制链路已补通
本轮继续验证后，运行中心里的 Linux 控制动作也已经打通：
- Worker `start` / `stop` 已可通过 `sudo -n systemctl` 正常执行
- API 自重启已改为 `systemctl --no-block restart domaincheck-api`
这样处理后，`systemd` 会异步接管重启流程，接口可以先返回成功，避免出现“服务其实已经重启成功，但调用方因为等待自身停机而收到 `500`”的误导性现象。
### 7. 服务态日志噪音已进一步收敛
本轮还额外处理了两类不会阻断功能、但会影响正式服务观察体验的日志噪音：
- Redis 配置订阅从阻塞 `listen()` 改为短轮询 `get_message()`，Linux 空闲时不再每分钟刷 `Redis订阅失败: Timeout reading from socket`
- `offscreen` 模式下去掉 Qt 不支持的按钮样式属性，Worker 启动时不再刷 `Unknown property transition/transform/box-shadow`
- Worker 图标资源定位改为优先使用 `detect_worker.py` 同目录，Linux 服务态不再误报 `/opt/new_logo.svg`、`/opt/favicon2.ico` 不存在
- 付费检测器改为按需初始化，默认关闭 `detect_jucha` / `detect_juziseo` 时，不再在启动阶段报 cookie 文件缺失
- Redis 未加载 Bloom 模块时保留为降级说明，继续使用普通缓存，不再作为故障级告警处理
这几项修改的结果是：
- `domaincheck-worker` 仍保持 `active (running)`
- `/api/v1/runtime/status` 中 `worker.running = true`
- 正式测试服日志更适合持续观察和上线前留档
## 五、这次联调后已经明确固化的部署规则
@@ -169,6 +232,7 @@ python init_database.py
- `domain-web` 主要页面已完成
- `domain-api` 主要接口已完成
- 运行中心、系统设置、导入、导出、日志诊断、自检、自测均已具备
- 正式 `systemd` 服务态下 `/health`、`/runtime/preflight`、`/runtime/status`、`smoke test` 已全部通过
### 3. 交付层
@@ -185,56 +249,23 @@ python init_database.py
- Linux 联调输入清单已完成
- 导航索引文档已完成
### 5. 真实业务回归层
- 已通过 API 上传样本 TXT
- 已确认导入结果：
- 总数 `5`
- 有效 `3`
- 新增 `3`
- 无效 `2`
- 已确认 `domains_total = 3`
- 已确认 `detect_tasks_total = 3`
- 已确认导入后会自动创建 `detect_tasks`
## 七、当前未完成项清单
以下内容仍属于“后续要做”：
### 1. 正式 Linux 目录落地
需要确认正式部署目录结构为：
```text
/opt/domaincheck
├── domainCheck
├── domain-api
├── domain-web
```
如果测试服当前目录不是这一套，需要统一。
### 2. 正式 systemd 服务化
需要把以下服务真正落好并验证：
- `domaincheck-api`
- `domaincheck-worker`
至少要完成：
- 安装 service 文件
- `daemon-reload`
- `enable`
- `start`
- `status`
- `journalctl`
### 3. worker_mode 切换为 linux-systemd
需要确认：
- Web 系统设置中运行模式改为 `linux-systemd`
- API `/health` 或运行中心能正确反映：
- `worker_mode = linux-systemd`
### 4. 正式服务态再跑一次 smoke test
不是临时 API 进程跑通就结束，还要在正式服务态下再跑一次：
```bash
python smoke_test.py --base-url http://127.0.0.1:8100
```
### 5. Worker 真实联动验证
### 1. Worker 真实联动验证
还应继续确认：
@@ -243,17 +274,26 @@ python smoke_test.py --base-url http://127.0.0.1:8100
- 检测控制页读取是否正常
- `detect_worker.log` 是否正常写入
### 6. 导入真实数据后的业务复测
### 2. 导入更多真实数据后的业务复测
当前 `domains_count = 0`，说明库表正常，但业务数据还没开始导入。
当前已经完成一轮小样本回归，不再是空库空表态。
后续应至少补一次真实业务复测：
- 导入域名
- 查看 `domains` 增长
- 查看 `detect_tasks` 生成
- 导入更接近真实业务规模的域名样本
- 查看 `domains` 持续增长
- 查看 `detect_tasks` 持续生成
- 再验证筛选与导出
### 3. 长时间运行与代理池观察
仍建议继续验证：
- Worker 长时运行稳定性
- Redis 订阅超时后的重连是否持续稳定
- 国内网络环境下代理池真实可用率
- Wayback 首次全量快照列表的耗时表现
## 八、后续继续收口的推荐顺序
建议 Linux 上的下一位接手人严格按下面顺序执行。
@@ -291,6 +331,11 @@ order by tablename;
- `domain-api/deploy/systemd/domain-api.service`
- `domain-api/deploy/systemd/domain-worker.service`
如果此前用 `root` 手工跑过 API 或 Worker，建议先确认下面这些路径对正式服务用户可写：
- `domain-api/runtime/`
- `domainCheck/detect_worker.log`
### 第四步：启动正式服务
```bash
@@ -318,6 +363,16 @@ curl http://127.0.0.1:8100/api/v1/runtime/preflight
curl http://127.0.0.1:8100/api/v1/runtime/status
```
### 第七步：做一轮导入回归
至少验证：
- `/api/v1/imports/upload`
- `/api/v1/imports/tasks`
- `/api/v1/imports/summary`
- `domains` 增长
- `detect_tasks` 自动创建
目标是确认：
- `status = ok`