Golang使用HTTP RESTful与gRPC的选择分析

HTTP RESTful适合对外暴露API、需浏览器/移动端/第三方调用、强调可读性与调试便利的场景；gRPC更适合内部微服务间高性能、强类型、多语言通信。

HTTP RESTful 适合什么场景

当你的服务需要被浏览器、移动端、第三方系统广泛调用，或要求可读性高、调试方便、能直接用 curl 或 Postman 测试时，HTTP RESTful 是更自然的选择。它天然兼容防火墙、CDN、反向代理（如 Nginx），且状态码、Header、JSON 格式都是开发者共识。

常见踩坑点：Content-Type 忘设为 application/json 导致前端收不到数据；未处理 OPTIONS 预检请求导致跨域失败；用 http.Error 返回非标准错误体，让客户端难以解析。

• Go 标准库 net/http 足够轻量，无需额外框架也能快速搭出可用接口
• 路径设计建议遵循 REST 约定：资源用复数名词（/users），操作用 HTTP 方法（GET /users/123 获取，PUT /users/123 更新）
• 若需 OpenAPI 文档，推荐搭配 swag 工具自动生成，避免手写 YAML 同步不一致

gRPC 更适合哪些情况

当你在内部微服务之间通信，追求高性能、强类型、多语言互通，且能接受二进制协议和额外工具链时，gRPC 是更优解。它基于 HTTP/2，支持流式传输（server-streaming、client-streaming、bidi-streaming），序列化用 Protocol Buffers，天生防字段错位。

典型问题：grpc-go 默认不启用 TLS，明文传输内网虽常见但有风险；客户端未设置超时（context.WithTimeout），导致请求卡死；Proto 文件中字段未加 json_name 注解，导致 JSON 映射不匹配（如 user_id → userId）。

• 必须用 protoc + protoc-gen-go 生成 Go 代码，版本要与 google.golang.org/grpc 兼容（例如 v1.60+ 对应 protoc-gen-go v1.32+）
• HTTP/2 的连接复用特性意味着单个 *grpc.ClientConn 应复用，而非每次请求新建
• 若需对外暴露 gRPC 接口，得配 grpc-gateway 做 HTTP/JSON 转发，否则浏览器无法直连

性能与开发体验的实际差距

纯吞吐量上，gRPC 在千级 QPS 以上通常比 JSON over HTTP 快 2–5 倍，主要来自 Protocol Buffers 序列化开销低、HTTP/2 头部压缩、连接复用。但这个差距在多数业务系统里并不构成瓶颈——数据库 IO、缓存延迟、业务逻辑复杂度才是真正的瓶颈点。

真正影响落地的是开发与协作成本：curl http://localhost:8080/api/v1/users 和 grpcurl -plaintext localhost:9090 list 的调试门槛完全不同；前端团队几乎无法直接消费 gRPC，而 REST 可以零成本对接；CI/CD 中 Proto 文件变更需同步生成、校验、升级，比改一个 JSON Schema 重得多。

• 压测时注意：gRPC 的 Unary 模式接近 REST 性能，但流式模式在长连接场景下优势明显（如实时日志推送）
• Go 中 http.Server 默认无连接池，而 grpc.ClientConn 内置连接管理，误用 http.Client 不设 Transport.MaxIdleConns 反而可能拖慢 REST
• 如果团队已有成熟 REST 监控体系（如 Prometheus + Gin middleware），迁移到 gRPC 需重写指标采集逻辑

混合使用是常见且合理的方案

很多生产系统采用「对外 REST，对内 gRPC」的分层设计：外部 API 网关统一接收 HTTP 请求，做鉴权、限流、日志后，转成 gRPC 调用下游服务。这种架构既保留开放性，又享受内部通信效率。

关键细节：grpc-gateway 默认将 gRPC 错误码映射为 HTTP 状态码（如 codes.NotFound → 404），但自定义错误需实现 status.FromError 解析；若用 echo 或 gin 做网关，需手动透传 gRPC 元数据（如 authorization Header 到 metadata.MD）。

• 不要为了“技术先进”强行全量切 gRPC，尤其当 80% 接口是 CRUD 且调用方多样时
• Proto 定义要早于代码编写，字段命名用小写下划线（created_at），并加 json_name 保证兼容性
• Go 中同时启动 HTTP 和 gRPC 服务时，注意端口冲突和健康检查路径区分（如 /healthz vs /health）

协议选型不是非此即彼的决定，而是看清楚谁在调用、怎么调试、出问题时谁能快速定位——这些往往比理论吞吐量更重要。