消息中间件怎么实现系统解耦

空白-键 2015-10-30 02:08:50
之前把系统拆分成几个系统,系统之间的通信用的是http接口方式,最近看到说可以使用消息中间件实现。
消息中间件相对http接口来说有哪些优点?比如可以异步?
怎么用消息中间件实现解耦,是系统各自定义消息格式和协议,然后在调用时发送消息吗?
假设我用netty自己实现,那是不是要每个系统都各自启动一个server,如果是用类似于mqtt来实现,是不是也要每个系统部署一个服务来监听消息?
第一次接触,可能问的问题很白痴,希望能帮我解惑下,谢谢各位!
...全文
1037 7 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
7 条回复
切换为时间正序
请发表友善的回复…
发表回复
空白-键 2015-11-04
  • 打赏
  • 举报
回复
引用 6 楼 sp1234 的回复:
其实这就跟有快递公司为你负责收件送件,跟每一个人都自己送件,这样的区别。 显然消息中间件是通过牺牲一些效率,来换取更大的灵活性(服务器中继寻址),从而最终用另外一种形式来提高效率。 例如,可以自动保持高可靠、复杂均衡,可以保证服务器集群中每一台主机热插拔、应用系统热更新。等等。等你有这种规模的系统的需求时,等你用低级的服务形式感觉很难配置很难优化时,你就觉得这是有效率的。而如果只是层次不高地随便弄几个webservice感觉就很足够的时候,那么搞消息分发反而不如你的webserivce更有效率的。
非常感谢,虽然还是有点晕,但至少有了一点思路了
  • 打赏
  • 举报
回复
其实这就跟有快递公司为你负责收件送件,跟每一个人都自己送件,这样的区别。 显然消息中间件是通过牺牲一些效率,来换取更大的灵活性(服务器中继寻址),从而最终用另外一种形式来提高效率。 例如,可以自动保持高可靠、复杂均衡,可以保证服务器集群中每一台主机热插拔、应用系统热更新。等等。等你有这种规模的系统的需求时,等你用低级的服务形式感觉很难配置很难优化时,你就觉得这是有效率的。而如果只是层次不高地随便弄几个webservice感觉就很足够的时候,那么搞消息分发反而不如你的webserivce更有效率的。
  • 打赏
  • 举报
回复
引用 楼主 linminqin 的回复:
之前把系统拆分成几个系统,系统之间的通信用的是http接口方式,最近看到说可以使用消息中间件实现。
如果抠技术字眼,你会被时髦的理论忽悠得看不懂。如果你看懂实质,其实就是一层窗户纸。
  • 打赏
  • 举报
回复
你所谓的“系统之间的通信用的是http接口方式”,是指一种网状分布,也就是服务器之间是各有各的角色,然后相互依赖。而消息队列机制是指星形机制,既“一对多”结构,只有两种角色——master和worker,它专注于简单消息分发,使用简单统一的协议,而不要求各自服务器去了解对方的”htt接口方式”协议。 你可以把master部署在公网上,然后同一机房、不同机房、各种私有局域网里的worker服务器都可以跟master双向通讯,联网很简单很简单。而你的”http接口方式“是基于对等网络的,公网上的服务器不能访问各种局域网网关背后的服务器,联网方式可以很乱也很“高大上”。
空白-键 2015-11-02
  • 打赏
  • 举报
回复
引用 1 楼 sinat_27650399 的回复:
使用http的话,应用需要care协议设计,care服务是否启动 http方式的缺点: 1.同步方式,当然这个不是绝对,看你自己实现了 2.如果想做横向可扩展,需要自己设计协议解决分布,负载均衡还有各种异常处理 3.A服务依赖B服务,如果B服务有瓶颈,使用HTTP的方式,B的瓶颈也会成为A的瓶颈(短板效应) mq有哪些优点: 1.异步方式,系统伸缩性好 2.横向拓展的问题基本不用考虑,生产者只需要PUT PUT PUT,起多个Consumer让他们自己去取数据即可 3.系统遇到大流量冲击的时候,MQ还可以帮忙缓冲,不至于直接被冲垮(HTTP同步的时候这里可能会是瓶颈)
谢谢回答,可以的话能不能大致说下用消息中间件来实现的大致思路
空白-键 2015-11-02
  • 打赏
  • 举报
回复
引用 1 楼 sinat_27650399 的回复:
使用http的话,应用需要care协议设计,care服务是否启动 http方式的缺点: 1.同步方式,当然这个不是绝对,看你自己实现了 2.如果想做横向可扩展,需要自己设计协议解决分布,负载均衡还有各种异常处理 3.A服务依赖B服务,如果B服务有瓶颈,使用HTTP的方式,B的瓶颈也会成为A的瓶颈(短板效应) mq有哪些优点: 1.异步方式,系统伸缩性好 2.横向拓展的问题基本不用考虑,生产者只需要PUT PUT PUT,起多个Consumer让他们自己去取数据即可 3.系统遇到大流量冲击的时候,MQ还可以帮忙缓冲,不至于直接被冲垮(HTTP同步的时候这里可能会是瓶颈)
谢谢回答,可以的话能不能大致说下用消息中间件来实现的大致思路
  • 打赏
  • 举报
回复
使用http的话,应用需要care协议设计,care服务是否启动 http方式的缺点: 1.同步方式,当然这个不是绝对,看你自己实现了 2.如果想做横向可扩展,需要自己设计协议解决分布,负载均衡还有各种异常处理 3.A服务依赖B服务,如果B服务有瓶颈,使用HTTP的方式,B的瓶颈也会成为A的瓶颈(短板效应) mq有哪些优点: 1.异步方式,系统伸缩性好 2.横向拓展的问题基本不用考虑,生产者只需要PUT PUT PUT,起多个Consumer让他们自己去取数据即可 3.系统遇到大流量冲击的时候,MQ还可以帮忙缓冲,不至于直接被冲垮(HTTP同步的时候这里可能会是瓶颈)

25,980

社区成员

发帖
与我相关
我的任务
社区描述
高性能WEB开发
社区管理员
  • 高性能WEB开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