小编Sus*_*arr的帖子

当面向消息的中间件完成工作时,为什么还要烦恼服务?

我得到的问题是etcd/consul/$试图解决的问题.服务消费者需要与服务提供商交谈,一个庞大流动的分布式系统需要一种机制来嫁给两者.

然而,"服务消费者在哪里满足他们的要求?"的问题.是旧的,IMO已经解决了MOM - 面向消息的中间件.

在MOM中,我们的想法是服务消费者并不关心服务提供商所在的位置.他们只是发送消息并让消息传递总线负责将消息路由到适当的消费者.可以有多个提供者都做同样的事情(基于队列的循环)或版本化的提供者(/ v1 /请求转到一个,/ v2 /请求转到另一个).

这是一个简单,强大的集成模式,它完全将服务接口与其实现分离.

然而,我看到了对发现服务提供商的这种奇怪的痴迷,这似乎在消费者和提供者之间创造了紧密的耦合(除了一些其他反模式之外).

那么,我在这里错过了什么?TIA.

service service-discovery mom etcd consul

18
推荐指数
1
解决办法
985
查看次数

标签 统计

consul ×1

etcd ×1

mom ×1

service ×1

service-discovery ×1