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

Question

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

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

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

感谢任何阐述/经验！

Answer 1

我刚开始学习微服务，所以这绝不是一个完美的答案。不过，这是我根据目前的理解得出的看法。

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

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

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

Answer 2

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

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

例如，假设您正在实现Twitter的主页。你向不同的微服务发出一堆请求(“给我推荐的关注者”、“给我最新的时间表”等等)。").您不希望阻塞和序列化所有这些请求。你想让它们异步运行，这样可以创造更好的用户体验，因为当响应返回时，它们会实时更新用户界面。

Twitter使用Finagle(http://twitter.github.io/finagle/guide/index.html)这正是（异步RPC）。它不做消息传递系统会做的一些事情（特别是，它实际上与JVM绑定，并且不实现流控制或队列），但它确实实现了异步请求/响应。

Answer 3

我之前已经发布过这方面的文章 - 但一般来说，同步操作（例如，用户单击按钮并期望返回一些数据）是同步的，这是有原因的。

也就是说，同步——不是因为用于处理呼叫的技术——而是因为用户一方固有的、通常不灵活的期望，即事情应该实时发生，而不是“离线”发生(即使大多数时候没有实质性的区别)。

因此，在用户和他们预期的响应之间放置任何类型的离线或异步技术堆栈通常都是不明智的。

与所有事情一样，异常比比皆是（并且可能产生全新的对话），但某些类型的用户调用可以而且应该根据情况“离线”处理。

然而，我确实觉得你断言的重点是：

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

有点错过了重点。我们实际上并不想将客户端（或消费者）和服务分离。

我们期望一个客户，比如说，应付账款业务能力与应付账款微服务高度耦合。

类似地，我们期望服务endpoint签名bool ProcessTransact（事务事务）与此类操作的使用者之间存在高度耦合。

解耦变得非常重要的地方是支持不同业务功能的服务之间的解耦。

正是在这一点上，消息传递的优势真正发挥了作用。让我知道你的想法，如果这对你有帮助的话。