在微服务中不复制数据的“实际”解决方案是什么？

Question

假设我有一个用于消息传递的微服务。微服务知道如何发送电子邮件。该服务具有电子邮件模板，这些模板具有某种“模板引擎”（如pugjs），并且可以替换邮件正文中的数据。

我有一个用户服务（例如用于身份验证/授权）和一个银行账户服务（每个用户都有一个）。在用户微服务和银行账户微服务之间，很明显，我们不必复制任何数据，而不是 de 用户的 uuid。

但是我现在想每天向每个用户发送一条消息，其中包含他们的帐户对帐单。消息传递微服务需要来自用户微服务和银行帐户微服务的数据。

好。。。这是现实世界的一个小案例。现在我知道，要获得解耦微服务的好处，我必须遵循一些规则：

• 我无法在微服务之间共享数据库
• 我无法在微服务之间发出同步请求

好。。。我可以使用代理，每次创建/更新新用户时，消息传递微服务都可以存储该数据。但实际上，这是一件愚蠢的事情：

• 我不想与这些数据不一致，并且很难保持同步
• 消息传递微服务的开发时间和复杂性现在必须考虑：侦听并从事件中提取相关数据，保持有关其他域/服务的数据一致，管理数据库中保存的数据
• 并考虑消息传递微服务。真的我必须存储解析模板所需的所有数据吗？

我读了很多关于微服务和人们为他们简单示例创建规则的信息。但我从来没有真正看到像上面这样的好解释和现实世界的例子。

那么如何在不重复数据的情况下拥有上面的微服务呢？

Answer 1

在您的域示例中，我不会让邮件服务知道有关银行或用户详细信息的任何信息。相反，邮件服务应该只接收将消息与给定内容一起发送给收件人的指令。我将使用专用的计划作业（可能作为帐户通知服务实现），该作业执行从相应服务获取用户和帐户数据的工作，编译消息服务的信息并指示它实际发送消息。这引入了另一个“更高层次的商业目的实体/服务”，但允许您EP 明确的关注点分离。

通常，您的“基本”域服务经常被代表特定业务目的并需要其数据的另一个服务使用。依赖性本身并不是一件坏事，只要关注点被清楚地分开，接口被版本控制，更改被传达等。

不要忘记微服务的整个想法是允许团队通过明确的接口承担专门的职责。它既关乎组织，也关乎建筑。