1. 为什么全局速率控制在分布式工作流里是个硬骨头先聊点实际的。做后端开发的兄弟应该都有过这种经历系统跑得好好的突然某个上游服务开始报429限流紧接着下游数据库连接被打满然后整个任务链路像多米诺骨牌一样连环崩掉。单体架构里我们会准备一个并发控制组件、一个令牌桶、或者干脆用一个分布式锁但这些手段放到分布式工作流引擎的场景里十分力只能使出三分。我最早是在一个跑批系统里遇到这个问题的。每天凌晨一堆定时任务被调度起来这些任务彼此之间有依赖关系有的还需要调用外部接口。外部接口的阈值是固定的——比如每分钟最多600次调用——但工作流引擎只负责帮你编排任务的顺序和重试逻辑它压根不知道你的外部接口每秒能扛多少请求。结果就是只要任务一多引擎发出去的并发请求数立刻超过外部服务的承受能力对方开始拒绝服务然后我们这边触发了大量重试重试又加剧了拥堵最终把整个集群拖垮。后来我转到了Temporal的框架下做新系统绕了一圈之后发现Temporal本身有不错的并发控制和速率限制能力。但它的默认机制更多是站在单Worker的角度去限制——每个Worker进程自己算自己每秒处理多少任务。问题在于当你部署了十个Worker节点时单节点的限流值叠加起来对下游服务来说依然是十倍的冲击。这时候就需要一个全局视角的速率控制方案让整个集群共享同一个速率阈值。我这次做的Temporal实现全局速率控制方案核心思路就是用Temporal自身的能力把速率控制从每个Worker自己约束自己升级为所有Worker一起遵守同一个约定。它适合的场景包括多Worker节点部署下游依赖外部API或数据库等有固定吞吐上限的服务需要在不同队列、不同任务类型之间共享同一个速率预算希望限流逻辑不依赖额外基础设施比如Redis完全跑在Temporal职责边界内想让速率配置能动态调整不用重启Worker进程这篇文章我先讲清楚方案的整体架构和两个关键实现路径属于系列的第一篇。后续会展开细节坑点和进阶调优。2. 先搞清楚Temporal限流机制的边界在动手设计之前我花了不少时间翻Temporal源码和官方文档想弄明白它的速率控制到底管到哪一层。不把这个问题搞清楚后面所有方案都会是空中楼阁。2.1 Temporal自带的限流管的是什么Temporal的默认限流分成几个层次工作的时候它们各管各的Task Queue级别的速率限制挂在某个Task Queue上的比如MaxConcurrentWorkflowTaskExecutionSize、MaxConcurrentActivityTaskExecutionSize这些参数控制的是单个Worker针对某个Queue的活动任务并发数。Worker进程级别的限流在创建Worker时设置的MaxConcurrentActivityExecutionSize、WorkerOptions里的速率限制项作用于当前进程内的所有任务。服务端本身的限流Temporal Server端也会根据自己的承受能力做限制这个通常不需要我们操心我们关心的是客户端侧的控制。实际跑起来你会发现这些参数解决的是单机并发天花板问题而不是全局速率预算问题。举个例子MaxConcurrentActivityExecutionSize 50意味着每个Worker最多同时运行50个Activity。但你部署5个Worker每个Worker都允许50并发下游看到的其实是250并发。外部服务可不管你是不是分布式架构它只会觉得你在疯狂打它。2.2 单机限流方案为什么在集群环境失效我用一个类比来解释这个问题。想象一个收费站Temporal的每个Worker就是一条收费通道。收费站规定每条通道每分钟最多放行30辆车——这就是单Worker限流。可是如果你修了10条通道每分钟实际放行的车就是300辆。下游高速路主干道的设计容量只有100辆/分钟那么拥堵和事故就成了必然。真正需要的方案是让所有通道共享同一个总账本不管你是哪条通道整个收费站每分钟合计放行不能超过100辆。这就意味着限流的状态信息必须对所有Worker可见而不是存在某个Worker自己的内存里。Temporal体系里适合承载这种全局可见状态的东西有好几个常见的做法包括利用Temporal的MutableSideEffect或LocalActivity读写某个全局存根用一个长期运行的Workflow充当协调者持有令牌桶状态对外提供查询和信号接口把限流状态放在数据库里但这样就引入了外部依赖我们这次的目标是不引入Redis等额外中间件纯靠Temporal自身能力实现全局限流所以重点放在前两种路径上。下面我会把这两种方案的核心设计拆开来讲。3. 方案A单一协调者Workflow 令牌桶状态机第一个思路很直白让整个Temporal集群里只存在一个特殊的限流协调者Workflow它持有全局令牌桶的全部状态。所有Worker在处理Activity之前先通过信号/Signal或查询/Query机制从这个协调者那里借令牌借到了才继续往下跑借不到就等待。3.1 为什么选单一协调者而不是多个协调者你可以把这个协调者理解成一个大楼的物业总闸。整栋楼的用电预算只有一个总闸在管各楼层的分电表都听从它的调配。如果每个楼层各自装一个总闸那和单机限流没有本质区别——协调者一多状态就碎片化了还得处理协调者之间的同步问题复杂度指数级上升。在Temporal里一个Workflow实例天然具备单点执行的特性同一个Workflow ID在同一时间只会有一个实例在推进。这正是全局状态收敛的地方。我们只需要保证所有Worker都调用同一个Workflow的Query/Signal接口状态就天然一致。3.2 协调者Workflow的核心结构先看代码骨架我用Java SDK做示例因为Temporal Java SDK在这块的API最直观WorkflowInterface public interface RateLimiterWorkflow { WorkflowMethod void run(); QueryMethod RateLimitStatus getStatus(); SignalMethod void applyLease(String clientId, int permits); }实现类public class RateLimiterWorkflowImpl implements RateLimiterWorkflow { private final RateLimiterState state new RateLimiterState(); Override public void run() { // 长期运行靠BlockedSignal等待信号 Workflow.await(() - state.isShutdown()); } Override public RateLimitStatus getStatus() { return state.snapshot(); } Override public void applyLease(String clientId, int permits) { state.tryAcquire(clientId, permits); } }这个run()方法是整个协调者的心脏。它不做任何重活就靠Workflow.await挂在那里等待信号驱动状态变更。为什么这么设计因为Temporal的Workflow是有状态机快照机制的await会让当前线程彻底挂起状态被持久化不会消耗计算资源。然后是状态机部分。这个RateLimiterState最关键的是要有令牌桶算法public class RateLimiterState { private final QueueLong tokenBucket new ArrayDeque(); public synchronized boolean tryAcquire(String clientId, int permits) { long now Workflow.currentTimeMillis(); // 清理过期令牌 while (!tokenBucket.isEmpty() now - tokenBucket.peek() REFILL_WINDOW_MILLIS) { tokenBucket.poll(); } long validTokens tokenBucket.size(); if (validTokens permits MAX_TOKENS) { for (int i 0; i permits; i) { tokenBucket.add(now); } return true; } return false; } }这个实现是滑动窗口令牌数量上限的混合体相比传统每秒固定补充N个令牌的令牌桶它更适合协调者模式的粒度控制。3.3 Worker端如何与协调者交互Worker端要做的事情很清晰每处理一个Activity之前先查询/申请令牌。这里有两种交互粒度我建议组合使用第一种同步查询令牌RateLimitStatus status WorkflowStub.fromTyped(workflow).getStatus();这种方式适合做软检查——比如在启动批量任务前先看一眼当前预算够不够不够就直接抛业务异常避免无谓的任务堆积。第二种信号申请令牌WorkflowStub.fromTyped(workflow).signal(applyLease, clientId, permits);信号方式适合硬申请。但注意Temporal的信号是异步的——发送方发出的信号不会立刻收到接收方的确认回复所以不能把Signal当作同步的令牌领取过程。这就引出一个很关键的实际操作技巧让Worker先发Signal然后在协调者Workflow里维护一个待下发配额事件由Worker在自己的Activity里主动查询清算结果。别嫌绕这是绕开Temporal Signal异步限制的通用手法。具体流程如下Worker准备执行某类任务向协调者发送applyLease信号附带需要的令牌数。协调者收到信号在状态机里尝试扣减令牌然后把扣减结果记录到一个配额结果列表里。Worker在启动Activity的代码块里轮询查询协调者的getStatus()或者用一个本地缓冲区做异步回调等待。如果拿到配额执行Activity如果没拿到就抛ApplicationFailure触发Temporal重试策略等下一个周期再试。3.4 这套方案的硬伤与取舍先说我实际踩过的坑。单一协调者方案最大的问题有两个问题一查询频率会成为性能瓶颈。如果每个Activity都同步查一次协调者Workflow高并发下Query调用本身会有一层序列化和网络开销。我实测过单个协调者Workflow大概能扛住每秒几百次查询再往上就开始出现响应延迟波动。对于大多数业务系统这个量级够用但如果你的目标是每秒上千任务的吞吐这套方案撑不住。问题二协调者是长期运行的Workflow意味着它会占用一个Workflow执行的历史记录。你每发一次Signal都会在History里追加一个事件。量一大History膨胀会拖慢该Workflow的恢复速度。这不是致命的但要注意隔一段时间主动让协调者重置一次状态或者定时归档历史。所以我给的取舍建议是协调者方案适合低频、强一致的限流场景比如每小时最多跑100个批处理任务、每个任务最多并发10个文件传输。如果你要的是毫秒级、每秒几千次的高频限流用第四部分的方案B更靠谱。4. 方案B本地缓冲 桶状态的分布化降级如果说方案A是中央集权那方案B就是地方自治中央备案。它的核心思路是每个Worker本地维护一个小的令牌桶缓存缓存容量由全局配置动态分配定期和全局账本对齐。这样一来大多数令牌申请都发生在本地内存里不涉及跨Worker通信性能上可以和单机限流持平。4.1 为什么会想到分布化降级还是在那个跑批系统里我后来把协调者方案部署上去以后刚开始还挺欣慰至少下游不再被冲垮了。但很快发现一个新问题业务的单批任务经常是500个Activity一起跑每个Activity都要在几百毫秒内完成外部调用。协调者每秒钟处理的Query请求量直接冲到上千次频繁的Signal事件也让那个协调者Workflow的历史记录越来越大恢复时间从几十毫秒涨到了几秒。那时候我才意识到全局限流不能只看全局两个字更重要的是怎么让全局状态和本地性能之间找到一个平衡点。分布式系统里的经典解法就是缓存配额定期同步。其实商业限流器的实现也有类似设计比如一些API网关的令牌桶就是每节点预领配额配额耗尽后再向中央节点申请。我觉得这个思路完全可以移植到Temporal上于是就有了方案B。4.2 本地桶缓存的数据结构每个Worker节点维护一个本地令牌桶LocalBucket它对外暴露和单机限流一样的tryAcquire()接口但内部多了两个能力配额预领启动时向全局协调者领一批未来N秒内可用的配额。配额归还与补充本地桶快用完时向全局协调者申请下一批配额同时把实际使用情况上报。public class LocalBucket { private final int maxCapacity; private final int refillRatePerSecond; private int availableTokens; private long nextRefillTime; public LocalBucket(int maxCapacity, int refillRatePerSecond) { this.maxCapacity maxCapacity; this.refillRatePerSecond refillRatePerSecond; this.availableTokens maxCapacity; this.nextRefillTime System.currentTimeMillis() / 1000; } public boolean tryAcquire(int permits) { refillIfNeeded(); if (availableTokens permits) { availableTokens - permits; return true; } return false; } private void refillIfNeeded() { long now System.currentTimeMillis() / 1000; if (now nextRefillTime) { availableTokens Math.min(maxCapacity, availableTokens refillRatePerSecond); nextRefillTime now 1; } } }注意这里我故意没有引入跨节点的同步锁。因为本地桶预领的配额本身就是一种信用额度即便出现两个Worker同时拿到配额且实际使用超过了总额度也只是造成少数时刻的临时超限。对于大多数外部API来说短暂的轻微超限是可以接受的你只需要保证宏观速率均值控制在阈值以内。4.3 全局账本与本地桶的同步协议为了让全局账本不至于完全失控我定义了三个同步操作leaseQuota(workerId, amount)向全局账本申请额度。reportUsage(workerId, actualUsed)上报实际使用量用于账本扣减。revokeQuota(workerId)Worker闲置时主动归还多余额度。同步协议的设计重点在于什么时候触发申请什么时候触发归还这里我给你一个我实测调得还算顺的参数模板参数推荐值调整依据预领周期5秒太长会导致配额浪费太短会增加协调者压力预领比例全局配额 / Worker数 x 80%预留20%缓冲给突发本地桶容量预领周期的预计消耗量保证至少覆盖一个周期归还阈值预领量剩余超过30%时低于30%继续持有避免抖动每次预领时全局协调者会做一次减法全局剩余配额 - 预领量。如果全局剩余配额不足协调者可以拒绝或者部分批准Worker端拿到部分批准之后就把本地桶容量下调做好降级准备。4.4 这个方案在Temporal里的落地实现落地方式我还是用协调者Workflow但交互逻辑变了不再是每个Activity都去协调者那里查状态而是Worker进程启动时批量预领Activity运行时只查看本地内存。这样做的好处是高频路径零跨节点通信低频路径每5秒一次预领负担极小协调者Workflow的历史记录事件量骤降具体代码层面可以在Worker的WorkerFactory构造阶段注入一个GlobalRateLimiter客户端它内部维护着LocalBucket和一个定时心跳任务。心跳任务每隔5秒向协调者Workflow发送信号携带workerId和预领请求。协调者处理完预领后把结果通过Query接口暴露给Worker下一次轮询读取。这里有个绕不过去的异步等待问题我当时的处理方法是Worker固定用一个私有TaskQueue注册一个配额回调 Activity。协调者把预领结果作为输入写入到该TaskQueue回调Activity被触发后把结果填充进LocalBucket。这种方法虽然多了一个Activity调用但完全避免了手写锁同步而且Temporal的Activity重试机制还能自动处理协调者临时不可用的情况。伪代码大概是ActivityInterface public interface QuotaCallbackActivity { ActivityMethod void applyResult(QuotaResult result); }Worker启动时调用QuotaRequest request new QuotaRequest(workerId, preloadAmount); WorkflowStub rateLimiterStub WorkflowStub.fromTyped(rateLimiterWorkflow); rateLimiterStub.signal(requestQuota, request); // 异步等待回调 QuotaResult result Workflow.await( () - quotaResultCache.containsKey(request.getRequestId()) ); localBucket.setCapacity(result.getAllocatedQuota());注意上面的Workflow.await只能在Workflow上下文里用所以这个预领动作会被设计成一个短命的QuotaPreloadWorkflow而不是在普通Java代码里调用。4.5 方案B的边界与注意事项这套方案解决了我之前遇到的性能瓶颈但也不是万能药。有几个点你必须心里有数首先配额是非强一致的。两个Worker可能同时各自预领了80%的配额瞬时全局总量达到160%下游那几秒会看到一点超限。如果你下游的限流阈值是严格不可超过这可能是个问题。解决办法是压低预领比例或者增大预领周期的粒度让超限窗口缩短。其次Worker动态扩缩容时要处理配额的回收。Worker崩溃或者重启时它之前预领的配额在全局账本上还挂着不会自动释放。如果频繁扩缩容全局剩余配额会越变越少。我建议在Worker进程关闭的钩子里主动发送一个revokeQuota信号同时全局协调者维护一个lastSeenTime对超过两倍预领周期未续约的Worker自动回收配额。这样即使Worker被强杀也不会永久泄漏配额。最后这个方案对本地的时钟同步有隐性要求。本地桶的补充逻辑依赖System.currentTimeMillis()如果某台Worker的时钟快了十几秒它的本地桶就会比别的Worker更快恢复容量。在跨机房部署时这个影响会被放大有条件的话可以用Temporal提供的Workflow.currentTimeMillis()来约束时间基准。5. 动态调参让速率控制可在运行时调整方案做出来之后另一个实际问题接踵而至速率控制的阈值不可能永远恒定。比如下游服务方在凌晨会把API配额提高一倍或者某天突发了运营活动需要在不停机的情况下临时上调并发量。这要求限流方案的配置必须支持动态更新。5.1 从配置文件到Workflow参数第一版方案里我把限流参数写死在了Worker的application.yml里。每次调整阈值都要经历改配置文件 → 重新发布 → 逐个节点滚动重启 → 验证生效这个流程。在集群规模小的时候还能忍但节点一多半小时就没了。后来我把参数迁移到了Temporal的动态配置体系里。Temporal的Workflow可以通过DynamicValue查询一些运行时配置不过更灵活的方式是把限流参数也封装成一个独立的配置Workflow由它持有所有限流参数并提供Query和Signal接口。WorkflowInterface public interface RateLimitConfigWorkflow { WorkflowMethod void run(); QueryMethod RateLimitConfig getConfig(); SignalMethod void updateConfig(RateLimitConfig newConfig); }这样操作员就能通过Temporal的命令行工具或者管理页面直接向这个配置Workflow发信号修改限流阈值。所有Worker的本地桶都会在下一个预领周期读取到新配置。5.2 配置变更时的平滑过渡我不建议在配置一变更就立刻让所有Worker同步到新值原因很实在假设当前全局限流是每分钟1000你把它改成每分钟2000立刻同步的话每个Worker的本地桶都会瞬间翻倍下游可能会经历一次2倍突发流量。某些质量较差的外部API对突发流量非常敏感直接就拒了。正确的做法是斜坡式过渡配置Workflow收到新值后不直接写入生效状态而是写入目标值字段。每次Worker预领配额时配置Workflow根据当前时间、过渡开始时间、过渡持续时间计算出一个当前生效的中间值。中间值平滑地从旧值爬到新值预领周期越长过渡越平滑。实现上就是一段线性插值public int getEffectiveLimit() { long now Workflow.currentTimeMillis(); if (now transitionEndTime) { return targetValue; } if (now transitionStartTime) { return sourceValue; } double progress (now - transitionStartTime) / (double) (transitionEndTime - transitionStartTime); return (int) Math.round(sourceValue (targetValue - sourceValue) * progress); }我实践中常用的过渡窗口是30秒到2分钟具体取决于下游服务的容忍度。如果下游有明确文档说能承受多少突发可以直接按那个文档来。5.3 基于任务优先级的差异化限流动态调参不仅能调全局总量还能做按任务类型分级配额。这个需求最开始来自一个既有高优先级实时任务又有低优先级批量任务的系统。实现方式不复杂全局令牌桶被划分成几个子桶每个子桶有独立的上限和补充速率。高优先级任务从高优先级子桶取令牌低优先级任务从低优先级子桶取。当高优先级子桶不足时可以借用低优先级子桶的配额反过来低优先级任务永远不能借用高优先级配额。这个借用逻辑我放在了协调者Workflow里public boolean tryAcquireWithPriority(PriorityLevel priority, int permits) { if (priority PriorityLevel.HIGH) { boolean ok highPriorityBucket.tryAcquire(permits); if (!ok) { // 额外借用低优先级剩余 ok lowPriorityBucket.tryAcquire(permits); } return ok; } return lowPriorityBucket.tryAcquire(permits); }实际运营中这个分级策略让我省了很多调优的精力。否则默认情况下一个跑批量导数的任务可能会把当时正在处理的交易类任务全部堵在限流门外引发线上投诉。6. 实际运营中的告警与排障方法方案上线之后后面就是运维层面的持久战。这里分享几个我真实踩过的坑和对应的排障手段。6.1 限流导致的隐形饥饿最隐蔽的问题是限流器正常工作但部分任务的等待时间异常拉长。表面上看令牌桶的容量是够的全局速率也没有超过阈值但某个任务种类总是拿不到配额。排查链路是这样的先在Temporal的Web UI上查看某个被饿死的任务历史记录确认它是否频繁遇到ApplicationFailure且报错信息是配额不足。检查协调者Workflow的Query返回结构看看全局剩余配额和各子桶的持有情况。如果全局剩余充足但某个Worker长期拿不到大概率是预领比例过大或者预领不及时导致的——某个Worker把配额预领了但没用完也不归还其他Worker就没得分了。解决手段我推荐两条一是缩短预领周期让配额能更快地在节点间流转二是设置一个最低保留配额全局协调者无论如何都保留20%~30%不预领出去留给临时的新Worker或突发任务。6.2 协调者Workflow卡在长History上这是我之前提过的痛点实际发生的时候确实让人抓狂。协调者Workflow每处理一个SignalHistory里就会追加一个WorkflowExecutionSignaled事件。一旦跑了几天几万甚至十几万个事件该Workflow的每次状态恢复都会变慢最终表现为Worker的预领请求超时。处理办法有三种我按推荐顺序列出来定期归档每隔一段时间协调者Workflow主动完成当前执行然后以同一个Workflow ID重新启动新的一轮执行。这样可以清空旧History。减少Signal频率把每5秒预领一次合并成每30秒批量上报一次牺牲一点实时性换取稳定性。改用短命Workflow作为协调者不维护一个长期运行的协调者而是每次预领都开一个新的短命Workflow。这样虽然会有额外的启动开销但完全规避了History膨胀问题。我之前提的QuotaPreloadWorkflow就是这个思路的充分应用。6.3 上下游耦合导致的假限流还有一种情况会让排查特别迷惑你明明把全局速率限制在了安全值以内但下游还是报压力过大。这时候要检查的不只是Temporal这边的速率控制还要看你的重试机制和超时设置。如果某个Activity调用外部API超时时间是30秒而外部API本身需要3秒响应那同一个时间里堆积在途的Activity请求数可能远大于你通过限流器放行的数量。因为第一个请求还没结束第二个请求已经被放行了。结果就是限流器放行了100个请求但在途的实际负载可能已经达到200。我当时修正的方式是在限流器计数上乘一个在途因子public boolean tryAcquireForExternalCall(int outgoingCallTimeoutSeconds) { double factor outgoingCallTimeoutSeconds / expectedResponseSeconds; int effectiveQuota (int) Math.ceil(quota * factor); return localBucket.tryAcquire(effectiveQuota); }虽然这个做法牺牲了一些精度但它能让限流器的行为更贴近下游真实的压力承受能力而不是理想化地假设每个请求都能秒回。7. 方案对比总结与选型建议这篇文章介绍了两种全局速率控制方案我在实际项目中都用过各有明确的适用场景。简单做一个横向对比维度方案A单一协调者方案B本地缓冲预领一致性强度强一致最终一致瞬时可能超限性能上限数百~一千次/秒查询单机并发级基本不受限实现复杂度较低中等需要处理预领协议对协调者压力高每个Activity都来查低只有周期预领上报适用场景低频严格限流高频吞吐型任务动态调参能力即时生效下一个预领周期生效如果让我给一个选型建议我会这么划分如果你是首次接入全局限流对Temporal的机制还不够熟建议直接从方案A开始代码少、逻辑直观、排障容易。把协调者Workflow写出来配合Query和Signal整个过程一两天就能完成。如果你的任务吞吐量明确会超过每秒几百次同时下游对瞬时超限有一定容忍度果断选择方案B。它虽然要处理预领协议和配额回调但换来的是长期稳定的性能表现。如果你的场景同时需要强一致和高性能那单靠Temporal自身能力是做不到的得引入外部分布式限流中间件。这个我后续可能在系列文章里单独分析。先写到这里。这个系列的第二篇我会重点聊如何在不入侵业务代码的前提下把限流逻辑做成可复用的Temporal组件以及Temporal限流的时序陷阱与测试方法到时候见。
