235 lines
6.4 KiB
Markdown
235 lines
6.4 KiB
Markdown
# IMPLEMENTATION_STATUS
|
||
|
||
更新时间：2026-04-19 03:38 CST
|
||
|
||
## 当前真实状态
|
||
|
||
阶段判断：
|
||
|
||
- 海外单脑接管能力：约 `95%`
|
||
- 分布式检测真实执行能力：约 `88%~90%`
|
||
- 距离“可稳定上线并放心用后台发起检测”：约 `86%~89%`
|
||
|
||
## 本轮最新结论
|
||
|
||
这轮结论需要更新为三段：
|
||
|
||
- 接管与同步能力已经明显趋于完成
|
||
- 检测执行面当前没有持续产出
|
||
- 其中一处代码级风险已经完成最小修复，但尚未完成线上部署验证
|
||
|
||
## 当前证据拆分
|
||
|
||
### 1. 代码闭环
|
||
|
||
已经完成：
|
||
|
||
- `detect_result_projection` 支持 `recent_domain_events`
|
||
- 中央 ingest 会把逐条事件写入 `detect_run_events`
|
||
- `sync_agent` 会自动产出 `detect_result_projection`
|
||
- worker 控制消息新增 `request_id`
|
||
- worker 运行态心跳会补偿消费 pending 控制消息
|
||
- worker 收到并处理控制消息后会按 `request_id` 清理 pending 指令
|
||
|
||
本地代码验证已通过：
|
||
|
||
- `unittest domain-api/tests/test_worker_control_service.py`
|
||
- `python -m py_compile domainCheck/detect_worker.py domain-api/app/services/worker_control_service.py`
|
||
|
||
### 2. 接管/同步闭环
|
||
|
||
当前已完成：
|
||
|
||
- `remote_access_ready = 3/3`
|
||
- `log_sync_state = full_capture`
|
||
- `mainland-controller-01` 的 `domaincheck-sync-agent` 已重启到新进程
|
||
- 首轮 `detect_result_projection` 推送成功过一次
|
||
- 中央已收到 mainland 首批 `domain_*` 事件
|
||
|
||
这说明：
|
||
|
||
- mainland 到中央的基础同步链是活的
|
||
- 结果投影链至少成功打通过一次
|
||
|
||
### 3. 检测执行闭环
|
||
|
||
当前未完成：
|
||
|
||
- 连续 40 秒观察窗口内：
|
||
- `progress_percent` 不变
|
||
- `items_completed` 不变
|
||
- `items_running` 不变
|
||
- `items_claimed` 不变
|
||
- `items_pending` 不变
|
||
- mainland `domain_*` 事件数仍固定在 `10`
|
||
- 最新 mainland `detect_result_ingest` 仍停在 `5382`
|
||
- `activity-stream` 明确提示：
|
||
- `近窗刚有吞吐 0 台`
|
||
|
||
这说明：
|
||
|
||
- 当前不是单纯“页面没刷新”
|
||
- 而是执行现场这段时间没有继续出结果
|
||
|
||
## 本轮新增硬证据
|
||
|
||
通过中央观测面、节点现场日志和远端 `domaincheck-worker` 日志，已确认：
|
||
|
||
- `mainland-controller-01` 现场日志显示：
|
||
- `当前可用代理数: 0`
|
||
- `最近结果: 刷新成功，可用 0 个`
|
||
- controller 新增远端日志显示：
|
||
- 代理源拉取成功
|
||
- 抽样校验后 `共 0 个可用代理`
|
||
- 失败集中在：
|
||
- `ProxyError@https://m.baidu.com`
|
||
- `Unable to connect to proxy`
|
||
- `ConnectTimeoutError`
|
||
- worker 新增远端日志显示：
|
||
- `时光机检测 外部依赖异常，步骤降级继续执行`
|
||
- 同时仍有 `域名检测完成`
|
||
- 新收到的重复启动指令被忽略，因为任务已在运行
|
||
- 两台大陆节点 full capture 已开启，但源日志时间没有继续前进
|
||
|
||
这说明：
|
||
|
||
- 当前第一主阻塞更像 controller 代理池不可用
|
||
- worker 的时光机异常是客观存在的次级问题
|
||
- 不是控制面未接管
|
||
- 不是同步链未打通
|
||
|
||
## 本轮新增代码修复
|
||
|
||
本轮不是只停留在诊断，还补了一处运行态最小修复：
|
||
|
||
### 修复点 1：控制消息唯一标识
|
||
|
||
- 文件：
|
||
- `domain-api/app/services/worker_control_service.py`
|
||
- 变更：
|
||
- 每次 `send_worker_command(...)` 都附带 `request_id`
|
||
- Redis `publish` 与 pending fallback 使用同一份消息体
|
||
|
||
### 修复点 2：worker 运行态补偿消费 pending 指令
|
||
|
||
- 文件：
|
||
- `domainCheck/detect_worker.py`
|
||
- 变更：
|
||
- 心跳线程每轮会补偿尝试消费 pending 控制消息
|
||
- 解决“worker 在线但 pubsub 消息漏收，导致 pending 指令长期不被消费”的风险
|
||
|
||
### 修复点 3：worker 收到指令后确认清理 pending
|
||
|
||
- 文件：
|
||
- `domainCheck/detect_worker.py`
|
||
- 变更：
|
||
- worker 实际收到控制消息后，会按 `request_id` 清理对应 pending 指令
|
||
- 避免修复后又产生重复回放
|
||
|
||
### 当前判断
|
||
|
||
这组修复解决的是：
|
||
|
||
- “检测启动已经发布，但 worker 可能静默漏收”的代码风险
|
||
|
||
这组修复还没有证明能够解决的是：
|
||
|
||
- `controller` 代理池校验后 `0 available` 的外部执行阻塞
|
||
|
||
所以当前最准确的状态是：
|
||
|
||
- 代码级控制链缺口已补上
|
||
- 运行态是否恢复，还要看线上节点拉代码重启后的观测结果
|
||
|
||
## 当前已闭合的问题
|
||
|
||
已闭合：
|
||
|
||
- 大陆 controller 无法 `pull_tasks`
|
||
- Detect 页面误判“大陆没跑”
|
||
- Detect 主统计口径不一致
|
||
- Runtime / Queue / Detect 主摘要不统一
|
||
- 中央逐条事件接收缺口
|
||
- `sync_agent` 自动产出结果投影缺口
|
||
|
||
## 当前唯一剩余问题
|
||
|
||
当前唯一主问题仍然是：
|
||
|
||
- 检测执行面停滞
|
||
|
||
但其下应拆成两个层次：
|
||
|
||
- 已补代码、待验证：
|
||
- worker 控制消息补偿消费链
|
||
- 已确认现场阻塞：
|
||
- controller 代理池可用性为 0
|
||
- 因此没有持续产生新的 domain 级结果
|
||
|
||
换句话说：
|
||
|
||
- 现在不是逻辑未实现
|
||
- 不是中央映射失败
|
||
- 不是节点未接管
|
||
- 而是执行现场没有继续产出，且 controller 侧卡在代理校验失败
|
||
|
||
## acceptance 当前状态
|
||
|
||
最新接管验收结果仍然成立：
|
||
|
||
- `pbr-9ce5c85f17`：`onboarding.acceptance` 成功
|
||
- `pbr-389abd618c`：`onboarding.acceptance` 成功
|
||
|
||
旧的 `attention` run 依然是历史残留，但它们已经不是当前最真实的生产阻塞。
|
||
|
||
## 当前是否可以继续跑检测测试
|
||
|
||
当前结论：
|
||
|
||
- 可以继续做最小部署验证
|
||
- 也可以继续做执行恢复类排查
|
||
- 但还不能把当前状态视作“后台检测已经稳定恢复”
|
||
|
||
## 当前是否建议直接上线
|
||
|
||
当前结论：
|
||
|
||
- 不建议现在按“可稳定上线”判断
|
||
|
||
原因不是接管面，而是执行面：
|
||
|
||
- 三台节点都已接入
|
||
- 但当前任务没有持续吞吐
|
||
- controller 代理池全部验不过会直接影响检测产出
|
||
- 并且这轮刚补上的 worker 控制消息修复还没经过线上运行验证
|
||
|
||
## 当前优先级判断
|
||
|
||
最高优先级：
|
||
|
||
- `J2-检测执行停滞收口批`
|
||
|
||
当前不应继续推进：
|
||
|
||
- 新控制面功能
|
||
- 新模块
|
||
- 新页面
|
||
- 发布动作
|
||
- 与检测执行停滞无关的工作
|
||
|
||
## 完成下一轮后的预期
|
||
|
||
如果下一轮确认：
|
||
|
||
- 大陆节点已拉到这版控制消息修复
|
||
- `domaincheck-worker` 重启后稳定收新指令
|
||
- controller 代理池恢复可用
|
||
- `domain_*` 开始继续增长
|
||
- `items_completed` 和近窗吞吐重新前进
|
||
|
||
则整体可上线程度预计可回升到：
|
||
|
||
- `92%~94%`
|
||
|
||
在那之前，当前口径应保持保守。
|