单个uvicorn进程无法承载生产流量，因其默认单进程架构导致无容错、无法分摊压力且CPU密集型任务会阻塞事件循环；正确方案是gunicorn多进程管理+uvicorn ASGI worker，并配好timeout、keep-alive、preload等关键参数，配合Nginx实现故障隔离与负载均衡。
为什么单个 uvicorn 进程撑不住生产流量
因为 uvicorn 默认是单进程单线程（或单进程多协程），不带负载均衡和故障转移——一个进程挂了，整个服务就 502；请求堆积时无法横向分摊压力；CPU 密集型任务还会阻塞整个事件循环。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 绝不能直接用
uvicorn main:app跑在生产环境，哪怕加了--workers 4也不行（uvicorn的--workers仅对--reload或--lifespan场景有限支持，且不适用于非 ASGI 生命周期管理） - 真正可行的方案是：用
gunicorn做多进程管理器 +uvicorn做 ASGI worker，即gunicorn -k uvicorn.workers.UvicornWorker - 注意
gunicorn的--workers数值别盲目设成 CPU 核数 × 2——Python GIL 下，I/O 密集型服务通常设为2 × CPU 核数 + 1即可；再高反而因进程切换开销拖慢响应
gunicorn + uvicorn 组合里哪些配置真关键
不是所有参数都影响高可用，但几个配置错了，集群就形同虚设。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
--timeout 120必须设，否则长连接或慢查询会卡住 worker，导致后续请求排队甚至雪崩；但别设太短（如 5 秒），否则正常文件上传或聚合查询会被误杀 -
--keep-alive 5推荐设为 5–30 秒，避免客户端频繁建连，但别超过反向代理（如 Nginx）的proxy_read_timeout，否则连接被提前中断 -
--preload要开，确保每个 worker 加载的是同一份应用实例，避免热重载引发状态不一致；但若代码依赖运行时动态加载（如插件系统），就得关掉并改用--reload（仅限开发） - 日志务必配全：
--access-logfile -和--error-logfile -接到 stdout，方便容器日志采集；漏掉--capture-output会导致子进程 print 输出丢失
Nginx 在这里到底干啥，不是可有可无的胶水
它不只是“转发一下”，而是承担了连接管理、TLS 终止、静态资源托管、健康检查入口、以及最关键的——worker 故障隔离。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 必须用
upstream定义多个gunicorn实例（哪怕只部署一台机器，也应启多个端口），例如：upstream backend { server 127.0.0.1:8000; server 127.0.0.1:8001; } -
proxy_next_upstream error timeout http_502 http_503这行不能少，否则某个gunicornworker 挂了，Nginx 还会继续往它转发请求，用户看到的就是稳定 502 -
proxy_buffering off对流式响应（如 SSE、大文件下载）必须关，否则 Nginx 缓存整块响应再吐给客户端，延迟飙升 - 别把
client_max_body_size设太小，默认 1MB，上传接口很容易 413，按业务需要调到100m或更高
健康检查端点怎么写才不会骗过自己
很多团队写个 /health 返回 {"status": "ok"} 就完事，结果数据库挂了、缓存超时、下游 API 失联，健康检查照样绿——这等于没做。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 检查项必须覆盖核心依赖：数据库连接（执行
SELECT 1）、Redis ping、关键下游 HTTP 探活（带超时和非 2xx 判定） - 不要在
/health里做耗时操作（如全表 count），更别触发任何写逻辑；超时控制在 1 秒内，Nginx 的health_check默认只等 5 秒 - 区分就绪（
/ready）和存活（/live）：前者查依赖，后者只确认进程活着（比如读个本地文件）；K8s 里两者用途完全不同 - 返回体里带上失败原因字段（如
"db": "timeout"），方便快速定位，而不是靠翻日志猜
高可用真正的难点不在启动多少个进程，而在各层之间怎么定义“失败”、谁来发现失败、失败后是否真的绕开了问题节点——这些细节一旦松动，再多副本也只是幻觉。
