作为一个人为的示例，假设我有一个Posts服务，用于包含所有博客文章的博客Web应用程序。这与Users和UserLikes等其他服务共存，并且这些服务通过基于发布订阅的消息代理进行通信。
UserLikes服务允许用户“喜欢”某些帖子，并且维护活动用户列表以增强一致性。为此，它订阅来自Users服务的消息，以供用户创建/删除/更新。
这一切都很好，但是现在我想添加一个UserDislikes服务。该服务在创建当前用户之后生效，因此它将不会从Users服务接收当前用户作为新用户事件。我们应该如何将该新服务与当前用户列表进行同步？
我最初的想法是让Users服务定期发布所有当前用户对象的列表（例如S3），并将此事件发布到UserSync主题。但是，这样的同步需求很少见，而且导出不会响应于另一个服务需要完全同步的情况。那么解决方案是什么？也许UserSyncRequest服务订阅了Users消息主题，并在其他服务要求时将其导出？
还有其他想法吗？
答案 0 :(得分：0)
示例似乎有点天真，因为“喜欢”和“不喜欢”的界限可能是相同的服务，但我将继续示例：)。您之所以创建UserLikes和UserDislikes服务的原因可能是因为用户的价值低于这些用户的喜欢和不喜欢服务。
在这种情况下，您可以通过将以下信息发布到事件总线来保存喜欢和不喜欢和相应的用户标识符当发生喜欢或不喜欢的动作时。现在，如果您要显示页面或使用用户信息以及类似信息进行响应，则只需进行两次服务调用，一个是对用户服务的调用，另一个是对“喜欢”或“不喜欢”服务的调用。
您可以查看的另一种潜在解决方案是，您可以发布整个整个用户对象，并将用户写入UserDislikes服务的数据库中，而不是仅发布相应的用户标识符。从技术上讲，在您的“喜欢”服务中，您不会关心用户，直到他们喜欢或不喜欢某些东西为止，这样就可以正常工作。同样，对于这两种解决方案，您仍然需要订阅用户创建，更新和删除的事件。
答案 1 :(得分：0)
在您的情况下，我不会在UserLike或UserDislike服务中维护活动用户列表。
您正在维护一个列表，这样，如果删除了用户，则该列表将不应该像发帖一样。
在99％或更多的情况下，如果删除用户，则其所有访问权限将被撤消，并且该用户将无法调用API来喜欢该帖子。因此，无论如何，只有有效的用户才能调用API。
对于用户仍具有访问权限的1％情况，在UserLike服务中维护用户列表将无济于事，因为在UserLike服务中处理已删除事件也可能会有延迟。
现在，如果我真的想在UserLike或Dislike Service端维护一个列表
首先，我将订阅列表，以便我也开始获取事件，但不对其进行处理
然后我将为用户服务调用api，以将用户分批给我
初始同步后，我将开始处理事件。
不执行UserSyncRequest的原因是，所有UserEvent的侦听器都将收到他们已处理的事件。