Golang使用GRPC与HTTP RESTful同时提供服务的策略

不能直接在同一个端口上同时跑 grpc 和 REST，因为 gRPC 基于 http/2 且依赖专用 handler 处理 application/grpc 流量，而标准 HTTP/1.1 的 REST 服务无法识别或解包其二进制帧，会导致连接拒绝、404 或 goAWAY 错误。

为什么不能直接在同一个端口上同时跑 gRPC 和 REST

gRPC 默认使用 HTTP/2 协议，而大多数 REST 客户端（如 curl、浏览器、axios）走的是 HTTP/1.1；两者在协议层不兼容。如果你强行把 grpc.Server 和 http.ServeMux 注册到同一个 http.Server 上，会遇到连接被拒绝、404 或 HTTP/2 Error: client sent GOAWAY 等问题。

根本原因在于：gRPC 服务端依赖 grpc.Server 的特殊 handler（grpc.NewServer().ServeHTTP），它只响应以 application/grpc 为 Content-Type 且启用 HTTP/2 的请求；而标准 http.ServeMux 不识别这种流量，也无法解包 gRPC 的二进制帧。

推荐方案：单进程双端口 + 共享业务逻辑

最稳妥、可维护性最高的做法是启动两个独立的 http.Server 实例，分别监听不同端口，但复用同一套 service 层代码。这样避免协议冲突，也便于后续拆分或灰度发布。

• gRPC 服务监听 :9000（或其他非 80/443 的端口），使用 grpc.Server 启动
• REST API 监听 :8080，使用 http.ServeMux 或 gin.Engine / echo.Echo 等框架封装
• 两者都调用相同的 *service.UserService、*repository.UserRepo 等结构体，不重复实现业务逻辑
• 共享中间件（如日志、认证、指标）可通过封装统一函数注入，例如 LogMiddleware(http.Handler) http.Handler

如何用 grpc-gateway 实现“一套 proto 生成 REST 接口”

如果你希望 REST 接口语义和 gRPC 方法严格对齐（比如 POST /v1/users 对应 CreateUser RPC），grpc-gateway 是目前 Go 生态最成熟的方案。它不是代理，而是基于 proto 文件生成反向代理式的 HTTP 路由处理器。

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

关键点：

• 必须在 proto 中用 google.api.http 扩展声明 REST 映射，例如：

  rpc CreateUser(CreateUserRequest) returns (CreateUserResponse) {   option (google.api.http) = {     post: "/v1/users"     body: "*"   }; }

• 生成时需同时运行 protoc 生成 gRPC stub 和 gateway stub：protoc --go_out=. --go-grpc_out=. --grpc-gateway_out=. api.proto
• 启动时，将 gateway 的 handler 注册到普通 http.ServeMux，再由同一个 http.Server 托管 —— 注意：此时该 server 必须启用 HTTP/2（用于 gRPC over HTTP/2），但 gateway 本身走 HTTP/1.1，所以要显式配置：server.TLSConfig = &tls.Config{NextProtos: []String{"h2", "http/1.1"}}
• 不要把 gateway handler 和 gRPC server 混在同一个 http.ServeMux 下直接 Serve；正确方式是用 runtime.NewServeMux() 创建独立 mux，并通过 grpc.Dial 连接本地 gRPC server（即让 gateway 反向调用本进程的 gRPC 端口）

常见陷阱与绕不过去的细节

实际落地时，这几个点最容易导致线上行为异常：

• grpc-gateway 默认不传递 gRPC metadata 到后端，如果鉴权信息存在 header（如 Authorization: Bearer xxx），需手动注册 runtime.WithIncomingHeaderMatcher 并在 handler 中提取塞入 context
• gRPC 流式接口（stream）无法被 grpc-gateway 映射为 REST，只能降级为 polling 或改用 websocket
• 错误码映射不完全：gRPC 的 codes.NotFound 会被转成 HTTP 404，但自定义状态码（如 codes.Aborted）默认变成 503，需用 runtime.WithErrorHandler 重写
• 超时控制分离：HTTP server 的 ReadTimeout 不影响 gRPC stream 的生命周期；gRPC client 的 ctx.WithTimeout 也不影响 gateway 的 HTTP 连接空闲超时，两者必须分别配置

真正麻烦的从来不是“能不能同时提供”，而是“怎么让两套协议下的错误处理、上下文传递、可观测性保持一致”。别省略日志字段对齐、traceID 透传、metric 标签标准化这些事——它们比选型重要得多。