RPC远程过程调用

RPC

RPC（Remote Procedure Call）远程过程调用也叫远程程序调用，是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而我们无序额外的关注这个交互过程。如果涉及的软件采用面向对象编程，那么远程过程调用也可称为远程调用或远程方法调用。

在单台计算机中，我们可以通过程序调用来传递控制和数据；或者说通过程序调用，我们可以将多个程序组成一个整体来实现某个功能。

如果将这种调用机制推广到多台彼此间可以进行网络通讯的计算机，由多台计算机中的多个程序组成一个整体来实现某个功能，这也是可以的。调用的一方发起远程过程调用，然后调用这方的环境挂起，参数通过网络传递给被调用方，被调用的一方执行程序，当程序执行完成后，产生的结果再通过网络回传给调用的一方，调用的一方恢复继续执行。这样一种原型思想，就是我们所说的RPC远程过程调用。

RPC这种思想最早可以追溯到1976年，RPC的发展到今天已经40年有余了。

如今的计算机应用中，单机性能上很难承受住产品的压力，需要不断扩充多台机器来提升整体的性能。同时为了充分利用这些集群里的计算机，需要对其从架构上进行划分，以提供不同的服务，服务间相互调用完成整个产品的功能。RPC就能帮助我们解决这些服务间的信息传递和调用。

RPC从广义上来说：

我们可以将所有通过网络来进行通讯调用的实现统称为RPC。

按照这样来理解的话，那我们发现HTTP其实也算是一种RPC实现。

RPC从侠义上来说：

区别于HTTP的实现方式，在传输的数据格式上和传输的控制上独立实现。比如在机器间通讯传输的数据不采用HTTP协议的方式（分为起始行、header、body三部份），而是使用自定义格式的二进制方式。

我们更多谈到的RPC都是指这种侠义上的理解。

RPC与HTTP对比：

• 优点
  • 效率高
  • 发起RPC调用的一方，在编写代码的时候可忽略RPC的具体实现，就如同调用本地函数一样
• 缺点
  • 通用性不如HTTP好

HTTP更多的是面向用户与产品服务器的通讯

RPC更多的面向产品内部服务器间的通讯

RPC结构

RPC的设计思想是力图使远程调用中的通讯细节对于使用者透明，调用双方无需关心网络通讯的具体实现。因而实现RPC需要进行一定的封装。

流程：

• 1.调用者（也叫客户端）以本地调用的方式发起调用
• 2.客户端辅助助手收到调用后，负责将被调用的方法名、参数等打包编码成特定个数能进行网络传输的消息体。
• 3.客户端辅助助手将消息体通过网络发送给服务端
• 4.服务端辅助助手接收消息后安装响应格式进行拆包解码，获取方法名和参数
• 5.服务端辅助助手根据方法名和参数进行本地调用
• 6.被调用者（也叫服务端）本地调用执行后将结果返回给服务端辅助助手
• 7.服务端辅助助手将返回值打包编码成消息，并通过网络发送给客户端
• 8.客户端辅助助手收到消息后，进行拆包解码，返回给调用者(客户端)
• 9.调用者（客户端）得到本次RPC调用的最终结果

gRPC

• gRPC是由Google公司开源的高性能RPC框架
• gRPC支持多语言
• gRPC支持多平台
• gRPC的消息协议使用Google自家开源的Protocol Buffers协议机制（proto3）序列化
• gRPC的传输使用HTTP/2标准，支持双向流和连接多路复用

使用方法：

• 1.使用Protocol Buffers(proto3)的IDL接口定义语言定义接口服务，编写在本文文件（必须以.proto为后缀名）中
• 2.使用protobuf编译器生成服务器和客户端使用的stub代码
• 3.编写补充服务器和客户端逻辑代码

Protocol Buffers

Protocol Buffers 是一种与语言无关、平台无关的可扩展机制，用于序列化结构数据。使用Protocol Buffers 可以一次定义结构化的数据，然后可以使用特殊生成的源代码轻松在各种数据流中使用各种语言编写和读取结构化数据。

1 文档结构

1） Protocol Buffers版本

Protocol Buffers文档的第一行非注释行，为版本申明，不填写的话默认为版本2。

syntax = "proto3";
或者
syntax = "proto2";

2）Package包

Protocol Buffers 可以声明package，来防止命名冲突。 Packages是可选的。

package foo.bar;
message Open { ... }

使用的时候，也要加上命名空间，

