企业官网建设流程全解析

Envoy Front Proxy 部署模式详解：在服务网格之上叠加 L7 边缘反向代理

【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy

本文基于 Envoy 官方文档中关于部署形态（Deployment Types）的说明，聚焦其中“服务间通信 + 前置代理”（front proxy）这一部署模式：Envoy 服务间集群后面再挂一层用作 HTTP L7 边缘反向代理的 Envoy 集群。读完本文，你将理解该模式下边缘 Envoy 的职责与能力边界（TLS 终结、多 HTTP 版本、L7 路由、与发现服务协同），并能基于仓库中真实存在的示例配置 front-proxy_envoy.yaml 与 front-proxy_service-envoy.yaml 搭建并读懂一套可运行的边缘代理 + 服务网格组合。

什么是 front proxy 部署形态

Envoy 官方在 deployment_types 文档 中将部署形态按复杂度递进分为三类：service to service、front proxy、double proxy。front proxy 正是介于二者之间的组合形态：

• 底层是标准的服务间（service to service）Envoy 部署，每个服务主机上都有一个与业务应用同机的 Envoy，负责服务发现、负载均衡、限流等；
• 上层再部署一个独立的 Envoy 集群，作为面向外部流量的HTTP L7 边缘反向代理，所有入站流量先经过它，再经标准入口端口（ingress port）转发到服务间 Envoy 集群。

官方文档对这一形态的核心描述是：边缘反向代理集群“behind an Envoy cluster used as an HTTP L7 edge reverse proxy”，而前置 Envoy 主机除了不与业务服务同机部署外，“work identically to any other Envoy host”——即以与其他 Envoy 主机完全相同的方式运维，并输出相同的统计指标。这一点很重要：front proxy 并不是一个特殊的代理种类，而是把标准 Envoy 主机放在入口处，因此网格内已有的配置、监控、故障排查手段可以直接复用。

边缘反向代理提供的四项能力

按照 front_proxy.rst 的列举，front proxy 形态下边缘 Envoy 集群提供以下能力：

1. TLS 终结（Terminates TLS）：客户端到边缘的 HTTPS 连接在 Envoy 处终止，其后 Envoy 到 Envoy、Envoy 到服务的流量按网格内部策略传输。
2. 同时支持 HTTP/1.1、HTTP/2 与 HTTP/3：边缘监听器可面向客户端提供多种 HTTP 版本。仓库中的示例配置使用codec_type: AUTO，由连接管理器自动识别客户端协商出的协议版本（见下文配置剖析）。
3. 完整的 HTTP L7 路由支持：可以按 Host、路径前缀、Header 等做路由，这是它区别于简单四层负载均衡的关键。
4. 通过标准 ingress 端口接入服务网格：边缘 Envoy 与“服务间 Envoy 集群”通信时，走的就是服务间部署里定义的入口端口，并且使用发现服务（discovery service）做主机查找。也就是说，边缘 Envoy 对网格而言就是一个普通的“远端 Envoy”，它并不感知服务与本地 Envoy 的同机关系，只通过服务发现拿到目标 Envoy 的地址。

补充说明第四点的背景：在 service to service 文档 中，ingress 监听器是“远端 Envoy 与本地 Envoy 通信所用”的端口（示例为http://servicename:9211），本地 Envoy 再把请求路由到本地服务的配置端口，并负责缓冲、熔断等处理。front proxy 中的边缘 Envoy 正是扮演这个“远端 Envoy”的角色——只不过它部署在与业务分离的边缘集群上。

官方示例配置剖析：边缘 Envoy

源码分发中自带 front proxy 示例，即 configs/front-proxy_envoy.yaml。下面逐段解读（静态配置，无 xDS 动态下发）：

static_resources: listeners: - address: socket_address: address: 0.0.0.0 port_value: 8080 # 面向客户端的边缘入口 filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager codec_type: AUTO # 自动识别 HTTP/1.1 与 HTTP/2 stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: backend domains: - "*" # 匹配所有 Host routes: - match: prefix: "/service/1" # L7 前缀路由 route: cluster: service1 - match: prefix: "/service/2" route: cluster: service2 http_filters: - name: envoy.filters.http.router typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router clusters: - name: service1 type: STRICT_DNS # DNS 服务发现 lb_policy: ROUND_ROBIN load_assignment: cluster_name: service1 endpoints: - lb_endpoints: - endpoint: address: socket_address: address: service1 # 目标服务的“网格入口”地址 port_value: 8000 # 即服务侧 Envoy 的 ingress 端口 - name: service2 type: STRICT_DNS lb_policy: ROUND_ROBIN load_assignment: cluster_name: service2 endpoints: - lb_endpoints: - endpoint: address: socket_address: address: service2 port_value: 8000 admin: address: socket_address: address: 0.0.0.0 port_value: 8001 # 管理端口

