基于事件的微服务：带有代理的 MQTT 还是带有 API GATEWAY 的 HTTP？

Question

我正在尝试使用微服务开发一个项目。

我对这个话题有一些疑问（有些不清楚）：

1)如何实现微服务通信？

A) HTTP ：每个微服务都暴露 HTTP API ，一个 API GATEWAY 广播请求。

B) MQTT：每个微服务发布/订阅到代理

C) 两者：但是如何理解什么时候比另一个更好？

即使对于通常通过 HTTP 执行的经典操作，我是否也必须使用 pub/sub 协议作为标准？例如我有两个微服务： 网络管理和产品服务。 web-management 是一个面板，允许管理员在其电子商务数字商店中添加、修改、...产品。假设我们要实现 createProduct 操作。这是一个命令（根据事件/命令区分），一对一的通信。

我可以在产品服务中打开一个 API，比如添加新产品的 (POST, "/product")。我还可以在 productCreationRequest 事件中实现此转换命令。在这种情况下：web-managemnet 发布此事件。 product-service 在收到通知后侦听 productCreationRequest 事件（以及 productUpdateRequest、productGetEvents...），它会执行操作并发出 productCreated事件。

我发现这种情况处于临界状态。例如，last-occasion-service 可能会监听 productCreated 并立即向客户发送消息（电子邮件或推送通知）。您如何看待这个用例？

2) 哪个可能是有效的代理（我将使用 docker-compose 或 kubernetes 来编排容器化微服务：采用的语言可能是 java、javascript、python）？

Answer 1

考虑为 Javascript/Node.js 使用 SMF 框架，它有助于通过消息代理 (RabbitMQ) 在开箱即用的微服务之间建立发布/订阅通信原型：

https://medium.com/@krawa76/bootstrap-node-js-microservice-stack-4a348db38e51

对于消息代理路由，使用事件驱动的命名约定，例如发布“web.new-product”，其中“web”是子系统名称，“new-product” - 事件名称。

Answer 2

两者绝对是可能的！选择一个允许您在 HTTP（同步）通信和更多异步事件驱动的发布/订阅之间轻松混合和匹配的代理。它应该允许您根据需要在两个选项之间迁移您的微服务。

HTTP API 非常适合分布式应用程序的边缘，客户想要提交订单或其他东西，并阻止等待响应（200 OK）。

但是在您的应用程序内部的微服务之间，很多微服务不需要响应...异步，最终一致。并且使用 pub/sub（如 MQTT）可以轻松地支持多个下游消费者。 MQTT 的另一个重要用途是将更新流式传输到下游消费者...例如来自公共汽车或航空公司或其他东西的数据馈送，而不必轮询 REST API 以获取更新。

对于您的用例和类似的用例，我几乎总是建议使用 pub/sub 通信，即使今天它是一个与单个后端进程的简单请求-回复交互。 REST over HTTP 是点对点的，也许将来您希望另一个进程能够查看/使用/监视该事件或交互。如果您已经在使用发布-订阅，那么添加该数据流的第二个（或更多）消费者是微不足道的。使用 REST/HTTP 更难。

在性能方面，我非常怀疑像 HTTP 这样的阻塞协议会胜过异步和双向的协议，比如使用 WebSockets 进行 Web 通信的 MQTT。

对于将所有这些粘合在一起的代理，请查看标准版 Solace PubSub+ 事件代理...可以同时执行（并在）MQTT 和 HTTP 之间进行转换。我什至写了CodeLab for this (almost) exact use case哈哈！

（顺便说一句，我为 Solace 工作！仅供参考。）