我正在尝试实现基于ASP.NET Core的Web服务,该服务将通过ARM模板和适用于.NET的Azure SDK部署Azure资源。
问题是,根据我的测试,某些操作最多可能需要四到三分钟才能完成。我没有设计API所需的时间来做某事。
所以我想做的是以下事情。
我不确定这种架构,因为我之前从未做过这样的事情。我正在考虑使用Azure队列来组织传入的请求,使用Azure表在进行部署时放置有关请求的信息,并使用Azure WebJob在执行请求时创建请求。
这是否是一个足够不错的体系结构,或者我应该考虑使用其他技术或模式来做到这一点?我不确定如何处理这种情况,欢迎任何输入。
答案 0 :(得分:1)
- 我返回了一个带有票证号码的200,供呼叫者监视进度,呼叫者可以通过呼叫另一个端点来达到此目的。
取而代之的是返回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内置了不错的重试逻辑。