在微服务架构的背景下，单个业务操作可能需要两个或多个服务之间的协作。
假设我们有一个订单管理服务和一个产品目录服务。 当用户向订单中添加订单商品时，订单管理服务将保留OrderItem对象，该对象除其他外还具有以下属性：
OrderItem
+ Id
+ ProductId
+ ProductName
为了让订单管理服务填写ProductName属性，我看到有4个选择：
选择1 ：产品名称由客户端应用提供，因为它可能已经具有来自先前请求的数据
选择2 ：如果体系结构使用Api网关，则该网关将负责从产品目录服务中检索ProductName，然后将其提供给订单管理服务。
选择3 ：订单管理服务将直接致电产品目录服务，并要求他提供产品ID的ProductName。
选择4 ：订单管理服务在其自己的数据库中具有重复的（但不是详尽的）产品信息，并且每次从产品目录服务收到更新事件时，这些数据都会被更新。
在这4个选择中，n°1对我而言似乎不合适，因为我们无法信任客户为我们提供正确且更新的ProductName值。
我想就您认为最佳选择是什么以及为什么选择发表看法！
谢谢！
Riana
答案 0 :(得分：0)
选择1：产品名称由客户端应用提供，因为它可能已经具有来自先前请求的数据
就像您说的那样，这不是最好的主意，因为客户可能拥有过时的信息。如果产品信息很少更改和/或您在订单处理中进行了二次验证，则可以接受。
选择2：如果体系结构使用Api网关，则该网关将负责从产品目录服务中检索ProductName，然后将其提供给订单管理服务。
恕我直言，这不是一个好主意。这样，您的域/业务逻辑将泄漏到API网关中。网关现在知道订单和产品之间的关系。该API网关配置/脚本将需要维护，并引入其他耦合。
选择3：订单管理服务将直接致电产品目录服务，并要求他提供产品ID的ProductName。
这是我的首选。尽管我不建议“直接”同步调用。可能通过消息传递机制（消息队列，事件总线）检索ProductName。链接的同步呼叫会降低服务的可用性。您可以在Microservice Messaging Pattern上找到更多信息。
选择4：“订单管理服务”在其自己的数据库中具有重复的（但不是详尽的）产品信息，并且每次从“产品目录服务”收到更新事件时，这些数据都会被更新。
除非确实有充分的理由，否则通常不赞成重复数据。在这种情况下，我看不到任何东西。为什么要为每个服务将数据库分成两个，又在它们之间复制数据呢？另外，每次接收到更新事件时都要更新数据表明某种事件/消息传递基础结构可用，在这种情况下，为什么不只使用消息传递呢？
对于大容量，低延迟的查找来说，这种重复可能是合理的，但它是一个滑坡，最终可能会在您的整个服务中产生重复的数据。想象一下ProductName字符串的长度或类型/格式更改的影响...