RPC笔记整理

什么是RPC

HTTP和RPC的关系

例如，HTTP+Restful规范+序列化与反序列化，构成一个完整的远程调用方案，再和RPC进行比较。而单纯的HTTP，只是一个通信协议，自然无法和RPC比较。

RPC的英文全称是Remote Procedure Call，翻译为中文叫“远程过程调用”。其中稍显晦涩的其实就是“过程”，过程其实就是方法。所以，可以把RPC理解为“远程方法调用”。

而在分布式系统中，因为每个服务的边界都很小，很有可能调用别的服务提供的方法。这就出现了服务A调用服务B中方法的需求，即远程过程调用。

要想让服务A调用服务B中的方法，最先想到的就是通过HTTP请求实现。是的，这是很常见的，例如服务B暴露Restful接口，然后让服务A调用它的接口。基于Restful的调用方式因为可读性好（服务B暴露出的是Restful接口，可读性当然好）而且HTTP请求可以通过各种防火墙，因此非常不错。

然而，如前面所述，基于Restful的远程过程调用有着明显的缺点，主要是效率低、封装调用复杂。当存在大量的服务间调用时，这些缺点变得更为突出。

服务A调用服务B的过程是应用间的内部过程，牺牲可读性提升效率、易用性是可取的。基于这种思路，RPC产生了。

通常，RPC要求在调用方中放置被调用的方法的接口。调用方只要调用了这些接口，就相当于调用了被调用方的实际方法，十分易用。于是，调用方可以像调用内部接口一样调用远程的方法，而不用封装参数名和参数值等操作。

RPC是一个完整的远程调用方案，它包括了：接口规范+序列化反序列化规范+通信协议等。

rpc是远端过程调用，其调用协议通常包含传输协议和序列化协议。

传输协议包含: 如著名的 [gRPC](grpc / grpc.io) 使用的 http2 协议，也有如dubbo一类的自定义报文的tcp协议。再比如常见的PRC协议有Http协议，WebSocket协议，Thrift，Hession。（底层都是http TCP/UDP 协议）

序列化协议包含: 如基于文本编码的 xml ，json，也有二进制编码的protobuf，hessian， Kryo等。

国内一些大公司的使用情况：

protobuf ，腾迅，百度等

thrift，小米，美团等

hessian，阿里用的是自己维护的版本，有js/cpp的实现，因为阿里主用java，更多是历史原因。

简单来说成熟的rpc库相对http容器，更多的是封装了“服务发现”，"负载均衡"，“熔断降级”一类面向服务的高级特性。可以这么理解，rpc框架是面向服务的更高级的封装。如果把一个http servlet容器上封装一层服务发现和函数代理调用，那它就已经可以做一个rpc框架了。

调用方调用内部的一个方法，但是被RPC框架偷梁换柱为远程的一个方法。之间的通信数据可读性不需要好，只需要RPC框架能读懂即可，因此效率可以更高。通常使用UDP或者TCP作为通讯协议，当然也可以使用HTTP。

gRPC是由google开发的一个高性能、通用的开源RPC框架，主要面向移动应用开发且基于HTTP/2协议标准而设计，同时支持大多数流行的编程语言。gRPC基于HTTP/2协议传输。

grpc 和通常的基于TCP的实现不同，是直接基于HTTP2 协议的。HTTP2 使得grpc 能够更好的适用于移动客户端和服务端通信的使用场景，并且连接多路复用也保证了RPC 的效率。

grpc 的协议设计上很好的使用了HTTP2 现有的语义，请求和响应的数据使用HTTP Body 发送，其他的控制信息则用Header 表示。先看个例子，假设Protobuf 定义如...。

谈到RPC，就避免不了序列化的话题。gRPC默认的序列化方式是protobuf，因为两者都是google发明的。在当初Google开源protobuf时，很多人就期待是否能把RPC的实现也一起开源出来。没想到最终出来的是gRPC，终于补全了这一块。

Trpc 基于http2 protobuf

微软发布gRPC-Web实现，可直接在浏览器端调用gRPC服务

GRPC基于http2（多路复用）支持全双工，类似websocket。要用双向流参数。再比如参考1，2。

bp 协议跨语言，前端可以直接使用生成的文件直接调用远程远程接口方法。比如：

前端使用的整个流程：

1. 将后端提供的所有的proto文件拷进src/proto文件夹

2. 运行npm run proto 生成proto.js

3. 根据接口枚举在src/api下写接口

4. .vue文件中使用接口。

RPC和GRPC