原理

一个完整的RPC主要包括三部分:

服务注册中心（Registry），负责将本地服务发布成远程服务，管理远程服务，提供给服务消费者使用。
服务提供者（RPC Server），负责提供服务接口定义与服务实现类。
服务消费者（RPC Client），负责通过远程代理对象调用远程服务。

服务提供者（Server）启动后主动向服务注册中心（Registry）注册机器IP、端口以及提供的服务列表；

服务消费者（Client）启动时向服务注册中心（Registry）获取服务提供方地址列表。

服务注册中心（Registry）可实现负载均衡和故障切换。

RPC调用过程如下图所示：

「系统架构」原来这就是RPC呀，也没那么难嘛

(1) 客户端（Client）以本地调用方式调用服务；

(2) 客户端存根（Client stub）接收到调用后，负责将方法、参数等组装成能够进行网络传输的消息体（将消息体对象序列化为二进制）；

(3) 客户端通过 Network Service 将消息发送到服务端；

(4) 服务端存根（Server stub）收到消息后进行解码（将消息对象反序列化）；

(5) 服务端存根（Server stub）根据解码结果调用本地的服务；

(6) 本地服务执行并将结果返回给服务端存根（Server stub）；

(7) 服务端存根（Server stub）将返回结果打包成消息（将结果消息对象序列化）；

(8) 服务端（Server）通过 Network Service 将消息发送到客户端；

(9) 客户端存根（Client stub）接收到结果消息，并进行解码（将结果消息发序列化）；

(10) 客户端（Client）得到最终结果。

RPC 就是要把 2、3、4、7、8、9 这些步骤都封装起来。

什么情况下使用 RPC ？

RPC一般用于分布式系统中，且通常是内部调用使用。例如，开发电商系统，需要拆分出用户服务、商品服务、优惠券服务、支付服务、订单服务、物流服务、售后服务等等，这些服务之间都相互调用，这时内部调用最好使用 RPC ，同时每个服务都可以独立部署，独立上线。也就说，当我们的项目太大，需要解耦服务，扩展性强、部署灵活，这时就要用到 RPC ，主要解决了分布式系统中，服务与服务之间的调用问题。

目前流行的开源 RPC 框架还是比较多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。选择什么样的RPC框架，大家可以根据自己项目的需要来定。

已经有HTTP请求，为什么还要RPC？

这主要是历史原因！RPC在1984年就被人用来做分布式系统的通信，Java在1.1版本提供了Java版本的RPC框架（RMI），而HTTP协议直到1990年才开始作为主流协议出现，而且HTTP发明的场景是用于web架构，而不是分布式系统间通信，这导致了在很长一段时间内，HTTP都是浏览器程序和后端web系统通信用的东西，没有人会把HTTP作为分布式系统通信的协议。在很长一段时间内，RPC才是正统。

随着前端技术的发展，AJAX技术和JSON文档在前端界逐渐成为主流，HTTP调用才摆脱HTML，开始使用JSON这一相对简洁的文档格式，为后面用于系统间调用定下基础。最后，随着RESTFUL思潮的兴起，越来越多系统考虑用HTTP来提供服务，但这时候，RPC已经是各种大型分布式调用的标配了。所以这个问题我们也可以反过来问，既然有RPC了，为什么还要有HTTP请求？

既然有RPC了，为什么还要有HTTP请求？这个问题不难回答，因为现在大部分的系统都是给浏览器使用的，因此，HTTP协议必不可少，而这大部分系统中的绝大部分，对于后端系统间调用的性能都是要求不高的，毕竟走的都是内网，它们关心的是前端和后端的性能，因此后端系统间调用如果能够采用和前端一样的技术栈，那无疑是维护成本最低的，而这时HTTP的技术生态也刚好满足这个条件，所以就星星之火可以燎原了。那么对于少数的部分系统，他们需要使用RPC，一可能是老架构，也不敢动这块，二是性能要求可能只有RPC可以满足。

传输协议