Database design 在微服务之间共享数据

我从事微服务体系结构的工作，我想解决一个小的数据共享问题（我不知道这个词是否正确）

例如：

我有一个用户服务，是数据库，存储电子邮件，用户名，密码

我有另一个服务和他的数据库，它处理用户数据，生成包含用户信息的文档

---

第二个服务访问用户数据的最佳方式是什么？在is数据库中为她复制用户数据（如果他的工作需要的话？

我不知道整个系统的设计，但我会让用户微服务在创建、更新或删除用户时发送事件。所有其他对此事件感兴趣的微服务都可以提取所需的用户数据

通过使用微服务，无法避免冗余数据，但每个微服务对数据有不同的看法

您的用户微服务可能会将用户更多地视为具有完整用户数据（例如id、密码、名字、姓氏、电子邮件、地址、组织等）的身份

---

另一方面，您的文档生成微服务可能会将用户视为文档的接收者，而不需要所有用户数据。

警告顾问的回答是“视情况而定”。每个人对什么是微服务都有不同的描述，但对我来说，它们是小型的、可独立部署的服务，可以很好地完成一件事（我通常订阅）

事实上，只要微服务位于同一“服务”边界内，我对微服务共享存储（无论是数据库、blob存储等）没有问题。我所说的服务边界是小型服务的逻辑分组，所有这些服务都协作以实现某些目标或业务能力。对我来说，正是这种逻辑分组形成了从团队外部看的“服务”。一个服务“用户服务”通常由许多小型微服务组成

例如，您可能有一个由许多微服务组成的“用户”服务。一个用于从网站捕获兴趣并将其存储在数据库中，一个用于网站处理地址更改，一个用于运行定时作业并向系统中的其他服务发布事件

但是，您不希望从用户数据库读取和写入文档生成（reporting service？），在这种情况下（如Stavreva所说），服务之间的事件通信将是一种方式

---

只有具备业务领域知识的您才能决定两个微服务是否属于同一服务，其中一个技巧是查看微服务所贡献的业务能力。

这是否意味着我们需要与所有其他服务共享用户事件合同（本例中为文档服务）？这就增加了依赖性。“我可能遗漏了什么。@ArunJames您可以使用它的名称或任何其他类型的标识来处理事件。这样你就不需要参考合同了。