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的高性能代理能力，實現了高可用、可擴展的微服務請求路由架構。若有更多實踐問題，歡迎在評論區交流！
）)
