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

[空白-键]

之前把系统拆分成几个系统，系统之间的通信用的是http接口方式，最近看到说可以使用消息中间件实现。
消息中间件相对http接口来说有哪些优点？比如可以异步？
怎么用消息中间件实现解耦，是系统各自定义消息格式和协议，然后在调用时发送消息吗？
假设我用netty自己实现，那是不是要每个系统都各自启动一个server，如果是用类似于mqtt来实现，是不是也要每个系统部署一个服务来监听消息？
第一次接触，可能问的问题很白痴，希望能帮我解惑下，谢谢各位！

[走在冷风中_南山南]

使用http的话，应用需要care协议设计，care服务是否启动 http方式的缺点： 1.同步方式，当然这个不是绝对，看你自己实现了 2.如果想做横向可扩展，需要自己设计协议解决分布，负载均衡还有各种异常处理 3.A服务依赖B服务，如果B服务有瓶颈，使用HTTP的方式，B的瓶颈也会成为A的瓶颈（短板效应） mq有哪些优点： 1.异步方式，系统伸缩性好 2.横向拓展的问题基本不用考虑，生产者只需要PUT PUT PUT，起多个Consumer让他们自己去取数据即可 3.系统遇到大流量冲击的时候，MQ还可以帮忙缓冲，不至于直接被冲垮（HTTP同步的时候这里可能会是瓶颈）

[空白-键]

引用 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同步的时候这里可能会是瓶颈）

谢谢回答，可以的话能不能大致说下用消息中间件来实现的大致思路

[空白-键]

引用 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接口方式”，是指一种网状分布，也就是服务器之间是各有各的角色，然后相互依赖。而消息队列机制是指星形机制，既“一对多”结构，只有两种角色——master和worker，它专注于简单消息分发，使用简单统一的协议，而不要求各自服务器去了解对方的”htt接口方式”协议。 你可以把master部署在公网上，然后同一机房、不同机房、各种私有局域网里的worker服务器都可以跟master双向通讯，联网很简单很简单。而你的”http接口方式“是基于对等网络的，公网上的服务器不能访问各种局域网网关背后的服务器，联网方式可以很乱也很“高大上”。

[以专业开发人员为伍]

引用 楼主 linminqin 的回复:

之前把系统拆分成几个系统，系统之间的通信用的是http接口方式，最近看到说可以使用消息中间件实现。

如果抠技术字眼，你会被时髦的理论忽悠得看不懂。如果你看懂实质，其实就是一层窗户纸。

[以专业开发人员为伍]

其实这就跟有快递公司为你负责收件送件，跟每一个人都自己送件，这样的区别。 显然消息中间件是通过牺牲一些效率，来换取更大的灵活性（服务器中继寻址），从而最终用另外一种形式来提高效率。 例如，可以自动保持高可靠、复杂均衡，可以保证服务器集群中每一台主机热插拔、应用系统热更新。等等。等你有这种规模的系统的需求时，等你用低级的服务形式感觉很难配置很难优化时，你就觉得这是有效率的。而如果只是层次不高地随便弄几个webservice感觉就很足够的时候，那么搞消息分发反而不如你的webserivce更有效率的。

[空白-键]

引用 6 楼 sp1234 的回复:

其实这就跟有快递公司为你负责收件送件，跟每一个人都自己送件，这样的区别。 显然消息中间件是通过牺牲一些效率，来换取更大的灵活性（服务器中继寻址），从而最终用另外一种形式来提高效率。 例如，可以自动保持高可靠、复杂均衡，可以保证服务器集群中每一台主机热插拔、应用系统热更新。等等。等你有这种规模的系统的需求时，等你用低级的服务形式感觉很难配置很难优化时，你就觉得这是有效率的。而如果只是层次不高地随便弄几个webservice感觉就很足够的时候，那么搞消息分发反而不如你的webserivce更有效率的。

非常感谢，虽然还是有点晕，但至少有了一点思路了