已合并
修复故障实例熔断时间过长 #715
修复故障实例熔断时间过长 #715
已合并
zhinengwu创建于 7 天前
zhinengwu
zhinengwu
7 天前
## **1. 合入背景** 当前存在两个实例故障场景下的问题: 1. 实例异常(如 pod 删除、IP 释放导致 TCP 黑洞)时,请求连接建立依赖内核 SYN 重试(约 63s 才失败),远超客户端超时,导致请求直接超时失败而非快速触发熔断降级; 2. 熔断恢复定时器到点后直接闭合熔断,若实例实际未恢复,请求会再次被派发进黑洞地址,反复超时。 关联 ISSUE:#470 ## **2. 修改内容** 1. **连接超时收敛(router 层)**:`BaseRouter` 新增 `_build_request_timeout()`,使用 `exception_config.connect_timeout`(默认 5s,取 0 保持原行为)单独约束 TCP connect 阶段,读写/总超时语义不变;流式与非流式两条转发路径均生效。引擎黑洞时请求快速失败 → 熔断及时再跳闸 → hybrid 降级按时接管。 2. **熔断解除前探活(scheduler 层)**:`_auto_recover` 定时器到点后不再直接闭合熔断,先执行 `_probe_instance()` 对实例业务端口做 TCP connect 探活(2s 超时),探活成功才 `auto_recover` 闭合。 3. **探活失败退避(熔断域)**:新增 `CircuitBreakerManager.process_probe_failure()`,探活失败时保持熔断打开,恢复超时按 trip_count 指数退避(30s 起、2 倍递增、封顶 300s),并重新调度恢复任务。 涉及文件: - `motor/coordinator/domain/circuit_breaker.py`(新增 `process_probe_failure`) - `motor/coordinator/router/strategies/base.py`(新增 `_build_request_timeout`) - `motor/coordinator/scheduler/runtime/scheduler_server.py`(新增 `_probe_instance`,改造 `_auto_recover`) ## **3. 资料变更** 不涉及。 ## **4. 接口变更** 不涉及(均为内部实现变更;`connect_timeout` 配置项此前已合入,未新增外部接口)。 ## **5. 测试结果** [MindIE-Motor 熔断修复验证测试报告](https://wiki.huawei.com/domains/123696/wiki/385355/WIKI2026081212268325) ## **6. CheckList** [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景,考虑了并发场景,不存在死锁问题(asyncio 单线程事件循环,定时器替换逻辑已处理)
likedislike
Pull Request已成功合入, 合并人@tobking
(感谢 zhinengwu 的贡献)
zhinengwuzhinengwu
7 天前 关联了issue:[Bug-Report|缺陷反馈]: 实例故障,长时间不触发熔断,导致请求超时失败
atomgit-bot
atomgit-bot
7 天前 评论:

变更摘要

此 PR 主要解决两个实例故障场景下的问题:一是实例异常(如 Pod 删除、IP 释放导致 TCP 黑洞)时连接建立依赖内核 SYN 重试(约 63s),远超客户端超时,导致请求直接失败而非快速熔断降级;二是熔断恢复定时器到点后直接闭合熔断,若实例未恢复则请求再次落入黑洞。修改通过在 BaseRouter 中新增 _build_request_timeout() 收敛 TCP connect 阶段超时,在 _auto_recover 中引入探活驱动的恢复流程,以及在 CircuitBreakerManager 中新增探活失败的指数退避逻辑,使黑洞场景下请求快速失败、熔断及时跳闸、恢复前验证实例可达。

