微服务：REST vs消息传递
我听说亚马逊使用HTTP作为其基于微服务的架构。另一种方法是使用RabbitMQ或Solace Systems这样的消息传递系统。我个人对基于Solace的微服务架构有经验，但从未使用过REST。
知道像Amazon、Netflix、UK Gov等各种大联盟实现使用什么吗？
其他方面是，在微服务中，还需要以下东西（除了其他东西）:
*模式匹配
*异步消息传递。接收系统可能已关闭
*发布订阅
*缓存加载事件..例如，在启动时，一个服务可能需要从几个其他服务加载所有数据，并且当数据完全加载时应该得到通知，这样它就可以“知道”它现在已经准备好为请求提供服务了
这些方面自然是通过消息传递而不是REST来完成的。为什么任何人都应该使用REST（公共API除外）。多谢了。
共有1个答案
我过去遵循的一个标准是，当关键需求是速度（数据丢失不是关键）时使用web服务，当关键需求是可靠性时使用消息传递。正如您所说的，如果接收系统关闭，消息将留在队列中，直到系统返回来处理它。如果它是一个RESTendpoint，并且它已关闭，那么请求将简单地失败。
-
我正在计划开发一个基于微服务的架构应用程序，当我阅读Ronnie Mitra的书《微服务架构》时，我决定使用Kafka进行内部通信；马特·麦克拉蒂；迈克·阿蒙森；伊拉克利·纳达雷什维利说： 让微服务直接与消息代理（如RabbitMQ等）交互很少是个好主意。如果两个微服务通过消息队列通道直接通信，那么它们共享一个数据空间（通道），我们已经详细讨论了两个微服务共享一个数据空间的弊病。相反，我们可以做的
-
我对尝试将微服务/SOA作为一种体系结构非常感兴趣，并且很难对服务之间的集成进行概念化。 我喜欢使用消息传递将客户端与服务分离的想法，但不理解系统如何独占地使用它。典型的异步操作和发布/订阅显然是有意义的——比如创建新订单、广播数据以进行报告等。我不明白的是，人们是否通常尝试在常见的请求/回复场景中使用消息传递——例如，用户点击他们的“个人资料”页面，而需要在页面上呈现的部分数据来自用户服务。 我
-
我们正在设计我们的新系统，它很可能是从头开始编写的，因为旧系统非常非常旧。对我们的系统来说，保留系统中发生的所有事情的审计跟踪日志非常重要。 由于审计跟踪的重要性，我们决定遵循事件源架构以获得它的所有好处。另一个关键因素是我们有多个团队在不同的“域”上工作。也就是说，我们想将每个域拆分为自己的服务（微服务架构），这样每个团队都可以独立工作。 我们面临的最大问题是谁将负责微服务之间的事件共享。例如，
-
我知道消息传递系统是无阻塞和可扩展的，应该在微服务环境中使用。 我质疑的用例是： 假设有一个admin dashboard客户机负责发送API请求以创建Item对象。有一个微服务提供APIendpoint，它使用一个MySQL数据库来存储项目。还有一个微服务使用弹性搜索进行文本搜索。 如果此管理仪表板客户端： a.发送2个API调用；1次调用MySQL服务和另一个elasticsearch服务 或
-
tl；博士：“我如何通过一堆异步、无序的微服务推送消息，并知道该消息何时通过每个微服务？” 我正在努力为特定的微服务体系结构找到合适的消息传递系统/协议。这不是一个“哪个是最好的”问题，而是一个关于我的设计模式/协议选项的问题。 我在开始队列上有一条消息。假设带有序列化JSON的RabbitMQ消息 我需要该消息通过任意数量的微服务 这些微服务中的每一个都是长时间运行的，必须是独立的，并且可以用多
-
我有一个BE服务a，它正在使用假客户端向microservice B发送Rest JSON消息： 终点： Rest Endpoint正在向AWS Ses邮件或其他邮件提供商发送邮件。 问题是来自飞格的第一个呼叫可能需要5秒或更长时间。我需要使其异步，以便FE客户端不要等待邮件发送。 我如何可以使从飞度异步发出的Rest调用到超文本传输协议响应OK没有等待时间可以预期？是否有一些更好的解决方案来实现