gRPC-Web场景下Envoy代理部署配置方案咨询

gRPC-Web 场景下不需要强制套用Service Mesh的Sidecar部署模式，根据你的架构规模选对应方案即可：

• 边缘反向代理部署（最匹配官方基础文档的方案，中小规模生产首选）
  把Envoy部署在公网流量入口层，和前端静态资源服务放在同一网络层级，直接承接浏览器发起的所有请求：静态页面/JS/CSS请求直接转发给前端静态资源服务，携带application/grpc-web标识的gRPC-Web请求由Envoy完成协议转换，转成标准gRPC协议后转发给后端Go服务，收到Go返回的标准gRPC响应后再转回gRPC-Web格式返回给浏览器。
  这个方案就是官方示例默认的部署逻辑，配置最简单，不需要对现有后端服务做任何改造，也不需要额外引入Mesh相关组件。
• 后端Sidecar部署（适合已落地Service Mesh的集群）
  如果你已经在集群里用Istio等基于Envoy的Service Mesh方案，可以直接复用现有Sidecar做gRPC-Web协议转换，不需要单独维护独立的Envoy代理节点。注意不要把后端Sidecar直接暴露给公网浏览器，需要在集群入口先部署一层网关，把gRPC-Web请求路由到对应服务的Sidecar上，由Sidecar完成协议转换和后续的流量治理。
  你觉得这个模式和官方文档描述不匹配是正常的：官方基础文档面向的是无Mesh的简单部署场景，不会涉及Mesh体系下的Sidecar用法。
• 内嵌代理（仅适合本地开发/极小流量场景）
  如果是本地调试或者个人小项目，不想单独部署Envoy进程，可以直接在Go后端服务里引入gRPC-Web的Go语言代理库，内嵌协议转换处理逻辑，省掉单独部署代理的成本。这个方案不推荐生产环境用，没法复用Envoy自带的限流、监控、流量管控能力。

配置注意点：不管选哪种部署方式，Envoy的HTTP过滤链顺序不要配错，要先加载envoy.filters.http.grpc_web过滤器做协议转换，再加载envoy.filters.http.cors过滤器处理浏览器跨域请求，最后再配置路由规则转发到后端服务，漏配跨域规则会被浏览器直接拦截请求。

内容的提问来源于stack exchange，提问作者user726350