我一直非常有兴趣尝试将微服务/ SOA作为架构，并且很难概念化服务之间的集成将如何实现。
我喜欢使用消息传递将客户端与服务分离的想法，但不了解系统如何专门使用它。典型的异步操作和发布/订阅内容显然是有意义的 - 例如创建新订单，广播报告数据等。我不明白的是人们是否通常尝试将消息传递用于常见的请求/回复场景 - 例如，用户点击他们的“个人资料”页面，需要在页面上呈现的部分数据来自用户服务。
我知道常见的消息传递实现提供类似REST的回复/请求功能，但是它通常用于简单的数据请求吗？微服务似乎更有可能暴露REST端点并向消息代理注册它将参与的不同类型的通信，但我所看到的SOA和微服务架构的所有这些演示似乎都暗示它们只使用其中一种。
感谢您的任何阐述/经验！
答案 0 :(得分：15)
我发布了这个before - 但一般来说，同步操作（例如，用户点击按钮并期待某些数据返回）是同步的。
也就是说，同步 - 不是因为用于处理他们的呼叫的技术 - 而是因为用户方面的内置且通常不灵活的期望事情应该实时发生而不是“离线” （即使大部分时间没有重大差异）。
因此，在用户和预期响应之间放置任何类型的离线或异步技术堆栈通常是不明智的。
与所有事情一样，异常比比皆是（并且可能会产生一个全新的对话），但某些类型的用户调用可以而且应该根据情况“离线”处理。
但是，我确实觉得你的断言的重点是：
我喜欢使用消息传递将客户端与客户端分离的想法 服务
稍微忽略了这一点。我们实际上并不希望将客户端（或消费者）与服务分离。
我们希望客户（例如，应付账款业务能力）与应付账款微服务高度耦合。
同样，我们期望服务端点签名bool ProcessTransaction(Transaction transaction)与此类操作的使用者之间存在高度耦合。
去耦变得非常重要的是在支持不同业务功能的服务之间进行解耦。
在这里，消息传递的好处确实有所作为。让我知道你的想法，以及这对你有什么帮助。
答案 1 :(得分：4)
我想当你问多久＆＃34;短信＆＃34;在请求/响应中使用，您可能意味着异步通信。
我会采取与此处的一些答案不同（相反）的观点，并说您应该几乎总是使用异步，即使在请求/响应中也是如此。这是因为异步意味着您没有阻止程序等待响应，并且您的程序可以在等待响应时继续进行其他处理。
例如，假设您正在实施Twitter的主页。你向不同的微服务发出了一堆请求（＆＃34;给我推荐的粉丝＆＃34;，＆＃34;给我最新的时间表＆＃34;等等＃34;）。您不想阻止和序列化所有这些请求。您希望通过异步触发它们并创建更好的用户体验，因为当响应重新出现时，它们会实时更新UI。
Twitter使用Finagle（http://twitter.github.io/finagle/guide/index.html）来实现这一点（异步RPC）。它没有做一些消息传递系统会做的事情（特别是，它真的与JVM绑定，并且它没有实现流控制或队列），但它确实实现了异步请求/响应。
答案 2 :(得分：0)
我刚开始学习微服务，所以这绝不是一个完美的答案。根据我目前的理解，这是我的观点。
如果您基于事件创建微服务，那么消息代理将发挥巨大作用。假设您有一个名为CreateUserService的服务，它只负责收集创建不持久保存数据的用户所需的数据。然后将此数据发布到队列中。
createUser队列的订阅者DuplicateUserService，UserDataStore等...然后可以相应地对每个服务中的数据做出反应。
最后，客户端从另一个服务接收数据，并提供有关尝试事件的相关信息。
答案 3 :(得分：0)
我不明白的是，人们是否通常会尝试将消息传递用于常见的请求/回复方案 - 例如，用户点击他们的＆＃34;个人资料＆＃34;页面和需要在页面上呈现的部分数据来自用户服务。
关键是完全避免请求/回复。从技术上讲，如果您的整个堆栈允许异步消息传递，包括通过在单页面应用程序（SPA）中使用类似WebSocket的Web前端，这是可能的。在实际示例中，您可以查看Typesafe的活动地图模板（https://www.typesafe.com/activator/template/reactive-maps-java）。
答案 4 :(得分：-1)
我没有使用REST，但我使用WSDL来允许层之间的通信。服务之间的集成非常简单，它们像后端的嵌套函数一样相互交谈，或者如果请求从服务器跳到服务器，则只使用XML和JSON。
此处服务器是内部Web服务的主机。并且基于要求排队可以提供给各个服务。但最后，只有一个响应从后端发送给调用者。