message Foo {
  ...
  foo.bar.Open open = 1;
  ...
}

注意：对于Python而言，package会被忽略处理，因为Python中的包是以文件目录来定义的。

3）导入

Protocol Buffers 中可以导入其它文件消息等，与Python的import类似。

import “myproject/other_protos.proto”;

4）定义各种消息和服务

消息messge是用来定义数据的，服务service是用来gRPC的方法的。

2 注释

Protocol Buffers 提供以下两种注释方式。

// 单行注释
/* 
多行注释 
多行注释 
*/

3 数据类型

3.1 基本数据类型

.proto	说明	Python
double		float
float		float
int32	使用变长编码，对负数编码效率低， 如果你的变量可能是负数，可以使用sint32	int
int64	使用变长编码，对负数编码效率低，如果你的变量可能是负数，可以使用sint64	int/long
uint32	使用变长编码	int/long
uint64	使用变长编码	int/long
sint32	使用变长编码，带符号的int类型，对负数编码比int32高效	int
sint64	使用变长编码，带符号的int类型，对负数编码比int64高效	int/long
fixed32	4字节编码， 如果变量经常大于2^{28} 的话，会比uint32高效	int
fixed64	8字节编码， 如果变量经常大于2^{56} 的话，会比uint64高效	int/long
sfixed32	4字节编码	int
sfixed64	8字节编码	int/long
bool		bool
string	必须包含utf-8编码或者7-bit ASCII text	str
bytes	任意的字节序列	str

3.2 枚举

在 Proto Buffers 中，我们可以定义枚举和枚举类型，

enum Corpus {
    UNIVERSAL = 0;
    WEB = 1;
    IMAGES = 2;
    LOCAL = 3;
    NEWS = 4;
    PRODUCTS = 5;
    VIDEO = 6;
}
Corpus corpus = 4;

枚举定义在一个消息内部或消息外部都是可以的，如果枚举是 定义在 message 内部，而其他 message 又想使用，那么可以通过 MessageType.EnumType 的方式引用。

定义枚举的时候，我们要保证第一个枚举值必须是0，枚举值不能重复，除非使用 option allow_alias = true 选项来开启别名。

enum EnumAllowingAlias {
    option allow_alias = true;
    UNKNOWN = 0;
    STARTED = 1;
    RUNNING = 1;
}

枚举值的范围是32-bit integer，但因为枚举值使用变长编码，所以不推荐使用负数作为枚举值，因为这会带来效率问题。

4 消息类型

Protocol Buffers使用message定义消息数据。在Protocol Buffers中使用的数据都是通过message消息数据封装基本类型数据或其他消息数据，对应Python中的类。

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}

4.1 字段编号

消息定义中的每个字段都有唯一的编号。这些字段编号用于以消息二进制格式标识字段，并且在使用消息类型后不应更改。 请注意，1到15范围内的字段编号需要一个字节进行编码，包括字段编号和字段类型。16到2047范围内的字段编号占用两个字节。因此，您应该为非常频繁出现的消息元素保留数字1到15。请记住为将来可能添加的常用元素留出一些空间。

最小的标识号可以从1开始，最大到2^29 - 1,或 536,870,911。不可以使用其中的[19000－19999]的标识号， Protobuf协议实现中对这些进行了预留。如果非要在.proto文件中使用这些预留标识号，编译时就会报警。同样你也不能使用早期保留的标识号。

4.2 指定字段规则

消息字段可以是以下之一：

• singular：格式良好的消息可以包含该字段中的零个或一个（但不超过一个）。

• repeated：此字段可以在格式良好的消息中重复任意次数（包括零）。将保留重复值的顺序。对应Python的列表。

    message Result {
      string url = 1;
      string title = 2;
      repeated string snippets = 3;
    }
  

4.3 添加更多消息类型

可以在单个.proto文件中定义多个消息类型。

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}

message SearchResponse {
 ...
}

4.4 保留字段

保留变量不被使用

如果通过完全删除字段或将其注释来更新消息类型，则未来用户可以在对类型进行自己的更新时重用字段编号。如果以后加载相同的旧版本，这可能会导致严重问题，包括数据损坏，隐私错误等。确保不会发生这种情况的一种方法是指定已删除字段的字段编号（或名称）reserved。如果将来的任何用户尝试使用这些字段标识符，protobuf编译器将会报错。

message Foo {
  reserved 2, 15, 9 to 11;
  reserved "foo", "bar";
}

4.5 默认值

