在微服务中是用队列好还是 RPC 好

业界本来就有这种实践吧 用 MQ 就属于消息型接口了 这种情况下我觉得不太适合高并发的场景？当然也能做但是相比 rpc 的实现来说，这种实现是不是成本也会更高了（比如还要多考虑下 MQ 的 backend ） 还有，容错方面 ，如果哪天 MQ 的集群因为某些原因炸了，那我的接口是不是都炸了？ 但是我始终觉得存在就是合理的，比如这种消息型接口在某些允许离线的工作模式下面价值就可以发挥出来（大晚上 XJB 乱打的）

阿里, 京东订单的状态流转是全部消息队列推动的.

那你有想过为了付出消息队列的你说的这两个特性需要付出多少代价吗

我觉得你这个有搞头但不可能像 http2.0 对 http1.1 那样的颠覆性
算是加 feature 不算是升级

zeroMQ 了解下，就是队列形式

两个有关系么？队列里面也可以塞 rpc 啊。有些 rpc 也支持队列啊。

rpc 不等价于同步。rpc 讲的是数据传输层的活；消息队列是传输数据的组织方式。 一个是用啥交通工具（汽车，飞机，火车），一个是物流方式，无中心点对点，还是有物流中心集中调配。怎么就可以对比了？

两者都不是一个类型，有什么好比的？

微服务本来就是队列的（ erlang ），只不过后来发现写面向对象的写不来队列才这样的。
本来同步就是伪问题，我们活在爱因斯坦的世界。

学习了

队列服务也可以有 rpc 接口。rpc 接口也可以用队列来处理请求。
两者不是互斥的

要什么队列要什么 RPC，大家一起走 HTTP 接口不好吗。

看你的整体的架构风格，很多系统可以拆分成 事件驱动来完成的话，消息队列很明显是一个非常好的东西，没有强一致性需求的时候 是非常不错的。

@Takamine 走 http 也算是 RPC 啊，RPC 可以通过 tcp http 等的方式实现，消息载体可以是 json、xml、二进制等

@justRua 我说的 HTTP 接口就是最直接的封装好暴露接口的业务逻辑，哪怕是一个 1+1，我也写个接口给你，要什么队列，要什么 RPC :doge:。

"Spring Cloud 的 RPC ？"
其实，SpringCloud 是基于 restful 的。Dubbo 才是基于 rpc 的。
rpc 是远程远程调用。通过某些协议调用其他模块的接口。
restful 是类似于用 url 进行 http 请求。

可行，微信的后台就有类似实践

@javaWeber http 也属于广义的 RPC，RPC 这个概念被滥用了，如果不严格限制的话消息队列也算是一种异步的 RPC。。。狭义的 RPC 才是 dubbo、hsf、grpc 这些

这个可不是同步和异步的关系、异步 gRPC 调用也是有的…

@petelin #63 ...... 我没有说颠覆性，我理解的优缺点我开头就说了，实现所需要付出的代价肯定是有的，但是同时也会带来一些队列的特性，我想知道如果两者放在微服务效果是怎样的，是否值得。我不是鼓吹队列肯定比传统 RPC 好，你们只是一个劲的反驳，看的我莫名其妙。

@scnace #61 性能不如传统 RPC 是必然的，但是同时高并发的压力也会转移到队列中一部分去。关于炸了，个人觉得现在队列都有分布式，应该还好。

@luozic #66 都可以放在微服务通讯中，为什么不可以比较？

@reus #70 我想的就是因为不是互斥的，在某些场景是可以替换的，想知道两者在微服务中的差距。

@javaWeber #75 关于 Spring Cloud，我在开头专门给它和其他传统 RPC 做了逗号分隔，就是因为 较真的话，http 也可以实现 RPC 的，只是不像我们理解的传统 RPC 是 socket 流传输的，其实 GRPC 默认还是 HTTP2 传输的呢。

@Duluku #78 我知道，是楼上们在较真同步和异步的调用，跟他们解释好费劲。