微服务和 PubSub：如何确保服务使用正确的事件
Micro services and PubSub: how to make sure a service consumes the right events
我有一个应用的微服务架构。
我有一个可以获取数据并将其存储在某处的服务 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 post 一个主题中的一条消息，并且该消息在每个订阅中都是重复的。
现在，您可以：
- 在 S2/S3 发送并由 S1 接收的消息中添加一个属性。根据此属性，S1 post 在 S2 的主题或 S3 的主题中。我不太喜欢这个解决方案，因为 S1 服务端的责任太多
- 在 S2/S3 发送并由 S1 接收的消息中添加一个属性。这一次，S1 只是简单地在唯一一个主题的响应中反映消息中的属性。当您创建 S2 和 S3 订阅时，您添加一个过滤器以仅接收具有相应属性的消息。像这样，例如，在S2订阅中只过滤和传递S2的消息。
- 在 S2/S3 发送并由 S1 接收的消息中添加一个属性。 posted 时，S1 服务将此信息反映在消息的正文或属性中。 PubSub 订阅上没有过滤器，S2 和 S3 服务接收到所有消息并在他们这边检查消息是否是给他们的（并继续处理）或不是（并丢弃消息 -> 正确确认但什么都不做）。
无论如何，由于通信是异步的，因此您需要一个元素来区分消息的正确接收者。第二种解决方案，使用 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 post 一个主题中的一条消息，并且该消息在每个订阅中都是重复的。
现在，您可以：
- 在 S2/S3 发送并由 S1 接收的消息中添加一个属性。根据此属性，S1 post 在 S2 的主题或 S3 的主题中。我不太喜欢这个解决方案，因为 S1 服务端的责任太多
- 在 S2/S3 发送并由 S1 接收的消息中添加一个属性。这一次，S1 只是简单地在唯一一个主题的响应中反映消息中的属性。当您创建 S2 和 S3 订阅时，您添加一个过滤器以仅接收具有相应属性的消息。像这样，例如，在S2订阅中只过滤和传递S2的消息。
- 在 S2/S3 发送并由 S1 接收的消息中添加一个属性。 posted 时，S1 服务将此信息反映在消息的正文或属性中。 PubSub 订阅上没有过滤器，S2 和 S3 服务接收到所有消息并在他们这边检查消息是否是给他们的（并继续处理）或不是（并丢弃消息 -> 正确确认但什么都不做）。
无论如何，由于通信是异步的，因此您需要一个元素来区分消息的正确接收者。第二种解决方案，使用 pubsub 过滤器是最有效的（我认为）。