我正在尝试使用微服务开发一个项目。
我有一些关于这个主题的问题(有些不清楚):
1)如何实现微服务通信？
A) HTTP:每个微服务都公开 HTTP API，一个 API 网关广播请求。
B) MQTT:每个微服务发布/订阅到代理
C) 两者兼而有之:但是如何理解一个比另一个更好呢？
即使对于通常通过 HTTP 执行的经典操作，我是否也必须使用 pub/sub 协议(protocol)作为标准？例如我有两个微服务: 网络管理和产品服务。 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)？
最佳答案
两者都绝对有可能!选择一个允许您在 HTTP(同步)通信和更多异步事件驱动的发布/订阅之间轻松混合和匹配的代理。它应该允许您根据需要在这两个选项之间迁移您的微服务。
HTTP API 在分布式应用程序的边缘非常有用，客户想要提交订单或其他东西，然后阻止等待响应(200 OK)。
但在微服务之间的应用程序内部，很多微服务不需要响应......异步，最终一致。使用 pub/sub(如 MQTT)可以轻松地让多个下游消费者使用。 MQTT 的另一个重要用途是将更新流式传输给下游消费者...例如来自公共(public)汽车或航空公司或其他公司的数据馈送，而不必轮询 REST API 以获取更新。
对于您的用例和类似的用例，我几乎总是建议使用发布/订阅通信，即使今天它是与单个后端进程的简单请求-回复交互。 REST over HTTP 是点对点的，也许将来您希望另一个进程能够查看/使用/监视该事件或交互。如果您已经在使用发布-订阅，则添加该数据流的第二个(或更多)消费者是微不足道的。 REST/HTTP 更难。
就性能而言，我非常怀疑像 HTTP 这样的阻塞协议(protocol)是否会胜过异步和双向协议(protocol)，例如使用 WebSockets 进行网络通信的 MQTT。
至于将所有这些粘合在一起的代理，请查看标准版 Solace PubSub+ 事件代理...可以同时执行(并在两者之间转换)MQTT 和 HTTP。我什至写了一个CodeLab for this (almost) exact use case哈哈!
(顺便说一句，我为 Solace 工作!仅供引用。)
关于rest - 基于事件的微服务 : MQTT with Broker OR HTTP with API GATEWAY?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/60709169/