设计电子商务微服务

Question

我正在使用微服务架构设计电子商务。假设我有两个上下文：产品目录、库存和定价。 我似乎很清楚他们有明确的责任。但是要为展示案例（产品列表）提供服务，我需要请求产品目录，获取 ID 列表，然后使用它来查询库存微服务以检查库存状态（有货或缺货）。除此之外，我还需要向 Pricing 提出请求以获取每种产品的价格。

所以基本上服务于一个基本功能让我在三个微服务中执行三个请求（如连接）。我一直在阅读有关微服务架构的信息，当您处理许多“连接”时，这些上下文可能应该是一个单独的。但是，IMO 对我来说似乎很清楚每个上下文都有不同的职责。

另一种选择是创建一个“搜索”微服务来汇总所有这些信息（产品 + 定价 + 库存）。我们可以使用域事件来通知“搜索”微秒发生了一些变化。所以我们可以通过一个请求来解决展示案例。这看起来像 CQRS。

问题是……

有正确的方法吗？

哪个更好？取舍？

Answer 1

2019 年 2 月 14 日更新

这可能会更详细地回答您的问题https://stackoverflow.com/a/54676222/1235935

---

我认为这里的正确方法是使用事件溯源将展示案例数据与产品描述、库存和价格进行预聚合。可能不需要单独的微服务。这种预先聚合的数据（也称为物化视图）可以存储在处理用户显示产品请求的同一微服务中（可能是订单创建服务）。

事件可以通过基于日志的变更数据捕获 (CDC) 从产品、库存和定价服务的数据库中生成，并将它们写入日志结构化流平台（例如 Kafka 或 AWS Kinesis）中的各自主题，如提到here。这也将确保产品、库存和定价服务中的“读你自己写”的保证

Answer 2

您可以尝试将来自不同域上下文的一些信息包含到其他域上下文中

因此您的产品目录域将包含 #of items 、来自库存和定价域的价格。

这将是一个只读的（值对象）并且应该由来自库存和定价域的事件更新。

在您的用例中，可信的事实来源将在库存域中携带，因此如果发生任何同步失败，库存仍将因可用性而拒绝任何订单。

Answer 3

在您的情况下，我认为最好创建一个单独的搜索微服务来汇总所有数据，因为搜索通常来自多个领域，例如产品、库存和 ....

您可以使用来自其他微服务（事件搜索）的事件来填充搜索中的数据。

Answer 4

您似乎需要在视图中显示来自不同微服务（上下文）的信息。

您可以使用 ViewModel 组合技术，其中基础架构组件（请求处理程序）拦截 http 请求并允许微服务参与响应，寻找说“嘿，我有那个信息”的微服务（库存有有关库存的信息、有关价格的定价等）。这个基础设施组件动态组成一个动态视图模型，信息来自不同的微服务。

我从来没有实现过，但是看看这个视频解释它，从 17:35 到 21:00 分钟

https://www.youtube.com/watch?v=KkzvQSuYd5I

希望对你有帮助。