微服务:REST 与消息传递 [英] Microservices: REST vs Messaging

问题描述

我听说亚马逊在其基于微服务的架构中使用 HTTP.另一种方法是使用消息系统，如 RabbitMQ 或 Solace 系统.我个人有使用基于 Solace 的微服务架构的经验，但从未使用过 REST.
知道 Amazon、Netflix、UK Gov 等各种大联盟实施使用什么吗?
另一个方面是，在微服务中，需要以下内容(除其他外):
* 模式匹配
* 异步消息.. 接收系统可能已关闭
* 发布订阅
* 缓存加载事件.. 即在启动时，一个服务可能需要从几个其他服务加载所有数据，并且应该在数据完全加载时得到通知，以便它可以知道"它现在可以提供服务了要求
这些方面自然是通过消息传递而不是 REST 来完成的.为什么任何人都应该使用 REST(公共 API 除外).谢谢.

I heard Amazon uses HTTP for its microservice based architecture. An alternative is to use a messaging system like RabbitMQ or Solace systems. I personally have experience with Solace based microservice architecture, but never with REST.
Any idea what do various big league implementations like Amazon, Netflix, UK Gov etc use?
Other aspect is, in microservices, following things are required (besides others):
* Pattern matching
* Async messaging.. receiving system may be down
* Publish subscribe
* Cache load event.. i.e. on start up, a service may need to load all data from a couple of other services, and should be notified when data is completely loaded, so that it can 'know' that it is now ready to service requests
These aspects are naturally done with messaging rather than REST. Why should anyone use REST (except for public API). Thanks.

推荐答案

我过去遵循的一个标准是，当关键要求是速度(并且数据丢失并不重要)和消息传递时使用 Web 服务关键要求是可靠性.就像您所说的那样，如果接收系统出现故障，则消息将位于队列中，直到系统重新启动以处理它.如果它是一个 REST 端点并且它关闭了，请求就会失败.

A standard that I've followed in the past is to use web services when the key requirement is speed (and data loss isn't critical) and messaging when the key requirement is reliability. Like you've said, if the receiving system is down, a message will sit on a queue until the system comes back up to process it. If it's a REST endpoint and it's down, requests will simply fail.

这篇关于微服务:REST 与消息传递的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！