即时通讯网官方技术群和社区里，经常有开发者在纠结怎么开发IM集群，虽然真正的使用人数，可能用个人电脑单机都能支撑。

你也许会说，明明不需要用到IM集群，干吗要自找麻烦？答曰：“老板说这个得有！”、“万一产品做成了，用户量达到百万、千万级呢？”，各种回答，反此种种。总之，IM集群就是得整一个（先甭管用不用的上...）。

当然，玩笑归玩笑，真正要做到可投入到生产级别的IM集群系统，难度还是相当大的。必竟IM这种长连接应用相比传统Http这种短连接应用太不标准。

我们以一个典型的IM聊天消息传输为例：

假设存在两个正在聊天的用户（用户A和用户B），当A连接的是IM集群中的IM实例1、B连接的是IM集群中的IM实例2，此时当用户A向用户B发送一条聊天消息时，这条消息应该如何传递呢？

我们梳理一下上面这个例子的消息流转过程：

1）IM聊天消息首先会由用户A发往IM实例1；2）IM实例1会将此条消息转交给IM实例2；3）IM实例2会将此条消息最终投递给连接在本实例上的用户B。

如上述流程所示，这就是一个IM集群系统中典型的聊天消息投递过程。

那么，这其中涉及到一个关键步骤：即第2）步中如何实现“IM实例1会将此条消息转交给IM实例2”？

此时，RPC技术出场了！

RPC 是1984年代由 Andrew D. Birrell & Bruce Jay Nelson 提出的（见二位大佬的论文《Implementing Remote Procedure Calls》），所以它并不是最近才有的技术概念。

关于RPC的介绍，正经的资料上大概是这样介绍的：

RPC（Remote Procedure Call）远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。即时通讯聊天软件app开发可以加小蓝豆的v：weikeyun24咨询

大白话理解RPC就是：RPC让你用别人家的东西就像自己家的一样。

看得我似懂非懂，于是我不得不问几个问题：

1）为啥要用别人家的东西——请求其他服务)；2）我怎么可以借到别人家的东西——其他服务调用；3）要是借用的话哪种形式更好——确定一个合适的调用方法）；4）怎么让我用别人东西像自己的一样——屏蔽底层细节透明通信）。

在解答这些问题之前，我们必须达到一个共识问题：RPC只是一种通信模式，和http并不冲突对立，相反http可以作为RPC传输数据的一种协议，把RPC当作一种模式和思想，我们才能更好地理解它。

以大家最熟悉的电商系统为例，这样规模的分布式系统，需要拆分出用户服务、商品服务、优惠券服务、支付服务、订单服务、物流服务、售后服务等等。这些服务之间都相互调用，这时内部调用最好使用 RPC ，同时每个服务都可以独立部署，独立上线。

也就说当我们的项目太大，需要解耦服务，扩展性强、部署灵活，这时就要用到 RPC ，这主要是解决了分布式系统中，服务与服务之间的调用问题。

在日常业务中我们可以把功能封装成静态库、动态库、sdk、独立服务等，最常见也最方便的还是HTTP这种形式的调用。

HTTP服务把需要提供的服务暴露成接口（也就是通常所说的http rest接口啦），使用方直接按约定的HTTP方法和URI进行数据交互。

我们都知道HTTP协议是应用层协议，是个非常标准的协议，在HTTP协议之下还有网络层、传输层、数据链路层等，一个数据包packet除了净荷payload之外还有很多header，由于标准和通用性的设计目标也使得HTTP一次数据交互真正传输的payload只是其中一部分。

HTTP是我们用的最多最熟悉的交互模式，在系统内部各个服务之间接口较少，交互不多的情况下工作得还不错。

但如果在内部系统调用很复杂的前提下，HTTP调用的效率和安全性就不那么理想了。

以IM系统为例，单个IM实例的吞吐效率至少可以达到几万甚至数十万QPS，使用HTTP这种短连接（调用时建立socket连接，完成后释放连接）方式显的相当低效（每次调用都要重新经历TCP的3次握手、4次挥手过程），在分布式的情况下势必拉低整个IM集群的吞吐效率。而对于RPC，这种socket长连接方式对于高性能场景来说，效果是显而易见的。

更重要的是面对众多的服务我们需要的不仅仅是一个通信方式，而是一个内部服务的管理系统，这也就是我们今天说的RPC框架。注意：RPC是一种模式策略和框架，并不是单纯的通信协议。

题外话：实际上，HTTP在RPC系统中，并不是个你死我活的关系，必竟HTTP只是个通信协议，而HTTP有某些性能要求不敏感的场景来说，是完全可以作为RPC的具体实现协议之一来使用的。