已关闭。此问题为opinion-based。当前不接受答案。
**想要改进此问题吗？**请更新此问题，以便editing this post可以用事实和引文来回答。
3天前关闭。
Improve this question
我正在实现一个微服务架构，我需要将后端用于前端，但我对如何实现其与微服务的通信有疑问。
你对使用RabbitMQ RPC来与所有微服务进行后端到前端的通信有什么看法？
我看到了这些优势：
- 它可能比REST提供更好的性能。
- 良好的可扩展性和本地负载平衡。
- 它很容易实现，没有像GRPC那样定义类型的开销。
但这些缺点：
- 这是一个单点故障。如果RabbitMQ崩溃，所有微服务都将无法访问，失去所有微服务的独立性。
- 它基于异步通信，在这种情况下，我们使用同步。
你会在这种情况下使用RabbitMQ RPC，还是只用于微服务之间的内部异步通信？根据你的经验，你建议后端和前端使用哪种类型的通信？
谢谢！
HTTP：
RPC：
1条答案
按热度按时间jfewjypa1#
你有效地在系统中添加了一个故障点，但RabbitMQ是一个非常稳定的系统，如果它配置良好/容器化，你可以依赖它。
RabbitMQ可以增加移动的/前端的复杂性，有用于MQTT/AMQP的JS库，但它们有一些限制，并且可以在构建功能性时获得。
RabbitMQ并不是真正设计来处理双向同步通信的，你不能真正确定你的后端是否收到了来自你的前端/移动的的请求，而不依赖于AMQP中的Ack。为什么你要“手动”处理确认，而不是在HTTP中构建？
在我的公司，我们使用RabbitMQ与物联网设备进行通信，物联网不需要确认，可以以异步方式发送数据。
我认为在你的用例中，经典的REST是一个更好的选择。