Azure App Service(.NET Framework) OData长耗时后台任务咨询

我们使用C#开发了内存占用较高的OData/Web API，部署在Azure App Service实例上。部分极少被调用的接口根据查询条件不同，执行耗时可达20秒甚至10分钟，目标是实现一套后台任务机制处理这类长耗时请求，理想状态下只需在请求中附加指定标头即可告知API将对应任务放入后台执行。

• 立即向客户端返回带跟踪ID的响应，再通过HostingEnvironment.QueueBackgroundWorkItem运行SendAsync任务，但任务完成时会尝试操作已被释放的原始Web请求，抛出异常
• 立即向客户端返回带跟踪ID的响应，将SendAsync作为函数传入HostingEnvironment.QueueBackgroundWorkItem，任务激活时同样抛出错误
• 立即向客户端返回带跟踪ID的响应，在Hangfire中入队作业直接调用应用服务等待执行完成，但即便使用内部DNS，Azure App Service仍存在无法修改的230秒请求超时限制
• 尝试在独立线程运行业务代码，但使用Autofac实现依赖注入时，即便尝试创建新的依赖作用域，原始请求返回时该作用域仍会被关闭

• 直接在Hangfire中运行业务逻辑：该方案需要为这类少量调用重新整套部署API，且现有Hangfire部署在Linux环境的AKS上，现有API基于.NET Framework开发，无法兼容
• 使用WebJob：现有API复杂度高，将其部署为WebJob风险极高，还需承担WebJob 24小时持续运行的额外成本
• 使用消息队列：不清楚如何从队列读取消息后调用OData控制器，完成上下文填充、数据库数据获取等请求所需的前置操作
• 使用IHostedService：现有API基于.NET Framework而非.NET Core，不支持该特性

我们已知晓相关运行风险，希望在无需重新部署整套API的前提下，实现向客户端返回跟踪ID后可按需长时间运行OData Web请求的可行方案。

核心原则是完全脱离原始请求的生命周期，不持有任何原始请求上下文的引用，所有逻辑都在现有API进程内完成，无需额外部署服务：

1. 新增一个自定义消息DelegatingHandler放在管道最前端，检测到请求携带指定后台执行标头时，同步生成唯一跟踪ID，将当前请求的全量快照（请求方法、路径、查询字符串、所有请求头、请求体二进制内容）完整拷贝为独立的纯数据对象，不要保留任何对原始HttpRequestMessage、HttpResponseMessage、请求级依赖实例的引用。将快照按跟踪ID存入进程内内存缓存，立刻向客户端返回202 Accepted响应，携带跟踪ID与状态查询路径。
2. 通过HostingEnvironment.QueueBackgroundWorkItem调度后台任务时，仅传入序列化后的请求快照、全局HttpConfiguration实例、Autofac根容器引用三个和原始请求无关的对象。后台任务启动后，首先从Autofac根容器调用BeginLifetimeScope()创建一个全新的、独立的依赖作用域，在该作用域下手动构造一个全新的HttpRequestMessage实例，把快照里的路径、头、查询、请求体全部填充到新请求中，再通过HttpConfiguration对应的HttpServer实例直接在进程内发送这个新构造的请求。
   这个新请求会完整走一遍Web API + OData的全管道流程，包括模型绑定、控制器激活、依赖注入、数据库操作所有逻辑，和原始请求的生命周期完全解绑，不会出现原始对象释放、依赖作用域关闭的问题。Azure App Service的230秒超时仅限制外部传入的前端请求，进程内自调用的后台任务不受该规则限制，开启App Service“始终打开”配置的前提下，任务跑满10分钟无压力。
3. 后台任务执行过程中，将任务状态（排队中/执行中/成功/失败）、最终返回结果、异常信息按跟踪ID写入缓存，新增一个轻量的状态查询接口，客户端传入跟踪ID即可查询任务进度、拉取结果。
4. 针对极低概率的App Service进程回收场景，因为对应接口本身调用量极低，可以给缓存的任务加个简单的未完成标记，应用启动时扫到未完成任务重新执行即可，不需要额外做持久化。

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