如何用 Traefik 的 grpcWeb 中间件把 gRPC-Web 请求转换为 HTTP/2 gRPC 转发到后端【免费下载链接】traefikThe Cloud Native Application Proxy项目地址: https://gitcode.com/GitHub_Trending/tr/traefik浏览器等前端环境无法直接向 gRPC 后端发起 HTTP/2 gRPC 请求只能发送 gRPC-Web 格式的请求。Traefik 提供的grpcWeb中间件在请求转发到后端之前先把 gRPC-Web 请求转换为 HTTP/2 gRPC 请求。本文的目标是在一个 gRPC 服务前挂上grpcWeb中间件让 gRPC-Web 客户端的请求经 Traefik 转换后正常到达 gRPC 后端。有一个硬性前提Traefik 文档在 grpcWeb 中间件说明 中明确提示Traefik 必须能用 gRPC 与后端通信即后端走h2c明文 HTTP/2或 HTTP/2 over TLS。如果你的后端只支持普通 HTTP/1.1这个中间件无法工作。前提后端服务支持 h2c 或 HTTP/2 over TLS按照 Exposing Services 指南Traefik 暴露 gRPC 服务分两种写法二者决定了服务里loadBalancer.servers.url的协议头不加密的 gRPC 通信服务 URL 使用h2c://协议头加密的 gRPC 通信服务 URL 使用标准 HTTPS 地址Traefik 通过 HTTP/2 over TLS 与后端通信必要时用 ServersTransport 配置后端证书。配置 grpcWeb 中间件grpcWeb中间件只有一个配置项allowOrigins允许的 Origin 列表可用通配*匹配所有请求默认值为[]。官方文档 给出的结构化 YAML 写法http: middlewares: test-grpcweb: grpcWeb: allowOrigins: - *其他等价写法TOML、Docker/Swarm labels、Kubernetes CRD文档中均有示例TOML 形式为[http.middlewares] [http.middlewares.test-grpcweb.grpcWeb] allowOrigins [*]labels 形式适用于 Docker、Swarm 等基于标签的 providerlabels: - traefik.http.middlewares.test-grpcweb.grpcweb.allowOrigins*Kubernetes 中则通过 CRD 定义Middleware资源spec下同样写grpcWeb.allowOrigins。allowOrigins的取值语义与浏览器 CORS 的Access-Control-Allow-Origin一致官方文档链接到了 MDN 与相关规范说明。从实现代码 pkg/middlewares/grpcweb/grpcweb.go 可以看到Origin 校验是按字符串精确匹配配置*时放行所有 Origin列表为空则没有任何 Origin 能通过。把中间件挂到路由并指向 gRPC 后端中间件定义好之后需要把它挂在路由上并让路由指向一个 gRPC 后端服务。以 file provider 的动态配置为例组合 Exposing gRPC Services 的示例 和中间件写法一个完整配置h2c明文后端是http: middlewares: test-grpcweb: grpcWeb: allowOrigins: - * routers: grpc-router: service: grpc-service rule: Host(grpc.example.com) middlewares: - test-grpcweb services: grpc-service: loadBalancer: servers: - url: h2c://backend:8080把grpc.example.com换成你的域名backend:8080换成 gRPC 服务实际地址。如果后端走 HTTPS则按指南把 router 加上tls: {}、服务 URL 改成https://backend:8080。如果你使用 Docker、Kubernetes 这类基于标签/CRD 的 provider对应写法labels: # 中间件本体 - traefik.http.middlewares.test-grpcweb.grpcweb.allowOrigins* # 后端 scheme 指定为 h2c指南中给出的标签名 - traefik.http.services.service-name.loadbalancer.server.schemeh2c其中service-name替换为你自己定义的 Traefik 服务名这个标签用于把负载均衡的后端 scheme 指定为h2c。如何验证配置生效仓库自带的 gRPC 集成测试展示了这条链路的完整验证方式启动一个 gRPC 服务让 Traefik 通过动态配置把路由指向它fixture 见 integration/fixtures/grpc/config.toml然后从 gRPC 客户端连接Traefik 的入口而不是直连后端调用Greeter服务的SayHello方法能收到后端返回的Hello name即说明请求经 Traefik 正常转发。测试代码在 integration/grpc_test.go其中覆盖了两种入口加密入口客户端带 TLS 凭据连接127.0.0.1:4443对应 fixture 中entryPoints.websecure服务 URL 为https://h2c 入口客户端用 insecure 凭据连接 h2c 服务端口如127.0.0.1:8081。也就是说验证手段是用 gRPC或 gRPC-Web客户端访问 Traefik 暴露的入口地址调用后端方法得到后端真实响应即成功。对 gRPC-Web 前端而言还需关注allowOrigins如果前端 Origin 不在列表中CORS 校验不通过请求会被拦截开发环境图省事可配*生产环境应收敛到具体 Origin配置项含义见 文档。限制与边界grpcWeb中间件只有allowOrigins一个可配置项不支持额外的转换参数转换只发生在 Traefik 到后端这一跳后端必须真正支持 HTTP/2 gRPCh2c 或 TLS完整的中间件配置字段与默认值以 动态配置文件示例 和 CRD 定义 中的grpcWeb段为准。如果转换配置完成后请求仍不通先核对两点router 是否挂上了grpcWeb中间件、服务 URL 是否用了h2c://或https://指向 gRPC 后端。【免费下载链接】traefikThe Cloud Native Application Proxy项目地址: https://gitcode.com/GitHub_Trending/tr/traefik创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
