API網關和路由

1） API網關在體系結構中的作用

• 接收傳入流量（HTTP/HTTP2/HTTP3，WebSocket，gRPC）；
• 按規則（host/path/headers/method/query/geo/weight/health）路由；
• 應用端到端策略：身份驗證/授權，評級限制，WAF，CORS，積壓；
• 執行轉換（標題/主體規範化，gRPC↔JSON，GraphQL定位）；
• 提供穩定性（時間、靜止、斷路器、斷路器檢測）；
• 提供可觀察性和計費（標誌，度量，跟蹤，配額）；
• 隔離內部拓撲（服務mesh,私人服務）。

通常配對使用：Edge/API-Gateway+Ingress/Mesh（Envoy/Istio/Linkerd）-前者決定外交政策，後者決定東西方。

2）典型拓撲

單一全局網關（CDN/edge POP → L7網關→服務）-簡單，集中的策略。
區域網關（per-region）+通過地理/潛伏期進行智能路由。
多租戶：專用路線/子域/密鑰、配額和租戶限制。
Hybrid： on prem+cloud、private link/peering, API網關後面的私人後端。

3） L7路由規則

• Host/Path: `api.example.com` → `/v1/orders/`.
• Headers: `X-Client`, `X-Region`, `User-Agent`, `Accept`.
• 方法/內容類型：JSON/Proto/GraphQL的區別。
• Query/Fragment：小心-影響kesh/變體。
• Geo/Latency：最近的ROR/區域, failover降解。
• Weighted/Canary：流量分配為90/10,50/50, sticky by cookie。
• Session affinity：按鍵/令牌哈希（縮放時小心）。

yaml nginx. ingress. kubernetes. io/canary: "true"
nginx. ingress. kubernetes. io/canary-weight: "10" # 10% traffic to new backend

yaml match: { prefix: "/orders", headers: [{name: "X-Experiment", exact_match: "new"}] }
route: { cluster: orders-v2 }

4）協議和互操作性

REST/JSON-默認,描述OpenAPI用於客戶端驗證/生成。
gRPC是HTTP/2頂部的二進制Proto；對於外部客戶,請使用gRPC-JSON轉碼。
GraphQL-匯總服務；在外圍控制請求的復雜性/深度。
WebSocket/SSE-雙向/push；記住sticky和timeouts。
HTTP/2/3（QUIC）-多路復用/快速啟動；檢查WAF/代理兼容性。

5）安全： 身份驗證和授權

5.1交通運輸

TLS 1.外圍2+，HSTS，OCSP stapling，PFS。
mTLS用於B2V/內部 API和機床。
IP allowlist/denylist，地理約束。

5.2個應用級別

OAuth2/OIDC：JWT啤酒代幣，簽名/演示/觀眾驗證。
NMAS/簽名：日期+槍法字符串+簽名（AWS類似）-可變、重復保護（nonce/超時窗口）。
API密鑰：僅作為ID；權利-通過RBAC/ABAC/漏洞。

CORS： 顯式allow-origin, pre-flight kesh.

WAF：簽名（OWASP API Top 10），anormalia，機器人保護，遞歸JSON字段。
DDoS/Abuse：連接極限，token-bucket/Leaky bucket，birst+平均速度，動態禁忌。

yaml plugins:
- name: oidc config: { issuer: "...", client_id: "...", client_secret: "...", scopes: ["orders. read"] }
- name: rate-limiting config: { minute: 600, policy: local }

6）驗證，轉換和互操作性

模式：通過OpenAPI/JSON-Schema/Protobuf驗證主體/標題/參數。
轉換：場規範化，PII掩蓋，添加相關標題（「traceparent」，「x-request-id」）。

轉化： 「Header：X-API-Version」，前綴「/v1」，資源轉化；deprecation policy и Sunset.

Backward-copat：僅限添加字段；避免在沒有新版本的情況下進行「中斷」更改。
Idempotency: `Idempotency-Key` для POST;網關使用TTL將密鑰存儲在Redis中。

7）可持續性： 連接政策

Timeouts: connect/read/write;合理的違約（例如1s/5s/5s）。
Retries：僅適用於安全且等效的；jitter, exponential backoff,最大嘗試。
Circuit breaker：在錯誤/潛伏時打開；半開放給樣品。
Outlier檢測：從池中取出不良實例。
Bulkhead/競爭：對同時進行每條路線請求的限制。
Failover：主動/被動,區域退化。
影子交通：與V1平行的「灰色」V2運行（不影響響應）進行比較。

yaml circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 1024 max_pending_requests: 2048 max_retries: 3

8）腰帶和性能

HTTP-кеш: `Cache-Control`, `ETag/If-None-Match`, `Vary`, `stale-while-revalidate`.

Edge-keshi/ROR：用於靜態和「kesh」 API（等效的GET）的CDN。
Compression： 「gzip/br」（不要壓縮已經壓縮）。
請求拼接（「coalescing」）：合並相同的並行查詢。
響應映射：字段/過濾器,分區（基於卷軸）,尺寸限制。

9）可觀察性和操作

