由远程过程调用学到的

远程过程调用RPC

大学课本中讲过，进程间的通信方式，有一种就叫做RPC，Remote Procedure Call，即远程过程调用，在一个应用（进程）中调用另一个应用（进程）的方法。远程过程调用描述的就是这样一个概念，理论上来说，只要是通过某种方式能够实现，让一个进程能够通过这种方式去调用另一个进程的方法，就可以将该方式称为RPC的一种实现。

RPC需要什么

正如同我们调用本地函数，例如我们定义了一个add 函数

int add（int a, int b）{
    return a + b;
}

在该程序中我们可以非常方便地进行调用：

int a = add（5，6）；

因此可以同理，要想进行RPC，必须提供：

• 调用的方法名：如此处的add
• 调用的参数：如此处的5，6
• 调用方法的地址
• 同时为了在网络上对这些数据进行传输，需要将这些各式各样的数据（方法名、参数），进行序列化，同时还需要提供相应的反序列化的规则。带来跨语言的数据交换格式。

这样就可以让被调用方，获取到被调用的是什么方法，该方法的参数传入的是什么，然后在执行完成以后向调用方返回期望的结果。

http和RPC

从上面来看，我们会发现目前非常流行的RESTful api接口，完全满足我们上述的定义，例如如下的接口约定：

POST：/search/userInfo
参数：type json
{
    "use_id":"xxx",
}
返回值：
{
    "status":"xxx",
    "data":{},
    "msg":"",
}

使用路由定义调用的方法名，利用json作为参数的序列化方式，同时也使用json定义函数调用后的返回值，因此可以说RESTful api接口是RPC的一种实现。只是http协议为了通用型与普适性，当中还包含了非常多的非调用相关的控制信息。

http传输时的序列化与反序列化

http与json

如上述http传输，其序列化的过程就是将我们传入的参数整理打包，并准备发送的过程，上述调用会被打包成如下的形式：

json被按照明文格式序列化后存储在请求的body当中，“Content-Type”:"application/json"被设置用于告诉被调用方接受到参数的形式，使得可以采用对应的反序列化方式获得被序列化后的参数。
但是这种传输方式有几个缺点：

1. 参数采用了明文序列化的方式，这意味着没有一点压缩，传输的体量会很大。
2. http包含了非常多的“无效的”控制信息，会使得头部进一步庞大，增加网络传输的消耗。
3. json这种组织数据的形式，反序列化时非常消耗cpu计算能力，特别是出现多层嵌套和浮点数时

http与Protobuf

式，来减少序列化和传输带来的开销，例如谷歌的protobuf。
protobuf是目前业界最为推崇的一种数据传输格式，由google开源，和json的明文传输的方式不同，protobuf采用非明文的序列化方法，采用二进制存储和压缩，最终呈现的是一大块二进制串，因此他会在传输时减少非常多的开销。
也由于他不是明文的序列化方式，在调用方和被调用方就必须定义统一的IDL，即protobuf的proto文件，用来描述数据的序列化和反序列化规则，protobuf提供的生成代码会自动解析并提供数据获取的接口。
一篇比较好的protobuf介绍文章：深入 ProtoBuf - 简介

RPC框架

在上面一节可以看到，我们使用protobuf代替了json进行参数的指定、序列化，减少了传输时的开销，那么我们有办法去减少http的无用控制信息带来的开销吗？答案是可以的，直接舍弃http协议，在tcp的传输信道上构建一套自有的、私有的高效控制协议，对外提供一个隐藏细节的使用接口，这个就是我们说的RPC框架。
比较好的介绍：谁能用通俗的语言解释一下什么是 RPC 框架? - 知乎

常用的RPC框架

gRPC

grpc框架是google开源的一个RPC框架。他就接管了上述http的通信功能，在http2上构建了自己的高效的grpc协议，实现RPC的通信过程。当然序列化你可以选择搭配protobuf，也可以选择其他的序列化方式。
比较好的介绍：ProtoBuf 与 gRPC 你需要知道的知识_yeasy的专栏-优快云博客

Thrift

Thrift 是一套包含序列化功能和支持服务通信的RPC框架，它涵盖的东西可以说比gRPC更为全面，通俗涵盖来说等于：protoc（序列化反序列化代码生成工具） + protobuffer（DL指定） + grpc（传输协议）
序列化协议可以看官网描述，大致如下：

 0 1 2 3 4 5 6 7 8 9 a b c d e f 0 1 2 3 4 5 6 7 8 9 a b c d e f
+----------------------------------------------------------------+
| 0|                          LENGTH                             |
+----------------------------------------------------------------+
| 0|       HEADER MAGIC          |            FLAGS              |
+----------------------------------------------------------------+
|                         SEQUENCE NUMBER                        |
+----------------------------------------------------------------+
| 0|     Header Size(/32)        | ...
+---------------------------------

                  Header is of variable size:
                   (and starts at offset 14)

+----------------------------------------------------------------+
|         PROTOCOL ID  (varint)  |   NUM TRANSFORMS (varint)     |
+----------------------------------------------------------------+
|      TRANSFORM 0 ID (varint)   |        TRANSFORM 0 DATA ...
+----------------------------------------------------------------+
|         ...                              ...                   |
+----------------------------------------------------------------+
|        INFO 0 ID (varint)      |       INFO 0  DATA ...
+----------------------------------------------------------------+
|         ...                              ...                   |
+----------------------------------------------------------------+
|                                                                |
|                              PAYLOAD                           |
|                                                                |
+----------------------------------------------------------------+

下面着重阐述，Thrift和gRPC类比的传输控制部分
Thrift在传输时，分成Framed和Buffer两种形式，前者常用于NIO、后者常用于BIO，因此前者的Protocol之上还加了个Header（4个字节的消息体大小）。