API网关和路由

1） API网关在体系结构中的作用

API网关是边界上的L7组件（边缘）,它：

接收传入流量（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：按键/令牌哈希（缩放时小心）。

示例（NGINX Ingress，金丝雀重量）：

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

示例（Envoy，基于头部的路由）：

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+平均速度，动态禁忌。

示例（Kong，OIDC和限量）：

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运行（不影响响应）进行比较。

示例（Envoy circuit breaker）：

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"，而且是策略和可持续性的中心。正确的路由，安全性，限制，验证和可观察性使发布具有可预测性和速度。将边缘网关与服务台结合起来，自动化金丝雀和配额，测试故障-外围将成为您的助推器而不是瓶颈。

API网关和路由

联系我们

快速联系

视频即将更新

我们目前正忙于各项项目