我得到了 etcd/consul/$whatever 试图解决的问题。服务消费者需要与服务提供者交谈，一个流动性极大的分布式系统需要一种机制来将两者结合起来。
然而，“服务消费者的请求去哪儿了”的问题？是旧的，IMO 已经用 MOM 解决了 - 面向消息的中间件。
在 MOM 中，这个想法是服务消费者不关心服务提供者住在哪里。他们只是发送一条消息并让消息总线负责将消息路由到适当的消费者。可以有多个提供者都在做同样的事情（基于队列的循环）或版本化的提供者（/v1/request 转到一个，/v2/request 转到另一个）。
这是一种简单而强大的集成模式，将服务接口与其实现完全分离。
然而我看到了这种对发现服务提供者的奇怪痴迷，这似乎在消费者和提供者之间建立了紧密的耦合（除了一些其他的反模式之外）。
那么，我在这里缺少什么？TIA。
In MOM, everything flows through the bus, so it might become a bottleneck. With service discovery, a consumer looks up a producer "once" (ok it might have to check back again after a while), and then "directly" (ok could be through a proxy) talks to it.
Or if you prefer catchy phrases: smart endpoints & dumb pipes vs (i guess) dumb endpoints & smart pipes.
就我个人而言，我不认为两者都适合这种架构。您可以使用服务发现来查看当前可用的服务，并订阅 MOM 以获取您知道将在那里的事件。如果您找不到您依赖的服务，您可以发出警报。当频道没有发布者时，并非所有 MOM 都会通知您。
您还可以将它们组合在一起，服务发现是您可以在其中找到要直接联系的服务的地方，例如不工作的数据存储，并且仍然使用 MOM 订阅事件以进行其他系统所做的更改。并非所有用例都适合作业排队，因为某些任务必须同步解决，然后服务发现是拥有动态环境的好方法。
我自己确实更喜欢异步 MQ，而且我认为如果你做对了，通过负载平衡、冗余、与单独的读取器和写入器进行集群等，你可以轻松地为所有组件提供出色的稳定性、可伸缩性和标准化的通信方式。