1. 从agency-agents这个名字说起一个被低估的架构信号第一次看到agency-agents这个命名我的直觉是这不是一个随手起的项目名。在软件工程里命名往往暴露了作者对系统边界的思考方式。agency 指向的是代理机构或中介服务这一业务语义而 agents 用的是复数说明系统里存在多个协同工作的代理实体。把这两个词拼在一起基本可以判断这是一个面向多代理协作的服务型系统而不是单体的工具脚本。我在实际接触这类项目时发现很多人第一眼会把它误读成某个爬虫代理池或者某个 AI Agent 框架的 demo。这两种误读都很常见但都偏离了重点。代理池解决的是网络请求的出口问题AI Agent 框架解决的是单智能体的推理编排问题而agency-agents这个命名暗示的是一个中介层——它站在业务请求和底层执行者之间负责调度、路由、状态管理这一整套中介机构该干的活。为什么这个区分很重要因为一旦你把它当成代理池你会去关心 IP 轮换、并发上限一旦你把它当成 Agent 框架你会去关心 prompt 模板、工具调用协议。但如果你把它当成一个中介调度系统你真正该关心的是任务怎么分发、代理怎么注册、状态怎么同步、失败怎么兜底。这三条路的技术选型和代码结构完全不同走错了方向后面全是返工。这篇文章我想做的事情很明确把这个标题背后可能对应的系统拆开讲清楚一个多代理中介系统从零搭建时哪些设计决策是真正影响成败的哪些是看起来重要其实可以后置的。我会用从业者的视角把架构选型、代理注册、任务路由、状态一致性、故障处理这几个核心环节讲透并且给出可以直接参考的代码骨架和参数配置。不管你是要复现一个类似系统还是接手了一个叫类似名字的代码库这篇内容都能帮你少走弯路。适合的读者范围我划一下有基本后端开发经验、理解 HTTP 和进程模型、写过多进程或多线程程序的人读起来会最顺。如果你只是好奇多代理系统长什么样也能看懂但部分代码细节需要你补一下基础。2. 拆解中介 多代理这个组合到底在解决什么问题2.1 为什么不是单体也不是纯消息队列先回答一个最根本的问题为什么需要中介这一层直接把任务丢给执行者不行吗在代理数量少于 3 个、任务类型单一的场景下确实不需要中介。你写个 for 循环挨个调用就行。但一旦代理数量上到两位数任务类型出现分化有的代理擅长长任务、有的擅长短平快、有的只能处理特定格式的输入直接调用的复杂度会呈指数上升。调用方需要知道每个代理的能力、当前负载、健康状态这本身就是一份需要维护的代理目录。消息队列能解决一部分问题——它把生产者和消费者解耦了。但消息队列解决不了能力路由。队列不知道哪个消费者擅长处理图片、哪个擅长处理文本它只负责把消息投递出去。而中介层的核心价值恰恰在于它知道每个代理的能力画像能根据任务特征做定向分发。我用一个生活化的类比来解释这个层次关系。消息队列像是一个小区的快递柜谁都能往里放、谁都能来取但它不负责判断这个包裹该给哪户人家。中介层像是小区物业的前台它认识每一户住户知道 3 号楼 502 家里白天有人、知道 7 号楼 101 经常收生鲜需要冷链包裹到了前台它会根据这些信息决定通知谁、怎么送。agency-agents里的 agency 干的就是前台的活。2.2 代理的三种典型角色划分在一个成熟的中介系统里代理通常不会只有一种。根据我见过的实现角色大致分三类角色类型职责典型特征数量级执行代理实际处理任务无状态、可水平扩展多协调代理拆分任务、汇总结果有状态、数量少少哨兵代理健康检查、指标上报轻量、常驻中执行代理是干活的主力它们应该是无状态的这样任何一个实例挂掉都不影响整体中介层重新分发即可。协调代理负责把一个大任务拆成子任务再把子结果拼回去它需要维护任务上下文所以是有状态的数量不能多否则状态同步成本会爆炸。哨兵代理是很多人会忽略的一环它不处理业务只负责告诉中介层我还活着、我当前负载多少这是实现动态路由的前提。提示新手最容易犯的错是把协调逻辑写进执行代理里。一旦执行代理开始维护任务上下文它就失去了无状态特性水平扩展立刻变成噩梦。协调逻辑必须单独抽出来。2.3 中介层的能力画像维护机制中介层要能做智能路由前提是它手里有一份准确的代理能力画像。这份画像怎么来两种方式静态注册和动态上报。静态注册是启动时写死在配置文件里简单但僵化代理扩容后要改配置重启。动态上报是代理启动后主动向中介层注册自己的能力中介层维护一个实时表。生产环境我强烈建议用动态上报配合心跳机制剔除失联代理。画像里至少要包含这几个字段代理 ID、能力标签能处理哪些任务类型、当前并发数、最大并发数、最近一次心跳时间、历史成功率。前四个字段决定能不能派给它后两个字段决定该不该派给它。一个成功率只有 60% 的代理即使当前空闲也不应该优先派发任务。3. 代理注册与心跳整个系统的地基3.1 注册协议的设计取舍注册协议看起来简单其实藏着不少坑。最朴素的做法是代理启动后发一个 HTTP POST 到中介层带上自己的信息。但这里有个时序问题如果中介层还没启动代理的注册请求就失败了代理会一直重试直到成功吗如果代理先启动、中介层后启动中介层怎么发现已经存在的代理我的经验是注册和心跳用同一套接口但语义分开。注册是我来了心跳是我还在。代理启动后先尝试注册失败就退避重试注册成功后进入心跳循环每隔固定间隔发一次心跳。中介层收到心跳就刷新该代理的活跃时间超过阈值没收到就标记为失联。退避重试的策略很关键。不要用固定间隔重试那样在中介层长时间不可用时会产生大量无效请求。用指数退避第一次等 1 秒第二次 2 秒第三次 4 秒上限封顶到 30 秒。这样既保证恢复后能快速重连又不会在故障期间打爆中介层。import time import random def register_with_backoff(register_func, max_retries10): 带指数退避的注册重试 base_delay 1.0 max_delay 30.0 for attempt in range(max_retries): try: result register_func() if result.get(ok): return True except Exception as e: pass # 指数退避 随机抖动避免多个代理同时重试 delay min(base_delay * (2 ** attempt), max_delay) delay delay * (0.5 random.random() * 0.5) time.sleep(delay) return False注意那个随机抖动。如果 50 个代理同时启动、同时失败、同时重试它们会在同一时刻再次冲击中介层这叫惊群效应。加上 0.5 到 1.0 倍的随机因子能把重试时间打散中介层的压力曲线会平滑很多。3.2 心跳间隔与失联判定的参数计算心跳间隔设多少合适这个不能拍脑袋。它取决于两个因素你能容忍多长的故障发现延迟以及你能承受多大的心跳流量。假设你有 100 个代理心跳间隔设为 10 秒那么中介层每秒收到 10 个心跳请求。这个量级对任何中介层都是小菜一碟。失联判定阈值一般设为心跳间隔的 3 倍也就是 30 秒没心跳就判定失联。为什么是 3 倍而不是 2 倍因为网络抖动、GC 停顿、瞬时负载高峰都可能导致单次心跳延迟2 倍阈值容易误判3 倍是实践中比较稳的平衡点。如果代理数量上到 1000 个10 秒间隔意味着每秒 100 个心跳这时候就要考虑把心跳接口做得极轻量——不查数据库、不写日志、只更新内存里的时间戳。中介层的内存表用代理 ID 做 key值是最后心跳时间戳这个操作是 O(1) 的1000 个代理每秒 100 次更新完全无压力。3.3 代理下线时的优雅退出代理不能想退就退。如果它正在处理任务时被强制杀掉那个任务就丢了。优雅退出的流程应该是代理收到退出信号后先向中介层发送我要下线的通知中介层把它标记为排空中不再给它派发新任务代理处理完手头的任务后再发一个已下线确认中介层把它从活跃表里移除。这个排空过程需要设一个超时上限比如 60 秒。如果代理手头的任务超过 60 秒还没处理完说明可能卡住了这时候强制退出把任务标记为失败让中介层重新分发。没有超时的排空会导致代理永远退不出去运维上很头疼。4. 任务路由中介层最核心的决策逻辑4.1 路由决策的输入变量中介层收到一个任务后要决定派给哪个代理。这个决策依赖哪些输入我梳理了一下至少有这么几类任务的能力需求这个任务需要什么能力标签候选代理的匹配度哪些代理有这个标签候选代理的当前负载并发数 / 最大并发数候选代理的历史成功率候选代理的响应延迟最近 N 次任务的平均耗时前两个是硬性过滤条件不满足直接排除。后三个是排序依据决定在满足条件的代理里选哪个。很多人只做了前两个结果就是任务全压到第一个注册的代理上其他代理闲着负载严重不均。4.2 加权评分路由的实现我给一个实际用过的加权评分公式简单但有效score w1 * (1 - load_ratio) w2 * success_rate w3 * (1 - normalized_latency)其中load_ratio是当前并发除以最大并发success_rate是历史成功率normalized_latency是延迟归一化到 0-1 区间的值。三个权重 w1、w2、w3 加起来等于 1具体取值看业务侧重。如果任务对延迟敏感w3 调大如果任务不能失败w2 调大。def compute_score(agent, weights(0.4, 0.4, 0.2)): w1, w2, w3 weights load_ratio agent[current] / max(agent[capacity], 1) success_rate agent[success] / max(agent[total], 1) # 延迟归一化假设 5 秒是上限 norm_latency min(agent[avg_latency] / 5.0, 1.0) return (w1 * (1 - load_ratio) w2 * success_rate w3 * (1 - norm_latency)) def pick_agent(candidates, weights(0.4, 0.4, 0.2)): if not candidates: return None scored [(compute_score(a, weights), a) for a in candidates] scored.sort(keylambda x: x[0], reverseTrue) return scored[0][1]这个公式的好处是可解释。当路由结果不符合预期时你能算出每个代理的得分看清楚是哪个因子拖了后腿。比那些黑盒的负载均衡算法好调试得多。4.3 任务队列与背压处理当所有代理都满载时新任务怎么办三个选择拒绝、排队、降级。拒绝最简单直接返回系统繁忙让调用方自己重试。适合对实时性要求高、可以容忍失败的场景。排队是把任务放进队列等代理空闲适合不能丢任务但可以等的场景。降级是把任务交给能力稍弱但空闲的代理处理适合任务有弹性空间的场景。我一般会组合使用先尝试路由路由不到就进队列队列满了就拒绝。队列长度要设上限不然内存会被撑爆。上限设多少看单个任务的平均大小和你能给队列分配的内存。假设单任务平均 10KB你愿意给队列 100MB那上限就是 1 万个任务。注意队列里的任务要有超时时间。一个任务在队列里躺了 5 分钟还没被处理大概率是系统出了结构性问题这时候应该让它失败并告警而不是无限期等待。5. 状态一致性多代理系统里最容易翻车的地方5.1 任务状态的流转模型一个任务从进入系统到完成状态会经历多次变化。我建议用状态机来管理明确定义每个状态和允许的转移状态含义可转移到pending已接收待路由routing, cancelledrouting路由中dispatched, faileddispatched已派发代理处理中completed, failed, timeoutcompleted成功完成终态failed处理失败终态timeout超时终态cancelled被取消终态状态机的好处是任何非法转移都会被立刻发现。比如一个已经 completed 的任务又收到 completed 事件说明有重复上报这时候要幂等处理而不是重复记录。5.2 重复派发与幂等处理分布式系统里重复派发几乎无法完全避免。中介层派发任务后如果代理的确认响应丢了中介层会认为派发失败并重试结果代理收到了两次同样的任务。解决办法是给每个任务一个全局唯一的 ID代理处理前先检查这个 ID 是否已经处理过。已经处理过的直接返回上次的结果不再重复执行。这个已处理 ID 集合要设过期时间不然会无限增长。过期时间设为任务最大可能耗时的 2 倍就够了。class IdempotentExecutor: def __init__(self, ttl_seconds600): self.processed {} # task_id - (result, timestamp) self.ttl ttl_seconds def execute(self, task_id, handler): now time.time() # 清理过期记录 self.processed { k: v for k, v in self.processed.items() if now - v[1] self.ttl } if task_id in self.processed: return self.processed[task_id][0] result handler() self.processed[task_id] (result, now) return result5.3 中介层重启后的状态恢复中介层如果挂了重启内存里的任务状态全丢了怎么办这是很多人上线后才发现的坑。解决办法是把关键状态持久化但不是所有状态都需要持久化。我的建议是任务状态持久化代理画像不持久化。任务状态丢了会导致任务永远卡住必须持久化。代理画像丢了没关系代理的心跳会重新把它注册回来几秒钟就恢复了。持久化用轻量的方案就行比如 SQLite 或者 Redis不用上重型数据库。持久化的频率也要控制。每个状态变更都写一次数据库在高并发下会成为瓶颈。可以批量写攒够 100 条或者每隔 1 秒写一次。代价是中介层崩溃时可能丢失最后 1 秒的状态变更这个损失通常可以接受。6. 故障处理把意外变成预期6.1 代理处理超时的分级处理代理处理任务超时了怎么处理不能一刀切。我一般分三级第一级软超时。任务处理时间超过预期但还在跑中介层记录一个警告不打断。第二级硬超时。超过硬性上限中介层标记任务失败重新派发给其他代理。第三级僵死检测。代理连续多次超时中介层把它标记为不健康暂停派发新任务给它。软超时和硬超时的阈值怎么定看任务的历史耗时分布。取 P95 耗时作为软超时P99 耗时的 2 倍作为硬超时。这样 95% 的正常任务不会触发警告99% 的任务不会被打断只有真正异常的才会被处理。6.2 中介层自身的单点问题中介层是整个系统的单点它挂了整个系统就瘫了。怎么破两个方向主备切换和多中介分片。主备切换是部署两个中介层实例一个主一个备主挂了备顶上。难点在于状态同步主备之间要实时同步任务状态和代理画像。用共享存储比如 Redis来存状态主备都读写同一个存储切换时状态就是连续的。多中介分片是把代理按某种规则分到多个中介层下每个中介层只管自己那部分代理。这样单个中介层挂了只影响一部分代理。分片规则可以按代理 ID 哈希也可以按能力标签分。代价是跨分片的任务路由变复杂了需要中介层之间互相转发。小规模系统用主备就够了规模上去了再考虑分片。不要一上来就搞分片复杂度太高容易把自己绕进去。6.3 告警阈值的设置经验告警设得太灵敏天天误报运维会麻木设得太迟钝真出事了才发现。我的经验是分三档提示级任务失败率超过 1%或者队列长度超过容量的 50%。发到群里不叫人。警告级任务失败率超过 5%或者队列长度超过容量的 80%或者失联代理超过 10%。发到群里并 值班人。严重级任务失败率超过 20%或者队列满了或者中介层无响应。直接打电话。阈值不是拍脑袋定的要跑一段时间看基线。系统平稳运行一周看看失败率的正常波动范围把提示级设在正常上限的 1.5 倍左右。这样既不会天天误报又能在真正异常时及时触发。7. 我在实际搭建这类系统时踩过的几个坑第一个坑是代理能力标签设计得太细。一开始我给每个代理打了十几个标签结果路由时匹配逻辑复杂得要命而且经常出现没有代理同时满足所有标签的情况。后来改成三层标签大类文本/图像/音频、子类具体任务类型、特性是否需要 GPU、是否支持长任务。路由时先按大类筛再按子类筛特性作为加分项而不是硬性条件。这样匹配成功率高了很多。第二个坑是心跳和业务请求共用连接池。代理的心跳请求和业务请求如果走同一个 HTTP 连接池业务请求一忙心跳就被挤掉了中介层误判代理失联。后来我把心跳单独走一个轻量连接和业务请求完全隔离问题就没了。这个坑很隐蔽因为平时看不出来只有业务高峰期才暴露。第三个坑是任务结果太大导致中介层内存暴涨。有些任务的结果是几 MB 的数据中介层如果全缓存在内存里等调用方来取几百个任务就能把内存吃光。解决办法是结果不经过中介层代理直接把结果写到对象存储只把存储路径返回给中介层。中介层只传路径不传数据内存占用立刻降下来了。第四个坑是日志打得太全反而找不到问题。一开始每个任务的每次状态变更都打日志一天几个 G出问题时 grep 半天。后来改成结构化日志只记录关键字段任务 ID、状态、代理 ID、耗时并且按任务 ID 建索引。查一个问题从几分钟缩短到几秒钟。提示结构化日志的字段设计要提前想好。任务 ID、代理 ID、状态、时间戳、耗时、错误码这六个字段基本能覆盖 90% 的排查场景。别等到日志堆成山了才想起来重构。8. 从能跑到好用几个值得投入的优化方向系统能跑起来只是第一步真正拉开差距的是这些优化。代理预热。代理刚启动时各种缓存都是冷的处理第一批任务会特别慢。可以在代理启动后先跑几个模拟任务把缓存和连接池预热起来再向中介层注册。这样它接到的第一个真实任务就是热状态延迟稳定。路由结果缓存。如果任务类型高度重复可以把任务特征 - 代理 ID的映射缓存起来下次遇到相同特征的任务直接命中缓存跳过评分计算。缓存要设短过期时间比如 10 秒因为代理负载是实时变化的缓存太久会导致路由决策过时。批量心跳。代理数量多的时候可以让代理把多次心跳攒起来批量发减少请求数。但要注意批量间隔不能太长否则失联判定会延迟。折中方案是正常时单发网络抖动时自动切换到批量模式。优雅降级。当系统负载超过容量时主动关闭一些非核心功能把资源让给核心任务。比如暂停哨兵代理的详细指标上报只保留最基础的心跳。降级策略要提前定义好出事时直接触发不要临时想。这些优化不需要一次性全做按投入产出比排序先做预热和缓存这两个见效最快。批量心跳和降级是规模上来之后才需要考虑的。我在实际项目里的体会是这类系统的复杂度不在于单个模块有多难而在于模块之间的交互边界要划清楚。注册归注册、路由归路由、状态归状态每个模块只干一件事出问题时才能快速定位。最怕的就是为了省事把逻辑揉在一起前期开发快后期维护能把人逼疯。如果你正在搭类似的系统建议先把接口定义清楚哪怕实现先用最笨的办法接口清晰了后面替换实现成本很低。
1. 从agency-agents这个名字说起一个被低估的架构信号第一次看到agency-agents这个命名我的直觉是这不是一个随手起的项目名。在软件工程里命名往往暴露了作者对系统边界的思考方式。agency 指向的是代理机构或中介服务这一业务语义而 agents 用的是复数说明系统里存在多个协同工作的代理实体。把这两个词拼在一起基本可以判断这是一个面向多代理协作的服务型系统而不是单体的工具脚本。我在实际接触这类项目时发现很多人第一眼会把它误读成某个爬虫代理池或者某个 AI Agent 框架的 demo。这两种误读都很常见但都偏离了重点。代理池解决的是网络请求的出口问题AI Agent 框架解决的是单智能体的推理编排问题而agency-agents这个命名暗示的是一个中介层——它站在业务请求和底层执行者之间负责调度、路由、状态管理这一整套中介机构该干的活。为什么这个区分很重要因为一旦你把它当成代理池你会去关心 IP 轮换、并发上限一旦你把它当成 Agent 框架你会去关心 prompt 模板、工具调用协议。但如果你把它当成一个中介调度系统你真正该关心的是任务怎么分发、代理怎么注册、状态怎么同步、失败怎么兜底。这三条路的技术选型和代码结构完全不同走错了方向后面全是返工。这篇文章我想做的事情很明确把这个标题背后可能对应的系统拆开讲清楚一个多代理中介系统从零搭建时哪些设计决策是真正影响成败的哪些是看起来重要其实可以后置的。我会用从业者的视角把架构选型、代理注册、任务路由、状态一致性、故障处理这几个核心环节讲透并且给出可以直接参考的代码骨架和参数配置。不管你是要复现一个类似系统还是接手了一个叫类似名字的代码库这篇内容都能帮你少走弯路。适合的读者范围我划一下有基本后端开发经验、理解 HTTP 和进程模型、写过多进程或多线程程序的人读起来会最顺。如果你只是好奇多代理系统长什么样也能看懂但部分代码细节需要你补一下基础。2. 拆解中介 多代理这个组合到底在解决什么问题2.1 为什么不是单体也不是纯消息队列先回答一个最根本的问题为什么需要中介这一层直接把任务丢给执行者不行吗在代理数量少于 3 个、任务类型单一的场景下确实不需要中介。你写个 for 循环挨个调用就行。但一旦代理数量上到两位数任务类型出现分化有的代理擅长长任务、有的擅长短平快、有的只能处理特定格式的输入直接调用的复杂度会呈指数上升。调用方需要知道每个代理的能力、当前负载、健康状态这本身就是一份需要维护的代理目录。消息队列能解决一部分问题——它把生产者和消费者解耦了。但消息队列解决不了能力路由。队列不知道哪个消费者擅长处理图片、哪个擅长处理文本它只负责把消息投递出去。而中介层的核心价值恰恰在于它知道每个代理的能力画像能根据任务特征做定向分发。我用一个生活化的类比来解释这个层次关系。消息队列像是一个小区的快递柜谁都能往里放、谁都能来取但它不负责判断这个包裹该给哪户人家。中介层像是小区物业的前台它认识每一户住户知道 3 号楼 502 家里白天有人、知道 7 号楼 101 经常收生鲜需要冷链包裹到了前台它会根据这些信息决定通知谁、怎么送。agency-agents里的 agency 干的就是前台的活。2.2 代理的三种典型角色划分在一个成熟的中介系统里代理通常不会只有一种。根据我见过的实现角色大致分三类角色类型职责典型特征数量级执行代理实际处理任务无状态、可水平扩展多协调代理拆分任务、汇总结果有状态、数量少少哨兵代理健康检查、指标上报轻量、常驻中执行代理是干活的主力它们应该是无状态的这样任何一个实例挂掉都不影响整体中介层重新分发即可。协调代理负责把一个大任务拆成子任务再把子结果拼回去它需要维护任务上下文所以是有状态的数量不能多否则状态同步成本会爆炸。哨兵代理是很多人会忽略的一环它不处理业务只负责告诉中介层我还活着、我当前负载多少这是实现动态路由的前提。提示新手最容易犯的错是把协调逻辑写进执行代理里。一旦执行代理开始维护任务上下文它就失去了无状态特性水平扩展立刻变成噩梦。协调逻辑必须单独抽出来。2.3 中介层的能力画像维护机制中介层要能做智能路由前提是它手里有一份准确的代理能力画像。这份画像怎么来两种方式静态注册和动态上报。静态注册是启动时写死在配置文件里简单但僵化代理扩容后要改配置重启。动态上报是代理启动后主动向中介层注册自己的能力中介层维护一个实时表。生产环境我强烈建议用动态上报配合心跳机制剔除失联代理。画像里至少要包含这几个字段代理 ID、能力标签能处理哪些任务类型、当前并发数、最大并发数、最近一次心跳时间、历史成功率。前四个字段决定能不能派给它后两个字段决定该不该派给它。一个成功率只有 60% 的代理即使当前空闲也不应该优先派发任务。3. 代理注册与心跳整个系统的地基3.1 注册协议的设计取舍注册协议看起来简单其实藏着不少坑。最朴素的做法是代理启动后发一个 HTTP POST 到中介层带上自己的信息。但这里有个时序问题如果中介层还没启动代理的注册请求就失败了代理会一直重试直到成功吗如果代理先启动、中介层后启动中介层怎么发现已经存在的代理我的经验是注册和心跳用同一套接口但语义分开。注册是我来了心跳是我还在。代理启动后先尝试注册失败就退避重试注册成功后进入心跳循环每隔固定间隔发一次心跳。中介层收到心跳就刷新该代理的活跃时间超过阈值没收到就标记为失联。退避重试的策略很关键。不要用固定间隔重试那样在中介层长时间不可用时会产生大量无效请求。用指数退避第一次等 1 秒第二次 2 秒第三次 4 秒上限封顶到 30 秒。这样既保证恢复后能快速重连又不会在故障期间打爆中介层。import time import random def register_with_backoff(register_func, max_retries10): 带指数退避的注册重试 base_delay 1.0 max_delay 30.0 for attempt in range(max_retries): try: result register_func() if result.get(ok): return True except Exception as e: pass # 指数退避 随机抖动避免多个代理同时重试 delay min(base_delay * (2 ** attempt), max_delay) delay delay * (0.5 random.random() * 0.5) time.sleep(delay) return False注意那个随机抖动。如果 50 个代理同时启动、同时失败、同时重试它们会在同一时刻再次冲击中介层这叫惊群效应。加上 0.5 到 1.0 倍的随机因子能把重试时间打散中介层的压力曲线会平滑很多。3.2 心跳间隔与失联判定的参数计算心跳间隔设多少合适这个不能拍脑袋。它取决于两个因素你能容忍多长的故障发现延迟以及你能承受多大的心跳流量。假设你有 100 个代理心跳间隔设为 10 秒那么中介层每秒收到 10 个心跳请求。这个量级对任何中介层都是小菜一碟。失联判定阈值一般设为心跳间隔的 3 倍也就是 30 秒没心跳就判定失联。为什么是 3 倍而不是 2 倍因为网络抖动、GC 停顿、瞬时负载高峰都可能导致单次心跳延迟2 倍阈值容易误判3 倍是实践中比较稳的平衡点。如果代理数量上到 1000 个10 秒间隔意味着每秒 100 个心跳这时候就要考虑把心跳接口做得极轻量——不查数据库、不写日志、只更新内存里的时间戳。中介层的内存表用代理 ID 做 key值是最后心跳时间戳这个操作是 O(1) 的1000 个代理每秒 100 次更新完全无压力。3.3 代理下线时的优雅退出代理不能想退就退。如果它正在处理任务时被强制杀掉那个任务就丢了。优雅退出的流程应该是代理收到退出信号后先向中介层发送我要下线的通知中介层把它标记为排空中不再给它派发新任务代理处理完手头的任务后再发一个已下线确认中介层把它从活跃表里移除。这个排空过程需要设一个超时上限比如 60 秒。如果代理手头的任务超过 60 秒还没处理完说明可能卡住了这时候强制退出把任务标记为失败让中介层重新分发。没有超时的排空会导致代理永远退不出去运维上很头疼。4. 任务路由中介层最核心的决策逻辑4.1 路由决策的输入变量中介层收到一个任务后要决定派给哪个代理。这个决策依赖哪些输入我梳理了一下至少有这么几类任务的能力需求这个任务需要什么能力标签候选代理的匹配度哪些代理有这个标签候选代理的当前负载并发数 / 最大并发数候选代理的历史成功率候选代理的响应延迟最近 N 次任务的平均耗时前两个是硬性过滤条件不满足直接排除。后三个是排序依据决定在满足条件的代理里选哪个。很多人只做了前两个结果就是任务全压到第一个注册的代理上其他代理闲着负载严重不均。4.2 加权评分路由的实现我给一个实际用过的加权评分公式简单但有效score w1 * (1 - load_ratio) w2 * success_rate w3 * (1 - normalized_latency)其中load_ratio是当前并发除以最大并发success_rate是历史成功率normalized_latency是延迟归一化到 0-1 区间的值。三个权重 w1、w2、w3 加起来等于 1具体取值看业务侧重。如果任务对延迟敏感w3 调大如果任务不能失败w2 调大。def compute_score(agent, weights(0.4, 0.4, 0.2)): w1, w2, w3 weights load_ratio agent[current] / max(agent[capacity], 1) success_rate agent[success] / max(agent[total], 1) # 延迟归一化假设 5 秒是上限 norm_latency min(agent[avg_latency] / 5.0, 1.0) return (w1 * (1 - load_ratio) w2 * success_rate w3 * (1 - norm_latency)) def pick_agent(candidates, weights(0.4, 0.4, 0.2)): if not candidates: return None scored [(compute_score(a, weights), a) for a in candidates] scored.sort(keylambda x: x[0], reverseTrue) return scored[0][1]这个公式的好处是可解释。当路由结果不符合预期时你能算出每个代理的得分看清楚是哪个因子拖了后腿。比那些黑盒的负载均衡算法好调试得多。4.3 任务队列与背压处理当所有代理都满载时新任务怎么办三个选择拒绝、排队、降级。拒绝最简单直接返回系统繁忙让调用方自己重试。适合对实时性要求高、可以容忍失败的场景。排队是把任务放进队列等代理空闲适合不能丢任务但可以等的场景。降级是把任务交给能力稍弱但空闲的代理处理适合任务有弹性空间的场景。我一般会组合使用先尝试路由路由不到就进队列队列满了就拒绝。队列长度要设上限不然内存会被撑爆。上限设多少看单个任务的平均大小和你能给队列分配的内存。假设单任务平均 10KB你愿意给队列 100MB那上限就是 1 万个任务。注意队列里的任务要有超时时间。一个任务在队列里躺了 5 分钟还没被处理大概率是系统出了结构性问题这时候应该让它失败并告警而不是无限期等待。5. 状态一致性多代理系统里最容易翻车的地方5.1 任务状态的流转模型一个任务从进入系统到完成状态会经历多次变化。我建议用状态机来管理明确定义每个状态和允许的转移状态含义可转移到pending已接收待路由routing, cancelledrouting路由中dispatched, faileddispatched已派发代理处理中completed, failed, timeoutcompleted成功完成终态failed处理失败终态timeout超时终态cancelled被取消终态状态机的好处是任何非法转移都会被立刻发现。比如一个已经 completed 的任务又收到 completed 事件说明有重复上报这时候要幂等处理而不是重复记录。5.2 重复派发与幂等处理分布式系统里重复派发几乎无法完全避免。中介层派发任务后如果代理的确认响应丢了中介层会认为派发失败并重试结果代理收到了两次同样的任务。解决办法是给每个任务一个全局唯一的 ID代理处理前先检查这个 ID 是否已经处理过。已经处理过的直接返回上次的结果不再重复执行。这个已处理 ID 集合要设过期时间不然会无限增长。过期时间设为任务最大可能耗时的 2 倍就够了。class IdempotentExecutor: def __init__(self, ttl_seconds600): self.processed {} # task_id - (result, timestamp) self.ttl ttl_seconds def execute(self, task_id, handler): now time.time() # 清理过期记录 self.processed { k: v for k, v in self.processed.items() if now - v[1] self.ttl } if task_id in self.processed: return self.processed[task_id][0] result handler() self.processed[task_id] (result, now) return result5.3 中介层重启后的状态恢复中介层如果挂了重启内存里的任务状态全丢了怎么办这是很多人上线后才发现的坑。解决办法是把关键状态持久化但不是所有状态都需要持久化。我的建议是任务状态持久化代理画像不持久化。任务状态丢了会导致任务永远卡住必须持久化。代理画像丢了没关系代理的心跳会重新把它注册回来几秒钟就恢复了。持久化用轻量的方案就行比如 SQLite 或者 Redis不用上重型数据库。持久化的频率也要控制。每个状态变更都写一次数据库在高并发下会成为瓶颈。可以批量写攒够 100 条或者每隔 1 秒写一次。代价是中介层崩溃时可能丢失最后 1 秒的状态变更这个损失通常可以接受。6. 故障处理把意外变成预期6.1 代理处理超时的分级处理代理处理任务超时了怎么处理不能一刀切。我一般分三级第一级软超时。任务处理时间超过预期但还在跑中介层记录一个警告不打断。第二级硬超时。超过硬性上限中介层标记任务失败重新派发给其他代理。第三级僵死检测。代理连续多次超时中介层把它标记为不健康暂停派发新任务给它。软超时和硬超时的阈值怎么定看任务的历史耗时分布。取 P95 耗时作为软超时P99 耗时的 2 倍作为硬超时。这样 95% 的正常任务不会触发警告99% 的任务不会被打断只有真正异常的才会被处理。6.2 中介层自身的单点问题中介层是整个系统的单点它挂了整个系统就瘫了。怎么破两个方向主备切换和多中介分片。主备切换是部署两个中介层实例一个主一个备主挂了备顶上。难点在于状态同步主备之间要实时同步任务状态和代理画像。用共享存储比如 Redis来存状态主备都读写同一个存储切换时状态就是连续的。多中介分片是把代理按某种规则分到多个中介层下每个中介层只管自己那部分代理。这样单个中介层挂了只影响一部分代理。分片规则可以按代理 ID 哈希也可以按能力标签分。代价是跨分片的任务路由变复杂了需要中介层之间互相转发。小规模系统用主备就够了规模上去了再考虑分片。不要一上来就搞分片复杂度太高容易把自己绕进去。6.3 告警阈值的设置经验告警设得太灵敏天天误报运维会麻木设得太迟钝真出事了才发现。我的经验是分三档提示级任务失败率超过 1%或者队列长度超过容量的 50%。发到群里不叫人。警告级任务失败率超过 5%或者队列长度超过容量的 80%或者失联代理超过 10%。发到群里并 值班人。严重级任务失败率超过 20%或者队列满了或者中介层无响应。直接打电话。阈值不是拍脑袋定的要跑一段时间看基线。系统平稳运行一周看看失败率的正常波动范围把提示级设在正常上限的 1.5 倍左右。这样既不会天天误报又能在真正异常时及时触发。7. 我在实际搭建这类系统时踩过的几个坑第一个坑是代理能力标签设计得太细。一开始我给每个代理打了十几个标签结果路由时匹配逻辑复杂得要命而且经常出现没有代理同时满足所有标签的情况。后来改成三层标签大类文本/图像/音频、子类具体任务类型、特性是否需要 GPU、是否支持长任务。路由时先按大类筛再按子类筛特性作为加分项而不是硬性条件。这样匹配成功率高了很多。第二个坑是心跳和业务请求共用连接池。代理的心跳请求和业务请求如果走同一个 HTTP 连接池业务请求一忙心跳就被挤掉了中介层误判代理失联。后来我把心跳单独走一个轻量连接和业务请求完全隔离问题就没了。这个坑很隐蔽因为平时看不出来只有业务高峰期才暴露。第三个坑是任务结果太大导致中介层内存暴涨。有些任务的结果是几 MB 的数据中介层如果全缓存在内存里等调用方来取几百个任务就能把内存吃光。解决办法是结果不经过中介层代理直接把结果写到对象存储只把存储路径返回给中介层。中介层只传路径不传数据内存占用立刻降下来了。第四个坑是日志打得太全反而找不到问题。一开始每个任务的每次状态变更都打日志一天几个 G出问题时 grep 半天。后来改成结构化日志只记录关键字段任务 ID、状态、代理 ID、耗时并且按任务 ID 建索引。查一个问题从几分钟缩短到几秒钟。提示结构化日志的字段设计要提前想好。任务 ID、代理 ID、状态、时间戳、耗时、错误码这六个字段基本能覆盖 90% 的排查场景。别等到日志堆成山了才想起来重构。8. 从能跑到好用几个值得投入的优化方向系统能跑起来只是第一步真正拉开差距的是这些优化。代理预热。代理刚启动时各种缓存都是冷的处理第一批任务会特别慢。可以在代理启动后先跑几个模拟任务把缓存和连接池预热起来再向中介层注册。这样它接到的第一个真实任务就是热状态延迟稳定。路由结果缓存。如果任务类型高度重复可以把任务特征 - 代理 ID的映射缓存起来下次遇到相同特征的任务直接命中缓存跳过评分计算。缓存要设短过期时间比如 10 秒因为代理负载是实时变化的缓存太久会导致路由决策过时。批量心跳。代理数量多的时候可以让代理把多次心跳攒起来批量发减少请求数。但要注意批量间隔不能太长否则失联判定会延迟。折中方案是正常时单发网络抖动时自动切换到批量模式。优雅降级。当系统负载超过容量时主动关闭一些非核心功能把资源让给核心任务。比如暂停哨兵代理的详细指标上报只保留最基础的心跳。降级策略要提前定义好出事时直接触发不要临时想。这些优化不需要一次性全做按投入产出比排序先做预热和缓存这两个见效最快。批量心跳和降级是规模上来之后才需要考虑的。我在实际项目里的体会是这类系统的复杂度不在于单个模块有多难而在于模块之间的交互边界要划清楚。注册归注册、路由归路由、状态归状态每个模块只干一件事出问题时才能快速定位。最怕的就是为了省事把逻辑揉在一起前期开发快后期维护能把人逼疯。如果你正在搭类似的系统建议先把接口定义清楚哪怕实现先用最笨的办法接口清晰了后面替换实现成本很低。
