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

问题描述

我听说亚马逊将HTTP用于其基于微服务的体系结构.一种替代方法是使用消息传递系统，例如RabbitMQ或Solace系统.我个人有基于Solace的微服务体系结构的经验，但从未有过REST的经验.
知道亚马逊，Netflix，英国政府等各种大联盟实施方案有什么用吗?
在微服务中，其他方面是必需的(除了其他方面):
*模式匹配
*异步消息传递..接收系统可能已关闭
*发布订阅
*缓存加载事件..即，在启动时，服务可能需要从几个其他服务中加载所有数据，并且应在数据完全加载后得到通知，以便它可以知道"现在可以进行服务了要求
这些方面自然是通过消息传递而不是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屋！