当面向消息的中间件完成这项工作时，为什么还要为服务发现而烦恼呢？

Question

我得到了etcd/consul/$正在尝试解决的问题。服务消费者需要与服务提供者对话，一个具有巨大流动性的分布式系统需要一种机制来将两者结合起来。

然而，“服务消费者的请求去了哪里？”是旧的，而IMO已经用MOM --面向消息的中间件解决了。

在MOM中，想法是服务消费者并不关心服务提供者住在哪里。它们只是发送一条消息，并让消息传递总线负责将消息路由到适当的使用者。可以有多个提供者都在做相同的事情(基于队列的循环)或版本化的提供者(/v1/request转到一个，/v2/request转到另一个)。

这是一个简单而强大的集成模式，它将服务接口与其实现完全解耦。

然而，我看到了这种对发现服务提供者的怪异痴迷，这似乎在使用者和提供者之间创建了紧密耦合(除了一些其他反模式之外)。

那么，我在这里错过了什么？蒂娅。

Answer 1

在MOM中，所有的东西都流经总线，所以它可能会成为瓶颈。对于服务发现，消费者“一次”查找生产者(好的，过一段时间可能需要再次检查)，然后“直接”(好的，可以通过代理)与之对话。

或者，如果您更喜欢朗朗上口的短语:智能端点&哑巴管道vs (我猜)哑巴端点&智能管道。

Answer 2

就我个人而言，我不认为这两种类型的架构是非此即彼的。您可以使用服务发现来查看当前有哪些服务可用，然后向MOM订阅您知道将会出现的事件。如果您找不到您所依赖的服务，您可以发出警报。并不是所有的妈妈都会让你知道什么时候一个频道没有出版商。

您还可以将它们组合在一起，使您可以在服务发现中找到您想要直接联系的服务，例如，不做任何工作的数据存储，并且仍然使用MOM来订阅其他系统所做更改的事件。并不是所有的用例都适合作业队列，因为一些任务必须同步解决，然后服务发现是拥有动态环境的一个很好的方法。

我自己确实更喜欢异步MQ，我认为如果你做得对，通过负载平衡、冗余、使用独立的读取器和写入器的集群等，你可以很容易地拥有很大的稳定性，可伸缩性和所有组件通信的标准化方式。