解析消息时，如果编码消息不包含特定的单数元素，则解析对象中的相应字段将设置为该字段的默认值。这些默认值是特定于类型的：

• 对于字符串，默认值为空字符串。
• 对于字节，默认值为空字节。
• 对于bools，默认值为false。
• 对于数字类型，默认值为零。
• 对于枚举，默认值是第一个定义的枚举值，该值必须为0。
• 对于消息字段，未设置该字段。它的确切值取决于语言。
• 重复字段的默认值为空（通常是相应语言的空列表）。

4.6 嵌套类型

你可以在其他消息类型中定义、使用消息类型，在下面的例子中，Result消息就定义在SearchResponse消息内，如：

message SearchResponse {
  message Result {
    string url = 1;
    string title = 2;
    repeated string snippets = 3;
  }
  repeated Result results = 1;
}

如果要在其父消息类型之外重用此消息类型，使用

SearchResponse.Result

5 map映射

如果要在数据定义中创建关联映射，Protocol Buffers提供了一种方便的语法：

map< key_type, value_type> map_field = N ;

其中key_type可以是任何整数或字符串类型。请注意，枚举不是有效的key_type。value_type可以是除map映射类型外的任何类型。

例如，如果要创建项目映射，其中每条Project消息都与字符串键相关联，则可以像下面这样定义它：

map<string, Project> projects = 3 ;

• map的字段可以是repeated。
• 序列化后的顺序和map迭代器的顺序是不确定的，所以你不要期望以固定顺序处理map
• 当为.proto文件产生生成文本格式的时候，map会按照key 的顺序排序，数值化的key会按照数值排序。
• 从序列化中解析或者融合时，如果有重复的key则后一个key不会被使用，当从文本格式中解析map时，如果存在重复的key，则解析可能会失败。
• 如果为映射字段提供键但没有值，则字段序列化时的行为取决于语言。在Python中，使用类型的默认值。

6 oneof

如果你的消息中有很多可选字段， 并且同时至多一个字段会被设置， 你可以加强这个行为，使用oneof特性节省内存。

为了在.proto定义oneof字段， 你需要在名字前面加上oneof关键字, 比如下面例子的test_oneof:

message SampleMessage {
  oneof test_oneof {
    string name = 4;
    SubMessage sub_message = 9;
  }
}

然后你可以增加oneof字段到 oneof 定义中. 你可以增加任意类型的字段, 但是不能使用repeated 关键字。

7 定义服务

Protocol Buffers使用service定义RPC服务。

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse) {}
}

注意：一个service中可定义多个方法。

示例：

接口原型：

接口名称： user_recommend

调用参数：

UserRequest:
    user_id       # 用户id
    channel_id    # 频道id
    article_num   # 推荐的文章数量
    time_stamp    # 推荐的时间戳

返回数据：

ArticleResponse:
    exposure         # 曝光埋点数据
    time_stamp       # 推荐的时间戳
    recommends:      # 推荐结果
        article_id   # 文章id
        track:         # 关于文章的埋点数据
            click    # 用户点击行为的埋点参数
            collect  # 用户收藏的埋点参数
            share    # 用户分享的埋点参数
            read     # 用户进入文章详情的埋点参数

新建一个reco.proto文件

sysnax = "proto3"

message UserRequest{
    string user_id = 1;
    int32 channel_id = 2;
    int32 article_num = 3;
    int64 time_stamp = 4;
    
}

message Track{
    string click = 1;
    string clooect = 2;
    string share = 3;
    string read = 4;
    
    
}



message Article{
    int32 article_id = 1;
    Track track = 2;
}

message ArticleResponse{
    string exposure = 1;
    int64 time_stamp = 2;
    repeated Artile recommends=3;
    
}

service UserRecommend{
    rpc user_recommend(UserRequest) returns(ArticleResponse){}
    
}

代码生成

编译生成代码

python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. reco.proto

• -I表示搜索proto文件中被导入文件的目录
• --python_out表示保存生成Python文件的目录，生成的文件中包含接口定义中的数据类型
• --grpc_python_out表示保存生成Python文件的目录，生成的文件中包含接口定义中的服务类型

在/common/rpc目录下执行上述命令，会自动生成如下两个rpc调用辅助代码模块：

• reco_pb2.py 保存根据接口定义文件中的数据类型生成的python类
• reco_pb2_grpc.py 保存根据接口定义文件中的服务方法类型生成的python调用RPC方法