我了解 Webjob 是一项后端作业,Webapp 可以通过 Azure 队列调用它。我的问题是如果 Webjob 完成,Webapp 如何知道 Webjob 已完成,Webapp 如何检索 Webjob 生成的结果?
有没有可以在这种情况下工作的异步方法?也欢迎其他方法。
谢谢
德里克
- - - - - - - - 更新 - - - - - - - - - - - -
“ListQueuesSegmentedAsync”方法可以工作吗?但我不知道如何使用它。
我了解 Webjob 是一项后端作业,Webapp 可以通过 Azure 队列调用它。我的问题是如果 Webjob 完成,Webapp 如何知道 Webjob 已完成,Webapp 如何检索 Webjob 生成的结果?
有没有可以在这种情况下工作的异步方法?也欢迎其他方法。
谢谢
德里克
- - - - - - - - 更新 - - - - - - - - - - - -
“ListQueuesSegmentedAsync”方法可以工作吗?但我不知道如何使用它。
你已经知道答案了!消息队列!
如果您需要超过几 KB 的消息(也许您想要传递 JPEG 文件)将其放入 Blob 存储中,并使用队列消息向 Web App/WebJob 发出信号,指示新到达的 blob 的完整路径。
有关实施以队列为中心的工作流程的更多信息,请在此处查看我的其他答案:
https ://stackoverflow.com/a/38036911/4148708
有时,如果保持状态不是您首先关心的问题,那么实现一个系统可能更容易,在该系统中,WebJob 调用 WebApp 中经过身份验证的 REST 端点来获取/发布数据。
没有灵丹妙药。每个场景往往都有点不同,并且可能受益于简单性而不是持久性(REST 与持久消息队列)。
哦,既然您确实特别要求异步,那么这是 REST 的一种方法(队列本质上是异步的):
202 Accepted
(就像我得到你一样,但 TPS 报告还没有准备好)Location: https://webapp/{a-chunk-of-sha1-representing-a-unique-id}
(这个header的重点是告诉WebJob不时检查这个URL来抓取完成的TPS报告)200 OK
意味着你有,417 Expectation Failed
意味着还没有。实际上HTTP 417
应该用于响应100 Continue
,但你永远不会使用它,所以我正在放慢竞选速度,以与弹性和破坏性417 Expectation Failed
等流行词竞争。但我离题了。