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

Question

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

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

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

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

还有其他想法吗？

标签： architecturemicroservicesmessagingpublish-subscribe

Answer 1

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

您正在维护一个列表，这样如果用户被删除，那么它不应该能够喜欢一个帖子。

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

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

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

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

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

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

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