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

Question

我对尝试将微服务/ SOA作为一种体系结构非常感兴趣，并且很难理解如何真正实现服务之间的集成。

我喜欢使用消息传递使客户端与服务脱钩的想法，但不了解系统如何专门利用它。典型的异步操作和发布/订阅内容显然是有意义的-例如创建新订单，广播数据以进行报告等方案。我不了解的是，人们是否通常尝试将消息传递用于常见的请求/答复方案-例如，则用户点击其“个人资料”页面，而需要在页面上呈现的部分数据来自用户服务。

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

感谢您的详尽阐述/经验!

Answer 1

我已经发布了有关before的信息-但一般而言，出于某种原因，同步操作(例如，用户单击按钮并期望返回一些数据)是同步的。

也就是说，同步-不是因为使用了处理 call 的技术-而是因为用户对内置的，通常不灵活的期望是事物应该实时发生而不是“离线”发生(即使大多数时候没有实质性差异)。

因此，将任何类型的脱机或异步技术堆栈放入用户及其预期响应之间通常是不明智的。

与所有事物一样，异常比比皆是(并且可能引发全新的对话)，但是根据情况，某些类型的用户调用可以并且应该“脱机”处理。

但是，我确实认为您主张的重点:

I like the idea of using messaging to decouple the clients from the services

有点错了。我们实际上并不希望使客户(或消费者)和服务脱钩。

我们希望客户(例如，应付帐款业务能力)与应付帐款微服务高度耦合。

同样，我们期望服务端点签名 bool ProcessTransaction(Transaction transaction)与此类操作的使用者之间存在高度的耦合。

去耦变得真正重要的地方是支持不同业务功能的服务之间的去耦。

在这里，消息传递的好处真正发挥了作用。让我知道您的想法以及这是否对您有帮助。