Azure Durable Functions是否适合替代Azure Service Bus？

Durable Functions 绝对存在过载可能性，从来没有“用了Durable Functions就可以完全扔掉Service Bus、彻底和过载绝缘”的说法，官方文档提到的替代是针对特定场景的，不是全场景通用替换。

为什么会有“Durable Functions能替代Service Bus”的误解 #

你现在用Service Bus配合普通Azure Function的核心作用是削峰填谷防过载，本质逻辑是靠Service Bus的队列做缓冲层，先把突发流量兜住，让函数按照自身能承载的并发速率拉取消息处理，避免瞬间请求把计算资源打满。
Durable Functions之所以在很多场景下能省掉额外的Service Bus，是因为它本身就内置了基于持久化存储的队列机制（默认用Azure Storage，也支持配置MSSQL等其他存储）：

• 自带独立的控制队列、工作项队列，天生具备消息缓冲能力
• 原生支持并发阈值配置，你可以直接限制单个函数实例同时运行的编排函数、活动函数数量，超过阈值的消息会自动留在队列中排队，不会直接压到函数执行层
• 内置了失败重试、状态持久化、错误处理能力，不用你自己在普通Function+Service Bus的组合里手写消息重试、状态追踪、死信处理的重复代码
  对中小规模的异步处理、工作流场景来说，这套内置机制完全能实现你之前靠Service Bus达到的防过载效果，不需要额外部署维护Service Bus资源。

Durable Functions的过载风险是真实存在的 #

它的防过载能力有明确边界，配置不对或者场景不匹配的时候照样会崩：

• 内置队列的性能上限远低于Service Bus：默认用Azure Storage作为存储提供方时，单队列的吞吐量上限大概是2000条消息/秒，如果遇到每秒上万条的突发流量，存储层本身会先被打满，直接出现消息堆积延迟、处理失败的问题
• 并发配置不当必然过载：如果你没有手动调整并发限制，默认配置下函数拉取消息的速率很可能超过后端依赖（数据库、第三方接口等）的承载上限，照样会引发服务雪崩
• 缺失Service Bus的高级消息能力：比如消息会话处理、自定义自动死信规则、消息转发、跨实例的消息路由、异地多活灾备、细粒度消息过期策略这些能力，Durable Functions的内置队列完全不支持，有这类需求的时候根本替代不了Service Bus

实际选型参考 #

• 如果你的场景是单应用内的异步任务处理、工作流编排，流量规模在存储队列的承载范围内，也不需要高级消息特性，直接用Durable Functions就行，能省掉额外维护Service Bus的成本
• 如果你的场景有大流量削峰需求、需要跨多个应用做消息解耦、依赖Service Bus的高级消息特性，那就保留Service Bus，甚至可以把两者组合使用：用Service Bus做入口层的大流量缓冲，再触发Durable Functions执行后续的有状态工作流，兼顾两者的优势

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