除MaximumSignalsPerExecution外如何让Cadence工作流拒绝信号

除服务端配置MaximumSignalsPerExecution全局参数外，有3种工作流级别的实现方案，完全适配continue-as-new前信号堆积触发超时、信号丢失的问题，可应对每秒多条信号的突刺场景：

• 工作流内置状态闸门
  在工作流代码中维护原子状态位isBlockingSignal，当工作流进入continue-as-new准备阶段时，将该状态位置为开启。所有信号处理逻辑的入口优先校验该状态位：如果处于信号阻断状态，直接在信号处理函数中返回自定义拒绝响应，不将信号加入工作流待处理队列，也不执行后续业务逻辑。
  该方案完全在工作流侧实现，不需要调整服务端配置，粒度可精确到单个工作流的不同运行阶段，还支持针对不同信号类型配置差异化策略（比如高优先级信号放行、普通业务信号临时拒绝），灵活性远高于全局参数配置。
• 动态阈值触发的提前冻结机制
  不要等工作流接近超时阈值才启动continue-as-new流程，在工作流中维护两个计数器：当前已接收未处理的信号总量、当前run的已运行时长。只要任意一个计数器达到预设的安全阈值（比如未处理信号到200条、运行时长达到工作流超时配置的70%），立刻开启信号阻断状态，停止接收新信号，待存量信号全部处理完成后立刻执行continue-as-new。
  该方案可以从根源避免信号堆积拖垮工作流run，实测应对每秒数十条的信号突刺场景稳定性很高，不会出现超时丢信号的问题。
• 前置缓冲层削峰（适配极端高突刺场景）
  如果信号峰值远高于单个工作流run的处理上限，可以在业务工作流前增加一层轻量缓冲逻辑（可以是同集群下的专用缓冲工作流，也可以是业务侧的本地队列）做削峰：所有信号先投递到缓冲层，缓冲层按照业务工作流的实际承载能力匀速投递信号。
  当业务工作流进入continue-as-new阶段时，给缓冲层返回暂停投递的标记，等新的工作流run启动完成后，再通知缓冲层恢复投递。该模式可以承载每秒上百条的信号突刺，完全不需要依赖服务端的全局信号数限制。

注意：MaximumSignalsPerExecution只适合作为兜底保护阈值使用，该参数是服务端层面的硬拦截，触发后直接返回通用错误，工作流侧无法自定义拒绝后的处理逻辑（比如将被拒信号转存到缓冲队列、给调用方返回自定义错误码），不适合作为核心的信号管控方案。

内容的提问来源于stack exchange，提问作者Aleks