用于前端UI查询的微服务通信

Question

根据微服务文档，建议不要通过请求/响应Http模式在微服务之间同步通信，除非需要。我有关于微服务通信的问题。

Catalog --> product information details
Pricing --> pricing details of products
Inventory --> product availability, in-stock or out of stock
Marketing --> notifying marketing team on searched product

我在这里的设计是，在UI搜索之后，我将到达APIhtml" target="_blank">网关，对Catalog微服务进行Http调用，当从Catalog获取细节时，我将进行两个不同的Http调用，一个用于定价微服务，另一个用于库存微服务，以获取细节，在得到响应后，我将形成响应DTO并将其传递给前端UI，以显示关于产品、定价、库存或缺货的细节。同时，我计划在RabbitMQ上发布一条消息，让营销团队订阅该消息，并将其用于营销目的。

现在，基于微服务设计模式，建议不要在微服务之间使用Http请求/响应类型的通信，但是这里有选择吗？否则，如果我不遵循同步请求/响应http通信，我如何在微服务之间进行通信，将响应发送回前端用户界面，包括关于价格、库存和产品信息的所有细节。

然而，在营销微服务中，我使用了从RabbitMQ获取关于项目搜索和更新营销数据库的消息的异步通信。

如果来自前端UI的请求需要来自多个微服务的详细信息在UI上显示，那么对于上面的交流有任何建议，是否有更好的方式在微服务之间进行评论。

Answer 1

在完全相同的背景下，我也有完全相同的怀疑，网上也没有什么可找的。

首先，我了解到有些情况下使用异步方法是行不通的，从目录中获取产品肯定是其中之一，因为它可能会损害用户体验。

话虽如此，您当然可以使用聚合来自多个服务的结果的API组合模式，但由于某些原因，大多数API网关框架/工具不支持聚合，此外，当需要复杂查询时，该模式存在缺陷。

我将维护一个聚合服务，该服务由查询时所需的联接数据组成（可能是非规范化的）。只要所拥有的数据发生变化，就会发布事件，并相应地更新新服务。

通过为查询提供一个单独的服务（基本上是在某些服务中实现CQRS)，您不会因为将“主”服务紧密耦合到其他服务/API网关而损害它们。此外，您将把读操作和写操作分开，这总是一个很好的做法。这些聚合的服务将只负责查询，通过单个请求，您可以获取多个服务中存在的数据，而不必直接询问它们。当然，进一步的最终一致性是摆在桌面上的，但CAP定理。