几个值得注意的实现要点：

• codec_type: AUTO：让同一监听器同时服务 HTTP/1.1 与 HTTP/2 客户端，对应文档所述“Supports HTTP/1.1, HTTP/2, and HTTP/3”中的协议协商能力（HTTP/3 需要 QUIC 下游监听器，此处示例未展开）。
• 路由即 L7 能力：示例用两条prefix路由把/service/1、/service/2分别指向service1、service2两个 cluster。virtual_hosts[].domains: ["*"]表示不区分 Host，实际部署中可按域名收敛。
• cluster 使用STRICT_DNS+ROUND_ROBIN：从源码结构看，边缘 Envoy 的 upstream 地址写的是service1:8000这类 DNS 可解析地址，指向服务主机上 Envoy 的入口端口，而非业务应用端口——这正是“通过标准 ingress 端口接入网格”的配置体现。生产环境可换成基于发现服务（如 xDS/ADS）的动态 cluster，边缘与网格内 Envoy 的寻址方式保持一致。
• admin端口 8001：边缘实例与网格内实例一样暴露管理接口，运维方式与指标口径统一。

服务侧配置：front-proxy_service-envoy.yaml

configs/front-proxy_service-envoy.yaml 描述了单个服务主机上 Envoy 的配置，结构更简单：

static_resources: listeners: - address: socket_address: address: 0.0.0.0 port_value: 8000 # 供远端 Envoy（含边缘 Envoy）访问的 ingress 端口 filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager codec_type: AUTO stat_prefix: service_envoy_1 route_config: name: local_route virtual_hosts: - name: backend domains: - "*" routes: - match: prefix: "/service/1" route: cluster: service1 http_filters: - name: envoy.filters.http.router typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router clusters: - name: service1 type: STRICT_DNS lb_policy: ROUND_ROBIN load_assignment: cluster_name: service1 endpoints: - lb_endpoints: - endpoint: address: socket_address: address: service1 # 业务应用本身 port_value: 8080 # 应用监听端口 admin: address: socket_address: address: 0.0.0.0 port_value: 8001

对照两份配置，完整的流量路径是：

客户端 (TLS/HTTP1.1/2) │ ▼ 边缘 Envoy 监听 8080 ── 前缀路由 /service/1 ──▶ cluster service1 (service1:8000) │ ▼ 服务主机 Envoy 监听 8000 (ingress) ── 前缀路由 /service/1 ──▶ cluster service1 (service1:8080) │ ▼ 业务应用 8080

边缘 Envoy 把请求交给服务主机上的 Envoy，后者再完成到本地应用的最后一跳；服务间 Envoy 与边缘 Envoy 的通信、统计、运维方式完全一致，这正是官方文档强调的“front Envoy hosts work identically to any other Envoy host”的含义。

与服务间/双重代理形态的边界

选择 front proxy 形态时，可与另外两种形态对照（见 deployment_types.rst 与 double_proxy.rst）：

• service to service only：纯网格，流量全部内部东西向，没有外部边缘。适合纯后端服务通信。
• front proxy（本文）：网格 + 独立边缘 L7 反向代理集群。边缘只负责入口路由与 TLS 终结，不感知服务同机部署细节。
• double proxy：网格 + 与服务同机的“前置 Envoy”叠加边缘能力，形态更重，适合入口层也要与业务同机运维的场景。

适用前提与限制需要说明：本文示例均为static_resources静态配置（STRICT_DNS+ 固定端点），用于演示拓扑与快速验证；文档所述“通过发现服务做主机查找”在生产形态中依赖外部 discovery service（如 xDS 控制面）提供 cluster 与主机信息，示例中的静态 DNS 条目只是其简化替代。TLS 终结所需的证书、HTTP/3（QUIC）下游监听、以及 ingress 端口上 Envoy 间默认使用 HTTP/2 的约定（见 service_to_service.rst）都需要按生产环境自行补全，示例配置中未包含这些部分。

小结

• front proxy 的本质是“标准 Envoy 主机被部署在入口处”：它以普通网格成员身份通过 ingress 端口 + 服务发现访问后端 Envoy 集群，运维与指标体系零差异。
• 边缘集群承担 TLS 终结、HTTP/1.1/2/3 协议协商与完整 L7 路由，把外部流量规范化后注入网格。
• 仓库中的 configs/front-proxy_envoy.yaml 与 configs/front-proxy_service-envoy.yaml 分别给出边缘与服务侧的完整可参考配置，可据此对照理解 8080（边缘入口）→ 8000（ingress）→ 8080（应用）的端到端转发链。

【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy