因此，当我了解每个服务模式的微服务数据库时，如果我正在构建社交网络应用程序
提要将在一个数据库中，用户将在另一个数据库中
那么如何处理用户和他们的帖子之间的外键关系，因为我需要用帖子返回用户数据，这是我能想到的不同方法
首先在post表中创建一个user_id字段并返回数据：1-apis进行调用以从user apis获取用户的数据
它不会让服务解耦得更少吗？
2.复制用户数据（需要的部分，例如名字，姓氏，头像和id）并使用分布式系统，例如kafka如果用户更改了他的数据，它也将在提要数据库中更改
但是拥有多个数据库不是毫无意义吗？
那么如何处理这种关系呢？
是否在存储帖子数据时复制用户数据取决于您（或客户）在用户数据更改时的期望。如果他们可以延迟帖子数据更新或根本不更新，那么可以在帖子中复制用户数据以提高效率。
但是，对于微服务设计，我们需要抛开数据库模式的顾虑，而不是从下到上（从数据层到应用层），而是从上到下（从应用层到数据层）进行设计。想想客户将如何使用应用程序，然后识别应用程序域内的子域（称为“限界上下文”），然后继续识别这个限界上下文中的“聚合”。参考聚合
