如何在Golang平台中部署gRPC-Web作为前端微服务直接通信网关

先说几个核心判断：浏览器不能直接调用 gRPC，这不是配置层面的问题，而是协议层本身的硬限制——HTTP/2 + Protobuf 与 HTTP/1.1 + JSON 之间的鸿沟，不是靠改几个参数就能跨越的。想让前端直连 Go 后端的 gRPC 服务，必须加一层 gRPC-Web 网关来承担协议转换。这不是可选组件，而是必经通路。

为什么是 Envoy 而不是 grpcwebproxy

可能有人会问，grpcwebproxy 不是也能用吗？但问题在于，它已经归档、不再维护了。本地跑个 demo 或许还能凑合，一上生产就容易露馅：没有 TLS 终止、没有健康检查、没有可观测性集成。Envoy 才是唯一靠谱的选择，尤其是在 Kubernetes 场景下。

实践中有几个关键点需要留意：

• envoy.filters.http.grpc_web 必须显式启用，否则浏览器发 application/grpc-web+proto 请求时，会静默返回 415 Unsupported Media Type
• Envoy 默认不转发 CORS 头，前端预检（OPTIONS）会直接失败。需要在 http_filters 里配置 envoy.filters.http.cors，或者交由后端处理
• 如果用 docker-compose 部署，Envoy 容器要能访问 Go gRPC server 的 0.0.0.0:9090，不能绑 127.0.0.1——在容器网络里，localhost 指的是自己

Go gRPC server 需要改什么

好消息是，业务代码完全不用动。但有两个隐性条件必须满足，否则网关转不动：

• 必须启用反射：reflection.Register(server)，否则前端调试工具（如 grpcurl 或 Web UI）查不到服务列表
• 监听地址必须是 0.0.0.0:9090，不能是 127.0.0.1:9090；否则 Envoy 在另一容器里根本连不上
• CORS 头建议由网关统一加（Envoy 支持），如果非要后端加，得用拦截器写 w.Header().Set("Access-Control-Allow-Origin", "*")，且注意 Access-Control-Allow-Headers 至少包含 content-type 和 x-grpc-web

前端怎么调用才不报错

生成的 JS 客户端桩（protoc-gen-grpc-web 输出）默认走 http://localhost:8080（grpcwebproxy 的默认端口），但你用的是 Envoy，所以需要手动指定网关地址：

• 初始化 client 时传入 host 参数：new MyServiceClient("http://your-envoy-host:10000")
• 流式 RPC（server-stream / bidi）需要确认 Envoy 配置启用了 stream_idle_timeout，否则连接空闲 60s 后会自动断开，前端 onEnd 会收到 status.UNKNOWN
• 不要用 fetch 手动拼请求——gRPC-Web 的协议头（如 Content-Type: application/grpc-web+proto）和帧格式（length-delimited）非常严格，手写极易出错

最容易被忽略的一个点是：Envoy 的 grpc_web filter 只识别特定的 MIME 类型，而前端生成的 client 默认发的是 application/grpc-web+proto。如果后端 proto 编译时用了 --grpc-web_out=import_style=commonjs+dts,mode=grpcweb，但 Envoy 没配对这个类型，就会卡在 415。这个点不排查，其他配置都白搭。