从ODATA/Web API请求运行在Azure App Service（.NET Framework）上运行长期运行的背景任务
我们有一个很好的内存重型ODATA/Web API，用C＃编写，并在Azure App Service实例上运行。使用的一些特定端点很少需要很长时间才能执行（20s），否则它们可能需要很长时间（10分钟），具体取决于查询。在这种情况下，我们希望拥有一些背景任务机制来执行此类任务，理想情况下，我们可以将标题附加到任何调用中，以告诉API在后台运行它。 我们已经尝试过：
- 请求，然后在hostingenvironment.queuebackgroundworkitem中运行sendAsync任务
- 立即使用跟踪ID返回 立即使用跟踪ID的请求，然后将SendAsync传递到hostingenvironment.queuebackgroundworkitem作为函数，但是在激活
- 返回 时也会引发错误立即使用跟踪ID的请求，然后在Hangfire中启动一份工作，这将直接呼叫应用程序服务，并可以等待尽可能长时间。但是，即使使用内部DNS，Azure应用程序服务的超时时间为230秒，我们也无法以任何方式更改它，
- 我们也尝试在其他线程中运行业务代码本身，但是我们使用AutoFac DI，如果我们尝试获取新的范围，当原始请求返回时，它仍然关闭。
类似的问题已经得到了我认为不适用于我们的答案：
- 在hangfire中运行工作本身，这意味着再次为这些罕见的电话旋转整个API，我们也不能这样做在Linux上的AK上，API是.NET框架。
- 使用WebJob-与API相似的问题非常复杂，并且将其部署到WebJob似乎非常危险，然后我们将不得不支付24/7 WebJob的费用。
- 使用队列，问题是我真的不知道我们如何从队列中获取消息，然后对ODATA控制器执行该消息，我们需要为填充各种上下文，然后从DB中获取数据我们需要这些请求。
- 使用iHostedService-我们的API是.NET框架，而不是.NET Core
基本上对我们如何实现这一目标的任何想法，在我们将跟踪ID返回给客户端（我们了解风险）之后，运行ODATA Web请求就需要尽可能长时间。不必再部署我们的API？
We have a pretty memory heavy OData/Web API written in C# and running on an Azure App Service instance. Some specific endpoints which get used rarely can take a long time to execute (20s) or they can take an extremely long time (10min) depending on the query. We would like in that case to have some of sort of background task mechanism for executing these kind of tasks, ideally a header we can attach to any call to tell the API to run it in the background.
We have tried:
- Returning the request immediately with a tracking id and then running the SendAsync task in a HostingEnvironment.QueueBackgroundWorkItem, however when the work is completed it throws an exception as its trying to do something with the initial web request which is already disposed
- Returning the request immediately with a tracking id and then passing the SendAsync to HostingEnvironment.QueueBackgroundWorkItem as a function, however that also throws an error upon activating
- Returning the request immediately with a tracking id and then enqueuing a job in the Hangfire which will make a direct call to the app service and can wait as long as it takes. However even using the internal dns, the azure app service has a timeout of 230 seconds, and we can not change that in any way
- We've also tried running the business code itself in a different thread, but we use autofac DI and if we try and get a new scope it still closes when the original request returns.
Similar SO questions have gotten answers that I don't think apply to us:
- Running the work itself in Hangfire, that would mean spinning up the whole API again, just for these rare calls, also we can't do that because our Hangfire is on AKS on Linux, and the API is .net framework.
- Using a webjob - similar issue as the api is very complex and deploying it to a webjob seems very dangerous, also we will then have to pay for 24/7 webjob.
- Using a queue, the problem is that I don't really know how we can take a message from a queue and then execute it against the odata controllers, which we will need to do to populate various contexts and then get data from the DB that we need for these request.
- Using IHostedService - Our API is .net framework and not .net core
Basically any thoughts on how we can achieve this, running an odata web request for as long as needed after we return a tracking id to the client (we understand the risks), without having to do another deployment of our API?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论