我遇到了etd / consul / $试图解决的问题。服务消费者需要与服务提供商交谈，一个流动性很大的分布式系统需要一种机制来嫁给两者。
然而，“服务消费者的请求在哪里？”已经过时了，IMO已经用MOM解决了 - 面向消息的中间件。
在MOM中，服务消费者并不关心服务提供商所处的位置。他们只是发送消息并让消息传递总线负责将消息路由到适当的消费者。可以有多个提供者都做同样的事情（基于队列的循环）或版本化的提供者（/ v1 /请求转到一个，/ v2 /请求转到另一个）。
这是一个简单，强大的集成模式，可以完全解耦服务接口与其实现。
然而，我看到了对发现服务提供商的这种奇怪的痴迷，这似乎在消费者和提供者之间建立了紧密的联系（除了一些其他的反模式之外）。
那么，我在这里错过了什么？ TIA。
答案 0 :(得分：3)
在MOM中，一切都流过总线，因此它可能成为瓶颈。通过服务发现，消费者可以查找生产者＆＃34;一次＆＃34; （好吧，它可能需要在一段时间后再次检查），然后＆＃34;直接＆＃34; （好的可以通过代理）与它谈话。
或者如果您更喜欢引人注目的短语：智能终端＆amp;哑管 vs（我猜）哑终点＆amp;智能管道。
答案 1 :(得分：3)
我个人认为这两种架构都不是这两种架构。您可以使用服务发现来查看当前可用的服务，并订阅MOM以获取您当时知道的事件。如果找不到您所依赖的服务，可以发出提醒。当没有频道的发布者时，并非所有MOM都会通知您。
您还可以通过服务发现的方式将它们组合在一起，以便找到您想要直接联系的服务，例如没有工作的数据存储，并且仍然使用MOM订阅事件以获取其他更改系统。并非所有用例都适合作业排队，因为某些任务必须同步解决，然后服务发现是创建动态环境的好方法。
我自己更喜欢异步MQ，我认为如果你做得对，通过负载平衡，冗余，使用独立的读者和编写器等集群，您可以轻松地为所有组件提供出色的稳定性，可扩展性和标准化方法沟通。