"real-world" 在微服务中不重复数据的解决方案是什么？

Question

假设我有一个用于消息传递的微服务。微服务知道如何发送电子邮件。该服务的电子邮件模板具有某种 "template engine" 之类的 pugjs，并且可以替换邮件正文中的数据。

我有一个用户服务（例如用于authentication/authorization）和一个银行账户服务（每个用户都有一个）。在用户微服务和银行账户微服务之间，很明显我们不需要复制除用户 uuid 之外的任何数据。

但我现在想每天向每个用户发送一条消息，其中包含他们的帐户报表。 Messaging 微服务需要来自 User 微服务和 Bank Account 微服务的数据。

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

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

好的...我可以使用代理，每次有新用户 created/updated 时，Messaging 微服务都可以存储该数据。但实际上，这是一件愚蠢的事情：

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

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

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

Answer 1

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

一般来说，您的 "basic" 域服务经常被代表特定业务目的并需要其数据的另一服务使用。依赖本身并不是一件坏事，只要关注点被清楚地分离，接口版本化，变更沟通等。

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