微服务 - 将用户数据存储在单独的数据库中

首先，挑战架构。让我们假设问题中的两个服务都是更大的微服务生态系统的一部分，这些生态系统都利用了用户信息。否则分离肯定会被过度设计。但是从“评论”这个词我们至少可以猜到至少还有一类对象，那就是被评论的东西。因此，让我们假设“用户服务”是分解为微服务的有意义的碎屑，因为至少其他一些碎屑获得了必要的权重来证明微服务分解是合理的。

在这种情况下，我建议以下策略：

其次，立即在您的评论服务中实现一个抽象层，这样大部分代码就不必关心用户来自哪里（即不加入或 $lookup）。这也是本地测试的绝佳机会，因为您只需创建一个包含所需数据的集合，然后针对它运行服务级别集成测试。

第三，为了与用户服务集成，每次需要时通过 API（在任何情况下都应该支持批量数据选择）从那里获取数据。因为你有抽象层，你可以在这个抽象层下面添加缓存、缓存超时和置换策略以及任何你可能需要的东西，而不必关心代码的主要部分。根据需要添加此类。把事情简单化。

第四，当事情真的变得很重要并且你必须关心数以万计的用户、大量的评论和每秒许多请求时，评论服务可以在抽象之下实现一个预先复制模式，以在本地获取完整的用户数据库。当用户群发生变化时，这通常基于用户服务向所有订阅者发送的异步消息来完成。当它适合订阅者（即评论服务）时，他们可以触发更改的完整或（不时）增量复制。从您为缓存所做的工作中，合适的集合已经到位。与存储在用户服务中的信息相比，您在评论服务中需要的信息可能要少得多（更不用说散列密码、其他登录选项或帐户信息了）。

第五，如果你仍然遇到性能挑战，你可以打破你需要的少数情况的抽象并执行 join 或 $lookup。

按顺序执行步骤，一旦整个组件正常工作，就停止。每一步都增加了相当大的复杂性，当你不需要它时，不要实施它。