我有一个 v1 Azure 函数，由写入 Azure 存储消息队列的消息触发。
Azure Function 需要对 SharePoint Online 执行多次更新。有时这些操作会失败。这会导致消息返回到队列并被重新处理。
我开发这个功能的时候，并没有考虑到它可能会部分完成然后重启。我做了一些研究，听起来我需要修改它才能重入。
我是否应该遵循一种设计模式来满足这一点，而不必添加大量检查来确定先前的执行是否已经执行了操作？或者，是否有任何 Azure 功能可以提供帮助（除了现有的消息重试和有害队列之外）
听起来您需要进行一些重新设计。我们的团队也遇到了类似的问题，并在几年前编写了一个自行开发的解决方案。但我们最终放弃了我们的解决方案并采用了Azure Durable Functions。
不会撒谎 - 这个框架有一定的复杂性，我花了一些时间才理解它。查看函数链接模式。
我们的处理需要多个步骤，所有步骤都必须完成。我们跨越多个数据存储（更新 Cosmos Db、Azure SQL、Blob 存储等），因此不支持跨多个 PaaS 产品的分布式事务。耐用功能将允许您将流程分解为离散的步骤。如果某个步骤失败，编排器将根据重试策略重新运行该步骤。
简而言之，我们使用持久任务活动函数来尝试每一步。如果该步骤由于我们认为是暂时性错误而失败，我们会重试。如果这是不可恢复的错误，我们不会重试。
我尝试过具有持久功能的编排、普通服务总线主题/队列和天蓝色表存储队列。我在尝试时发现了什么（我认为是 2022 年左右）。对于我们的案例，使用 tablestorage/sql 来跟踪步骤是否已完成的 servicebus 队列似乎更可靠、更快。我们有几千张发票需要处理，并根据情况执行不同的操作，并根据发票接收者的个人设置执行多个步骤。
编排似乎对冷启动更敏感，除非您将轮询间隔更改为更严格的计划。而且控制有点难以掌握。如果调试的话可以在指定的tablestorage和logg中看到进程。但在现场演出中却相当困难。它有效，但对我来说有点黑盒魔法^^