405 lines
11 KiB
Markdown
405 lines
11 KiB
Markdown
# domainCheck 国内外联调交接说明
|
||
|
||
## 1. 当前目标
|
||
|
||
本次联调的目标是把现有架构整理成下面这条可运行链路：
|
||
|
||
- 海外机保留主数据与后台展示
|
||
- 海外机把待检测任务批次下发到国内 controller
|
||
- 国内 controller 落本地任务与本地 `domains`
|
||
- 国内 worker 执行检测
|
||
- 国内运行时状态、检测结果再同步回海外
|
||
- 海外后台统一查看总体进度与结果
|
||
|
||
当前主链路已经基本跑通，剩下的是：
|
||
|
||
- 海外 cluster/readiness 视图的最后收尾
|
||
- 文档固化
|
||
- 最好增加“国内日志回调到海外”的调试手段，减少人工复制日志
|
||
|
||
---
|
||
|
||
## 2. 当前已确认跑通的链路
|
||
|
||
### 2.1 海外 API 正常
|
||
|
||
海外 API 已经具备：
|
||
|
||
- `/health`
|
||
- `/api/v1/runtime/cluster`
|
||
- `/api/v1/runtime/readiness`
|
||
- `/api/v1/runtime/preflight`
|
||
- `/api/v1/runtime/sync-summary`
|
||
|
||
并且 nginx 对 `/api/v1/runtime/*` 的转发已经修好。
|
||
|
||
### 2.2 国内 controller 正常
|
||
|
||
国内 controller 这边已经确认：
|
||
|
||
- `domaincheck-api` 正常运行
|
||
- `domaincheck-sync-agent` 正常运行
|
||
- 本地 PostgreSQL 可用
|
||
- 本地 Redis 可用
|
||
- `detect/start` 不再受 `sudo: a password is required` 影响
|
||
|
||
### 2.3 国内 worker 正常
|
||
|
||
国内 worker 这边已经确认：
|
||
|
||
- `domaincheck-worker` 正常运行
|
||
- 可以连接国内 controller 的 PostgreSQL
|
||
- 可以连接国内 controller 的 Redis
|
||
- Redis 密码配置后，Worker 控制指令已能正确消费
|
||
|
||
### 2.4 海外任务下发到国内已跑通
|
||
|
||
已实现并验证：
|
||
|
||
- 海外导出待检测任务批次
|
||
- 国内 controller 主动拉取任务批次
|
||
- 国内本地写入 `domains`
|
||
- 国内本地生成 `detect_jobs` / `detect_job_items`
|
||
- 国内 worker 已开始执行实际检测任务
|
||
|
||
实际验证过的现象：
|
||
|
||
- 国内 `domains` 从 `0` 变成 `200`
|
||
- `detect/start` 能创建任务
|
||
- `job_id=1` 已进入 `running`
|
||
- `items_completed`、`items_running`、`items_claimed` 已持续变化
|
||
|
||
### 2.5 结果与运行时同步部分已跑通
|
||
|
||
已确认：
|
||
|
||
- 国内 `runtime_projection` 已成功推送到海外
|
||
- 国内 `detect_result_projection` 已开始生成
|
||
- 海外已能看到新的大陆 controller 节点在线
|
||
|
||
---
|
||
|
||
## 3. 本次实际修改过的核心代码
|
||
|
||
以下文件已经被修改，是后续接手时最需要优先查看的：
|
||
|
||
### 3.1 任务下发/同步相关
|
||
|
||
- [domain-api/app/services/sync_push_service.py](/www/wwwroot/getDomain/domain-api/app/services/sync_push_service.py:1)
|
||
- [domain-api/app/services/sync_record_service.py](/www/wwwroot/getDomain/domain-api/app/services/sync_record_service.py:1)
|
||
- [domain-api/app/api/routes/runtime.py](/www/wwwroot/getDomain/domain-api/app/api/routes/runtime.py:1)
|
||
- [domain-api/app/sync_agent.py](/www/wwwroot/getDomain/domain-api/app/sync_agent.py:1)
|
||
|
||
新增/补充的能力包括：
|
||
|
||
- `runtime_projection` 推送与接收
|
||
- `detect_result_projection` 推送与接收
|
||
- `detect_task_projection` 任务批次导出
|
||
- 国内 `pull_detect_task_batch_now()`
|
||
- 海外 `task-export`
|
||
- 海外 `task-ack`
|
||
- 国内任务批次入库逻辑
|
||
|
||
### 3.2 任务创建与控制
|
||
|
||
- [domain-api/app/services/detect_job_service.py](/www/wwwroot/getDomain/domain-api/app/services/detect_job_service.py:1)
|
||
- [domain-api/app/services/worker_control_service.py](/www/wwwroot/getDomain/domain-api/app/services/worker_control_service.py:1)
|
||
- [domain-api/app/services/runtime_control_service.py](/www/wwwroot/getDomain/domain-api/app/services/runtime_control_service.py:1)
|
||
- [domain-api/app/api/routes/detect.py](/www/wwwroot/getDomain/domain-api/app/api/routes/detect.py:1)
|
||
|
||
关键变化：
|
||
|
||
- 本地没有任务时，`create_detect_job_if_needed()` 会先尝试从海外拉一批任务
|
||
- Linux `systemd` 模式下不再强依赖 `sudo -n`
|
||
- 增加了 `pull_tasks` 运行时动作
|
||
|
||
### 3.3 运行时节点与 cluster 视图
|
||
|
||
- [domain-api/app/services/cluster_runtime_service.py](/www/wwwroot/getDomain/domain-api/app/services/cluster_runtime_service.py:1)
|
||
|
||
关键变化：
|
||
|
||
- 支持导入远端 runtime 节点
|
||
- 支持清理历史 `*-imported` 脏节点
|
||
- 正在补齐“海外显示大陆 worker 节点”的投影逻辑
|
||
|
||
### 3.4 前面已经做过的部署类改动
|
||
|
||
这些文件之前也已经做过较多修复，交接时可一起复核：
|
||
|
||
- `domain-api/deploy/multi-region/install_overseas_quick.sh`
|
||
- `domain-api/deploy/multi-region/install_mainland_controller_quick.sh`
|
||
- `domain-api/deploy/multi-region/install_mainland_worker_quick.sh`
|
||
- `docs/17_domainCheck_全流程部署实操手册.md`
|
||
- `docs/18_domainCheck_CentOS9一键复制部署与更新文档.md`
|
||
|
||
---
|
||
|
||
## 4. 当前仍未完全收尾的问题
|
||
|
||
### 4.1 海外 cluster 里大陆 worker 显示不完整
|
||
|
||
当前已经能在海外看到：
|
||
|
||
- `mainland-controller-01`
|
||
|
||
但一度没有稳定看到：
|
||
|
||
- `mainland-worker-01`
|
||
|
||
原因：
|
||
|
||
- 海外主要是根据大陆 controller 回传的 `runtime_projection` 做远端节点物化
|
||
- 之前 projection 里缺少 `active_job.node_stats`
|
||
- 后续已补代码，让海外可根据 `node_stats` 额外注册 worker 节点
|
||
|
||
接手人需要重点验证：
|
||
|
||
- 海外 `/api/v1/runtime/cluster` 中是否出现 `mainland-worker-01`
|
||
- `online_worker_nodes` 是否从 `0` 变为 `1`
|
||
|
||
### 4.2 历史脏节点 `mainland-control-imported`
|
||
|
||
这是早期调试阶段遗留的 imported 节点。
|
||
|
||
现象：
|
||
|
||
- 海外 `readiness` / `cluster` 曾显示：
|
||
- `mainland-control-imported`
|
||
- `status: offline`
|
||
|
||
影响：
|
||
|
||
- 不影响主流程执行
|
||
- 但会污染 readiness / cluster 展示
|
||
|
||
已经补了清理逻辑，但需要继续验证是否彻底清干净。
|
||
|
||
### 4.3 结果回传展示还需要继续观察
|
||
|
||
当前已经看到：
|
||
|
||
- `detect_result_projection` 在国内生成
|
||
- 海外 `sync-summary` 中出现结果相关记录
|
||
|
||
还需要继续确认：
|
||
|
||
- 海外是否稳定生成 `detect_result_ingest`
|
||
- 海外业务展示页/结果页是否正确反映国内执行结果
|
||
- 海外主库中的业务表是否已被正确更新
|
||
|
||
---
|
||
|
||
## 5. 两边部署时容易踩的坑
|
||
|
||
### 5.1 root 和 www 的职责不要混
|
||
|
||
建议约定：
|
||
|
||
- `git pull` / 仓库代码操作：用 `www`
|
||
- `systemctl restart ...`：用 `root`
|
||
|
||
原因：
|
||
|
||
- `root` 在当前环境下经常遇到 git safe.directory / ssh / dubious ownership 问题
|
||
- `www` 是仓库实际维护用户
|
||
|
||
### 5.2 国内 controller 与 worker 的 Redis 密码必须一致
|
||
|
||
至少这些位置要确认：
|
||
|
||
- `/etc/default/domaincheck-api`
|
||
- `/etc/default/domaincheck-worker`
|
||
- `/www/wwwroot/getDomain/domainCheck/.env`
|
||
|
||
如果 Redis 开了密码，但上述文件里 `REDIS_PASSWORD=` 为空，会出现：
|
||
|
||
- `Authentication required.`
|
||
- API 无法发 Worker 控制指令
|
||
- Worker 无法订阅控制消息
|
||
|
||
### 5.3 国内 controller 本地数据库并不是海外主数据
|
||
|
||
之前最大的误区就是：
|
||
|
||
- 海外有 `16w` 数据
|
||
- 但国内本地 `domains` 一开始是 `0`
|
||
|
||
当前设计已经调整为：
|
||
|
||
- 海外通过 `task-export` 导出待检测批次
|
||
- 国内主动拉批次，落本地最小 `domains`
|
||
- 国内 worker 只跑本地任务
|
||
|
||
不要再假设“国内本地库天然就有海外那 16w 主数据”。
|
||
|
||
### 5.4 代码更新要确认文件内容，不要只看 restart
|
||
|
||
如果 `systemctl restart domaincheck-api` 之后行为没变，不要只怀疑服务。
|
||
|
||
先直接检查源码关键片段是否真的更新到位。
|
||
|
||
例如本次调试里最典型的就是：
|
||
|
||
- `domain-api/app/services/sync_push_service.py`
|
||
|
||
通过 `grep` 关键代码判断是否已是新版，比只看服务状态更可靠。
|
||
|
||
---
|
||
|
||
## 6. 建议给海外 Codex 的接手任务
|
||
|
||
建议在海外机新开 Codex 后，直接按下面顺序接手：
|
||
|
||
### 6.1 第一优先级
|
||
|
||
- 确认海外 cluster 能稳定显示：
|
||
- `overseas-control-01`
|
||
- `mainland-controller-01`
|
||
- `mainland-worker-01`
|
||
|
||
- 确认海外 `readiness` 中：
|
||
- `online_worker_nodes >= 1`
|
||
- 不再被 `mainland-control-imported` 影响
|
||
|
||
### 6.2 第二优先级
|
||
|
||
- 确认 `detect_result_projection -> detect_result_ingest` 的闭环
|
||
- 确认海外业务查询接口/后台页面能看到国内执行回流结果
|
||
|
||
### 6.3 第三优先级
|
||
|
||
- 整理 `docs/18_domainCheck_CentOS9一键复制部署与更新文档.md`
|
||
- 把国内 controller / worker 的最终正确部署流程写成“复制即可执行”的版本
|
||
|
||
---
|
||
|
||
## 7. 建议的优秀调试方式：国内日志主动回调到海外
|
||
|
||
当前最大问题不是代码本身，而是：
|
||
|
||
- 每次都要在国内机执行命令
|
||
- 再手工复制长日志给海外
|
||
- 调试效率太低
|
||
|
||
最推荐的改法不是继续人工贴日志，而是做“日志回调到海外调试面板”。
|
||
|
||
### 7.1 推荐目标
|
||
|
||
增加一个轻量调试链路：
|
||
|
||
- 国内 controller
|
||
- 国内 worker
|
||
- 国内 sync-agent
|
||
|
||
把最近 N 条关键日志、关键事件、关键指标，主动推送到海外一个调试接口，或写入海外一张调试表。
|
||
|
||
### 7.2 最小可行方案
|
||
|
||
推荐只同步“结构化调试事件”，不要直接全量推原始日志文件。
|
||
|
||
建议结构：
|
||
|
||
- `source_region`
|
||
- `node_code`
|
||
- `service`
|
||
- `event_type`
|
||
- `level`
|
||
- `message`
|
||
- `payload_json`
|
||
- `created_at`
|
||
|
||
来源可以先选这三类：
|
||
|
||
- `domaincheck-api`
|
||
- `domaincheck-worker`
|
||
- `domaincheck-sync-agent`
|
||
|
||
### 7.3 最值得先回调的事件
|
||
|
||
不是所有日志都要回传，优先回传高价值事件：
|
||
|
||
- Worker 控制指令成功/失败
|
||
- 任务批次拉取成功/失败
|
||
- 任务创建成功/失败
|
||
- 结果投影生成成功/失败
|
||
- 结果同步推送成功/失败
|
||
- Redis/PostgreSQL 连接失败
|
||
- 代理池刷新结果摘要
|
||
- `domain_started` / `domain_completed` / `domain_failed`
|
||
|
||
### 7.4 为什么推荐结构化事件而不是原始日志
|
||
|
||
因为结构化事件更适合：
|
||
|
||
- 海外 Codex 直接查询分析
|
||
- 后台页面直接展示
|
||
- 做筛选、聚合、时间线回放
|
||
- 后续做自动告警
|
||
|
||
### 7.5 建议实现方式
|
||
|
||
建议海外增加一个轻量接口，例如：
|
||
|
||
- `POST /api/v1/runtime/debug-ingest`
|
||
|
||
国内三类服务把关键事件 POST 到海外。
|
||
|
||
海外落库到新表，例如：
|
||
|
||
- `detect_debug_events`
|
||
|
||
建议字段：
|
||
|
||
- `id`
|
||
- `source_region`
|
||
- `node_code`
|
||
- `service`
|
||
- `event_type`
|
||
- `level`
|
||
- `message`
|
||
- `payload_json`
|
||
- `created_at`
|
||
|
||
这样后面海外 Codex 只要直接查海外库，就能复原国内问题，不需要再人工复制日志。
|
||
|
||
---
|
||
|
||
## 8. 建议下一步实施顺序
|
||
|
||
### 方案 A：先收尾展示，再补日志回调
|
||
|
||
1. 修海外 cluster/readiness 的 worker 显示
|
||
2. 清理 `mainland-control-imported`
|
||
3. 确认结果回流展示
|
||
4. 再做日志回调
|
||
|
||
### 方案 B：先补日志回调，再继续深度调试
|
||
|
||
1. 海外新增 `debug-ingest`
|
||
2. 国内 controller / worker / sync-agent 回调关键事件
|
||
3. 海外 Codex 直接观察结构化事件
|
||
4. 再做 cluster/readiness 视图收尾
|
||
|
||
如果后续还要继续高频调试，我更推荐 **方案 B**。
|
||
|
||
---
|
||
|
||
## 9. 当前阶段结论
|
||
|
||
截至本交接文档生成时，可以确认：
|
||
|
||
- 国内外任务下发链路已打通
|
||
- 国内本地任务落库已打通
|
||
- 国内 worker 已实际执行检测
|
||
- 国内运行时已回传海外
|
||
- 海外已能看到新的大陆 controller 节点
|
||
|
||
当前剩余问题已经从“主流程不通”降级为：
|
||
|
||
- 海外 cluster/readiness 视图收尾
|
||
- 结果回流展示补强
|
||
- 调试手段升级为结构化日志回调
|
||
|
||
主流程已经不再是 blocker。
|