0

在微服务架构的上下文中，单个业务操作可能需要两个或多个服务之间的协作。

假设我们有一个订单管理服务和一个产品目录服务。当用户将订单项目添加到订单时，订单管理服务将保留一个 OrderItem 对象，该对象具有以下属性：

OrderItem 
+ Id
+ ProductId
+ ProductName

为了让 Order Management Service 填充 ProductName 属性，我们有 4 个选择，如我所见：

选择 1：ProductName 由客户端应用程序给出，因为它可能已经拥有来自先前请求的数据

选择 2：如果架构使用 Api 网关，网关将负责从产品目录服务中检索产品名称，然后将其提供给订单管理服务。

选择 3：订单管理服务将直接调用产品目录服务并要求他提供产品 ID 给定的产品名称。

选择 4：订单管理服务在其自己的数据库中有重复的（但不是详尽的）产品信息，每次从产品目录服务接收到更新事件时，这些数据都会更新。

在这 4 个选择中，n°1 对我来说似乎不太合适，因为我们不能相信客户会给我们一个正确和更新的 ProductName 值。

我想听听您对您认为最好的选择是什么以及原因的看法！

谢谢 ！

里亚纳

4

1 回答 1

0

选择 1：ProductName 由客户端应用程序给出，因为它可能已经拥有来自先前请求的数据

就像你说的，这不是最好的主意，因为客户可能有过时的信息。如果产品信息不经常更改和/或您在订单处理时进行二次验证，则可能可以接受。

选择 2：如果架构使用 Api 网关，网关将负责从产品目录服务中检索产品名称，然后将其提供给订单管理服务。

恕我直言，这不是一个好主意。通过这样做，您的域/业务逻辑将泄漏到 API 网关中。网关现在知道订单和产品之间的关系。此 API 网关配置/脚本将需要维护并引入额外的耦合。

选择 3：订单管理服务将直接调用产品目录服务并要求他提供产品 ID 给定的产品名称。

这是我的首选。虽然我不推荐“直接”同步调用。可能是通过消息传递机制（消息队列、事件总线）检索 ProductName。链式同步调用会降低服务的可用性。您可以在微服务消息传递模式中找到更多信息。

选择 4：订单管理服务在其自己的数据库中有重复的（但不是详尽的）产品信息，每次从产品目录服务接收到更新事件时，这些数据都会更新。

除非有充分的理由，否则数据重复通常是不受欢迎的。在这种情况下，我看不到任何东西。为什么要为每个服务将数据库分成两个，而在它们之间复制数据呢？此外，每次收到更新事件时更新数据表明某种事件/消息传递基础设施可用，在这种情况下，为什么不只使用消息传递？

这种重复对于大容量、低延迟的查找可能是合理的，但这是一个滑坡，最终可能会导致整个服务中的数据重复。想象一下 ProductName 字符串的长度或类型/格式更改的影响......

于 2019-05-31T05:45:03.333 回答