为什么openstack要用rabbitmq这类消息中间件来进行RPC这类的操作呢，直接rpc不行吗？

标题是别人提到问题，下面是两个回答。不一定正确，可以辅助理解

先来看一下什么是RPC：

RPC英文全称remote procedure call 翻译成中文的意思就是远程过程调用。RPC的出现其实主要是为了解决分布式系统间的通信透明性的问题。

那什么是分布式系统的通信透明性问题？这个问题就是指分布式系统间的相互调用其实是基本进程间的显式消息交换，然而，消息的发送和接收过程无法隐藏。而通信的隐藏对于分布式中实现访问的透明性是极为重要的。试想一下比如你要想查看一个订单详情，然后订单系统部署了三台机器。假设没有RPC，其它系统想通过调订单系统查询订单详情的信息，就必须知道订单系统部署机器的ip和端口，每个调用者必须关注订单系统新加或者下线和换机器部署等情景。试想这对调用者来说是有多蛋疼。换言之分布式系统通信就应该是透明的，这样调用者就不需要关心调用的是那台机器上面的服务。在调用者的角度这个远程服务应该和调用本地服务一样是一个单一稳定可靠的服务。

回答1 

有个大神的回复是：用mq更方便处理分布式和异步消息。然后举了个例子：举个例子 不一定恰当，但可以理解思路。比如rpc调用方可能需要考虑有那些节点，那个节点可以处理，调用哪个。而用mq，不管有多少节点，只需要把请求丢进队列，所有节点都认识mq，其中一个节点把消息拿走处理，然后把处理结果丢回队列就行了。

应该就是说MQ可以更灵活地进行消息的处理，特别是业务比较复杂的系统；可以独立于应用，不用关注相关应用的底层细节；可以使用灵活的路由策略进行消息的分发；有丰富的插件系统，例如management插件，可以进行监控和管理，还有一些其他的插件，可以更方便地实现某些功能。后面这段是我自己的理解，请大家批评指正，谢谢！

回答2

openstack也可以用zeromq直接发起RPC请求，不需要单独做服务器；

而且两种方式各有利弊。比如专职服务器也会面对CPU、内存、磁盘（如果有持久化）使用率高等问题； 相反，zeromq使用连接数非常大（为了解决这个问题，openstack中基于zeromq也采用了proxy/broker的中转模型）。