Sus*_*arr 18 service service-discovery mom etcd consul
我得到的问题是etcd/consul/$试图解决的问题.服务消费者需要与服务提供商交谈,一个庞大流动的分布式系统需要一种机制来嫁给两者.
然而,"服务消费者在哪里满足他们的要求？"的问题.是旧的,IMO已经解决了MOM - 面向消息的中间件.
在MOM中,我们的想法是服务消费者并不关心服务提供商所在的位置.他们只是发送消息并让消息传递总线负责将消息路由到适当的消费者.可以有多个提供者都做同样的事情(基于队列的循环)或版本化的提供者(/ v1 /请求转到一个,/ v2 /请求转到另一个).
这是一个简单,强大的集成模式,它完全将服务接口与其实现分离.
然而,我看到了对发现服务提供商的这种奇怪的痴迷,这似乎在消费者和提供者之间创造了紧密的耦合(除了一些其他反模式之外).
那么,我在这里错过了什么？TIA.
在 MOM 中，一切都通过总线流动，因此它可能会成为瓶颈。通过服务发现，消费者“一次”查找生产者（好吧，它可能需要在一段时间后再次检查），然后“直接”（好吧，可以通过代理）与其交谈。
或者，如果您更喜欢朗朗上口的短语：智能端点和哑管道与（我猜）哑端点和智能管道。