微服务前端的后端。 HTTP 或 RPC 与 RabbitMQ 进行通信？

Question

我正在实现一个微服务架构，我需要使用Backend for Frontends，但是我对如何实现它与微服务的通信有疑问

您如何看待使用 RabbitMQ RPC 将后端与前端与所有微服务进行通信？

我看到这些优点：

• 它可能提供比 REST 更好的性能。
• 良好的可扩展性和本机负载平衡。
• 无需像 GRPC 那样定义类型的开销即可轻松实现。

但是这些缺点：

• 这是单点故障。如果 RabbitMQ 崩溃，所有的微服务都将无法访问，失去所有微服务的独立性。
• 它基于异步通信，在那种情况下我们同步使用它。

你会在那种情况下使用 RabbitMQ RPC 还是只用于微服务之间的内部异步通信？ 根据您的经验，您为前端后端推荐哪种通信类型？

谢谢！

HTTP：

远程过程调用：

Answer 1

你有效地在系统中添加了一个故障点，但 RabbitMQ 是一个非常稳定的系统，如果它配置/容器化良好，你可以依赖它。

RabbitMQ 会增加移动端/前端的复杂性，有用于 MQTT/AMQP 的 JS 库，但它们有一些局限性，可能会妨碍您构建功能。

RabbitMQ 并不是真正设计用于处理双向同步通信，如果不依赖 AMQP 中的 Ack，您无法真正确定您的后端是否从您的前端/移动设备收到了您的请求。为什么要“手动”处理确认然后它是在 HTTP 中构建的？

在我公司，我们使用 RabbitMQ 与物联网设备通信，物联网设备不需要确认，可以异步方式发送数据。

我认为在您的用例中，经典 REST 是更好的选择。