什么是处理长时间运行任务的良好API架构?

时间:2018-08-13 00:58:53

标签: .net api azure architecture

我正在尝试实现基于ASP.NET Core的Web服务,该服务将通过ARM模板和适用于.NET的Azure SDK部署Azure资源。

问题是,根据我的测试,某些操作最多可能需要四到三分钟才能完成。我没有设计API所需的时间来做某事。

所以我想做的是以下事情。

  1. 当API请求提供资源时,我将请求信息放入队列中。
  2. 我返回了一个带有票证号码的200,供呼叫者监视进度,呼叫者可以通过呼叫另一个端点来达到此目的。
  3. 我使用网络作业创建资源请求,并更新数据库中的信息。
  4. 当呼叫者致电端点以获取有关资源部署进度的反馈时,我现在可以提供更新的信息(成功或失败)。

我不确定这种架构,因为我之前从未做过这样的事情。我正在考虑使用Azure队列来组织传入的请求,使用Azure表在进行部署时放置有关请求的信息,并使用Azure WebJob在执行请求时创建请求。

这是否是一个足够不错的体系结构,或者我应该考虑使用其他技术或模式来做到这一点?我不确定如何处理这种情况,欢迎任何输入。

2 个答案:

答案 0 :(得分:1)

  
      
  1. 我返回了一个带有票证号码的200,供呼叫者监视进度,呼叫者可以通过呼叫另一个端点来达到此目的。
  2.   

取而代之的是返回202 Accepted,以明确表示“嘿,我有你的东西,我待会儿再去。”

返回Location标头(而不是票号),并在结果中添加Retry-after标头(如果您对客户何时应该“回叫”有个大概的想法)。

客户端,当位置URL不再返回404时,客户端UI应该尝试呈现结果,或者-如果没有UI,则开始处理这些结果的任何逻辑处理。

  

我正在考虑使用Azure队列来组织传入的请求[...]

我赞成这个决定。否则,您将只是从头开始重新实现持久性,重试和错误的actor处理,我们都知道最好的代码是别人的代码。

使用Azure队列,您需要implement your own poison message logic,Service Bus可以为您提供开箱即用的服务。

答案 1 :(得分:0)

这个问题正在征求意见,并且很可能会结束。但是在此之前,这是您要完成的工作的非常合理的计划。我亲自实现了一个非常相似的体系结构,该体系结构在重负载下保持良好。一些指针:

  • 确保正确选择队列实现。您可以选择服务总线队列或存储队列。您可以find a great comparison here

  • Azure桌子非常便宜(可以快速闪电存储),可以真正扩展。但是您只有一个分区键和一个行键可以使用。如果这足以满足您的需求,那就太好了!否则,请考虑使用诸如CosmosDB表或Azure SQL DB之类的东西。

  • 对于长时间运行的处理,请考虑如果Webjob崩溃并且必须重新开始处理队列消息会发生什么情况。如果存在不应重复的多个处理阶段,则需要为此进行计划。否则,ServiceBusTrigger内置了不错的重试逻辑。