在发布-订阅消息系统中同步新的/取消同步的微服务

Question

作为一个人为的示例，假设我有一个 Posts 服务，用于包含所有博客文章的博客 Web 应用程序。这与其他服务共存，例如 Users 和 UserLikes，并且这些服务通过基于 pub-sub 的消息代理进行通信。

UserLikes 服务允许用户“点赞”某些帖子，并维护一个活跃用户列表以确保一致性。为此，它订阅来自Users 服务的消息，用于用户创建/删除/更新。

这一切都很好，但假设现在我想添加一个UserDislikes 服务。此服务在当前用户创建后生效，因此它不会从Users 服务接收当前用户作为新用户事件。我们应该如何将这项新服务与当前用户列表同步？

我最初的想法是让Users 服务定期发布所有当前用户对象的列表（比如 S3），并将此事件发布到 UserSync 主题。但是，很少需要像这样同步，而且导出不会响应另一个服务需要完全同步的事件。那么解决方案是什么？也许UserSyncRequest 消息主题是Users 服务订阅并在其他服务请求时导出的？

还有其他想法吗？

Answer 1

示例似乎有点幼稚，因为“喜欢”和“不喜欢”的界限可能是同一个服务，但我会继续使用示例 :)。您可能创建UserLikes 和UserDislikes 服务的原因可能是因为用户的价值低于这些服务中的喜欢 和不喜欢。

在这种情况下，您可以通过将此信息发布到事件总线来保存 likes 和 dislikes 以及相应的用户标识符当发生喜欢或不喜欢的动作时。现在，如果您想显示页面或响应用户信息等，您只需进行两次服务调用，一次调用用户服务，另一次调用“喜欢”或“不喜欢”服务。

您可以查看的另一个潜在解决方案是，您可以发布整个用户对象，并将用户写入UserDislikes 服务的数据库中，而不是只发布相应的用户标识符。从技术上讲，在您的“喜欢”服务中，您不关心用户，直到他们喜欢或不喜欢某物，所以这会正常工作。同样，对于这两种解决方案，您仍然需要订阅用户创建、更新和删除事件。

Answer 2

在您的情况下，首先我不会在 UserLike 或 UserDislike Service 中维护活动用户列表。

您正在维护一个列表，这样如果用户被删除，那么它应该无法点赞帖子。

在 99% 或更多的情况下，如果用户被删除，他的所有访问权限都将被撤销，并且用户将无法调用 API 来点赞帖子。所以无论如何，只有有效的用户才会调用 API。

对于那 1% 的用户仍然具有访问权限的情况，在 UserLike 服务中维护用户列表将无济于事，因为在 UserLike 服务中处理已删除的事件也会有延迟。

现在，如果我真的想在 UserLike 或 Dislike Service 端维护一个列表

首先我将订阅该列表，以便我也开始获取事件但不处理它

那我会调用用户服务的api分批给我用户

在初始同步后，我将开始处理事件。

不做 UserSyncRequest 的原因是所有 UsersEvent 的监听器都会收到他们已经处理过的事件。