基于事件的微服务：带有代理的 MQTT 或带有 API 网关的 HTTP？

Question

我正在尝试开发一个带有微服务的项目。

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

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

A) HTTP：每个微服务都会公开 HTTP API，即 API 网关广播请求。

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

C) 两者：但是如何理解一个比另一个更好呢？

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

我可以在产品服务中打开一个 API，比如说（POST，“/product”）来添加新产品。我还可以在ProductCreationRequest事件中实现此转换命令。在这种情况下：web-managemnet发布此事件。产品服务监听productCreationRequest事件（以及productUpdateRequest、productGetEvents等），一旦收到通知，它就会执行操作并发出productCreated事件。

我觉得这个案子很边缘化。例如，最后一次服务可以侦听ProductCreated并立即向客户发送消息（电子邮件或推送通知）。您对这个用例有何看法？

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

Answer 1

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

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

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

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

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

至于将所有这些粘合在一起的代理，请查看标准版 Solace PubSub+ 事件代理...可以同时执行 MQTT 和 HTTP（并在它们之间进行转换）。我什至为这个（几乎）完全相同的用例编写了一个 CodeLab哈哈！

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