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 | 不可恢复的数据丢失或损坏 |
