nginx.conf

一、

AI 产品上线后，第一次遇到流量峰值：营销活动带来 10 倍流量，系统扛不住了。推理服务崩溃、API 限流、用户投诉……这时候才意识到：AI 系统的架构设计不能只考虑正常情况，必须考虑流量峰值、模型故障、依赖服务不可用等异常场景。弹性架构（Resilient Architecture）不是"加几个实例"就能解决，它需要系统性的设计，覆盖流量控制、故障隔离、自动恢复、降级策略多个层面。那些看似稳定的 AI 产品，背后都有一套精心设计的弹性机制。

二、AI 系统弹性的核心挑战与设计方案

AI 系统面临的主要弹性挑战：

1. 流量峰值：营销活动、热点事件导致流量激增。
2. 模型故障：模型服务崩溃、GPU 故障、推理延迟飙升。
3. 依赖故障：数据库、缓存、外部 API 不可用。
4. 级联故障：一个服务故障导致整个系统雪崩。

graph TB A[AI系统弹性架构] --> B[流量控制<br/>限流/熔断/降级] A --> C[故障隔离<br/>舱壁模式/超时控制] A --> D[自动恢复<br/>健康检查/自愈] A --> E[弹性伸缩<br/>HPA/VPA/预测性伸缩] B --> B1[限流算法<br/>令牌桶/漏桶/滑动窗口] B --> B2[熔断机制<br/>Circuit Breaker] B --> B3[降级策略<br/>返回缓存/简化响应] C --> C1[线程隔离<br/>线程池/信号量] C --> C2[进程隔离<br/>Sidecar/容器] C --> C3[超时控制<br/>合理设置超时] D --> D1[健康检查<br/>Liveness/Readiness] D --> D2[自动重启<br/>Kubernetes Self-Healing] D --> D3[故障转移<br/>多可用区部署] E --> E1[水平伸缩<br/>HPA基于CPU/QPS] E --> E2[垂直伸缩<br/>VPA调整资源] E --> E3[预测性伸缩<br/>基于历史数据] style B fill:#ffebee style C fill:#fff3e0 style D fill:#e8f5e9 style E fill:#e1f5fe

设计一：流量控制

流量控制是弹性架构的第一道防线。核心手段：

1. 限流（Rate Limiting）：限制单位时间内的请求数，保护后端服务。

   • 算法：令牌桶（Token Bucket）、漏桶（Leaky Bucket）、滑动窗口（Sliding Window）。
   • 粒度：按 IP、按用户、按 API Key。

2. 熔断（Circuit Breaker）：检测下游服务故障，自动切断请求，避免雪崩。

   • 状态：关闭（Closed）、打开（Open）、半开（Half-Open）。
   • 触发条件：错误率超过阈值、延迟超过阈值。

3. 降级（Fallback）：服务不可用时，返回降级响应（如缓存数据、默认响应、简化功能）。

设计二：故障隔离

故障隔离防止单个故障扩散到整个系统。

1. 舱壁模式（Bulkhead Pattern）：将系统资源（如线程池、连接池）隔离，避免一个服务耗尽所有资源。
2. 超时控制（Timeout）：设置合理的超时时间，避免无限等待。
3. 重试策略（Retry）：故障后自动重试，但需要退避策略（如指数退避）避免重试风暴。

设计三：自动恢复

系统应该能自动检测故障并恢复。

1. 健康检查（Health Check）：定期探测服务健康状态，自动摘除故障节点。
2. 自愈（Self-Healing）：Kubernetes 的 Pod 重启、缩放组（ASG）的实例替换。
3. 故障转移（Failover）：主节点故障时，自动切换到备用节点。

设计四：弹性伸缩

根据负载自动调整资源。

1. 水平伸缩（HPA）：增加实例数量。
2. 垂直伸缩（VPA）：增加单个实例的资源（CPU、内存）。
3. 预测性伸缩：基于历史数据预测流量峰值，提前扩容。

三、生产级弹性架构的实现

以下是一个基于 Kubernetes 的 AI 推理服务弹性架构实现：

限流实现（使用 Nginx + Lua）

# nginx.conf http { # 共享内存区域（存储限流状态） lua_shared_dict rate_limit 10m; server { location /api/generate { access_by_lua_block { local limit_req = require "resty.limit.req" local lim, err = limit_req.new("rate_limit", 100, 50) -- 100 req/s, 桶容量 50 local key = ngx.var.remote_addr -- 按 IP 限流 local delay, err = lim:incoming(key, true) if not delay then if err == "rejected" then ngx.exit(429) -- Too Many Requests end ngx.exit(500) end if delay > 0 then ngx.sleep(delay) -- 等待令牌 end } proxy_pass http://llm-inference; } } }

