Proxy圖層和反向路由

簡短摘要

代理層是平臺的「前端總線」：它完成TLS，認證客戶，分布流量，平滑峰值並使發布安全（金絲雀，藍綠色）。最小成熟度集：清晰的代理角色分層，確定性的路由規則，時空/後繼控制，kesh+rate-limit，端到端可觀察性和自動化。

代理分類法

Forward proxy-客戶端/服務出站（egress）、過濾器/鏡像、DLP。
反向驗證-接受外部請求並路由到後端（我們的主要重點）。

prod輪廓中的圖層：

1.Edge/CDN/WAF（Anycast，機器人過濾器，kesh）

2.L7 入口/API網關（路由、身份驗證、策略）

3.服務層/Mesh （sidecar）用於東西方、mTLS和retrais

4.用於出站集成的Egress-gateway （PSP,合作夥伴）

路由（L4/L7）和算法

L4 （TCP/UDP, passthrough TLS）：最小延遲,不了解HTTP。
L7 (HTTP/1.1，HTTP/2，HTTP/3/gRPC）：關於主機/path/header/cookie，轉換，WAF，kesh的規則。

算法：

Round-robin/Least-connections/EWMA是常見病例。
Consistent-hash（通過cookie/ID）是sticky會話和緩存本地性。
Header -/Geo -/Latency-按區域/提供商定位，快速PoP。
金絲雀/重量級-分階段滾動（5→25→50→100％）。
Shadow/Mirroring-將流量復制到新服務而不會影響響應。

請求/響應轉換

URL rewrite/redirect：統一路徑、轉換（'/v1/ →/svc/v1/'）。
標題：標準化"X-Forwarded-For/Proto/Host",添加"traceparent"/"x-request-id,過濾更多。
CORS/CSRF：集中在網關中,不要在每項服務中實現設置。
Compression/Decompression：brotli/gzip，類型控制。
身體極限和防慢速起搏器/超速起搏器。

身份驗證和安全性

TLS 1.3+OCSP stapling+HSTS在外側。
mTLS：管理,操作API,合作夥伴渠道。
OAuth2/OIDC：通過網關（token introspection/JWT-verify）獲得授權→在上遊進入氣候。
用於服務間和合作夥伴集成的API密鑰/簽名（HMAC）。
WAF/機器人過濾器：簽名+行為規則，greypass/kapcha。
CSP/X-Frame-Options/Referrer-Policy是邊緣的安全標題。

可靠性： retrai/taymout/SV

Taymauts： connect/read/write on L4/L7,單一策略（例如「connect 500 ms」、「read 3-5s」 for API）。
Retrai：僅偶數（「GET/HEAD」），時間/數量限制，「retry-budget」。
電路斷路器：對同時查詢/錯誤、快速故障和退化的限制。
Outlier檢測：從池中排除「不良」實例。
Backoff+Jitter：不創建「牛群效應」。

Kesh和流量管理

Kesh L7：靜態/半動力學（目錄，configs），「s-maxage」+「stale-wile-revalidate」。
Rate-limit/Quota：通過IP/ASN/device/cookie,分布式計數器（Redis/Rate-service）。
Sticky會話：cookie/consistent-hash；考慮故障轉移和「重鋪」。
請求碰撞（dedupe）：保護起源免受相同的GET的「風暴」。

協議和功能

HTTP/2：多路復用，優先次序；保持「ALPN：h2」。
HTTP/3/QUIC：抵禦損失/緊張；打開UDP/443，留意MTU/PMTUD。
gRPC: health-checks, streaming, deadlines;代理必須支持「grpc-status」。
WebSocket/SSE：長壽命連接器，熟練的idle-mayout和限制。

可觀察性和SLO

度量標準：

L4/L7: `p50/p95/p99`, ошибки (`4xx/5xx/Grpc-codes`), `open_conns`, `CPS/RPS`, `retry_rate`.
TLS：版本/密碼,p95 handshake, resumption。
路由：沿路線/集群的份額,outlier ejections。
Rate-limit/WAF：觸發/FP-rate。
Logs：訪問（沒有PII）,路由原因,跟蹤標題。
Traces：「traceparent」/B3, sampling。

SLO（示例）：

p95 TTFB API ≤ 250-300毫秒；L7 ≤ 0錯誤。5%.
加那利群島的成功（沒有指標降解）≥ 99％的發射。
FP-rate WAF ≤ 0.1%.

類型configs

Nginx（逆向代理、HTTP/2、金絲雀、壓縮）

nginx map $http_x_canary $upstream_pool {
default "stable";
~^1$ "canary";
}

upstream api_stable { zone zst 64k; server 10. 0. 1. 10:8443; server 10. 0. 1. 11:8443; keepalive 256; }
upstream api_canary { zone zcn 64k; server 10. 0. 2. 10:8443; keepalive 64; }

server {
listen 443 ssl http2 reuseport;
server_name api. example. com;

ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_stapling on; ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000" always;

basic limits/protection client_max_body_size 10m;
sendfile on; brotli on; gzip on;

location / {
proxy_http_version 1. 1;
proxy_set_header Host $host;
proxy_set_header X-Request-Id $request_id;
proxy_set_header X-Forwarded-Proto https;
proxy_connect_timeout 500ms;
proxy_read_timeout 5s;
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 1; # Retrays are limited to proxy_pass https://api_$upstream_pool;
}
}

HAProxy （JWT-verify+mTLS to backend+ rate-limit）

haproxy frontend fe_https bind:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1. 1 http-request set-header X-Request-Id %[unique-id]
http-request lua. jwt_verify # external verification script JWT stick-table type ip size 1m expire 10m store http_req_rate (10s)
http-request deny if { src_http_req_rate(10s) gt 100 }

default_backend be_api

backend be_api balance roundrobin option httpchk GET /healthz server s1 10. 0. 1. 10:8443 check ssl verify required ca-file /etc/haproxy/ca. pem server s2 10. 0. 1. 11:8443 check ssl verify required ca-file /etc/haproxy/ca. pem

Envoy (JWT + weighted routes + outlier detection)

yaml static_resources:
listeners:
- name: https address: { socket_address: { address: 0. 0. 0. 0, port_value: 443 } }
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 stat_prefix: ingress route_config:
virtual_hosts:
- name: api domains: ["api. example. com"]
routes:
- match: { prefix: "/" }
route:
weighted_clusters:
clusters:
- { name: api-stable, weight: 95 }
- { name: api-canary, weight: 5 }
http_filters:
- name: envoy. filters. http. jwt_authn typed_config: { "@type": type. googleapis. com/envoy. extensions. filters. http. jwt_authn. v3. JwtAuthentication }
- name: envoy. filters. http. router clusters:
- name: api-stable connect_timeout: 0. 5s type: STRICT_DNS lb_policy: ROUND_ROBIN outlier_detection: { consecutive_5xx: 3, interval: 2s, base_ejection_time: 30s }
transport_socket:
name: envoy. transport_sockets. tls
- name: api-canary connect_timeout: 0. 5s type: STRICT_DNS lb_policy: ROUND_ROBIN transport_socket:
name: envoy. transport_sockets. tls

Traefik（基於規則的路由,概念）

yaml http:
routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1/`)"
service: api-svc tls: { certResolver: letsencrypt }
services:
api-svc:
loadBalancer:
servers:
- url: "https://10. 0. 1. 10:8443"
- url: "https://10. 0. 1. 11:8443"

代理性能

連接並保持到後端，連接限制為實例。
Reuseport，pin CPU/IRQ，足夠的套接字緩沖區。
TLS： ECDSA+短鏈,resumption ≥ 70%, HTTP/2/3包括在內。
緩存到「熱」響應的代理中（包括304驗證）。
Warm-up：在峰前加熱DNS/TLS/Connects。

DR和容錯能力

降級節點的自動對接（「outlier-ejection」）。
健康檢查L4/L7（HTTP身體標記版本）。
Fail-open/Fail-closed-有意識地選擇支付/關鍵路徑。
在將流量切換到新服務之前進行陰影模式。
Runbooks：「群落崩塌」，「重定向循環」，「連接泄漏」，「重定向風暴」。

實施支票

分層：Edge → Ingress/API-GW → Mesh/Egress，角色和責任界限。
路由策略：host/path/header/weight, canary/blue-green, shadow。
安全：TLS 1.3、mTLS用於敏感路徑,JWT/OAuth2 WAF。
Taymauts/retrai/SV：統一值，冪等，retry-budget。
Kesh/Rate-limit/Request-collapsing在適當的時候。
可觀察性：度量/logi/traces，correlation id。
SLO：p95/錯誤/資源；外圍故障的差異。
IaC/GitOps：存儲庫中的代理組合、金絲雀版本、快速回滾。
測試：e2e路線、混沌場景、載荷前。

典型錯誤

沒有角色劃分的「魔術」代理收割機→復雜的RCA和高爆炸半徑。
非偶數請求的轉發→重復的事務。
沒有標題/URL歸一化→ cache-poisoning和錯誤密鑰。
沒有失敗計劃的sticky會話→降級實例。
缺乏「traceparent」/「x-request-id」 →無法解決問題。
在代理級別剛性301/302 →「環路」和API版本控制丟失。

iGaming/fintech的細節

付款/PSP：帶有mTLS的專用egress-gateway，嚴格的計時器，偶數密鑰，白色IP/ASN列表。
高峰（比賽/錦標賽）：金絲雀/重量，機器人灰色路線，激進的kesh GET，防禦起源「風暴」。
調節/邏輯：在審計邏輯中捕獲策略版本和路由原因；最小化PII。
內容提供商：通過提供商密鑰來進行緩存本地性和均勻分發。

迷你花花公子

1）金絲雀API發行版

1.在「api-canary」上包括5％的權重；2）監視p95/錯誤；3）擴大份額；4）降解時自動退貨。

2）緊急拆除退化的節點

1.Outlier-ejection或手動「drain」；2）檢查池和kesh命中；3）事後RCA。

3）功能鏡像

1.啟用影子而不影響響應；2）比較響應的度量/深度；3）決定切換。

4）風暴撤退

1.降低背包/時間限制；2）啟用request-collapsing；3）本地存根/緩存；4）穩定起源。

結果

設計良好的代理層是角色劃分，確定性路由，強大的策略（taymout/retrai/SV），安全性（mTLS/JWT/WAF）和可觀察性。將配置固定在IaC中，使用金絲雀和影子，測量SLO-即使在最熱的高峰時段，您的平臺也將具有可擴展性，可預測性和安全性。