FastAPI 生产部署用 Uvicorn 多 Worker 进程--workers榨取多核 CPU【免费下载链接】fastapiFastAPI framework, high performance, easy to learn, fast to code, ready for production项目地址: https://gitcode.com/GitHub_Trending/fa/fastapi本文聚焦 FastAPI 官方文档日文版「Server Workers - ワーカー付きUvicorn」一节讲解如何通过fastapi或uvicorn命令的--workers选项启动多工作进程从而让应用并行处理请求、利用多核 CPU并结合本仓库的 CLI 入口源码与部署概念文档说明 worker 进程模型的底层结构进程管理器 子进程、内存占用规律以及它在整体部署概念中解决与未解决的部分读完即可在单机服务器上以多进程方式安全地跑起一个生产级 FastAPI 服务。背景部署概念清单与复制问题在讨论 worker 之前先回顾 FastAPI 部署文档中列出的六个核心部署概念安全 - HTTPS启动时的自动运行自动重启复制Replication即同时运行的进程数内存启动前的预置步骤如数据库迁移在此之前的教程中我们通常用fastapi run其内部运行 Uvicorn以单个进程启动服务。而部署到生产环境时为了利用服务器的多个 CPU 核心并处理更多并发请求我们希望复制出多个进程——这就是本节的主题。本仓库中fastapi命令的实际入口很短可以印证它只是委托给 CLI 工具这一事实fastapi/cli.py 中main()函数会尝试from fastapi_cli.cli import main as cli_main若未安装则提示执行pip install fastapi[standard]而python -m fastapi的入口 fastapi/main.py 仅两行导入并调用fastapi.cli.main。也就是说--workers这类多进程能力由 Uvicorn / fastapi-cli 提供FastAPI 框架本身只是被它们加载的 ASGI 应用。注意如果你已经使用 Docker、Kubernetes 等容器化部署多进程的策略不同官方文档在 容器内 FastAPI - Docker 中专门讨论尤其是在Kubernetes上通常建议每个容器只运行单个 Uvicorn 进程用容器副本而非进程来做复制。启动多个 Worker方式一使用fastapi命令fastapi run是本仓库文档推荐的生产模式启动方式相对fastapi dev的开发模式详见 fastapi-cli 文档。加上--workers即可$ fastapi run --workers 4 main.py FastAPI Starting production server Searching for package file structure from directories with __init__.py files Importing from /home/user/code/awesomeapp module main.py code Importing the FastAPI app object from the module with the following code: from main import app app Using import string: main:app server Server started at http://0.0.0.0:8000 server Documentation at http://0.0.0.0:8000/docs Logs: INFO Uvicorn running on http://0.0.0.0:8000 (Press CTRLC to quit) INFO Started parent process [27365] INFO Started server process [27368] INFO Started server process [27369] INFO Started server process [27370] INFO Started server process [27367] INFO Waiting for application startup. INFO Waiting for application startup. INFO Waiting for application startup. INFO Waiting for application startup. INFO Application startup complete. INFO Application startup complete. INFO Application startup complete. INFO Application startup complete.方式二直接使用uvicorn命令也可以绕过fastapi命令直接调用 Uvicornmain:app为标准的模块:实例导入字符串$ uv run uvicorn main:app --host 0.0.0.0 --port 8080 --workers 4 INFO: Uvicorn running on http://0.0.0.0:8080 (Press CTRLC to quit) INFO: Started parent process [27365] INFO: Started server process [27368] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Started server process [27369] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Started server process [27370] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Started server process [27367] INFO: Waiting for application startup. INFO: Application startup complete.这里唯一的新选项就是--workers它指示 Uvicorn 启动 4 个 worker 进程。进程结构解析管理器进程 4 个 Worker从上面的日志可以读出整个进程树的形态日志中的每个 PID 对应一个真实操作系统进程父进程process managerPID 为 273654 个worker 进程PID 分别为 27368、27369、27370、27367父进程是进程管理器它是唯一在 IP 端口上监听listen的进程负责把收到的请求分发给各 worker这一点在 部署概念文档 中也被强调——同一台机器上IP 与端口的组合同一时刻只能由一个进程监听因此多进程部署必须有一个组件负责监听并转发每个 worker 独立完成Waiting for application startup → Application startup complete的 ASGI 生命周期也就是说应用启动事件会在每个 worker 中各执行一次。如果你的启动逻辑如加载模型、建立连接池较重它会被执行 N 次。这个管理器 worker结构与部署概念文档中描述的多进程示例一致管理器进程监听端口并转发通信worker 进程负责实际执行请求处理与主要计算。内存开销每个进程独立占内存多进程模型有一个关键代价进程之间通常不共享内存。部署概念文档给出了直观的算例如果应用启动时加载一个1GB 的机器学习模型1 个进程至少消耗 1GB RAM启动4 个 worker则每个各消耗 1GB合计4GB。若服务器 RAM 只有 3GB这样的配置就无法启动。因此选择 worker 数量时必须先估算单进程内存 × worker 数 系统及其他进程是否落在服务器容量内。另外从文档的观察可以推断各进程占用的CPU 比例会随时间大幅波动而内存RAM相对稳定——因此内存才是规划 worker 数时的硬约束CPU 使用率则适合作为后续调优的观测指标可用htop之类工具查看。Worker 在部署概念清单中的定位使用--workers之后六个部署概念中的进展是概念worker 是否解决安全 - HTTPS❌ 仍需 TLS Termination ProxyTraefik、Caddy、Nginx 等启动时的自动运行❌ 仍需 systemd / Supervisor / 容器等外部组件重启⚠️ 部分帮助管理器进程可拉起崩溃的 worker但管理器本身崩溃仍无人重启复制进程数✅ 直接解决多个 worker 并行处理请求内存⚠️ 需要自行核算每个 worker 独立占内存启动前的预置步骤❌ 仍需单独的单进程步骤执行迁移等避免多 worker 并行执行互相冲突值得注意的一点是由于每个 worker 都会完整执行一次应用启动代码如果启动前步骤如数据库迁移写在应用启动钩子里会被并行执行多次并可能互相冲突。官方建议将这类预置步骤放在外部组件中、由单一进程执行一次。与容器化策略的对照容器内 FastAPI 的 Docker 文档 中给出了两种互补用法非 Kubernetes 的单容器场景可以直接在容器内使用--workers例如CMD [fastapi, run, app/main.py, --port, 80, --workers, 4]Kubernetes 等分布式容器编排场景避免在容器内开多 worker应保持一个容器一个 Uvicorn 进程把复制交给编排层的副本数。小结通过fastapi run --workers N main.py或uvicorn main:app --workers N可以零代码改动地为 FastAPI 应用启用多 worker 进程由一个 Uvicorn 进程管理器监听端口并分发请求N 个 worker 进程并行处理业务从而吃满多核 CPU。需要记住的三点约束是——每个 worker 独立占内存启动钩子也各执行一次、管理器只覆盖重启概念的一部分、HTTPS/开机自启/预置步骤仍需外部组件兜底。若你正在自建部署系统而非直接使用 Docker/Kubernetes这些fastapi/uvicorn命令与管理器 worker的思路同样可以直接复用下一步可继续阅读 容器内 FastAPI - Docker学习用容器化方式一并解决其余部署概念。原文档参见 server-workers.md相关背景可延伸阅读 部署概念、手动部署 与 FastAPI 与其他框架/服务器对比。【免费下载链接】fastapiFastAPI framework, high performance, easy to learn, fast to code, ready for production项目地址: https://gitcode.com/GitHub_Trending/fa/fastapi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考