如何用Cron表达式实现工作日午夜定时触发Azure Durable Function

问题1：是否可以直接创建Timer触发的Durable Function？该方案有哪些限制？ #

• 可以直接实现，这是官方原生支持的标准调度方案，完全能满足工作日午夜执行编排的需求。
• 正确实现逻辑：不要给编排器函数本身绑Timer触发器，而是给Durable Function的客户端函数配置Timer触发器，在触发器属性里直接写符合需求的Cron表达式即可，比如工作日午夜的Cron为0 0 0 * * 1-5。Timer触发时，客户端函数通过Durable Client调用StartNewAsync方法启动目标编排流程即可。注意Timer触发器默认使用UTC时区，要在函数应用配置中添加WEBSITE_TIME_ZONE参数，设置为你业务对应的时区（比如国内业务设为China Standard Time），避免触发时间和预期不符。
• 该方案的明确限制如下：
  • 禁止将Timer触发器直接绑定到使用OrchestrationTrigger的编排器函数上，否则会破坏Durable Function的状态重放、幂等执行保证，导致流程执行异常、状态错乱。
  • 如果单轮编排的执行时长可能超过调度间隔（比如你是每日调度，单轮流程如果可能跑超过24小时），需要自行做并发控制：启动新实例前先通过Durable Client查询对应业务标识的实例状态，若存在处于Running/Pending状态的实例则跳过本次启动，避免重复执行。
  • 该方案的触发可靠性和普通Timer触发Azure Function一致：如果函数应用在计划触发时间点处于停止状态，错过的触发默认不会补执行，有强一致补触发需求的场景需要额外配置调度监控逻辑。

问题2：是否应当采用「HTTP触发Durable Function常驻等待外部事件+配置Cron的普通Timer函数发事件触发」的方案？ #

• 该方案技术上可以跑通，但完全不推荐，属于冗余设计，存在多个明显缺陷：
  • 运维成本极高：为了每日触发一次流程，你需要维护一个全年无休常驻运行的编排实例等待事件，还要额外处理实例因应用重启、代码发布、存储故障意外终止后的自动重建、状态恢复逻辑，远不如直接启动新实例的方案轻量。
  • 故障点更多：链路多了一层事件投递环节，如果Timer函数发事件时，常驻编排实例刚好处于重放、临时不可用状态，很容易出现事件丢失、调度漏执行的问题，还要额外补事件重试、死信处理逻辑，进一步增加复杂度。
  • 资源浪费：长期运行的等待态编排实例会持续占用Durable Function背后的存储配额，产生不必要的成本。
• 对你的固定时点调度需求来说，直接用Timer触发Durable Client启动新编排实例的方案链路最短、可靠性最高、维护成本最低，完全没必要采用绕路的外部事件触发方案。

补充说明：你提到的Eternal Function仅支持配置延迟间隔、无法适配Cron固定时点调度的问题，在上述Timer触发客户端的方案里完全不存在——Timer触发器本身原生支持标准Cron表达式配置，不需要靠编排内部的延迟逻辑凑调度时间。

内容的提问来源于stack exchange，提问作者Pramod J C