聊聊对RPC的理解

什么是RPC？

PRC是一种远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。比如两个不同的服务 A、B 部署在两台不同的机器上，那么服务 A 如果想要调用服务 B 中的某个方法该怎么办呢？使用 HTTP请求当然可以，但是可能会比较麻烦。 RPC 的出现就是为了让你调用远程方法像调用本地方法一样简单。

RPC原理

1. 服务消费方（client）调用以本地调用方式调用服务；

2. client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；

3. client stub找到服务地址，并将消息发送到服务端；

4. server stub收到消息后进行解码；

5. server stub根据解码结果调用本地的服务；

6. 本地服务执行并将结果返回给server stub；

7. server stub将返回结果打包成消息并发送至消费方；

8. client stub接收到消息，并进行解码；

9. 服务消费方得到最终结果。

已经有 http 协议接口，为什么还要使用 RPC 技术？

在接⼝不多的情况下，使用 http 确实是一个明智的选择，比如在初创企业，我们不确定业务能顺利开展下去，可能面临随时倒闭，开发人员也不足，这个时候使用简洁高效的技术，先把东西做出来是最明智的选择，无需一步登天。

系统与系统交互较少的情况下，使用 http 协议优点显而易见：开发简单、测试也比较直接、部署方便，利用现成的 http 协议进行系统间通讯，如果业务真的慢慢做大，系统也慢慢扩大，RPC 框架的好处就显示出来 了，

⾸先RPC 支持长链接，通信不必每次都要像 http 一样去重复 3 次握⼿，减少了网络开销。

其次就是 RPC 框架一般都有注册中心模块，有完善的监控管理功能，服务注册发现、服务下线、服务动态扩展等都方便操作，服务化治理效率大大提高。

基于 TCP 协议实现的 RPC，能更灵活地对协议字段进行定制，相比 http 能减少网络传输字节数，降低网络开销（握手）提高性能。实现更大的吞吐量和并发数，但是需要更多的关注底层复杂的细节， 对开发人员的要求也高，增加开发成本。