我对尝试使用微服务/SOA架构非常感兴趣，但很难理解服务之间的集成如何实现。
我喜欢使用消息传递来解耦客户端和服务端，但不明白一个系统如何完全使用它。异步操作和发布/订阅等典型的场景都是有意义的——例如创建新订单、广播用于报告的数据等。但我不明白是否通常尝试将消息传递用于常见的请求/响应场景——例如用户点击其“个人资料”页面，页面上需要呈现的部分数据来自用户服务。
我知道常见的消息传递实现提供类似于REST的请求/响应功能，但这种功能是否经常用于简单的数据请求？看起来更可能的是，微服务既会暴露REST终点，也会向消息代理注册不同类型的通信，但是我观看的所有SOA和微服务架构的演示似乎都暗示只使用其中一种...
感谢任何详细说明/经验！
我之前在这里发过类似的帖子 - 但总的来说，同步操作（例如用户点击按钮并期望得到一些数据）之所以是同步的是有原因的。
也就是说，同步-不是由于处理调用的技术而产生的，而是由于用户内置的且普遍缺乏灵活性的期望，即事情应该实时发生而不是“脱机”(即使大多数时候没有任何实质性区别)。
因此，通常不明智将任何离线或异步技术栈放在用户和他们预期的响应之间。
像所有事物一样，例外很多（并可能引发全新的讨论），但某些类型的用户调用可以根据情况进行“离线”处理。
然而，我认为你所肯定的重点:
我喜欢使用消息传递来解耦客户端和服务的理念
有些遗漏了。我们实际上不想要将客户端(或消费者)与服务解耦。
例如，我们期望Accounts Payable业务能力的客户端与accounts payable微服务高度耦合。
同样，我们期望一个服务终端点签名bool ProcessTransaction(Transaction transaction)与这种操作的使用者之间有很高程度的耦合。
在支持不同业务能力的服务之间进行解耦真正重要的地方就是在这里。
而这正是消息传递的好处所在，让我知道你的想法，是否有帮助到你。
我刚开始学习微服务，所以这并不是一个完美的答案。但这是基于我的当前理解和个人观点。
如果你正在创建基于事件的微服务，那么消息代理将扮演重要角色。比如说你有一个名为CreateUserService的服务，它只负责收集创建用户所需的数据而不是持久化数据。然后将这些数据发布到队列中。
订阅者可以是createUser队列的DuplicateUserService、UserDataStore等等，每个服务都可以根据数据做出相应的反应。
最终，客户端从另一个服务接收到有关尝试事件的相关信息。
我没有使用REST，但我使用WSDL来允许层之间的通信。服务之间的集成非常简单，它们像后端嵌套函数一样相互交谈，或者如果请求从服务器跳转，则仅使用XML和JSON。
这里的服务器是内部Web服务的主机。根据要求，可以为各个服务提供排队。但最终，只有一个响应从后端发送给调用方。
