Azure长耗时函数链选型：Durable Functions/Event Hub/Event Grid咨询

Event Grid 适配性说明 #

实现思路 #

• 所有Function App保持独立部署，每个节点完成当前任务后，向Event Grid推送自定义事件，事件体携带任务上下文ID、下一流水线所需的输入参数引用、运行状态等核心元数据
• 为每个后续步骤的Function配置Event Grid触发器，通过事件类型、主题筛选器匹配对应前序步骤的完成事件，触发自身逻辑运行
• 搭配Azure存储表/Cosmos DB独立存储全链路任务状态、中间计算结果，事件内仅传递结果存储地址，避免payload超限，同时方便异常回溯、手动重试。

优劣 #

• 优势：投递延迟低（毫秒级），内置自动重试、死信队列能力，按实际投递次数计费成本极低，无需预分配资源，天然支持事件多订阅模式，后续扩展并行分支流程非常方便。
• 劣势：单事件最大Payload为1MB，超过体积的中间结果需要单独存存储后传引用；无内置链路编排能力，需要自行维护步骤依赖、重试策略、异常回滚逻辑；不适合每秒十万级以上的超高吞吐场景。

Event Hub 适配性说明 #

实现思路 #

• 可选择为每个流程步骤单独创建Event Hub主题，或者同一主题下按任务维度做分区，保证同一任务的所有事件按顺序投递
• 每个步骤的Function配置对应主题/分区的Event Hub触发器，消费到消息后执行业务逻辑，完成后将下游所需参数写入下一个步骤对应的Event Hub
• 利用Event Hub的消息持久化能力（最长可保留90天），配合独立存储的链路状态，可快速做失败任务重放。

优劣 #

• 优势：支持百万级每秒的超高吞吐，完全匹配海量数据处理场景的流量需求；单消息最大支持1MB（基础层）/2MB（标准层及以上），消息持久化能力可靠性高。
• 劣势：无内置事件筛选能力，若共用主题需要自行做消息过滤，若按步骤拆分会带来额外成本；同样没有原生编排能力，需要自行实现流程调度、超时检测逻辑，整体运维复杂度高于Event Grid方案。

其他可选方案 #

1. 跨Function App调用的Durable Functions #

你之前认为Durable Functions需要所有函数迁移到同一Function App是认知误区，完全可以保持各函数独立部署：

• 用Durable Functions的外部事件机制：编排器所在的主Function App监听外部事件，其他独立部署的业务Function完成任务后，向编排器发送任务完成事件，即可驱动编排流程向下推进
• 也可以通过跨Function App的HTTP调用触发活动函数，只要配置好访问权限即可，无需合并任何业务代码到同一App，同时可以保留Durable Functions内置的编排、重试、状态管理能力，是最贴合你原有验证结果的方案。

2. Azure Logic Apps 消耗层/标准层 #

• 直接用Logic Apps做可视化流程编排，每个步骤触发对应独立的Function App运行，内置支持重试规则、超时检测、异常分支处理，无需自行开发编排逻辑
• 单步骤最长运行时长支持1年，完全覆盖你单函数1小时的运行要求，全链路状态自动留存，调试、回溯非常便捷，不需要使用ADF集成的Logic Apps，避免触发230秒超时限制。

3. Azure Queue Storage 触发器 #

3~5个节点的短链路场景下最轻量化的方案：

• 为每个流程步骤单独创建存储队列，前序步骤完成后将任务参数写入下一个步骤的队列，触发对应Function运行
• 内置消息不可见超时、死信队列能力，成本极低，实现逻辑简单，不需要引入额外的事件类服务，运维复杂度最低。

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