Golang部署gRPC-Web前端微服务通信网关

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

为什么选择 Envoy 而非 grpcwebproxy

可能有人会问，grpcwebproxy 不是也能用吗？但问题在于，它已经归档、不再维护。本地运行一个演示或许还能凑合，一旦投入生产就容易暴露问题：缺少 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。这个点不排查，其他配置都无济于事。