Spring Cloud Gateway与Envoy Sidecar在微服务请求路由中的架构设计分享
在现代微服务架构中，请求路由层承担着流量分发、安全鉴权、流量控制等多重职责。传统的单一网关方案往往面临可扩展性和可维护性挑战。本文将从真实生产环境出发，分享如何结合Spring Cloud Gateway与Envoy Sidecar实现高可用、可扩展的请求路由设计。
1. 业务场景描述
- 我们的电商平台包含几十个微服务，接口种类繁多。
- 需要统一的流量入口，用于鉴权、限流、灰度发布、权重路由等。
- 随着服务规模扩大，单台网关承载压力和部署频率成为瓶颈。
- 期望将网关功能解耦、轻量化，并支持不同协议（HTTP/ gRPC）路由。
2. 技术选型过程
2.1 Spring Cloud Gateway（SCG）
- 基于Reactor Netty，易于与Spring生态集成。
- 提供路由匹配、过滤链、限流器等功能。
- 但纯Java实现对高并发场景下的性能存在一定开销。
2.2 Envoy Sidecar
- CNCF项目，采用C++高性能实现，支持丰富协议。
- 提供外置代理能力，可与服务部署在同一Pod中。
- 配置灵活，支持动态下发路由和集群健康检查。
2.3 架构方案对比
| 方案 | 优点 | 缺点 | | ------------ | ------------------------------ | ---------------------------- | | 单一SCG网关 | 易集成、可编程性强 | 性能瓶颈、扩缩容慢 | | Envoy网关 | 高性能、协议丰富 | 配置复杂、与业务耦合度高 | | SCG+Envoy | 双层路由：轻量协议过滤+业务路由 | 运维成本上升 |
综合考虑后，我们采用SCG+Envoy Sidecar的双层网关架构，将Envoy作为轻量协议入口，SCG作为业务路由与过滤链执行。
3. 实现方案详解
3.1 架构图
+-----------------+ +--------------+ +-------------+
| Client | ---> | Envoy Sidecar| ---> | Spring Cloud|
| (HTTP/gRPC/X) | | Load Balancer| | Gateway |
+-----------------+ +--------------+ +-------------+| |v v+--------------+ +--------------+| microservice1| | microservice2|+--------------+ +--------------+
3.2 Envoy Sidecar配置
在每个Pod中部署Envoy Sidecar，示例envoy.yaml：
static_resources:listeners:- name: listener_httpaddress:socket_address: { address: 0.0.0.0, port_value: 8080 }filter_chains:- filters:- name: envoy.filters.network.http_connection_managertyped_config:"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManagerstat_prefix: ingress_httproute_config:name: local_routevirtual_hosts:- name: svcdomains: ["*"]routes:- match: { prefix: "/" }route: { cluster: spring_gateway }http_filters:- name: envoy.filters.http.routerclusters:- name: spring_gatewayconnect_timeout: 1stype: STRICT_DNSlb_policy: ROUND_ROBINload_assignment:cluster_name: spring_gatewayendpoints:- lb_endpoints:- endpoint: { address: { socket_address: { address: spring-gateway.default.svc.cluster.local, port_value: 9090 } } }
3.3 Spring Cloud Gateway配置
在Spring Boot项目application.yml中：
server:port: 9090
spring:cloud:gateway:default-filters:- StripPrefix=1routes:- id: user-serviceuri: lb://USER-SERVICEpredicates:- Path=/user/**filters:- RewritePath=/user/(?<path>.*), /${path}- id: order-serviceuri: lb://ORDER-SERVICEpredicates:- Path=/order/**filters:- RewritePath=/order/(?<path>.*), /${path}discovery:locator:enabled: truelower-case-service-id: true
3.4 项目结构示例
gateway-service/
├── src/main/java/
│ └── com.example.gateway
│ ├── GatewayApplication.java
│ └── filters/
│ └── AuthFilter.java
├── src/main/resources/
│ └── application.yml
└── Dockerfile
3.5 部署与CI/CD
- 使用Kubernetes Deployment部署时，每个Pod挂载Envoy Sidecar与Spring Cloud Gateway
- 利用Helm Chart统一管理
- CI/CD流水线可拆分镜像构建与Envoy配置下发
4. 踩过的坑与解决方案
-
Envoy与SCG端口冲突：
- 问题：两者默认端口可能冲突导致启动失败。
- 解决：统一规划端口，Envoy监听8080，SCG监听9090。
-
动态路由更新滞后：
- 问题：服务注册中心（Eureka）变更后，Envoy无法及时感知。
- 解决：借助xDS API或Sidecar自动重启机制，实现配置热更新。
-
证书配置复杂：
- 问题：安全通信需TLS，证书自动化下发难度大。
- 解决：结合SPIFFE/SDS动态管理证书，Envoy自动拉取。
-
高并发下延迟增大：
- 问题：双层路由增加网络跳数。
- 解决：开启直连模式，对高频热点路径直连服务，跳过SCG层。
5. 总结与最佳实践
- 双层网关——Envoy侧车+Spring Cloud Gateway结合了高性能与可编程性。
- 配置管理：采用xDS、Helm 与GitOps流水线实现配置动态化。
- 健康检查与熔断：Envoy与SCG各自侧重层面，保障系统高可用。
- 安全：建议使用mTLS或SPIFFE证书管理框架统一下发。
- 性能优化：对核心路径可直接绕过SCG，降低网络跳数。
通过上述方案，既保留了Spring Cloud Gateway的灵活可编程特性，又利用Envoy的高性能代理能力，实现了高可用、可扩展的微服务请求路由架构。若有更多实践问题，欢迎在评论区交流！
）)
