如何处理微服务中的常见数据 [关闭]答案

【问题标题】：Howto handle common data in Microservices [closed]如何处理微服务中的常见数据 [关闭]
【发布时间】：2021-02-26 18:51:53
【问题描述】：

我正在尝试找出有关微服务架构的一般理解问题。

例如，如果我有三个服务：

并且每个服务数据都需要连接到用户。那么哪个用户添加了产品，哪个用户订购了一些东西等等。

所以我需要说“嘿订单服务，给我特定用户的所有订单”。这意味着在订单服务数据库中会有一个“用户 ID”列，对吗？但这只是与用户服务数据库中的用户数据无关的列，对吗？是这样的吗？

因此，如果用户被删除，可能需要询问订单服务是否还有具有该用户 ID etx 的订单。

所以问题是，用户 ID 的列是否根本没有连接到用户表，所以没有外键等，因为它们是完全不同的数据库？

非常感谢！

【问题讨论】：

刚刚快速阅读了一下，根据我的理解，共享同一个数据库并不违反微服务架构，只要每个微服务拥有的数据都是私有的。接下来，我确实相信需要某种形式的外键来将信息与用户联系起来。在继续向订单服务询问与该特定密钥匹配的订单之前，用户服务可能必须获取此密钥。请记住，我没有开发过微服务，所以这只是我对该主题的初步了解。

【解决方案1】：

微服务的理念是您应该将它们视为单独的服务，它们只是很小的——“微”。这在设计上意味着（逻辑上）独立的数据库。实际上，您可能会使用相同的数据库（例如，更简单，节省成本），但您会将表分开 - 服务之间没有外键。您还可以避免在同一个数据库事务中接触来自多个微服务的表。

注意：对于 NoSQL 数据库，情况类似 - 即使您使用相同的数据库，也要至少在逻辑上保持数据分离。

这意味着总是存在“最终一致性”——一个对象不能同时在多个微服务中被删除，总是存在延迟。

这是处理此类用户和订单服务的一种方法：

用户 X 在订单服务中创建订单 Y
从 Order 服务获取 X 的订单将返回 Y。
用户 X 已从用户服务中删除。一条“用户已删除”消息被发送到消息代理（后者将其发送给所有正在监听此类消息的微服务）
从 Order 服务获取 X 的订单仍将返回 Y。您可以选择在每次调用 Order 服务时验证用户，但这会带来服务之间额外调用的额外费用。在大多数情况下，我会信任会话 cookie 或不记名令牌，而无需为每次调用重新验证它。
现在订单服务接收并处理用户 X 的“用户已删除”消息并删除 X 的所有订单
现在获取 X 的订单将不会返回任何内容或“无效用户”

在本例中，Order 表可能会有类似“user_id”列的内容，该列将映射到 User 表中的用户 ID。但即使 Order 表（来自 Order 微服务）和 User 表（来自 User 微服务）使用相同的数据库实例，也不会设置为外键。

【讨论】：