作者 l 会点代码的大叔（CodeDaShu）

RPC：Remote Procedure Call，中文意思就是远程过程调用。

远程是相对于本地来说的，有远程调用就有本地调用，那么先说说本地调用是什么，这个就简单了；

比如下图，我们的代码在同一个进程中（或者说同一个地址空间）调用另外一个方法，得到我们需要的结果，这就是本地调用：

那么想象一下，如果这里的add方法是一个很复杂的方法，很多系统都想用这个方法，那么我们可以把这个方法单独拆成一个服务，提供给各个系统进行调用，那么本地就会变成远程，就会变成这样：

01

RPC：让远程调用变得和本地调用一样

那么在 Server_A 中怎么调用 Server_B 中的 add 方法呢？

很多人都会想到 Server_B 封装一个接口，通过服务把这个方法暴露出去，比如通过 HTTP 请求，那么 Server_A 就可以调用 Server_B 中的 add 方法了。

通过这种方法实现起来没有问题，也是一个不错的解决方法，就是在每次调用的时候，都要发起 HTTP 请求，代码里面要写 HttpClient.sendRequest 这样的代码，那么我们有没有可能像调用本地一样，去发起远程调用呢？让程序员不知道这是调用的远程方法呢？这时候就要提到RPC了（并不是说 RPC 优于 HTTP 请求，关于这两个概念我们在下文中讨论）。

完整的RPC过程，如图：

• 服务调用方（Client）调用以本地调用方式调用服务；

• Client stub 负责将方法名、参数组装成消息体并进行序列化，找到服务地址，将消息发送到服务端；

• Server stub 收到消息后进行反序列化后调用本地的服务；

• 本地服务执行，将结果返回给 Server stub；

• Server stub 将运行结果打包成消息序列化后，发送调用方；

• Client stub接收到消息，并进行反序列化，调用方最终得到调用结果。

总结来说，RPC 用于服务之间的调用问题，特别是分布式环境；RPC 让远程调用时，像调用本地方法一样方便和无感知；RPC框架屏蔽了很多底层的细节，不需要开发人员关注这些细节，比如序列化和反序列化、网络传输协议的细节。

02

既然有 HTTP ，为什么还要用 RPC ？

其实，这个问题本身就是有问题的！

HTTP 和 RPC 并不是两个并行的概念，虽然很多书或文章，都介绍 HTTP 和 RPC 是在“应用层”，但实际上可以把应用层细分成多层，RPC 的所处的位置是高于 HTTP 的；HTTP 是网络协议，而RPC 可以看做是一种编程模式或实现方案；

RPC 通常包含传输协议和序列化协议，单说传输协议，RPC 可以建立在 TCP 协议之上（比如 Dubbo），也可以建立在 HTTP 协议之上（比如 gRPC）；如果是基于数据形式分类，RPC 又可以分成基于二进制、XML 和 JSON 三种；

而现在非常流行的开源 RPC 框架，比如上文中提到的Dubbo 和 gRPC 分别出身于阿里和谷歌，它们更多地是封装了服务注册发现、负载均衡、链路跟踪等功能，也可以这么理解，RPC 框架是对服务更高级的封装。

03

RPC VS Restful 风格的 API

RPC：面向过程，也就是要做一件什么事情，只发送 GET 和 POST 请求；GET 用来查询信息，其他情况下一律用 POST；请求参数是动词。

RESTful：面向资源，这里的资源可以是一段文字、一个文件、一张图片，总之是一个具体的存在，可以使用 GET、POST、DELETE、PUT 请求，对应了增删查改的操作；请求参数是名词。

比如按照id 查找用户：

• 如果是 RPC 风格的 url 应该是这样的：GET /queryUser?userid=xxx；

• 而 RESTful 风格通常是这样的：GET /user/{userid}

当然，对于遵守接口风格这一点，我个人是保留意见的，在实际的项目开发过程中，很多时候这些接口风格过于理想化；有些东西借鉴一下可以，更多的还需要结合项目实际使用。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：长按订阅更多精彩▼如有收获，点个在看，诚挚感谢