feat: stabilize multi-region runtime sync and worker orchestration
This commit is contained in:
84
docs/shenhe.md
Normal file
84
docs/shenhe.md
Normal file
@@ -0,0 +1,84 @@
|
||||
可以,按“尽量省额度但不丢高风险”的思路,我建议你把全项目审核拆成 3 轮,目标控制在 `800万 ~ 1200万 tokens`。
|
||||
|
||||
**先排除**
|
||||
第一轮先不要审这些,不然额度会被白白吃掉:
|
||||
|
||||
- `release/`
|
||||
- `.venv/`
|
||||
- `node_modules/`
|
||||
- `domain-web/package-lock.json`
|
||||
- `domainCheck/app/sdk_leg.js`
|
||||
- `domainCheck/detect/sdk_leg.js`
|
||||
- 运行时产物、日志、快照、历史 night runs
|
||||
- 大 JSON 词库这类静态数据,除非代码直接依赖逻辑可疑
|
||||
|
||||
**三轮顺序**
|
||||
1. 控制面与数据正确性
|
||||
预算:`300万 ~ 450万`
|
||||
- `domain-api/app/services/detect_job_service.py`
|
||||
- `domain-api/app/services/detect_service.py`
|
||||
- `domain-api/app/services/runtime_status_service.py`
|
||||
- `domain-api/app/services/dashboard.py`
|
||||
- `domain-api/app/services/sync_record_service.py`
|
||||
- `domain-api/app/services/sync_push_service.py`
|
||||
- `domain-api/app/services/worker_control_service.py`
|
||||
- `domain-api/app/services/settings_service.py`
|
||||
- `domain-api/app/services/cluster_runtime_service.py`
|
||||
- 对应 `routes/` 和关键测试
|
||||
|
||||
这一轮最值钱,因为它直接查:
|
||||
- 页面显示为什么和现场不一致
|
||||
- sync 为什么会把旧状态盖新状态
|
||||
- runtime projection / queue health / active job 是否互相打架
|
||||
- 配置下发和节点实际执行是否一致
|
||||
|
||||
2. Worker 并发与执行链
|
||||
预算:`300万 ~ 400万`
|
||||
- `domainCheck/detect_worker.py`
|
||||
- `domainCheck/app/utils/database.py`
|
||||
- `domainCheck/app/detectors/`
|
||||
- `domainCheck/detect/`
|
||||
- `domainCheck/tests/` 里和并发、连接池、超时、代理有关的测试
|
||||
|
||||
这一轮重点查:
|
||||
- 多进程 / 多线程是否真能提升吞吐
|
||||
- DB 连接池、代理池、任务领取链有没有硬瓶颈
|
||||
- 内存为什么高、进程为什么空转
|
||||
- 超时、重试、降级逻辑是否会拖垮吞吐
|
||||
|
||||
3. 发布、运维、前端展示
|
||||
预算:`200万 ~ 300万`
|
||||
- `domain-api/deploy/`
|
||||
- `domain-api/app/node_agent.py`
|
||||
- `domain-api/app/services/ops_*`
|
||||
- `domain-web/src/views/detect/`
|
||||
- `domain-web/src/views/runtime/`
|
||||
- `domain-web/src/views/settings/`
|
||||
- systemd 模板、迁移/发布脚本
|
||||
|
||||
这一轮重点查:
|
||||
- 发布链和实际运行是否一致
|
||||
- 多实例 worker 的部署是否完整
|
||||
- 前端是否误导运维判断
|
||||
- 迁移、接管、rollout 有没有高风险坑
|
||||
|
||||
**模型建议**
|
||||
- 第 1 轮:`gpt-5.4 + xhigh`
|
||||
- 第 2 轮:`gpt-5.4 + xhigh`
|
||||
- 第 3 轮:`gpt-5.4 + high`
|
||||
|
||||
这样通常能把额度压在你要的区间里。
|
||||
|
||||
**输出方式**
|
||||
每轮都只要这 3 类结果,最省额度:
|
||||
|
||||
- `P0/P1` 真实问题
|
||||
- 影响面
|
||||
- 修复建议
|
||||
|
||||
不要第一轮就让模型写大篇架构说明,不然额度会烧很快。
|
||||
|
||||
一句话版:
|
||||
先审 `domain-api` 的状态/同步链,再审 `domainCheck` 的并发执行链,最后审 `deploy + ops + 前端展示`;按这个顺序,`800万~1200万 tokens` 是有机会压住的。
|
||||
|
||||
如果你要,我下一步可以直接给你生成一份“第一轮审核清单”,精确到文件名单。
|
||||
Reference in New Issue
Block a user