17370845950

Unary是单次请求-响应模式，适合常规RPC场景；Stream分Client/Server/BiDi三类，复用TCP连接实现多次消息交互；选型应基于数据交互需求而非性能或“高级”程度。

Unary 是单次请求-响应，适合常规 RPC 场景

当你调用一个 gRPC 方法，客户端发一次请求、服务端回一次响应，中间不保持连接，这就是 Unary。它和 HTTP 的 GET/POST 语义最接近，也是默认生成的 stub 类型。

常见错误是误以为 Unary 能“推”数据：比如想让服务端在响应后持续发新消息——这做不到，Unary 的 ctx 在响应返回后就结束，服务端无法再写入。

实操建议：

• 用 proto 定义时，方法签名形如 rpc GetUserInfo(UserID) returns (User)，即单入单出
• 服务端 handler 函数签名必须是 func(ctx context.Context, req *XXXRequest) (*XXXResponse, error)
• 超时、鉴权、日志等中间件天然适配，因为生命周期清晰

Stream 分为 Client/Server/BiDi 三类，核心是复用 TCP 连接传递多条消息

Stream 不是“流式传输大文件”的代名词，而是指在同一个 gRPC 调用上下文中，允许多次读写。区别在于谁主动发起消息：

立即学习“go语言免费学习笔记（深入）”；

• ClientStreaming：客户端发多条，服务端收完再统一响应（如日志批量上报）
• ServerStreaming：客户端发一次，服务端边处理边发多条响应（如实时行情推送）
• BidiStreaming：双方可随时读写，类似聊天室（如协作文档同步）

容易踩的坑是忽略流的关闭时机：Send() 后不调 CloseSend()，服务端会一直等；或客户端未循环 Recv() 就退出，导致部分响应丢失。

示例（ServerStreaming）：

func (s *server) ListEvents(req *pb.ListRequest, stream pb.EventService_ListEventsServer) error {
    for _, e := range s.events {
        if err := stream.Send(&pb.Event{Id: e.ID, Data: e.Payload}); err != nil {
            return err
        }
        time.Sleep(100 * time.Millisecond)
    }
    return nil
}

Unary 和 Stream 的底层 transport 差异影响连接复用与错误恢复

gRPC 底层基于 HTTP/2，Unary 每次调用对应一个 HTTP/2 DATA 帧往返；而 Stream 复用同一个 HTTP/2 stream ID，所有消息共享连接状态。

这意味着：

• Stream 更省连接数，但单个 stream 故障（如网络抖动）会导致整个流中断，需应用层重连或重试逻辑
• Unary 天然幂等（GET 类），而 ServerStreaming 无法保证“断点续传”，除非你在 proto 中显式带 offset 或 cursor 字段
• 拦截器（interceptor）对 Stream 的 stream 参数需要特殊处理——不能像 Unary 那样直接 wrap ctx，得包装 xxxServer 接口

选型关键看数据交互模式，不是性能或“高大上”程度

别因为 Stream 听起来更“高级”就强行用 BiDi。真实项目中 80% 的场景用 Unary 更稳：调试方便、超时控制明确、可观测性工具（如 grpcurl）支持完整。

真正该切 Stream 的信号只有两个：

• 需要服务端主动推送（非轮询），且客户端必须实时接收（如告警通知）→ 选 ServerStreaming
• 客户端要连续上传并等待服务端渐进反馈（如语音识别分片上传+实时文字返回）→ 选 BidiStreaming

其他情况，先写 Unary，压测发现瓶颈再评估是否值得改。