我正在尝试用微服务开发一个项目。
我对这个话题有一些问题(有些事情不清楚(：
1(如何实现微服务通信？
A( HTTP：每个微服务都公开HTTP API，一个API网关广播请求。
B( MQTT：代理的每个微服务pub/sub
C( 两者：但如何理解一个比另一个好？
即使对于通常通过HTTP执行的经典操作，我是否也必须使用pub/sub协议作为标准？例如，我有两个微服务：网络管理和产品服务web管理是一个面板，允许管理员添加、修改、。。。其电子商务数字商店中的产品。假设我们想要实现createProduct操作。这是一个命令(根据事件/命令的区别(，一对一的通信。
我可以在product-service中打开一个API，比如说(POST，"/product"(来添加新产品。我还可以在productCreationRequest事件中实现对命令的转换。在这种情况下：web managemnet发布此事件产品服务在收到执行操作并发出productCreated事件的通知后，会监听产品创建请求的事件(以及productUpdateRequest、productGetEvents…(。
我觉得这个案子已经到了临界点。例如，最后一次服务可能会收听productCreated并立即向客户发送消息(电子邮件或推送通知(。你觉得这个用例怎么样？
2( 哪一个可能是有效的代理(我将使用docker-compose或kubernetes来编排容器化的微服务：可能采用的语言是java、javascript、python(？
两者都有可能！选择一个代理，使您能够轻松地在HTTP(同步(通信和更异步的事件驱动pub/sub之间进行混合和匹配。它应该允许您根据需要在这两个选项之间迁移微服务。
HTTP API在分布式应用程序的边缘非常好，在那里客户想要提交订单或其他东西，阻止等待响应(200 OK(。
但在微服务之间的应用程序内部，许多微服务不需要响应。。。异步，最终一致。使用pub/sub(如MQTT(可以方便地支持多个下游消费者。MQTT的另一个伟大用途是将更新流式传输到下游消费者。。。像公共汽车或航空公司或其他公司的数据馈送，而不必轮询REST API进行更新。
对于您的用例和类似的用例，我几乎总是建议使用pub/sub通信，即使今天它是一个简单的请求-回复交互，只有一个后端进程。基于HTTP的REST是点对点的，也许将来您希望另一个进程能够查看/使用/监视该事件或交互。如果您已经在使用发布-订阅，那么添加该数据流的第二个(或更多(消费者是微不足道的。REST/HTTP更难。
就性能而言，我非常怀疑像HTTP这样的阻塞协议是否会优于异步和双向的协议，比如使用WebSockets进行web通信的MQTT。
至于将所有这些粘合在一起的broker，请查看标准版Solace PubSub+事件broker。。。可以同时执行MQTT和HTTP(并在两者之间转换(。我甚至为这个(几乎(精确的用例写了一个CodeLab哈哈！
(顺便说一句，我为Solace工作！仅供参考。(
考虑使用Javascript/Node.js的SMF框架，它有助于通过消息代理(RabbitMQ(在开箱即用的微服务之间进行原型发布/子通信：
https://medium.com/@krawa76/bootstrap-node-js-microservice-stack-4a348db38e51
至于消息代理路由，请使用事件驱动的命名约定，例如发布一个"web.new product"，其中"web"是子系统名称，"new product"是事件名称。