初识grpc

gRPC

特性 gRPC RESTful API
规范 必须.proto 可选OpenAPI
协议 HTTP/2 任意版本 HTTP
有效载荷 ProtoBuf(小、二进制) JSON (大、易读)
浏览器支持 否(需要 grpc-web)
流传输 客户端、服务端、双向 客户端、服务端
代码生成 OpenAPI + 第三工具

gRPC 远程过程调用 (Remote Procedure Call)调用包含传输协议和编码、协议。允许一台计算机上的程序调用另一台计算上的子程序,而开发人员无须额外为这个交互编程。

gRPC 基于HTTP/2 拥有双向流、流控、头部压缩、但TCP链接上的多复用请求等特性

Protobuf 相比JSON、XML区别

  • 文件跟小啊(1/10 - 1/3)
  • 解析速度 20-100倍
  • 减少了二义性
  • 生成了更易使用的额数据访问类
  • 序列化和反序列化跟快
  • 传输过程中不需要过多关注其内容

gRPC通过 HTTP/2 对流传输提供了大量支持

  • Unary RPC:一元RPC
  • Server-side streaming RPC:服务端流式RPC
  • Client-side streaming RPC:客户端流式 RPC
  • Bidirectional streaming RPC: 双向流式 RPC

缺点

  • 不易读
  • 不支持浏览器
  • 支持插件少
protoc --go_out=plugins=grpc:. ./proto/*.proto 

需要注意的一点是,我们在 tag.proto 文件中 import 了 common.proto,因此在执行 protoc 命令生成时,如果你只执行命令 protoc --go_out=plugins=grpc:. ./proto/tag.proto 是会存在问题的。

因此建议若所需生成的 proto 文件和所依赖的 proto 文件都在同一目录下,可以直接执行 ./proto/*.proto 命令来解决,又或是指定所有含关联的 proto 引用 ./proto/common.proto ./proto/tag.proto ,这样子就可以成功生成.pb.go 文件,并且避免了很多的编译麻烦。

但若实在是存在多层级目录的情况,可以利用 protoc 命令的 -I 和 M 指令来进行特定处理。

code status notes
0 ok
1 cancelled 操作被调用方取消
2 unknown 未知错误
3 invalid_argument 无效的参数
4 deadline_exceeded 在操作完成之前超过了约定的最后期限
5 not_found 找不到
6 already_exists 已经存在
7 permission_denied 权限不足
8 resource_exhausted 资源耗尽
9 failed_precondition 该操作被拒绝,因为未处于执行该操作需的状态
10 aborted 该操作被终止
11 out_of_range 超出范围,尝试执行的操作超出了约定的有效范围
12 unimplemented 未实现
13 internal 内部错误
14 unavailable 该服务当前不可用
15 data_loss 不可恢复的数据丢失或损坏

你可能感兴趣的:(go,java,开发语言)