nginx.conf

一、AI 产品上线后第一次遇到流量峰值营销活动带来 10 倍流量系统扛不住了。推理服务崩溃、API 限流、用户投诉……这时候才意识到AI 系统的架构设计不能只考虑正常情况必须考虑流量峰值、模型故障、依赖服务不可用等异常场景。弹性架构Resilient Architecture不是加几个实例就能解决它需要系统性的设计覆盖流量控制、故障隔离、自动恢复、降级策略多个层面。那些看似稳定的 AI 产品背后都有一套精心设计的弹性机制。二、AI 系统弹性的核心挑战与设计方案AI 系统面临的主要弹性挑战流量峰值营销活动、热点事件导致流量激增。模型故障模型服务崩溃、GPU 故障、推理延迟飙升。依赖故障数据库、缓存、外部 API 不可用。级联故障一个服务故障导致整个系统雪崩。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设计一流量控制流量控制是弹性架构的第一道防线。核心手段限流Rate Limiting限制单位时间内的请求数保护后端服务。算法令牌桶Token Bucket、漏桶Leaky Bucket、滑动窗口Sliding Window。粒度按 IP、按用户、按 API Key。熔断Circuit Breaker检测下游服务故障自动切断请求避免雪崩。状态关闭Closed、打开Open、半开Half-Open。触发条件错误率超过阈值、延迟超过阈值。降级Fallback服务不可用时返回降级响应如缓存数据、默认响应、简化功能。设计二故障隔离故障隔离防止单个故障扩散到整个系统。舱壁模式Bulkhead Pattern将系统资源如线程池、连接池隔离避免一个服务耗尽所有资源。超时控制Timeout设置合理的超时时间避免无限等待。重试策略Retry故障后自动重试但需要退避策略如指数退避避免重试风暴。设计三自动恢复系统应该能自动检测故障并恢复。健康检查Health Check定期探测服务健康状态自动摘除故障节点。自愈Self-HealingKubernetes 的 Pod 重启、缩放组ASG的实例替换。故障转移Failover主节点故障时自动切换到备用节点。设计四弹性伸缩根据负载自动调整资源。水平伸缩HPA增加实例数量。垂直伸缩VPA增加单个实例的资源CPU、内存。预测性伸缩基于历史数据预测流量峰值提前扩容。三、生产级弹性架构的实现以下是一个基于 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; } } }熔断实现使用 Resilience4jimport 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) { // 使用熔断 重试装饰器 SupplierString 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] # 等待负载均衡摘除四、弹性架构的性能监控与混沌工程弹性架构需要持续的监控和验证。关键监控指标流量指标QPS、并发数、限流拒绝数。延迟指标P50、P90、P99 延迟。错误指标错误率、熔断触发次数、重试次数。资源指标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(statussuccess).inc() return result except Exception as e: if rate_limit in str(e): rate_limit_exceeded.inc() request_count.labels(statuserror).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])混沌工程工具Chaos MeshKubernetes 原生混沌工程平台支持 Pod 故障、网络故障、压力测试。Gremlin商业混沌工程平台提供 UI 和丰富的故障注入场景。AWS Fault Injection SimulatorAWS 托管的混沌工程服务。# 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 分钟执行一次五、弹性架构的代价与工程权衡弹性架构不是免费的午餐它引入一系列代价代价一系统复杂度显著增加引入限流、熔断、降级、弹性伸缩等机制后系统复杂度指数级上升。团队需要投入大量时间学习和维护。代价二资源成本增加弹性架构需要冗余资源如多副本、备用实例成本显著增加。需要在弹性和成本之间找到平衡。代价三用户体验可能下降降级策略可能导致用户体验下降如返回简化响应、缓存数据。需要精心设计降级逻辑尽量减少对用户的影响。工程权衡策略根据业务重要性决定弹性级别核心功能如支付、下单高弹性多副本、自动恢复、降级策略。非核心功能如推荐、搜索中弹性基本限流、手动恢复。边缘功能如评论、点赞低弹性简单限流、无降级。使用托管服务降低运维成本云厂商的 AI 推理服务如 AWS Bedrock、Azure OpenAI已经内置弹性机制。云原生限流服务如 AWS API Gateway 限流、Cloudflare Rate Limiting。建立混沌工程文化定期主动注入故障验证弹性架构的有效性。记录故障处理过程持续优化弹性机制。弹性架构的反模式过度设计早期产品不需要复杂的弹性架构简单限流 监控足矣。忽视成本弹性架构需要冗余资源成本可能远超收益。缺少演练弹性架构不是配了就行需要定期演练验证有效性。独立开发者的实用主义建议从简单开始早期产品只需要基本限流如 Nginx limit_req和健康检查。优先保证核心功能不是所有功能都需要高弹性优先保护核心功能。使用云服务云厂商的托管服务可以快速搭建弹性架构且免运维。定期演练每季度进行一次故障演练如模拟推理服务崩溃验证弹性机制。咖啡喝完了弹性架构的设计也终于完成。弹性架构不是炫技而是生存技能。真正重要的是在可用性、成本、复杂度之间找到平衡点让系统在异常情况下依然可信赖。毕竟技术的终极目标是创造价值而可信赖的系统才能持续创造价值。全文完