来自前端 UI 的查询的微服务通信答案

【问题标题】：Microservices communication for queries from front end UI来自前端 UI 的查询的微服务通信
【发布时间】：2021-01-10 04:04:05
【问题描述】：

根据微服务文档，除非需要，否则建议不要通过请求/响应 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 界面，用户可以在其中搜索产品，并在搜索产品时对目录微服务进行 http 调用以获取产品详细信息。现在，在将产品信息拉到前端 UI 上显示的同时，我还需要作为定价微服务的产品价格和库存微服务，以在 UI 上显示它是有货还是缺货.此外，我必须将产品搜索通知营销部门。

我在这里的设计是，在 UI 搜索之后，我会到达 API 网关，对 Catalog 微服务进行 Http 调用，在从 Catalog 获取详细信息时，我会进行两个不同的 Http 调用，一个用于定价微服务，另一个用于 Inventory 微服务以获取详细信息，在我收到响应后，我将形成响应 DTO 并将其传递到前端 UI 以显示有关产品、定价、库存或缺货的详细信息。同时，我计划将消息发送到 RabbitMQ for Marketing 团队以订阅消息并将其用于营销目的。

现在基于微服务设计模式，建议不要在微服务之间使用 Http 请求/响应类型的通信，但是我可以在这里选择吗？如果我不遵循同步请求/响应 http 通信，我还能如何在微服务之间进行通信以将响应发送回前端 UI，其中包含有关定价、库存以及产品信息的所有详细信息。

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

关于上述通信的任何建议，如果来自前端 UI 的请求需要来自多个微服务的详细信息以显示在 UI 上，是否有更好的微服务之间的通信方式。

【问题讨论】：

我不认为这是一个坏方法。您可以跨多个维度对 api 进行分类。一种这样的方式可能是机制：请求/回复或响应（想想 REST）、异步消息传递（想想 Rabbit MQ）和基于参与者的框架。当你知道下一个逻辑和它的位置时，你可以选择 req/repl，当你知道下一个逻辑是什么时，你可以选择 actor - 但不一定是它的位置，当你现在既不是下一个逻辑也不是位置时，你可以选择 asych 消息（你基本上过渡状态）。我确定还有其他机制（例如广播/粉丝），但是

标签： .net microservices cqrs

【解决方案1】：

我在完全相同的情况下也有完全相同的疑问，网上没有太多可查找的内容。

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

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

我会维护一个聚合服务，该服务由您在查询时需要的连接数据组成（可能是非规范化的）。每当拥有的数据更改事件被发布，新的服务就会相应地更新。

通过为查询提供单独的服务（基本上在某些服务中实现 CQRS），您不会因为将“主要”服务与其他服务/api 网关紧密耦合而损害它们。此外，您会将读取与写入操作分开，这始终是一个好习惯。这些聚合服务仅负责查询，并且通过单个请求，您可以获取多个服务中存在的数据，而无需直接询问它们。当然，更进一步的最终一致性是摆在桌面上的，但 CAP 定理。

【讨论】：