Метрики: `l7_req_total{route,method,code}`, `latency_ms{p50,p95,p99}`, `upstream_errors`, `retry_count`, `cb_state`, `429_rate`, `quota_usage{tenant}`.

Logs：結構,帶有'trace_id/span_id'、'user_id/tenant_id'、'client_ip'。
Traces： W3C Trace Context（「traceparent」,「tracestate」）,在apstrims中宣傳。
審計：誰調用了什麼，哪些權利；敏感的API的不可變存儲。
SLO/SLA：目標p99，錯誤預算；rout-level比全球更好。

10）容量計劃管理

Quota per-tenant/鑰匙/客戶池，每小時/分鐘。
爆破+持續限制；泄漏桶來平滑。
Fairness：當超載時-fair queuing而不是「第一次見面」。
優先級：具有優先級和專用池的系統/關鍵路由。

11）更改管理和發布

金絲雀/藍綠色：重量路由；自動升級SLO（錯誤/潛伏期）。
功能gates/後端標誌：按標題/令牌包含。
Shadowing/diff驗證器：物體/狀態的比較，通過三角洲的公差。
Stagings：專用域/路徑（'staging.api……'），單個密鑰和配額。

12）配置示例

12.1個NGINX-具有極限和腰果的基本網關

nginx map $http_x_request_id $reqid { default $request_id; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

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

security add_header Strict-Transport-Security "max-age = 31536000" always;

location /v1/ {
limit_req zone=perip burst=30 nodelay;
proxy_set_header X-Request-ID $reqid;
proxy_set_header Authorization $http_authorization;
proxy_connect_timeout 1s;
proxy_read_timeout 5s;

proxy_cache api_cache;
proxy_cache_valid 200 10s;
proxy_cache_use_stale error timeout updating;
proxy_pass http://orders-v1;
}
}

12.2 Envoy-按重量和retrai路由

yaml routes:
- match: { prefix: "/orders" }
route:
weighted_clusters:
clusters:
- name: orders-v1 weight: 90
- name: orders-v2 weight: 10 retry_policy:
retry_on: "5xx,reset,connect-failure"
num_retries: 2 per_try_timeout: 2s

12.3 Traefik-Middlwari和Headers

yaml http:
middlewares:
secHeaders:
headers:
stsSeconds: 31536000 contentTypeNosniff: true routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1`)"
service: svc-orders middlewares: ["secHeaders"]

13）反模式

所有人的一個全球限制是「好鄰居」因「嘈雜」而受苦。
不具有相等性的retrai →效果組合（支付，實體創建）。
忽略「timeout」/「max body size」 →掛起/用盡竊賊。
在網關中混合邊緣策略和業務邏輯（周長加重）。
缺乏模式驗證→客戶脆弱性和「打破」版本。
裸體WebSocket不包括auth/限制/中場休息。
頭條新聞中的秘密沒有旋轉；內部B2B不存在mTLS。

14）花花公子（Game Days）

查詢風暴：limiter/quota驗證,429行為,退化。
失去一個集群：failover/重新分配重量；SLO金絲雀。
加重的答案：max body/timeouts；切斷化合物。
註射/異常：WAF規則，禁止遞歸JSON，GraphQL深度較大。
跟蹤失敗：檢查「traceparent」宣傳和采樣。
秘密：鍵輪換/JWKS，令牌到期，時鐘跳躍公差。

15）實施支票

• 已定義域/路徑/版本,由OpenAPI/Proto發布。
• 配置了TLS/mTLS，HSTS，秘密管理和輪換。
• 包括身份驗證（OIDC/HMAC），RBAC/scoops，CORS。
• 限額/配額per-tenant，公平隊列，429-UX。
• 權重/標頭路由，金絲雀計劃和rollback。
• timeout/retry/circuit-breaker/outlier策略。
• 驗證方案，轉換，PII掩蓋。

[] Edge-кеш/ETag, coalescing, gzip/br.

• 可觀察性：度量，標誌，軌跡，dashbords和alerta。
• Runbooks：事件、鑰匙輪換、紙張、「黑色星期五」。

16) FAQ

Q： API網關與服務網關有何不同?

答：門戶是南北（外圍，直通政策）。Mesh是東西方（集群內連接/MTLS/retrai）。通常一起使用。

Q： 在哪裏實現auth：在網關或服務中?

A：兩個級別：網關-coarse-grained（身份驗證,基本權利/配額）,服務-fine-grained（域角色/屬性）。

Q： 什麼時候需要gRPC-JSON轉碼?

答：當內部gRPC和外部需要REST/JSON和簡單的客戶端/瀏覽器時。

Q： 如何選擇考試策略?

答：對於公共API-路徑'/vN'+標題剝奪和冗長的覆蓋。對於內部-功能標誌/兼容性方案。

17）結果

API網關不僅是「proxik」，而且是策略和可持續性的中心。正確的路由，安全性，限制，驗證和可觀察性使發布具有可預測性和速度。將邊緣網關與服務臺結合起來，自動化金絲雀和配額，測試故障-外圍將成為您的助推器而不是瓶頸。