生产环境 Agent 编排我为什么给每个环节都加了失败降级凌晨 2 点 47 分监控告警把我从梦里拽了出来。生产环境的某个 Agent 工作流卡在了“调用外部工具”这一步上下游全部堵死队列里的任务越堆越多。我爬起来看了一眼日志发现是第三方接口响应超时但我们的编排引擎还在傻傻地等它重试导致后面的环节全部阻塞。那个瞬间我意识到Agent 编排系统不是不能出故障而是不能在故障面前毫无弹性。从那之后我给自己定了一条铁律——每个环节都要有降级方案而且要能真正落到生产上。这篇内容适合正在做 Agent 系统、任务编排、工作流引擎的开发者参考也适合那些把 Agent 接进业务系统后发现一挂全挂、无从下手的团队看一看。我把我自己踩过的坑、改过的代码、线上压测的经验都整理出来希望能帮你在设计阶段就少走弯路。1. 为什么 Agent 编排必须默认“一定会失败”先说一个反直觉的结论越是复杂的 Agent 编排越不能按“所有环节都正常工作”的假设来设计。原因很简单链条太长了任何一个点出问题都会沿着调用链传导。1.1 一条 Agent 链路里藏着多少个“脆弱点”我手头的一个典型 Agent 任务是这样的接收用户请求 → 调用语义理解模块 → 决策引擎选择工具 → 调用外部 API → 获取结果 → 汇总结论 → 回复用户。看起来只有七步但每一步背后都有隐藏的依赖——模型服务、向量库、Redis、消息队列、第三方 API、网关、对象存储随便数一数就是十几个组件。在生产环境待得久了你就会发现这些组件的可靠性是参差不齐的。模型服务偶尔会超时或返回乱码第三方 API 会在高峰期限流Redis 可能出现慢查询甚至网络抖动都能让一次原本 200 毫秒的调用变成 3 秒。如果一个编排系统对这些“小毛刺”不做处理后果就是任务失败、重试风暴、数据不一致运维群里一片哀嚎。1.2 失败的传导比你想的更可怕很多人觉得“某个环节失败了把这个任务标记为失败不就行了”。问题是编排系统里的任务往往是链式的一个任务失败了依赖它的下游任务也会失败。更麻烦的是如果重试机制设计得不合理失败的任务会在高峰期反复重试把系统资源吃掉一大半反而让本来正常的任务也跟着失败。我做了一次线上故障复盘某次第三方接口出现抖动持续了大概 20 分钟。我们的编排引擎默认重试 3 次每次间隔 5 秒结果那 20 分钟里系统内部产生了近 2 万次无效重试把数据库连接池和线程池都打满了。最后故障面从“单个接口超时”扩大到了“整个编排服务不可用”。那一刻我才彻底明白——失败不可怕可怕的是没有降级策略让失败无限传导。1.3 “降级”不是退步是给系统装保险丝降级这个词听起来像是“能力缩水”但实际上它是在说当系统无法按最理想的方式运行时你能不能提供一个虽然不是最优、但依然可用的替代方案。就像开车的时候备胎不是让你开不快而是让你不至于半路抛锚。在我的编排系统里降级方案的基本思路就一条——保留核心流程砍掉非核心依赖失败时给出可接受的兜底结果。核心流程必须要走完不能因为某个辅助功能挂了就整个链路停摆。2. 我的降级分层设计从模型调用到结果回传我做的降级不是笼统地“整个流程加 try-catch”而是按照调用链路上每一类环节的特点分别设计降级策略。分得越细致降级效果越好。2.1 模型服务层的降级超时、换路、简化Agent 的“大脑”是模型服务这一层也是最容易出现故障的地方。模型服务出问题通常有三种表现响应超时、返回格式异常、内容质量明显下降。针对这三种情况我分别做了不同的处理。第一层是超时控制。我给模型调用设置了多级超时时间比如“首字延迟 5 秒、总响应 30 秒”超过任何一个阈值就直接断开。这里的关键是不要用“无限等待”的默认配置生产环境的超时必须设得比训练环境更激进。第二层是模型路由切换。如果主模型的连续失败率达到阈值通过一个配置中心动态切换到备用模型。备用的模型效果差一点但至少能完成任务。降级后的模型选择、参数配置都会由配置中心自动推送整个过程业务方无感知。第三层是简化版本。如果主备模型都不可用就退而求其次用精简版的提示词模板走一遍把 Agent 从“深度思考模式”降为“快速应答模式”保证用户不用干等。这套分层降级落实之后模型服务出问题的时候业务中断率明显下降故障期间贴反馈也平和了不少。2.2 工具调用层的降级重试、换源、缓存兜底Agent 编排里工具调用是另一个重灾区。我在这里总结了一个四挡降级策略第一挡是快速重试第二挡是换备用工具第三挡是降缓存或死数据第四挡才是放弃本次调用并标记人工处理。重试的时候有个细节——退避时间必须带随机抖动。我见过很多团队直接用固定间隔重试结果一遇到故障所有任务都在同一个时间点重试形成“惊群效应”。我现在的实现是「指数退避 随机抖动」第一次重试等 500 毫秒到 1000 毫秒之间随机一个值第二次 2 到 4 秒之间随机第三次之后封顶 30 秒。实测下来这套重试策略对下游服务的压力少了百分之四十以上。工具调用还有一个容易忽略的坑不是所有重试都安全。对于“查询型”工具重试十次都没问题但“下单型”“转帐型”这类有副作用的操作盲目重试会造成重复扣款或重复发货。对这类工具我的策略是“幂等键 失败后转人工确认”绝不自动重试。2.3 数据访问层的降级缓存“兜底”是最后一根稻草Agent 执行过程中经常要查知识库、用户画像、历史订单等数据。数据源一旦超时或报错很多编排上会直接抛异常。我的做法是给常用数据加一层“本地内存缓存 Redis 缓存”的双层兜底缓存过期时间设得比较长宁可数据稍微旧一点也不能让任务失败。在执行数据访问降级的时候我用的规则是数据新鲜度优先级低于流程完成度。也就是说如果拿不到最新数据就用最近一次成功缓存的数据来继续流程。比如查库存的时候数据库超时了就返回缓存里上一次查到的库存数量并在最终结果里标注“库存信息可能滞后”让下游环节或者人工去判断是否采纳。2.4 调度引擎层的降级并行转串行、异步转同步编排引擎本身也要有降级能力。我之前遇到过一个很典型的场景某个环节依赖的组件不稳定导致并行分片大面积卡住整体吞吐降到几乎为 0。后来我加了一个动态调度策略——当某个环节的超时率超过阈值时自动把并行分支改为串行执行。虽然串行会变慢但至少每个任务都有机会完成不会因为任务积压导致整体雪崩。展开来说这套策略分成三个层级正常状态并行执行多个分支追求吞吐量。过载状态降为半并行控制同时执行的分支数量。熔断状态降为串行逐条处理保证任务不丢。切换动作通过一个分布式的协调组件下发不用重启服务也不用人工干预。我在生产环境压测过这个“并行转串行”的动作能在 10 秒内完成对正在执行的任务影响极小。3. 具体的降级实现代码级别怎么做方案说得再好落地才是关键。我挑三个最核心的环节把具体实现拆开来讲代码可以直接抄抄完根据自己的业务改改参数就能用。3.1 模型调用的降级封装我会封装一个统一的模型调用入口所有 Agent 的模型请求都走这个入口。内部实现一个降级路由根据配置决定调用主模型、备用模型还是简化模型。import time import random from typing import Any, Dict class ModelRouter: def __init__(self, config: Dict[str, Any]): self.config config self.failure_count 0 self.degraded False def call(self, prompt: str, use_cache: bool True) - str: if use_cache: cached self._get_cache(prompt) if cached: return cached # 第一层主模型 if not self.degraded: try: start time.time() result self._call_main_model(prompt, timeout20) self.failure_count 0 self._set_cache(prompt, result) return result except TimeoutError: self.failure_count 1 if self.failure_count 5: self.degraded True # 进入降级模式 except Exception: self.failure_count 1 if self.failure_count 3: self.degraded True # 第二层备用模型 try: return self._call_backup_model(prompt, timeout10) except Exception: # 第三层简化模型用固定模板快速响应 return self._call_simplified_model(prompt)这个封装看起来简单但有几个细节值得注意降级状态是“粘性”的一旦触发降级不会马上恢复。我用的是一个半开状态机制——每 5 分钟尝试恢复一次主模型成功一次就把降级状态关掉。缓存优先同一问题的结果在短时间内直接返回既省成本又省时间。超时时间是动态的主模型 20 秒、备用模型 10 秒确保降级后用户等待时间更短。3.2 工具调用的降级编排工具调用的降级核心是“按操作类型区分策略”。我用一个装饰器来标记每个工具的类型然后由执行器根据类型选择降级策略。import time import random from enum import Enum from functools import wraps class ToolType(Enum): QUERY query # 查询型可以安全重试 ACTION action # 操作型不能盲目重试 EXTERNAL external # 外部依赖型需要特殊处理 def tool(tool_type: ToolType, max_retries: int 3): def decorator(func): wraps(func) def wrapper(*args, **kwargs): if tool_type ToolType.QUERY: return _query_with_retry(func, max_retries, *args, **kwargs) elif tool_type ToolType.ACTION: return _action_with_idempotency(func, *args, **kwargs) else: return _external_with_circuit_breaker(func, *args, **kwargs) return wrapper return decorator def _query_with_retry(func, max_retries, *args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: wait min(30, (2 ** attempt) random.uniform(0, 1)) time.sleep(wait) return None # 最终返回 None由上层决定下一步 def _action_with_idempotency(func, *args, **kwargs): kwargs[idempotency_key] kwargs.get(idempotency_key, str(time.time_ns())) try: return func(*args, **kwargs) except Exception: # 操作型失败直接抛给上层转人工处理 raise def _external_with_circuit_breaker(func, *args, **kwargs): # 熔断器逻辑失败率过高时直接短路 if external_breaker.is_open(): return _fallback_external_result(*args, **kwargs) try: return func(*args, **kwargs) except Exception: external_breaker.record_failure() return _fallback_external_result(*args, **kwargs)这个实现里最重要的决策是“查询型允许重试、操作型禁止重试”。实际操作中我发现把这条规则刻在每个开发者的脑子里非常难所以干脆从代码级别强制约束——用ToolType枚举约束每一个工具的降级行为。这样同类工具统一处理不容易出错。3.3 编排引擎的熔断与半开恢复编排引擎本身的降级我用了一个轻量级的熔断器来保护各个环节。核心逻辑是记录最近 1 分钟内的调用成功率和耗时。成功率低于阈值或平均耗时超过预期就把该环节标记为“熔断”。熔断状态下新请求直接走降级路径不实际调用下游。每 30 秒尝试一次半开探测放少量请求过去看下游是否恢复。# 伪代码熔断器的状态转换 # 状态: CLOSED - OPEN - HALF_OPEN - CLOSED/OPEN # 关键参数 # request_volume_threshold: 10 # 1分钟内最少请求数低于这个数不触发熔断 # error_ratio_threshold: 0.5 # 错误率超过 50% 触发熔断 # open_timeout: 30 # 熔断持续时间 30 秒 # half_open_max_calls: 3 # 半开状态最多放 3 个请求探测熔断器的参数需要根据业务特性调整。比如内部 API 可以激进一点错误率阈值设低一些、熔断时间设短一些第三方 API 则保守一些熔断时间拉长避免频繁打断第三方服务可能存在的慢恢复过程。4. 降级踩坑实录与排查锦囊降级方案上线之后并不能一劳永逸。我在生产环境里遇到的问题不少有些已经彻底解决有些还在持续优化。挑几个典型的聊一聊。4.1 降级被“误触发”远比“不触发”更频繁我起初把降级阈值设得太敏感结果正常波动也会触发降级。比如某个外部接口偶尔会有一两次超过 3 秒的响应正常时候平均只要 200 毫秒。按“平均耗时超过 1 秒就熔断”的规则每天都在误触发。后来我把熔断条件改成“1 分钟内请求量超过 10 次且错误率超过 50% 或 p99 耗时超过 5 秒”双重条件误触发率才降下来。这个经验是降级的触发条件要同时看“量”和“率”不能只看平均耗时平均耗时很容易被极端值拉偏。4.2 多级降级的“恢复”动作会造成二次故障我在一个时间段内同时给三层都配了“每 5 分钟探测恢复一次”的策略。结果下游服务恢复的时候三层降级同时触发恢复探测瞬间把下游打爆了导致刚缓过来的服务又被干趴下。后来我把恢复探测做了分散化不同环节的恢复探测时间随机化比如在 4 到 8 分钟之间随机选一个时间并且配置了“恢复探测并发上限”。这样下游恢复时探测流量是逐步增加的不会形成尖峰。4.3 可观测性是降级系统的重要组成部分降级方案做得好不好没有监控数据就是盲人摸象。我为每个降级动作都埋了指标降级触发次数按降级类型打点。降级后的成功率判断降级方案本身是否有效。降级恢复的耗时看系统是否及时回到正常状态。用户受影响面降级期间有多少任务走了非理想路径。这三项监控指标我建议你一定要加上。等到线上真的出问题的时候你会发现没有这些数据你根本不知道从哪里开始排查降级方案也形同虚设。4.4 降级不是万能药最终兜底还需要“人工”最后一个经验是降级方案能做到的是“不让系统直接挂掉”但有些业务场景仍然需要人在回路里做最终决策。比如财务相关的操作高并发场景下系统降级成什么都要确保这笔账能对得上。所以我在编排系统里设计了一个“降级 人工确认”的联动机制——当自动降级连续触发多次时自动创建一个人工复核任务推给值班人员。值班人员只要在处理列表里点一下“确认”或“驳回”后续流程才会继续走。这套机制上线之后生产环境里好几次第三方接口长期故障系统都没有完全中断人工介入后也很快导流到可用路径。可以说这是整轮降级改造里争议最大、但事后效果最好的一块。写到最后再说一个个人体会。给每个环节都加失败降级表面上是技术方案实际上是一种心态转变——从“期待系统永远正常”变成“接受系统会出故障但保证故障可控”。这种转变发生之后你再设计系统时看问题的角度就会完全不一样会本能地去想“如果这里挂了会发生什么我要怎么让它别挂那么惨”。这套思路应用到 Agent 编排的每一个细节里之后我这里的线上稳定性有了质的提升值班期间能睡个踏实觉了。
生产环境 Agent 编排我为什么给每个环节都加了失败降级凌晨 2 点 47 分监控告警把我从梦里拽了出来。生产环境的某个 Agent 工作流卡在了“调用外部工具”这一步上下游全部堵死队列里的任务越堆越多。我爬起来看了一眼日志发现是第三方接口响应超时但我们的编排引擎还在傻傻地等它重试导致后面的环节全部阻塞。那个瞬间我意识到Agent 编排系统不是不能出故障而是不能在故障面前毫无弹性。从那之后我给自己定了一条铁律——每个环节都要有降级方案而且要能真正落到生产上。这篇内容适合正在做 Agent 系统、任务编排、工作流引擎的开发者参考也适合那些把 Agent 接进业务系统后发现一挂全挂、无从下手的团队看一看。我把我自己踩过的坑、改过的代码、线上压测的经验都整理出来希望能帮你在设计阶段就少走弯路。1. 为什么 Agent 编排必须默认“一定会失败”先说一个反直觉的结论越是复杂的 Agent 编排越不能按“所有环节都正常工作”的假设来设计。原因很简单链条太长了任何一个点出问题都会沿着调用链传导。1.1 一条 Agent 链路里藏着多少个“脆弱点”我手头的一个典型 Agent 任务是这样的接收用户请求 → 调用语义理解模块 → 决策引擎选择工具 → 调用外部 API → 获取结果 → 汇总结论 → 回复用户。看起来只有七步但每一步背后都有隐藏的依赖——模型服务、向量库、Redis、消息队列、第三方 API、网关、对象存储随便数一数就是十几个组件。在生产环境待得久了你就会发现这些组件的可靠性是参差不齐的。模型服务偶尔会超时或返回乱码第三方 API 会在高峰期限流Redis 可能出现慢查询甚至网络抖动都能让一次原本 200 毫秒的调用变成 3 秒。如果一个编排系统对这些“小毛刺”不做处理后果就是任务失败、重试风暴、数据不一致运维群里一片哀嚎。1.2 失败的传导比你想的更可怕很多人觉得“某个环节失败了把这个任务标记为失败不就行了”。问题是编排系统里的任务往往是链式的一个任务失败了依赖它的下游任务也会失败。更麻烦的是如果重试机制设计得不合理失败的任务会在高峰期反复重试把系统资源吃掉一大半反而让本来正常的任务也跟着失败。我做了一次线上故障复盘某次第三方接口出现抖动持续了大概 20 分钟。我们的编排引擎默认重试 3 次每次间隔 5 秒结果那 20 分钟里系统内部产生了近 2 万次无效重试把数据库连接池和线程池都打满了。最后故障面从“单个接口超时”扩大到了“整个编排服务不可用”。那一刻我才彻底明白——失败不可怕可怕的是没有降级策略让失败无限传导。1.3 “降级”不是退步是给系统装保险丝降级这个词听起来像是“能力缩水”但实际上它是在说当系统无法按最理想的方式运行时你能不能提供一个虽然不是最优、但依然可用的替代方案。就像开车的时候备胎不是让你开不快而是让你不至于半路抛锚。在我的编排系统里降级方案的基本思路就一条——保留核心流程砍掉非核心依赖失败时给出可接受的兜底结果。核心流程必须要走完不能因为某个辅助功能挂了就整个链路停摆。2. 我的降级分层设计从模型调用到结果回传我做的降级不是笼统地“整个流程加 try-catch”而是按照调用链路上每一类环节的特点分别设计降级策略。分得越细致降级效果越好。2.1 模型服务层的降级超时、换路、简化Agent 的“大脑”是模型服务这一层也是最容易出现故障的地方。模型服务出问题通常有三种表现响应超时、返回格式异常、内容质量明显下降。针对这三种情况我分别做了不同的处理。第一层是超时控制。我给模型调用设置了多级超时时间比如“首字延迟 5 秒、总响应 30 秒”超过任何一个阈值就直接断开。这里的关键是不要用“无限等待”的默认配置生产环境的超时必须设得比训练环境更激进。第二层是模型路由切换。如果主模型的连续失败率达到阈值通过一个配置中心动态切换到备用模型。备用的模型效果差一点但至少能完成任务。降级后的模型选择、参数配置都会由配置中心自动推送整个过程业务方无感知。第三层是简化版本。如果主备模型都不可用就退而求其次用精简版的提示词模板走一遍把 Agent 从“深度思考模式”降为“快速应答模式”保证用户不用干等。这套分层降级落实之后模型服务出问题的时候业务中断率明显下降故障期间贴反馈也平和了不少。2.2 工具调用层的降级重试、换源、缓存兜底Agent 编排里工具调用是另一个重灾区。我在这里总结了一个四挡降级策略第一挡是快速重试第二挡是换备用工具第三挡是降缓存或死数据第四挡才是放弃本次调用并标记人工处理。重试的时候有个细节——退避时间必须带随机抖动。我见过很多团队直接用固定间隔重试结果一遇到故障所有任务都在同一个时间点重试形成“惊群效应”。我现在的实现是「指数退避 随机抖动」第一次重试等 500 毫秒到 1000 毫秒之间随机一个值第二次 2 到 4 秒之间随机第三次之后封顶 30 秒。实测下来这套重试策略对下游服务的压力少了百分之四十以上。工具调用还有一个容易忽略的坑不是所有重试都安全。对于“查询型”工具重试十次都没问题但“下单型”“转帐型”这类有副作用的操作盲目重试会造成重复扣款或重复发货。对这类工具我的策略是“幂等键 失败后转人工确认”绝不自动重试。2.3 数据访问层的降级缓存“兜底”是最后一根稻草Agent 执行过程中经常要查知识库、用户画像、历史订单等数据。数据源一旦超时或报错很多编排上会直接抛异常。我的做法是给常用数据加一层“本地内存缓存 Redis 缓存”的双层兜底缓存过期时间设得比较长宁可数据稍微旧一点也不能让任务失败。在执行数据访问降级的时候我用的规则是数据新鲜度优先级低于流程完成度。也就是说如果拿不到最新数据就用最近一次成功缓存的数据来继续流程。比如查库存的时候数据库超时了就返回缓存里上一次查到的库存数量并在最终结果里标注“库存信息可能滞后”让下游环节或者人工去判断是否采纳。2.4 调度引擎层的降级并行转串行、异步转同步编排引擎本身也要有降级能力。我之前遇到过一个很典型的场景某个环节依赖的组件不稳定导致并行分片大面积卡住整体吞吐降到几乎为 0。后来我加了一个动态调度策略——当某个环节的超时率超过阈值时自动把并行分支改为串行执行。虽然串行会变慢但至少每个任务都有机会完成不会因为任务积压导致整体雪崩。展开来说这套策略分成三个层级正常状态并行执行多个分支追求吞吐量。过载状态降为半并行控制同时执行的分支数量。熔断状态降为串行逐条处理保证任务不丢。切换动作通过一个分布式的协调组件下发不用重启服务也不用人工干预。我在生产环境压测过这个“并行转串行”的动作能在 10 秒内完成对正在执行的任务影响极小。3. 具体的降级实现代码级别怎么做方案说得再好落地才是关键。我挑三个最核心的环节把具体实现拆开来讲代码可以直接抄抄完根据自己的业务改改参数就能用。3.1 模型调用的降级封装我会封装一个统一的模型调用入口所有 Agent 的模型请求都走这个入口。内部实现一个降级路由根据配置决定调用主模型、备用模型还是简化模型。import time import random from typing import Any, Dict class ModelRouter: def __init__(self, config: Dict[str, Any]): self.config config self.failure_count 0 self.degraded False def call(self, prompt: str, use_cache: bool True) - str: if use_cache: cached self._get_cache(prompt) if cached: return cached # 第一层主模型 if not self.degraded: try: start time.time() result self._call_main_model(prompt, timeout20) self.failure_count 0 self._set_cache(prompt, result) return result except TimeoutError: self.failure_count 1 if self.failure_count 5: self.degraded True # 进入降级模式 except Exception: self.failure_count 1 if self.failure_count 3: self.degraded True # 第二层备用模型 try: return self._call_backup_model(prompt, timeout10) except Exception: # 第三层简化模型用固定模板快速响应 return self._call_simplified_model(prompt)这个封装看起来简单但有几个细节值得注意降级状态是“粘性”的一旦触发降级不会马上恢复。我用的是一个半开状态机制——每 5 分钟尝试恢复一次主模型成功一次就把降级状态关掉。缓存优先同一问题的结果在短时间内直接返回既省成本又省时间。超时时间是动态的主模型 20 秒、备用模型 10 秒确保降级后用户等待时间更短。3.2 工具调用的降级编排工具调用的降级核心是“按操作类型区分策略”。我用一个装饰器来标记每个工具的类型然后由执行器根据类型选择降级策略。import time import random from enum import Enum from functools import wraps class ToolType(Enum): QUERY query # 查询型可以安全重试 ACTION action # 操作型不能盲目重试 EXTERNAL external # 外部依赖型需要特殊处理 def tool(tool_type: ToolType, max_retries: int 3): def decorator(func): wraps(func) def wrapper(*args, **kwargs): if tool_type ToolType.QUERY: return _query_with_retry(func, max_retries, *args, **kwargs) elif tool_type ToolType.ACTION: return _action_with_idempotency(func, *args, **kwargs) else: return _external_with_circuit_breaker(func, *args, **kwargs) return wrapper return decorator def _query_with_retry(func, max_retries, *args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: wait min(30, (2 ** attempt) random.uniform(0, 1)) time.sleep(wait) return None # 最终返回 None由上层决定下一步 def _action_with_idempotency(func, *args, **kwargs): kwargs[idempotency_key] kwargs.get(idempotency_key, str(time.time_ns())) try: return func(*args, **kwargs) except Exception: # 操作型失败直接抛给上层转人工处理 raise def _external_with_circuit_breaker(func, *args, **kwargs): # 熔断器逻辑失败率过高时直接短路 if external_breaker.is_open(): return _fallback_external_result(*args, **kwargs) try: return func(*args, **kwargs) except Exception: external_breaker.record_failure() return _fallback_external_result(*args, **kwargs)这个实现里最重要的决策是“查询型允许重试、操作型禁止重试”。实际操作中我发现把这条规则刻在每个开发者的脑子里非常难所以干脆从代码级别强制约束——用ToolType枚举约束每一个工具的降级行为。这样同类工具统一处理不容易出错。3.3 编排引擎的熔断与半开恢复编排引擎本身的降级我用了一个轻量级的熔断器来保护各个环节。核心逻辑是记录最近 1 分钟内的调用成功率和耗时。成功率低于阈值或平均耗时超过预期就把该环节标记为“熔断”。熔断状态下新请求直接走降级路径不实际调用下游。每 30 秒尝试一次半开探测放少量请求过去看下游是否恢复。# 伪代码熔断器的状态转换 # 状态: CLOSED - OPEN - HALF_OPEN - CLOSED/OPEN # 关键参数 # request_volume_threshold: 10 # 1分钟内最少请求数低于这个数不触发熔断 # error_ratio_threshold: 0.5 # 错误率超过 50% 触发熔断 # open_timeout: 30 # 熔断持续时间 30 秒 # half_open_max_calls: 3 # 半开状态最多放 3 个请求探测熔断器的参数需要根据业务特性调整。比如内部 API 可以激进一点错误率阈值设低一些、熔断时间设短一些第三方 API 则保守一些熔断时间拉长避免频繁打断第三方服务可能存在的慢恢复过程。4. 降级踩坑实录与排查锦囊降级方案上线之后并不能一劳永逸。我在生产环境里遇到的问题不少有些已经彻底解决有些还在持续优化。挑几个典型的聊一聊。4.1 降级被“误触发”远比“不触发”更频繁我起初把降级阈值设得太敏感结果正常波动也会触发降级。比如某个外部接口偶尔会有一两次超过 3 秒的响应正常时候平均只要 200 毫秒。按“平均耗时超过 1 秒就熔断”的规则每天都在误触发。后来我把熔断条件改成“1 分钟内请求量超过 10 次且错误率超过 50% 或 p99 耗时超过 5 秒”双重条件误触发率才降下来。这个经验是降级的触发条件要同时看“量”和“率”不能只看平均耗时平均耗时很容易被极端值拉偏。4.2 多级降级的“恢复”动作会造成二次故障我在一个时间段内同时给三层都配了“每 5 分钟探测恢复一次”的策略。结果下游服务恢复的时候三层降级同时触发恢复探测瞬间把下游打爆了导致刚缓过来的服务又被干趴下。后来我把恢复探测做了分散化不同环节的恢复探测时间随机化比如在 4 到 8 分钟之间随机选一个时间并且配置了“恢复探测并发上限”。这样下游恢复时探测流量是逐步增加的不会形成尖峰。4.3 可观测性是降级系统的重要组成部分降级方案做得好不好没有监控数据就是盲人摸象。我为每个降级动作都埋了指标降级触发次数按降级类型打点。降级后的成功率判断降级方案本身是否有效。降级恢复的耗时看系统是否及时回到正常状态。用户受影响面降级期间有多少任务走了非理想路径。这三项监控指标我建议你一定要加上。等到线上真的出问题的时候你会发现没有这些数据你根本不知道从哪里开始排查降级方案也形同虚设。4.4 降级不是万能药最终兜底还需要“人工”最后一个经验是降级方案能做到的是“不让系统直接挂掉”但有些业务场景仍然需要人在回路里做最终决策。比如财务相关的操作高并发场景下系统降级成什么都要确保这笔账能对得上。所以我在编排系统里设计了一个“降级 人工确认”的联动机制——当自动降级连续触发多次时自动创建一个人工复核任务推给值班人员。值班人员只要在处理列表里点一下“确认”或“驳回”后续流程才会继续走。这套机制上线之后生产环境里好几次第三方接口长期故障系统都没有完全中断人工介入后也很快导流到可用路径。可以说这是整轮降级改造里争议最大、但事后效果最好的一块。写到最后再说一个个人体会。给每个环节都加失败降级表面上是技术方案实际上是一种心态转变——从“期待系统永远正常”变成“接受系统会出故障但保证故障可控”。这种转变发生之后你再设计系统时看问题的角度就会完全不一样会本能地去想“如果这里挂了会发生什么我要怎么让它别挂那么惨”。这套思路应用到 Agent 编排的每一个细节里之后我这里的线上稳定性有了质的提升值班期间能睡个踏实觉了。
