我有一个长时间运行的活动，其执行完成时间将超过 10 分钟，但它是具有许多内部任务的单一活动。我想在消费计划上将这个长期运行的活动作为 Azure Function 运行，而不是在应用程序服务的高级（或）成本因素上运行。但是消费计划上的 Azure 功能有最大值。超时时间为 10 分钟，因此消费计划中的 Azure 功能将不适合。
对于上述要求，Azure Durable 功能是正确的选择吗？我可以在消费计划上启动持久功能，并考虑将长时间运行的功能作为持久功能“编排上下文”中的一项活动（尽管我的要求与编排或功能链接无关）以经济高效的方式克服 Azure 功能超时限制.
上述方法在技术上可行吗？ Durable 函数“orchestrationcontext/DurableClient”中的活动函数不会在消费计划 10 分钟后超时吗？是否符合最佳实践？请澄清。
【问题讨论】：
标签： azure-functions azure-durable-functions
如果我了解您的要求，那么您使用持久功能的主要目标是实现无服务器并且只为您使用的内容付费。
如果上述理解是正确的，那么如果不将 30 分钟的长时间运行功能分解为可以在 5 分钟或最多 10 分钟内完成的多个活动功能，您就无法解决您的问题。
但是您可以使用不同的方法来解决您的问题陈述。
您可以创建控制台应用程序的 docker 映像，将其部署到 azure 容器注册表，一旦消息到达队列，您可以编写一个简单的队列触发 azure 函数，该函数可以使用 Azure 容器实例启动此映像。
Azure 容器实例是无服务器的，仅按执行时间收费，在您的情况下为 30 分钟。
这将解决您不重构代码仍然使用无服务器模型的问题。
让我知道你的想法
【讨论】：
函数应该是短暂的，它们不应该运行很长时间。函数的优势在于吞吐量很小或可变的短期执行。
尽可能将大型函数重构为较小的函数集，这些函数集可以协同工作并快速返回响应。例如，webhook 或 HTTP 触发函数可能需要在特定时间限制内的确认响应； webhook 需要立即响应是很常见的。您可以将 HTTP 触发器负载传递到队列中以由队列触发器函数处理。这种方法可以让您推迟实际工作并立即返回响应。
看看这个：
使用 Durable Functions，您可以轻松地支持长时间运行的进程，应用 Async HTTP APIs。如果您正在处理需要一些时间来处理有效负载或请求的功能，则在“应用服务计划、WebJob 或持久功能”下运行是正确的方法。
【讨论】：