熔断实现（使用 Resilience4j）

import io.github.resilience4j.circuitbreaker.CircuitBreaker; import io.github.resilience4j.circuitbreaker.CircuitBreakerConfig; import io.github.resilience4j.retry.Retry; import io.github.resilience4j.retry.RetryConfig; import java.time.Duration; import java.util.function.Supplier; public class AIServiceClient { private final CircuitBreaker circuitBreaker; private final Retry retry; public AIServiceClient() { // 配置熔断器 CircuitBreakerConfig cbConfig = CircuitBreakerConfig.custom() .failureRateThreshold(50) // 错误率超过 50% 触发熔断 .waitDurationInOpenState(Duration.ofMillis(30000)) // 熔断 30 秒 .slidingWindowSize(10) // 滑动窗口大小 .build(); circuitBreaker = CircuitBreaker.ofDefaults("ai-service"); CircuitBreaker.of("ai-service", cbConfig); // 配置重试 RetryConfig retryConfig = RetryConfig.custom() .maxAttempts(3) .exponentialBackoffMultiplier(2.0) .randomizedWaitFactor(0.5) .build(); retry = Retry.of("ai-service", retryConfig); } public String generateText(String prompt) { // 使用熔断 + 重试装饰器 Supplier<String> decoratedSupplier = CircuitBreaker .decorateSupplier(circuitBreaker, () -> { return callAIService(prompt); }); decoratedSupplier = Retry .decorateSupplier(retry, decoratedSupplier::get); try { return decoratedSupplier.get(); } catch (Exception e) { // 熔断打开或重试失败，返回降级响应 return getFallbackResponse(prompt); } } private String callAIService(String prompt) { // 调用 AI 推理服务 // 实现省略 return ""; } private String getFallbackResponse(String prompt) { // 降级响应：返回缓存结果或默认响应 String cached = cache.get(prompt); if (cached != null) { return cached; } return "AI 服务暂时不可用，请稍后重试。"; } }

Kubernetes 弹性伸缩配置

# Horizontal Pod Autoscaler (HPA) apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: llm-inference-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llm-inference minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Pods pods: metric: name: inference_requests_per_second target: type: AverageValue averageValue: "10" # 每个 Pod 处理 10 QPS behavior: scaleUp: stabilizationWindowSeconds: 60 policies: - type: Percent value: 100 # 每次扩容 100% periodSeconds: 60 scaleDown: stabilizationWindowSeconds: 300 # 缩容前稳定 5 分钟 policies: - type: Percent value: 50 # 每次缩容 50% periodSeconds: 60 # Vertical Pod Autoscaler (VPA) apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: llm-inference-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: llm-inference updatePolicy: updateMode: "Auto" # 自动更新资源 resourcePolicy: containerPolicies: - containerName: vllm maxAllowed: cpu: 4 memory: 16Gi minAllowed: cpu: 1 memory: 4Gi

健康检查与自愈

# Kubernetes Deployment 健康检查配置 apiVersion: apps/v1 kind: Deployment metadata: name: llm-inference spec: replicas: 3 template: spec: containers: - name: vllm image: vllm/vllm-openai:latest ports: - containerPort: 8000 resources: requests: cpu: "2" memory: "8Gi" limits: cpu: "4" memory: "16Gi" # 存活探针（Liveness Probe） livenessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 60 # 启动后 60 秒开始检查 periodSeconds: 10 # 每 10 秒检查一次 timeoutSeconds: 5 # 超时时间 5 秒 failureThreshold: 3 # 连续失败 3 次重启 Pod # 就绪探针（Readiness Probe） readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 30 periodSeconds: 5 timeoutSeconds: 3 failureThreshold: 3 # 连续失败 3 次从负载均衡摘除 # 启动探针（Startup Probe） startupProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 30 # 启动最长允许 5 分钟 # 优雅关闭 lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 15"] # 等待负载均衡摘除

四、弹性架构的性能监控与混沌工程

弹性架构需要持续的监控和验证。

关键监控指标

1. 流量指标：QPS、并发数、限流拒绝数。
2. 延迟指标：P50、P90、P99 延迟。
3. 错误指标：错误率、熔断触发次数、重试次数。
4. 资源指标：CPU 利用率、内存使用率、GPU 利用率。

# 弹性架构监控实现 from prometheus_client import Counter, Histogram, Gauge import time # 定义指标 request_count = Counter('ai_requests_total', 'Total requests', ['status']) request_latency = Histogram('ai_request_duration_seconds', 'Request latency') circuit_breaker_state = Gauge('circuit_breaker_state', 'Circuit breaker state', ['service']) rate_limit_exceeded = Counter('rate_limit_exceeded_total', 'Rate limit exceeded') def monitor_wrapper(func): """监控装饰器""" def wrapper(*args, **kwargs): start = time.time() try: result = func(*args, **kwargs) request_count.labels(status='success').inc() return result except Exception as e: if "rate_limit" in str(e): rate_limit_exceeded.inc() request_count.labels(status='error').inc() raise finally: latency = time.time() - start request_latency.observe(latency) return wrapper

混沌工程（Chaos Engineering）

混沌工程是主动注入故障，验证系统弹性。

# 混沌工程实验：模拟推理服务延迟 import random import time def chaotic_delay(): """模拟延迟（10% 概率延迟 5 秒）""" if random.random() < 0.1: time.sleep(5) # 在推理服务中注入 @app.route("/generate", methods=["POST"]) def generate(): chaotic_delay() # 注入混沌 # 正常推理逻辑 return inference_model.generate(request.json["prompt"])

混沌工程工具

1. Chaos Mesh：Kubernetes 原生混沌工程平台，支持 Pod 故障、网络故障、压力测试。
2. Gremlin：商业混沌工程平台，提供 UI 和丰富的故障注入场景。
3. AWS Fault Injection Simulator：AWS 托管的混沌工程服务。

# Chaos Mesh 实验：模拟 Pod 故障 apiVersion: chaos-mesh.org/v1alpha1 kind: PodChaos metadata: name: pod-failure-experiment spec: action: pod-failure mode: one # 随机杀掉一个 Pod selector: namespaces: - ai-services labelSelectors: app: llm-inference duration: "30s" # 故障持续 30 秒 scheduler: cron: "@every 10m" # 每 10 分钟执行一次

五、弹性架构的代价与工程权衡

弹性架构不是免费的午餐，它引入一系列代价：

代价一：系统复杂度显著增加

引入限流、熔断、降级、弹性伸缩等机制后，系统复杂度指数级上升。团队需要投入大量时间学习和维护。

代价二：资源成本增加

弹性架构需要冗余资源（如多副本、备用实例），成本显著增加。需要在弹性和成本之间找到平衡。

代价三：用户体验可能下降

降级策略可能导致用户体验下降（如返回简化响应、缓存数据）。需要精心设计降级逻辑，尽量减少对用户的影响。

工程权衡策略

1. 根据业务重要性决定弹性级别：

   • 核心功能（如支付、下单）：高弹性（多副本、自动恢复、降级策略）。
   • 非核心功能（如推荐、搜索）：中弹性（基本限流、手动恢复）。
   • 边缘功能（如评论、点赞）：低弹性（简单限流、无降级）。

2. 使用托管服务降低运维成本：

   • 云厂商的 AI 推理服务（如 AWS Bedrock、Azure OpenAI）已经内置弹性机制。
   • 云原生限流服务（如 AWS API Gateway 限流、Cloudflare Rate Limiting）。

3. 建立混沌工程文化：

   • 定期主动注入故障，验证弹性架构的有效性。
   • 记录故障处理过程，持续优化弹性机制。

弹性架构的反模式

1. 过度设计：早期产品不需要复杂的弹性架构，简单限流 + 监控足矣。
2. 忽视成本：弹性架构需要冗余资源，成本可能远超收益。
3. 缺少演练：弹性架构不是"配了就行"，需要定期演练验证有效性。

独立开发者的实用主义建议：

1. 从简单开始：早期产品只需要基本限流（如 Nginx limit_req）和健康检查。
2. 优先保证核心功能：不是所有功能都需要高弹性，优先保护核心功能。
3. 使用云服务：云厂商的托管服务可以快速搭建弹性架构，且免运维。
4. 定期演练：每季度进行一次故障演练（如模拟推理服务崩溃），验证弹性机制。

咖啡喝完了，弹性架构的设计也终于完成。弹性架构不是炫技，而是生存技能。真正重要的，是在可用性、成本、复杂度之间找到平衡点，让系统在异常情况下依然可信赖。毕竟，技术的终极目标，是创造价值，而可信赖的系统才能持续创造价值。

（全文完）