我正在尝试实现基于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内置了不错的重试逻辑。