getDomain/docs/ops_center_runtime/IMPLEMENTATION_STATUS.md

IMPLEMENTATION_STATUS

更新时间：2026-04-19 03:41 CST

当前真实状态

阶段判断：

• 海外单脑接管能力：约 95%
• 分布式检测真实执行能力：约 88%~90%
• 距离“可稳定上线并放心用后台发起检测”：约 86%~89%

本轮最新结论

这轮结论需要更新为四段：

• 接管与同步能力已经明显趋于完成
• worker 控制消息补偿链已经完成线上验证
• controller 运行环境漂移已经被现场修正
• 当前唯一剩余主阻塞已经收紧到 controller 代理池无可用代理

当前证据拆分

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

线上运行验证也已经出现正向证据：

• mainland-worker-01
  • 启动后发现待执行控制指令
  • 接受 start_detection
  • 开始执行远程检测任务
• mainland-controller-01
  • 修正 Redis 环境后
  • 重新接受 start_detection
  • 开始执行远程检测任务

2. 接管/同步闭环

当前已完成：

• remote_access_ready = 3/3
• log_sync_state = full_capture
• mainland-controller-01 的 domaincheck-sync-agent 已重启到新进程
• 首轮 detect_result_projection 推送成功过一次
• 中央已收到 mainland 首批 domain_* 事件

这说明：

• mainland 到中央的基础同步链是活的
• 结果投影链至少成功打通过一次

3. 检测执行闭环

当前未完成：

• 短观察窗口内：
  • progress_percent 仍是 2.1
  • items_completed 仍是 21
  • items_claimed 仍是 34
  • items_pending 仍是 931
• 中央 recent events 已刷新到更晚时间
• runtime/sync-summary 最新记录已继续增长
• 但 completed 尚未继续上涨

这说明：

• 当前不是单纯“页面没刷新”
• 而是执行现场这段时间没有继续出结果

本轮新增硬证据

通过中央观测面、节点现场日志和远端 domaincheck-worker 日志，已确认：

• mainland-controller-01 现场日志显示：
  • 当前可用代理数: 0
  • 最近结果: 刷新成功，可用 0 个
• controller 新增远端日志显示：
  • 代理源拉取成功
  • 抽样校验后 共 0 个可用代理
  • 失败集中在：
    • ProxyError@https://m.baidu.com
    • Unable to connect to proxy
    • ConnectTimeoutError
• worker 新增远端日志显示：
  • 发现待执行 Worker 控制指令
  • 已接受检测启动指令
  • 开始执行远程检测任务
  • 说明线上补偿消费链已真正工作
• controller 新增远端日志显示：
  • 初次重启后：
    • Authentication required
    • maximum recursion depth exceeded
  • 进一步排查确认：
    • /etc/default/domaincheck-worker 的 REDIS_PASSWORD 为空
  • 修正后再次重启：
    • Redis 连接成功: 127.0.0.1:6379
    • 已接受检测启动指令
    • 开始执行远程检测任务
  • 后续日志继续收紧到：
    • 代理已启用，但当前无可用代理
• 两台大陆节点 full capture 已开启，但源日志时间没有继续前进

这说明：

• worker 控制消息链不再是主阻塞
• controller Redis 环境漂移也不再是主阻塞
• 当前第一主阻塞已经进一步收紧到 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 自动产出结果投影缺口

当前唯一剩余问题

当前唯一主问题仍然是：

• 检测执行面没有恢复到持续产出

但现在已经不需要再拆成“代码待验证”和“现场阻塞”两层。

当前唯一剩余现场阻塞就是：

• controller 代理池可用性为 0
• 因此没有持续产生新的 domain 级结果

换句话说：

• 现在不是逻辑未实现
• 不是中央映射失败
• 不是节点未接管
• 而是执行现场没有继续产出，且 controller 侧卡在代理校验失败

acceptance 当前状态

最新接管验收结果仍然成立：

• pbr-9ce5c85f17：onboarding.acceptance 成功
• pbr-389abd618c：onboarding.acceptance 成功

旧的 attention run 依然是历史残留，但它们已经不是当前最真实的生产阻塞。

当前是否可以继续跑检测测试

当前结论：

• 可以继续做最小运行态排查
• 但不需要再优先验证 worker 控制消息链
• 当前还不能把状态视作“后台检测已经稳定恢复”

当前是否建议直接上线

当前结论：

• 不建议现在按“可稳定上线”判断

原因不是接管面，而是执行面：

• 三台节点都已接入
• worker / controller 都已重新接上控制链
• 但当前任务没有持续吞吐
• controller 代理池全部验不过会直接影响检测产出

当前优先级判断

最高优先级：

• J2-检测执行停滞收口批

当前不应继续推进：

• 新控制面功能
• 新模块
• 新页面
• 发布动作
• 与检测执行停滞无关的工作

完成下一轮后的预期

如果下一轮确认：

• controller 代理池恢复可用
• domain_* 开始继续增长
• items_completed 和近窗吞吐重新前进

则整体可上线程度预计可回升到：

• 92%~94%

在那之前，当前口径应保持保守。