Architecture 使用消息传递的微服务和SOA

我对尝试将微服务/SOA作为一种体系结构非常感兴趣，并且很难概念化服务之间的集成将如何实际完成

我喜欢使用消息传递将客户机与服务分离的想法，但不理解系统如何专门利用它。典型的异步操作和发布/订阅内容显然是有意义的——比如创建新订单、广播数据以进行报告等等。我不明白的是，人们是否通常尝试将消息传递用于常见的请求/回复场景——例如，用户点击他们的“配置文件”页面和需要在页面上呈现的部分数据来自用户服务

我知道常见的消息传递实现提供了类似REST的回复/请求功能，但这经常用于简单的数据请求吗？微服务似乎更有可能公开REST端点，并向消息代理注册它将参与的不同类型的通信，但我看到的所有这些SOA和微服务体系结构演示似乎都表明它们只使用其中一种

---

感谢您的精心设计/体验

我没有使用REST，但我使用WSDL来允许层之间的通信。服务之间的集成非常简单，它们像后端的嵌套函数一样相互通信，或者如果请求从一个服务器跳到另一个服务器，则只使用XMLs和json

这里，服务器是内部web服务的主机。根据需求，可以为单个服务提供排队。但最后，从后端只向调用方发送一个响应

我已经发布了关于这一点的帖子-但一般来说，同步操作（例如，用户单击按钮并希望返回一些数据）是同步的，这是有原因的

也就是说，同步——不是因为用于处理呼叫的技术——而是因为用户有一种内置的、通常不灵活的期望，即事情应该实时发生，而不是“离线”（即使大部分时间没有实质性差异）

因此，将任何一种离线或异步技术堆栈置于用户与其预期响应之间通常是不明智的

与所有事情一样，例外情况比比皆是（并可能引发全新的对话），但某些类型的用户呼叫可以而且应该根据情况“离线”处理

然而，我确实认为你的主张的重点是：

我喜欢使用消息传递将客户机与服务器分离的想法 服务

有点没抓住要点。我们实际上并不想将客户机（或消费者）和服务解耦

例如，我们希望客户的应付账款业务能力与应付账款微服务高度耦合

类似地，我们期望服务端点签名

boolprocessTransaction（Transaction Transaction）

与此类操作的使用者之间存在高度耦合

解耦真正重要的地方是支持不同业务能力的服务之间的解耦

---

正是在这里，信息传递的好处真正起到了作用。让我知道你的想法，如果这对你有帮助

我刚开始学习微服务，所以这绝不是一个完美的答案。这是基于我目前的理解，我的观点

如果您正在基于事件创建微服务，那么消息代理将发挥巨大作用。假设您有一个名为CreateUserService的服务，它只负责收集创建用户所需的数据，而不是持久化数据。然后将该数据发布到队列中

createUser队列DuplicateUserService、UserDataStore等的订阅服务器。。。然后可以对每个服务中的数据做出相应的反应

---

最后，客户端接收来自另一个服务的数据，其中包含有关尝试事件的相关信息

我想当你问在请求/响应中使用“消息传递”的频率时，你可能指的是异步通信

我将采取与这里的一些答案不同的（相反的）观点，并说您几乎应该始终使用异步，即使在请求/响应中也是如此。这是因为async意味着您不会阻止您的程序等待响应，并且您的程序可以在等待响应的同时继续执行其他处理

例如，假设您正在实现Twitter的主页。您向不同的微服务发出一系列请求（“获取我推荐的关注者”、“获取我最新的时间线”等）。您不希望阻止和序列化所有这些请求。您希望异步发出这些请求，从而创建更好的用户体验，因为当响应返回时，它们会实时更新UI

Twitter使用Finagle（）来实现这一点（异步RPC），它没有做一些消息传递系统会做的事情（特别是，它确实与JVM绑定，并且没有实现流控制或队列），但它实现了异步请求/响应

我不明白的是，人们是否通常尝试在常见的请求/回复场景中使用消息传递—例如，用户点击他们的“配置文件”页面，需要在页面上呈现的部分数据来自用户服务

---

关键是完全避免请求/回复。从技术上讲，如果您的整个堆栈允许异步消息传递，包括通过在单页应用程序（SPA）中使用WebSocket之类的东西来实现web前端的异步消息传递，这是可能的。有关一个实际示例，您可以查看Typesafe的反应式映射模板（）.

感谢您的回复，我特别想知道在回复/请求场景中使用消息传递（基于jms/amqp/etc）。非常好，谢谢！这就是我所怀疑的，从