我正在设计一个使用微服务架构的电子商务。假设我有两个上下文，即产品目录，库存和定价。 在我看来，他们有明确的责任。但是，要为展示柜（产品列表）提供服务，我需要请求产品目录，获取ID的列表，然后使用它查询库存微服务以检查库存状态（库存或缺货）。除此之外，我需要向定价请求以获取每种产品的价格。
因此，基本上服务于基本功能使我在三个微服务中执行三个请求（如联接）。我一直在阅读有关微服务架构的信息，当您处理许多“联接”时，这些上下文可能应该是一个。但是，IMO对我而言似乎很清楚，每种情况都有不同的职责集。
另一个选择是创建一个“搜索”微服务，以汇总所有这些信息（产品+定价+库存）。我们可以使用域事件来通知“搜索”微秒，其中发生了某些更改。因此，我们可以通过一个请求解决展示案例。看起来像CQRS。
问题是...
是否有正确的方法？
哪个更好？权衡？
答案 0 :(得分：0)
这可能会更详细地回答您的问题https://stackoverflow.com/a/54676222/1235935
我认为这里的正确方法是使用“事件采购”来将展示案例数据与产品描述，库存和价格预先汇总在一起。可能不需要单独的微服务。可以将这些预先聚合的数据（也称为物化视图）存储在处理用户显示产品请求的同一微服务中（可能是订单创建服务）。
产品，库存和定价服务可以通过在here中提到的日志结构化流平台（例如，Kafka或AWS Kinesis）中直接写入各自的主题，或写入各自的数据库来生成事件然后使用更改数据捕获（CDC）流式传输。
答案 1 :(得分：0)
您可以尝试将一些信息从不同的域上下文包含到其他域上下文中
因此您的产品目录域将包含#of件商品，来自库存的价格和定价域。
这是只读的（值对象），应该由库存和定价域中的事件进行更新。
在您的用例中，可信的真实来源将被携带在库存域中，因此，如果发生任何同步失败，库存仍然会由于可用性而拒绝任何订单。
答案 2 :(得分：0)
在您的情况下，我认为最好创建一个单独的搜索微服务来聚合所有数据，因为搜索通常总是来自产品，库存和...等多个领域。
，您可以使用其他微服务中的事件（事件源）填充搜索中的数据。
答案 3 :(得分：0)
似乎您需要的是在视图信息中显示来自不同微服务（上下文）的信息。
您可以使用ViewModel Composition技术，其中基础结构组件（请求处理程序）拦截http请求，并允许微服务参与响应，寻找一个微服务，该服务说“嘿，我有该信息”（清单包含有关库存的信息，有关价格的定价等）。该基础结构组件可动态构成动态视图模型，其信息来自差异微服务。
我从未实现过它，但请观看这段视频，从17:35分钟到21:00
https://www.youtube.com/watch?v=KkzvQSuYd5I
希望有帮助。