主要改动

  • Router 层连接超时收敛BaseRouter 新增 _build_request_timeout() 方法,读取 exception_config.connect_timeout(默认 5s,>0 时生效)单独约束 TCP connect 阶段,读写/总超时保持不变;forward_stream_request 及非流式转发路径均改用该方法构建 httpx.Timeout,使黑洞地址的连接快速失败而非阻塞约 63s。
  • Scheduler 层探活驱动的熔断恢复_auto_recover 不再直接闭合熔断,而是先调用新增的 _probe_instance() 对实例业务端口执行 TCP connect 探活(2s 超时),仅在探活成功后才调用 auto_recover 闭合熔断,避免请求重新派发到不可达实例。
  • 熔断域探活失败指数退避CircuitBreakerManager 新增 process_probe_failure() 方法,探活失败时保持熔断打开,恢复超时按 trip_count 指数退避(30s 起、2 倍递增、封顶 300s),并返回新的超时值供 _schedule_recovery 重新调度。
  • 探活实例不存在或无端点的防御处理_probe_instance() 在实例不在可用池中或无端点时直接返回 False,避免空端点或不存在实例导致的异常,同时 process_probe_failure 对非 OPEN 状态实例返回 None 作为安全防护。
  • 新增单元测试覆盖:新增 test_base_router_request_timeout.py(验证 connect_timeout > 0<= 0 两种行为)和 test_scheduler_circuit_breaker_probe.py(覆盖探活成功/失败、指数退避、恢复调度、边界条件),并在 test_circuit_breaker.py 中新增 process_probe_failure 的退避与状态校验用例。
likedislike
atomgit-bot
atomgit-bot
7 天前 评论:

代码审查

Now let me write the closing summary.


审查总结

本批次审查了 6 个变更文件,逐一核查结果如下:

文件 审查结论
motor/coordinator/domain/circuit_breaker.py 无问题 — process_probe_failure 指数退避逻辑正确,边界值封顶 300s
motor/coordinator/router/strategies/base.py 发现 1 个 P3 问题(非 httpx 客户端兼容性)
motor/coordinator/scheduler/runtime/scheduler_server.py 发现 1 个 P2 问题(business_port 类型未校验)
tests/coordinator/domain/test_circuit_breaker.py 无问题
tests/coordinator/router/test_base_router_request_timeout.py 无问题
tests/coordinator/scheduler/test_scheduler_circuit_breaker_probe.py 无问题

按优先级统计:

  • P0: 0
  • P1: 0
  • P2: 1 — _probe_instancebusiness_port 可能为非整数类型,导致探活静默失败、熔断永不解锁
  • P3: 1 — _open_nonstream_response 非 httpx 分支传递 httpx.Timeout 对象而非原始 int,可能影响内部测试客户端

整体风险评估:低风险。 核心逻辑(connect 超时收敛、熔断解除前 TCP 探活、探活失败指数退避)设计合理,边界处理正确。两个发现问题均为边界/防御性编程问题,不影响生产主路径。建议在合入前确认 business_port 的运行时类型,并对非 httpx 客户端分支做兼容处理。

类型 数量
🔴 阻塞 0
🟡 建议 1

💬 仅评论

likedislike
ascend-robotascend-robot成员
7 天前 添加了label:ascend-cla/yes
ascend-robot
ascend-robot成员
7 天前 评论:

Thanks for your pull-request.
The full list of commands accepted by me can be found at here
You can get sig-info at here


PR Approval Progress

Congratulations! All modules have met the lgtm and approve requirements.

Module Approval Details

module lgtm status approve status
repo-Ascend/MindIE-Motor 吕有辉, 王君 (2/2) 吕有辉 (1/1)

💡 Tip:

  • Committer can comment /approve or /lgtm
  • Commenting /approve implies both code review (lgtm) and intent to merge (approve)

CLA Signature Pass

qq_46749096, thanks for your pull request. All authors of the commits have signed the CLA. 👍

likedislike
此处折叠了97条消息 查看更多
tobking
tobking成员
6 天前 评论:

/lgtm

likedislike
jason lyujason lyu成员
6 天前 解决了最后一个问题
jason lyu
jason lyu成员
6 天前 评论:

/approve

likedislike
ascend-robotascend-robot成员
6 天前 添加了label:approvedlgtm
tobkingtobking成员
6 天前 合入了pull request