微服务和 PubSub：如何确保服务使用正确的事件

如何解决微服务和 PubSub：如何确保服务使用正确的事件

我有一个应用程序的微服务架构。 我有一个服务 S1 可以获取数据并将其存储在某处。然后是 2 个服务，S2 和 S3，它们都运行非常不同的 ML 任务。 当 S2 或 S3 需要数据时，它们会在名为 fetch_request 的主题上向 PubSub 发布消息。 获取数据的服务不断从该主题中拉取数据。当它完成一项任务时，它会在名为“fetch_done”的主题上发布一条消息，让发出请求的服务知道数据已被获取。

我的问题是：如何确保 S2 和 S3 不使用它们不应该使用的来自“fetch_done”的消息？ 我想过解决方案，但我不确定：

• 可能是在尝试从“fetch_done”中拉取时，我可以添加一个过滤器以仅拉取消息，前提是它们包含我会在初始请求消息中写入的 UUID？这样，您只能在知道 ID 的情况下才能拉取消息。当然，获取数据的服务随后需要将 id 放入响应中。

• 有点相同的想法，但可能只是在初始请求中添加请求服务的名称而不是 id ？这个问题的问题在于，如果我是对的，一个服务最终可能会模仿另一个服务，而且由于我可能不会成为应用中每个服务的唯一开发者，我认为 UUID 是一个更好的主意。

• 我完全错过了一些明显的东西？

解决方法

您可以实施多种模式。 IMO 最好为每个服务订阅 1 个。像这样，S1 在一个主题中发布一条消息，该消息在每个订阅中重复。

现在，您可以：

• 在由 S2/S3 发送并由 S1 接收的消息中放置一个属性。根据此属性，S1 在 S2 的主题或 S3 的主题中发帖。我不是很喜欢这个方案，因为 S1 服务端的责任太大
• 在由 S2/S3 发送并由 S1 接收的消息中放置一个属性。这一次，S1 只是在唯一一个主题中镜像响应发送的消息中的属性。创建 S2 和 S3 订阅时，您添加一个过滤器以仅接收具有相应属性的消息。像这样，例如，只有 S2 的消息在 S2 订阅中被过滤和传递。
• 在由 S2/S3 发送并由 S1 接收的消息中放置一个属性。此信息在发布时由 S1 服务反映在消息的正文或属性中。对 PubSub 订阅没有过滤器，S2 和 S3 服务收到所有消息，并在他们这边检查消息是否适合他们（并继续处理）（并删除消息 -> 正确确认但什么都不做）。

无论如何，因为通信是异步的，所以您需要一个元素来区分消息的正确接收者。使用 pubsub 过滤器的第二种解决方案是最有效的（我认为）。