protobuf vs gRPC

Question

我尝试了解protobuf和gRPC以及如何使用它们.你能帮我理解一下:

• 考虑到OSI模型是什么,例如Protobuf在第4层？
• 通过消息传递思考如何"流动"gRPC做什么是protobuf错过的？
• 如果发件人使用protobuf,服务器可以使用gRPC还是gRPC添加只有gRPC客户端可以提供的内容？
• 如果gRPC可以进行同步和异步通信,Protobuf只是用于编组,因此与状态无关 - 真或假？
• 我可以在前端应用程序中使用gRPC而不是REST或GraphQL吗？

我已经知道 - 或者假设我这样做 - 那:

的Protobuf

• 用于数据交换的二进制协议
• 由谷歌设计
• 使用生成的"结构"类似客户端和服务器上的描述来取消 - / - 马歇尔消息

GRPC

• 使用protobuf(v3)
• 再次来自谷歌
• RPC调用的框架
• 也使用HTTP/2
• 可以进行同步和异步通信

对于已经使用该技术的人,我再次认为这是一个简单的问题.我仍然会感谢你对我有耐心并帮助我.我也非常感谢网络深入研究这些技术.

Answer 1

协议缓冲区是(是？)接口定义语言和序列化库:

• 您可以在其IDL中定义数据结构,即描述要使用的数据对象
• 它提供了将数据对象转换为二进制文件的例程,例如用于从磁盘写入/读取数据

gRPC使用相同的IDL,但添加了语法"rpc",它允许您使用Protobuf数据结构作为数据类型定义远程过程调用方法签名:

• 您可以定义数据结构
• 您添加了rpc方法定义
• 它提供代码以通过网络提供和调用方法签名
• 如果需要,您仍然可以使用Protobuf手动序列化数据对象

在回答问题时:

1. gRPC在第5,6和7层工作.Protobuf在第6层工作.
2. 当你说"消息传输"时,Protobuf并不关心传输本身.它只适用于任何数据传输的任何一端,将字节转换为对象
3. 根据定义使用gRPC意味着您使用的是Protobuf.您可以编写自己的客户端使用Protobuf但不能使用gRPC与gRPC进行互操作 - 但使用gRPC会更容易
4. 真正
5. 是的你可以

Answer 2

实际上,gRPC和Protobuf是两个完全不同的东西.让我简化:

• gRPC管理客户端和服务器可以交互的方式(就像具有REST API的Web客户端/服务器)
• protobuf只是一个序列化/反序列化工具(就像JSON一样)

gRPC有两个方面:服务器端和客户端,可以拨打服务器.服务器公开RPC(即可以远程调用的函数).你有很多选择:你可以保护通信(使用TLS),添加认证层(使用拦截器),...

你可以在任何程序中使用protobuf,它不需要是客户端/服务器.如果你需要交换数据,并希望它们是强类型的,protobuf是一个不错的选择(快速和可靠).

话虽这么说,您可以将两者结合起来构建一个不错的客户端/服务器系统:gRPC将是您的客户端/服务器代码,并为您的数据协议提供原型.

PS:我写这篇论文是为了说明如何使用Go逐步构建带有gRPC和protobuf的客户端/服务器.

Answer 3

grpc是由谷歌构建的框架，它用于谷歌本身的生产项目，#HyperledgerFabric 是用 grpc 构建的，有许多开源应用程序是用 grpc 构建的

protobuff是一种类似于json的数据表示，这也是由谷歌提供的，实际上他们在生产项目中生成了数千个 proto 文件

gpc

• gRPC 是 google 开发的开源框架
• 它允许我们为 RPC 创建请求和响应并由框架处理其余部分
• REST 是面向 CRUD 的，但 grpc 是面向 API 的（无约束）
• 建立在 HTTP/2 之上
• 提供 >>>>> 身份验证、负载平衡、监控、日志记录
• [HTTP/2]
  • HTTP1.1 早在 1997 年就发布了
  • HTTP1 在每次请求时打开一个到服务器的新 TCP 连接
  • 它不压缩标头
  • 没有服务器推送，它只适用于 Req、Res
  • 2015 年发布的 HTTP2 (SPDY)
  • 支持复用
  • 客户端和服务器可以通过同一个 TCP 连接并行推送消息
  • 大大减少延迟
  • HTTP2 支持头压缩
  • HTTP2 是二进制的
    • proto buff 是二进制的，所以它非常适合 HTTP2
• [类型]
  • 一元
  • 客户端流
  • 服务器流媒体
  • 双向流媒体
  • grpc 服务器默认是异步的
  • grpc 客户端可以同步或异步

原始缓冲

• 协议缓冲区与语言无关
• 解析协议缓冲区（二进制格式）对 CPU 的占用较少
• [命名]
  • 消息名称使用驼峰式大小写
  • underscore_separated 字段
  • 对枚举使用驼峰式大小写，对值名称使用 CAPITAL_WITH_UNDERSCORE
• [注释]
  • 支持 //
  • 支持 /* */
• [好处]
  • 数据是完全类型化的
  • 数据完全压缩（更少的带宽使用）
  • 生成代码和读取代码需要Schema(message)
  • 文档可以嵌入到架构中
  • 可以使用任何语言读取数据
  • Schema 可以随时以安全的方式发展
  • 比 XML 快
  • 代码会自动为您生成
  • Google 发明了 proto buff，他们使用了 48000 条 protobuf 消息和 12000.proto 文件
  • 许多 RPC 框架，包括 grpc 使用协议缓冲区来交换数据