微服务：REST与消息传递

我听说亚马逊使用HTTP作为其基于微服务的架构。另一种方法是使用RabbitMQ或Solace系统等消息传递系统。我个人对基于Solace的微服务体系结构有经验，但从未对REST有过经验
你知道亚马逊、Netflix、英国政府等大联盟的实现使用了什么吗？
另一个方面是，在微服务中，需要以下内容（除了其他内容）：
*模式匹配
*异步消息传递。。接收系统可能已关闭
*发布订阅
*缓存加载事件。。i、 e.在启动时，服务可能需要加载来自其他两个服务的所有数据，并且在数据完全加载时应该得到通知，以便它可以“知道”它现在已经准备好为请求提供服务

---

这些方面自然是通过消息传递而不是休息来完成的。为什么任何人都应该使用REST（公共API除外）。谢谢。

我过去遵循的一个标准是，当关键要求是速度（数据丢失并不重要）时使用web服务，当关键要求是可靠性时使用消息传递。正如您所说的，如果接收系统关闭，消息将位于队列上，直到系统返回来处理它。如果它是一个REST端点，并且它关闭了，请求就会失败。

RESTAPI假定只使用HTTP。它相当于石器时代的技术，不接受异步。信息。要在那里插入消息，我会考虑WebSockets Gateways

---

-抱歉，最终出现了伪语句

HTTP，其余都是规范。RabbitMQ/Solace是消息代理。您的问题是“什么是基于HTTP/REST的服务应用程序”？嗯，可能是应该使用REST和应该使用消息传递的用例，或者两者的组合。。为什么是这种+1，而不是那种+1，您可能想考虑一下同步通信（REST）的耦合含义，如果一个失败了，那么它的所有依赖项都将失败，因此除了丢失数据之外，它还可能导致连锁反应，可能会导致整个系统崩溃。@SeanFarmar这就是我所说的多米诺骨牌效应。一个相关的问题是连锁反应，其中一个服务的更改可能需要下游服务的更改。有时您可能需要这种行为。例如，如果您希望得到快速的同步响应，并且出现超时或其他服务器错误，那么您可以相应地处理它。有些进程不能容忍等待。我相信还有其他类似的用例，那么为什么会有很多缺点呢？实际上，REST是基于HTTP方法的！是的，REST是同步的！这显然是错误的：HTTP是一种契约，一种通信协议。REST是一个概念，一种可以使用HTTP、FTP或其他通信协议的体系结构样式。HTTP是REST最常用的通信协议之一，我想这就是你产生误解的原因。