使用消息传递的微服务和SOA
我一直对尝试将微服务/ SOA作为架构非常感兴趣，并且很难概念化如何实现服务之间的集成。
我喜欢使用消息传递将客户端与服务分离的想法，但不了解系统如何独占地利用它。 典型的异步操作和pub / sub的东西显然是有意义的 - 例如创建一个新订单，为报表广播数据等。我不明白的是人们是否通常尝试将消息传递用于常见的请求/回复场景 - 例如，用户点击他们的“个人资料”页面，并且需要在页面上呈现的部分数据来自用户服务。
我知道常见的消息传递实现提供类似REST的回复/请求功能，但常用于简单的数据请求？ 微服务似乎更有可能暴露REST端点，并向其消息代理注册其参与的不同类型的通信，但是我关注SOA和微服务体系结构的所有演示似乎都表明他们只使用其中一种。 。
感谢任何阐述/经验！
之前我已经发布过关于此的内容 - 但一般来说，同步操作（例如，用户单击按钮并期望返回某些数据）是同步的，这是有原因的。
也就是说，同步 - 不是因为用于处理他们的呼叫的技术 - 而是因为用户的内置和通常不灵活的期望，事情应该实时发生，而不是“脱机”（即使大部分时间没有实质性差异）。
因此，在用户和他们期望的响应之间放置任何类型的离线或异步技术堆栈通常是不明智的。
与所有情况一样，例外情况比比皆是（并且可能会产生一个全新的对话），但某些类型的用户呼叫可以并应该根据情况“离线”处理。
不过，我确实认为你的主张是：
我喜欢使用消息传递将客户端与服务分离的想法
有点错过了这一点。 我们实际上并不想分离客户（或消费者）和服务。
我们希望客户可以将应付账款业务能力与应付账款微服务高度结合。
同样，我们期望服务端点签名bool ProcessTransaction(Transaction transaction)与此操作的使用者之间高度耦合。
去耦合变得非常重要的是支持不同业务能力的服务之间的分离。
在这里，消息传递的好处确实有所作为。 让我知道你的想法，如果这对你有所帮助。
我想，当你问在请求/响应中多长时间使用“消息传递”时，你可能意味着异步通信。
我会采取与这里的一些答案不同的（相反的）观点，并且说你应该几乎总是使用异步，即使在请求/响应中也是如此。 这是因为异步意味着你不会阻止你的程序等待响应，并且你的程序可以在等待响应时继续进行其他处理。
例如，假设您正在实施Twitter的主页。 你向一些不同的微服务请求发出了一堆请求（“让我推荐的追随者”，“给我最新的时间线”，等等）。你不想阻止和序列化所有这些请求。异步，并创建更好的用户体验，因为随着响应回来，他们实时更新UI。
Twitter使用Finagle（http://twitter.github.io/finagle/guide/index.html）来完全实现这一点（异步RPC）。 它不会执行消息传递系统所做的一些事情（特别是，它实际上与JVM绑定，并且不实现流控制或队列），但它确实实现了异步请求/响应。
我刚开始学习微服务，所以这绝不是一个完美的答案。 尽管如此，我认为这是基于我目前的理解。
如果您正在基于事件创建微服务，那么消息代理将扮演巨大的角色。 假设你有一个名为CreateUserService的服务，它只负责收集创建用户不需要持久化数据所需的数据。 这些数据然后发布到队列中。
createUser队列的订阅者DuplicateUserService，UserDataStore等...可以对每个服务中的数据作出相应的反应。
最后，客户端从另一个服务接收有关尝试事件的相关信息的数据。
链接地址: http://www.djcxy.com/p/34079.html