RPC过程————一篇就够了

概述

RPC即Remote Processing Call，远端过程调用。主要用途就是解决日益扩展的服务后台内，服务之间的调用通信。

组成

RPC由三大部分组成，分别是服务调用方（client），服务被调用方（server，也就是服务提供者）和服务注册中心（server register center）。三者之间相互配合，完成一次服务的RPC调用。

调用过程

1. client需要调用远端server上的一个服务
2. client将需要调用的服务信息打包发送给client stub（存根），client stub利用自身的一些机制将调用信息进行转换，转换为可以传递的消息体，外带附加上所调用服务的信息，并将这些信息发送给server register center。
3. register 负责提取 client 所要调用的服务信息，并负载均衡（说白了就是选择一个服务节点）给一个服务进行处理。
4. register选择完服务后，负责将client stub 传过来的消息体发送给特定服务的 server stub。
5. server stub将消息体进行解析，解析完成后发送给server。
6. server进行相应的服务处理，并将结果包装返还给server stub。
7. server stub接到服务执行的结果，将结果打包为消息体（这个消息体指可以进行网络通信传输的数据），发送给server register center。
8. server register center负载均衡给一个client server，并将消息体传递给 client stub。
9. client stub 解析 server register center 传递过来的结果，并将结果发送给 client server。
   10.client 进行相应处理。

---

注：在上述步骤中，有一个绕弯子的误区，即很多人认为client server只有一个。其实RPC的三大组件，都是集群部署，一个或者多个。A client 发出的RPC请求，可以被B client 接到服务结果后继续处理。（其实这个决定于个人的代码设计）

---

Http 和 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则是面向前后端通信的（面向范围不一样）。RPC可以用http实现。RPC快，HTTP稍微慢。