当使用面向消息的中间件处理任务时，为什么还需要进行服务发现？

Question

23

我理解etcd/consul/$whatever想要解决的问题。服务消费者需要与服务提供者交流，一个极其复杂的分布式系统需要一种机制来将二者联系起来。

然而，“服务消费者应该去哪里发送请求？”的问题是老问题了，而且在我看来，已经通过MOM——面向消息中间件得到了解决。

在MOM中，服务消费者不关心服务提供者位于何处。他们只需发送消息，让消息总线负责将消息路由到适当的消费者即可。可能有多个服务提供者都在做同样的事情（基于队列的轮询），或者有版本化的提供者（/v1/request发往其中之一，/v2/request发往另一个）。

这是一种简单、强大的集成模式，完全将服务接口与实现分离。

尽管如此，我仍然看到了一种奇怪的迷恋于发现服务提供者的现象，它似乎会在消费者和提供者之间产生紧密耦合（除了其他几种反模式）。

那么，我在这里错过了什么？谢谢您。

- Susan Barr

我有同样的困惑。大多数服务发现和弹性技术（如断路器和重试）的示例都假定服务之间是同步通信... - drogon

2个回答

3

在MOM中，所有内容都通过总线进行流动，因此它可能会成为一个瓶颈。使用服务发现后，消费者只需查找生产者一次（好吧，可能过一段时间需要再次检查），然后直接（好吧，可能是通过代理）与其通信。

或者如果您喜欢有趣的短语：智能端点和愚笨的管道 vs（我猜）愚笨的端点和智能的管道。

- milan

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Canis · Accepted Answer

个人认为对于这种类型的架构，服务发现和消息队列并不是非此即彼的选择。你可以使用服务发现来查看当前可用的服务，并订阅MOM以获得你所知道的事件。如果找不到所依赖的服务，则可以发出警报。并非所有的MOM都会在通道没有发布者时通知你。

你还可以将它们结合起来，例如使用服务发现直接查找要联系的服务，例如没有任何工作的数据存储，并仍然使用MOM来订阅其他系统所做更改的事件。并非所有用例都适合作业排队，因为有些任务必须同步解决，而服务发现则是拥有动态环境的好方法。

我个人更喜欢异步MQ，并且如果你正确地使用负载平衡、冗余、分离读写等集群方式，你可以轻松地实现稳定性、可扩展性和所有组件间通信的标准化。