引言
在現代雲原生架構中，代理（Proxy）、閘道（Gateway）與服務網格（Service Mesh）是流量管理的核心元件。然而，這些術語常因功能重疊與技術抽象層次不同，導致理解困難。本文將深入解析其定義、功能差異與實際應用，協助讀者釐清概念並做出合適的技術選型。
技術定義與核心功能
代理（Proxy）的本質與功能
代理是位於用戶與服務器之間的中間層，可作為客戶端、服務端或中間節點。其核心功能包括：
- 流量路由：根據請求頭部、路徑或IP進行路由（如
company.com/v1 路由至不同後端）。
- 流量修改：讀取/寫入/修改HTTP頭部（如添加認證標頭）。
- 安全控制：認證授權、限流、IP白名單/黑名單。
- 協議層支持：層4（TCP/UDP）與層7（HTTP/HTTPS/gRPC）代理，層7代理可終止SSL並處理應用層邏輯。
- 擴展性：支持函數調用（如WASM模塊）進行動態決策。
正向代理與反向代理
- 正向代理：位於客戶端側，用於代理用戶請求（如Docker TestContainers工具），常見用途包括隱私保護與訪問控制。
- 反向代理：位於服務端側，作為系統入口點（如負載均衡器），處理SSL終止、認證授權等，並支援直接服務器回應（DSR）以減少網絡跳數。
網關（Gateway）的定位
網關是具備智能的代理，通常作為API管理入口點，整合負載均衡、認證、日誌等功能。其核心功能包括：
- API管理：支持OpenAPI/Protobuf解析，提供開發者_portal展示API端點。
- 安全控制：集成OAuth2/JWT認證、限流與IP控制。
- 協議支持：支持HTTP/HTTPS/gRPC，可作為API網關或服務網關。
- 擴展性：可與外部身份驗證服務集成，或與服務網格協同工作。
Kubernetes Gateway API 與 Ingress 的差異
- Ingress API：早期Kubernetes的API，用於配置反向代理（如Nginx）進行流量路由，但僅支持同命名空間後端，功能有限。
- Gateway API：新一代標準，支援跨命名空間後端與更靈活的流量控制（如TCP/UDP路由），本身不直接實現代理功能，而是透過配置（如Envoy）實現負載均衡與服務網格功能。
現代代理的演進：Envoy 的配置方式
Envoy 作為現代代理的典範，其創新點包括：
- 放棄傳統配置文件，改用gRPC API進行動態配置。
- 支持上游（Upstream）與下游（Downstream）通信，實現高靈活性的流量控制。
- 作為服務網格（如Istio）的核心元件，整合服務發現、策略執行與流量管理。
Envoy 的架構與配置
- 核心概念：Upstream（外部客戶端流量）與Downstream（後端服務）。
- Listeners：定義監聽端口與協議（如HTTP/HTTPS），並指定後端服務（Pod、VM等）。
- XDS API：透過gRPC接口實現動態配置，支援實時更新策略（如路由、TLS設定、熔斷機制）。
- 控制平面：作為配置源頭，可管理多個Envoy代理，實現無中斷配置更新。
服務網格（Service Mesh）的本質
服務網格基於控制平面與邊車代理（Sidecar Proxy）架構，實現服務間通信的細粒度管理。
- 控制平面：管理路由規則、安全策略（如mTLS）與故障恢復機制（重試、超時、熔斷）。
- 邊車代理：每個服務Pod內嵌Envoy代理，處理服務間流量。
- 與API閘道的區別：服務網格側重服務間通信管理，而API閘道側重外部流量入口管理。
技術關鍵點總結
- 代理（Proxy）：通用流量轉發工具，支援SSL卸載、日誌、路由等功能。
- 閘道（Gateway）：專門處理外部流量的代理，支援認證授權委託與動態配置。
- 服務網格（Service Mesh）：基於控制平面與邊車代理的架構，實現服務間通信的細粒度管理。
- Envoy 的 XDS API：現代代理的標準配置方式，支援實時策略更新與多種協議（HTTP/gRPC/TLS）。
- Gateway API 的演進：解決Ingress的限制，結合負載平衡與服務網格功能，成為Kubernetes的現代化流量管理方案。
總結
代理、閘道與服務網格的區別在於「中間層的智能程度」與「功能範疇」，而非嚴格的技術分類。代理是基礎，閘道是具備API管理能力的代理，服務網格則是基於代理的更高階抽象層。技術選型需根據需求（如安全性、可擴展性、協議支持）選擇合適的工具，並理解其背後的設計原則。