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

Question

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

我有一个用户服务（例如用于身份验证/授权）和一个银行帐户服务（每个用户都有一个）。在 User 微服务和 Bank Account 微服务之间，很明显我们不需要复制除用户 uuid 之外的任何数据。

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

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

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

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

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

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

那么如何让上面的微服务不重复数据呢？

Answer 1

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

一般情况下，您的“基本”域服务被代表特定业务目的并需要其数据的其他服务使用会经常发生。依赖本身并不是一件坏事，只要关注点被清楚地分开，接口版本化，变更沟通等等。

不要忘记微服务的整个理念是允许团队通过清晰的接口承担专门的职责。它既关乎组织，也关乎架构。