message-queue - 将数据推送到队列与工作人员提取数据

Question

我正在构建一个网站后端，该后端涉及客户端提交请求以执行一些昂贵的（及时）操作。昂贵的操作还涉及收集一些信息以完成。

客户提交的工作可以用uuid. 我希望使用面向服务的架构（SOA）（即多个微服务）。

客户端通过 HTTP 使用 RESTful 通信与后端通信。我计划使用一个队列，执行昂贵操作的工作人员可以轮询工作。队列具有持久性并提供了不错的可靠性语义。

一个考虑因素是我是否收集上游昂贵操作所需的所有数据，然后将所有这些数据排入队列，或者我是否只是将这些数据排入队列uuid并让工作人员获取数据。

以下是正在考虑的两种架构的图表：

基于推送（即上游收集数据）：

基于拉的（即工人收集数据）：

我想到的一些事情：

1. 在基于推送的情况下，我可能会在收集所需数据时被阻塞，因此客户端的 HTTP 请求在收集数据然后入队之前不会得到响应。从 UI 的角度来看，请求将处于未决状态，直到响应返回。
2. 在基于拉的场景中，只有工作人员需要知道工作需要哪些数据。这意味着我可以让多种类型的客户端与各种后端进行通信。如果数据需要更改，我只更新工作人员而不是每个上游服务。

还有什么我在这里想念的吗？

Answer 1

基于拉的方法的另一个好处是您不必担心队列中的数据会变得陈旧。

Answer 2

我想你已经解释了第二种（基于拉的）方法更好。

1. 如果无论如何都应该异步处理用户的请求，那么为什么要等待收集数据然后返回响应。您只需要将工作项排队并返回 HTTP 响应。
2. 通过队列传递数据不是一个好的选择。如果您在上游获取数据，您将不得不以某种方式将其传递给工作人员（通常是 BLOB 存储），而不是通过队列。这是您的情况并不真正需要的额外工作。

Answer 3

我会推荐Cadence Workflow而不是队列，因为它支持长时间运行的操作和开箱即用的状态管理。

与使用队列进行任务处理相比，Cadence 提供了许多其他优势。

• 建立了指数重试，具有无限的过期间隔
• 故障处理。例如，如果在配置的时间间隔内两次更新都不能成功，它允许执行通知另一个服务的任务。
• 支持长时间运行的心跳操作
• 能够实现复杂的任务依赖。例如，在不可恢复的故障 ( SAGA )的情况下实现调用链或补偿逻辑
• 提供对当前更新状态的完整可见性。例如，当使用队列时，您都知道队列中是否有一些消息，并且您需要额外的数据库来跟踪整体进度。使用 Cadence 记录每个事件。
• 能够取消飞行中的更新。

请参阅有关Cadence 编程模型的演示文稿。