我有一个长时间运行的活动，其执行完成时间将超过 10 分钟，但它是具有许多内部任务的单个活动。我想在消耗计划上将此长时间运行的活动作为 Azure 函数运行，而不是在应用服务上的高级(或(上运行成本因素。但消耗计划上的 Azure 函数的最大超时期限为 10 分钟，因此消耗计划上的 Azure 函数不适合。
对于上述要求，Azure 持久函数是否是正确的选择？我可以在消耗计划中启动持久函数，并考虑将长时间运行的函数作为持久函数"业务流程上下文"中的活动调用(尽管我的要求与业务流程或函数链无关(，以经济高效的方式克服 Azure 函数超时限制。
上述方法在技术上是否可行？持久函数"业务流程上下文/持久客户端"中的活动函数不会在消费计划10分钟后超时吗？ 它是否符合最佳实践？请澄清。
函数应该是短暂的，它们不应该运行很长时间。函数的优势在于具有小吞吐量或可变吞吐量的短期执行。
尽可能将大型函数重构为较小的函数集，这些函数集协同工作并快速返回响应。例如，Webhook 或 HTTP 触发器函数可能需要在特定时间限制内进行确认响应;Webhook 通常需要立即响应。您可以将 HTTP 触发器有效负载传递到队列中，由队列触发器函数处理。此方法允许您延迟实际工作并返回即时响应。
看看这个：
https://learn.microsoft.com/en-us/azure/azure-functions/functions-best-practices#avoid-long-running-functions
使用持久函数，您可以轻松支持长时间运行的进程，应用异步 HTTP API。如果要处理需要一些时间来处理有效负载或请求的函数，则在"应用服务计划、Web 作业或持久函数"下运行是正确的方法。
如果我理解您的要求，您使用持久函数的主要目标是实现无服务器，并且只需为您使用的内容付费。
如果上述理解是正确的，那么如果不将30分钟长时间运行的功能分解为可以在5分钟或最多10分钟内完成的多个活动功能，就无法解决问题。
但是您可以使用不同的方法来解决问题陈述。
可以创建控制台应用程序的 docker 映像，将其部署到 azure 容器注册表，消息到达队列后，可以编写一个简单的队列触发器 azure 函数，该函数可以使用 Azure 容器实例启动此映像。
Azure 容器实例是无服务器的，仅向你收取执行时间费用，在你的情况下为 30 分钟。
这将解决不重构代码但仍使用无服务器模型的问题。
让我知道你的想法