原来这就是RPC呀，也没那么难嘛？

Posted 2021-04-11 服务端思维

回复”669“获取独家整理的精选资料集

回复”加群“加入全国服务端高端社群「后端圈」

RPC就是远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想。

原理

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

• 服务注册中心（Registry），负责将本地服务发布成远程服务，管理远程服务，提供给服务消费者使用。

• 服务提供者（RPC Server），负责提供服务接口定义与服务实现类。

• 服务消费者（RPC Client），负责通过远程代理对象调用远程服务。

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

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

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可以满足。

传输协议

• RPC，可以基于TCP协议，也可以基于HTTP协议

• HTTP，基于HTTP协议

传输效率

• RPC使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以很好的减少报文的体积，提高传输效率

• HTTP，如果是基于HTTP1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装一下是可以作为一个RPC来使用的，这时标准RPC框架更多的是服务治理

性能消耗，主要在于序列化和反序列化的耗时

• RPC，可以基于thrift实现高效的二进制传输

• HTTP，大部分是通过json来实现的，字节大小和序列化耗时都比thrift要更消耗性能

负载均衡

• RPC，基本都自带了负载均衡策略

• HTTP，需要配置nginx，HAProxy来实现

服务治理（下游服务新增，重启，下线时如何不影响上游调用者）

• RPC，能做到自动通知，不影响上游

• HTTP，需要事先通知，修改Nginx/HAProxy配置

总结：

• RPC主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。

• HTTP主要用于对外的异构环境，浏览器接口调用，APP接口调用，第三方接口调用等。

— 本文结束 —

● 

● 

● 

● 

● 

关注我，回复 「加群」 加入各种主题讨论群。

对「服务端思维」有期待，请在文末点个在看

在看点这里