microservices - "real-world"在微服务中不重复数据的解决方法有哪些？

Question

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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