长时运行Azure Function任务完成后通知用户应选用哪些Azure服务？

消息服务选型结论 #

你这个场景优先选Event Grid Topic，另外两个服务的适配性对比如下：

• Event Hub：直接排除，它是面向海量流式数据摄入的服务，比如日志、IoT遥测数据批量处理，天生不适合单事件的精准通知投递场景，没有动态订阅路由能力。
• Service Bus：适合需要严格消息顺序、事务、长周期延迟调度的消息队列场景，订阅管理灵活性低，不支持用户动态注册自定义订阅，成本也高于Event Grid，除非你有强事务需求否则不用考虑。
• Event Grid Topic：完全匹配你的核心需求，天生是为事件驱动架构的多订阅者投递设计的，支持动态增删订阅、事件内容过滤，内置至少一次投递的重试保障，成本极低，完全满足用户自行注册通知规则的需求。

用户自定义通知方式的实现 #

用Azure Communication Services就能实现，它已经封装了邮件、短信、移动端推送、Teams/微信消息等主流通知渠道，你不需要自己对接各渠道的底层接口。
整个链路的标准搭法：

1. 用户上传文件时，同步记录用户选择的通知方式、联系方式到Cosmos DB或者Table Storage，直接返回提交成功响应，不用等文件处理完成。
2. 长耗时的文件处理Azure Function运行完成后，向Event Grid Topic发布一个FileProcessingCompleted事件，携带用户ID、文件ID、处理状态、结果地址等核心字段。
3. 配置Event Grid Topic的默认订阅，触发专门负责通知的Azure Function，该函数接收到事件后根据用户ID查询预设的通知配置，调用Azure Communication Services对应接口发送通知即可。

如果要支持更灵活的用户自定义订阅，你可以给授权用户开放Event Grid Topic的订阅权限，用户可以自行配置事件过滤规则、投递目标（比如自己的Webhook、Teams频道地址等），不需要你修改后端代码。

优化建议 #

• 给Event Grid配置死信队列，投递失败的事件会自动存入你指定的存储账户，避免通知丢失，后续可以手动重试。
• 如果单文件处理时长超过你用的Azure Function计划的最长执行时间（消费计划最长10分钟，弹性计划最长60分钟），建议改用Durable Functions拆分处理步骤，避免执行超时。

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