gRPC入门与实操
gRPC入门与实操
为什么选择gRPC
历史
长久以来,我们在前后端交互时使用WebApi + JSON
方式,后端服务之间调用同样如此(或者更久远之前的WCF + XML
方式)。WebApi + JSON 是优选的,很重要的一点是它们两者都是平台无关的三方标准,且足够语义化,便于程序员使用,在异构(前后端、多语言后端)交互场景下是不二选择。然而,在后端服务体系改进特别是后来微服务兴起后,我们发现,前后端交互理所当然认可的 WebApi + JSON 在后端体系内显得有点不太合适:
- JSON 字符编码方式使得传输数据量较大,而后端一般并不需要直接操作 JSON,都会将 JSON 转为平台专有类型后再处理;既然需要转换,为什么不选择一个数据量更小,转换更方便的格式呢?
- 调用双方要事先约定数据结构和调用接口,稍有变动就要手动更新相关代码(Model 类和方法签名);是否可以将约定固化为文档,服务提供者维护该文档,调用方根据该文档可以方便地生成自己需要的代码,在文档变化时代码也可以自动更新?
- [之前] WebApi 基于的 Http[1.1] 协议已经诞生 20 多年,其定义的交互模式在今日已经捉襟见肘;业界需要一个更有效率的协议。
高效传输-Http2.0
我们先来说第 3 个问题,其实很多大厂内部早已开始着手处理,并诞生了一些应用广泛的框架,如阿里开源的Dubbo
,直接抛弃了 Http 改为基于 TCP实现,效率得到明显提升,不过 Dubbo 依赖 Java 环境,无法跨平台使用,不在我们考虑范围。
另一个大厂 Google,内部也在长期使用自研的Stubby
框架,与 Dubbo 不同的是,Stubby是跨平台的,但是 Google 认为 Stubby不基于任何标准,而且与其内部基础设施紧密耦合,并不适合公开发布。
同时 Google 也在对 Http1.1 协议进行增强,该项目是 2012 年提出的 SPDY 方案,其优化了 Http 协议层,新增的功能包括数据流的多路复用、请求优先级以及HTTP报头压缩。Google 表示,引入 SPDY 协议后,在实验室测试中页面加载速度比原先快 64%。巨大的提升让大家开始从正面看待和解决老版本 Http 协议的问题,这也直接加速了 Http2.0 的诞生。实际上,Http2.0 是以 SPDY 为原型进行讨论和标准化的,当然也做了更多的改进和调整。
随着 Http2.0 的出现和普及,许多与 Stubby 相同的功能已经出现在公共标准中,包括 Stubby 未提供的其他功能。很明显,是时候重做 Stubby 以利用这种标准化,并将其适用范围扩展到分布式计算的最后一英里,支持移动设备(如安卓)、物联网(IOT)、和浏览器连接到后端服务。
2015 年 3 月,Google决定在公开场合构建下一版 Stubby,以便与业界分享经验,并进行相关合作,也就是本文的主角gRPC
。
高效编码-protobuf
回头来看第 1 个问题,解决起来相对比较简单,无非是将傻瓜式字符编码转为更有效的二进制编码(比如数字 10000 JSON 编码后是 5 个字节,按整型编码就是 4 个字节),同时加上些事先约定的编码算法使得最终结果更紧凑。常见的平台无关的编码格式有MessagePack
和protobuf
等,我们以 protobuf 为例。
protobuf 采用 varint
和 处理负数的 ZigZag
两种编码方式使得数值字段占用空间大大减少;同时它约定了字段类型和标识,采用 TLV
方式,将字段名映射为小范围结果集中的一项(比如对于不超过 256 个字段的数据体来说,不管字段名本身的长度多少,每个字段名都只要 1 个字节就能标识),同时移除了分隔符,并且可以过滤空字段(若字段没有被赋值,那么该字段不会出现在序列化结果中)。
高效编程-代码生成工具
第 2 个问题呢,其实需要的就是[每个平台]一套代码生成工具。生成的代码需要覆盖类的定义、对象的序列化/反序列化、服务接口的暴露和远程调用等等必要的模板代码,如此,开发人员只需要负责接口文档的维护和业务代码的实现(很自然的面向接口编程:))。此时,采用 protobuf 的gRPC
自然而然的映入眼帘,因为对于目前所有主要的编程语言和平台,都有 gRPC 工具和库,包括 .NET、Java、Python、Go、C++、Node.js、Swift、Dart、Ruby 以及 PHP。可以说,这些工具和库的提供,使得 gRPC 可以跨多种语言和平台一致地工作,成为一个全面的 RPC 解决方案。
proto文件
|
- syntax 标识Protobuf版本为v3
- option csharp_namespace 标识生成C#类的命名空间
- package 标识proto文件的命名空间
- service 定义服务
- rpc FuncName (Input) returns (Output) 定义一个远程过程
- message 声明数据结构
Protobuf 消息(message)
消息是 Protobuf 中的主要数据传输对象。 它们在概念上类似于 .NET 类。
|
前面的消息定义将三个字段指定为名称/值对。 与 .NET 类型上的属性类似,每个字段都有名称和类型。 字段类型可以是 Protobuf 标量值类型(如 int32
),也可以是其他消息。
标量值类型
Protobuf 支持一系列本机标量值类型。 下表列出了全部本机标量值类型及其等效 C# 类型:
Protobuf 类型 | C# 类型 |
---|---|
double |
double |
float |
float |
int32 |
int |
int64 |
long |
uint32 |
uint |
uint64 |
ulong |
sint32 |
int |
sint64 |
long |
fixed32 |
uint |
fixed64 |
ulong |
sfixed32 |
int |
sfixed64 |
long |
bool |
bool |
string |
string |
bytes |
ByteString |
日期和时间
本机标量类型不提供与 .NET 的 DateTimeOffset、DateTime 和 TimeSpan 等效的日期和时间值。 可使用 Protobuf 的一些“已知类型”扩展来指定这些类型。 这些扩展为受支持平台中的复杂字段类型提供代码生成和运行时支持。
下表显示日期和时间类型:
.NET 类型 | Protobuf 已知类型 |
---|---|
DateTimeOffset |
google.protobuf.Timestamp |
DateTime |
google.protobuf.Timestamp |
TimeSpan |
google.protobuf.Duration |
|
C# 类中生成的属性不是 .NET 日期和时间类型。 属性使用 Google.Protobuf.WellKnownTypes
命名空间中的 Timestamp
和 Duration
类。 这些类提供在 DateTimeOffset
、DateTime
和 TimeSpan
之间进行转换的方法。
|
可为 null 的类型
C# 的 Protobuf 代码生成使用本机类型,如 int
表示 int32
。 因此这些值始终包括在内,不能为 null
。
对于需要显式 null
的值(例如在 C# 代码中使用 int?
),Protobuf 的“已知类型”包括编译为可以为 null 的 C# 类型的包装器。 若要使用它们,请将 wrappers.proto
导入到 .proto
文件中,如以下代码所示:
|
wrappers.proto
类型不会在生成的属性中公开。 Protobuf 会自动将它们映射到 C# 消息中相应的可为 null 的 .NET 类型。 例如,google.protobuf.Int32Value
字段生成 int?
属性。 引用类型属性(如 string
和 ByteString
)保持不变,但可以向它们分配 null
,这不会引发错误。
下表完整列出了包装器类型以及它们的等效 C# 类型:
C# 类型 | 已知类型包装器 |
---|---|
bool? |
google.protobuf.BoolValue |
double? |
google.protobuf.DoubleValue |
float? |
google.protobuf.FloatValue |
int? |
google.protobuf.Int32Value |
long? |
google.protobuf.Int64Value |
uint? |
google.protobuf.UInt32Value |
ulong? |
google.protobuf.UInt64Value |
string |
google.protobuf.StringValue |
ByteString |
google.protobuf.BytesValue |
小数
Protobuf 本身不支持 .NET decimal
类型,只支持 double
和 float
。在 Protobuf 项目中,我们正在探讨这样一种可能性:将标准 decimal 类型添加到已知类型,并为支持它的语言和框架添加平台支持。尚未实现任何内容。
可以创建消息定义来表示 decmial
类型,以便在 .NET 客户端和服务器之间实现安全序列化。但其他平台上的开发人员必须了解所使用的格式,并能够实现自己对其的处理。
为 Protobuf 创建自定义 decimal 类型
|
nanos
字段表示从0.999_999_999
到-0.999_999_999
的值。例如,decimal
值1.5m
将表示{ units = 1, nanos = 500_000_000 }
。这就是此示例中的 nanos
字段使用 sfixed32
类型的原因:对于较大的值,其编码效率比 int32
更高。 如果 units
字段为负,则 nanos
字段也应为负。
集合
列表
Protobuf 中,在字段上使用repeated
前缀关键字指定列表。以下示例演示如何创建列表:
|
在生产的代码中,repeated
字段由Google.Protobuf.Collections.RepeatedField<T>
泛型类型表示。
|
RepeatedField<T>
可实现 IListRepeatedField<T>
属性没有公共 setter。项应添加到现有集合中。
|
字典
.NET IDictionary<TKey, TValue> 类型在 Protobuf 中使用 map<key_type, value_type>
表示。
|
在生成的 .NET 代码中,map
字段由Google.Protobuf.Collections.MapField<TKey, TValue>
泛型类型表示。
MapField<TKey, TValue>
可实现 IDictionary<TKey, TValue>。与repeated
属性一样,map
属性没有公共 setter。项应添加到现有集合中。
|
无结构的条件消息
Protobuf 是一种协定优先的消息传递格式。 构建应用时,必须在 .proto
文件中指定应用的消息,包括其字段和类型。 Protobuf 的协定优先设计非常适合强制执行消息内容,但可能会限制不需要严格协定的情况:
- 包含未知有效负载的消息。 例如,具有可以包含任何消息的字段的消息。
- 条件消息。 例如,从 gRPC 服务返回的消息可能是成功结果或错误结果。
- 动态值。 例如,具有包含非结构化值集合的字段的消息,类似于 JSON。
Protobuf 提供语言功能和类型来支持这些情况。
任意
利用Any
类型,可以将消息作为嵌入类型使用,而无需.proto
定义。若使用Any
类型,请导入any.proto
。
|
|