1. 为什么需要将FastAPI部署为Windows服务

在Windows服务器环境下运行FastAPI应用时，直接通过命令行启动uvicorn服务器存在几个明显痛点。首先，命令行窗口一旦关闭服务就会终止，这在生产环境中显然不可接受。其次，服务器重启后需要手动重新启动服务，缺乏自动恢复机制。更关键的是，这种运行方式难以集成到Windows的服务监控体系中。

NSSM（Non-Sucking Service Manager）正是为解决这类问题而生。作为一款轻量级的Windows服务封装工具，它可以将任意可执行程序包装成标准的Windows服务。与Windows自带的sc命令相比，NSSM提供了更友好的配置界面和更完善的服务管理功能。实测表明，使用NSSM部署的服务在稳定性方面表现优异，服务崩溃后能够自动重启，且支持完善的日志记录。

2. 环境准备与基础配置

2.1 NSSM的安装与配置

首先需要从NSSM官网下载最新版本。建议选择64位版本以获得更好的兼容性。下载完成后，将nssm.exe文件解压到系统PATH包含的目录中，例如C:\Windows\System32，这样可以在任意路径下直接调用nssm命令。

验证安装是否成功：

nssm --version

正常情况应输出类似"2.24-101-g897c7ad"的版本信息。

2.2 FastAPI应用改造

标准的FastAPI启动方式是通过命令行调用uvicorn，例如：

uvicorn main:app --host 0.0.0.0 --port 8000

为了适配NSSM部署，我们需要修改启动方式，改为在Python代码中直接调用uvicorn.run()。这是因为NSSM更适合监控长期运行的进程，而命令行方式会产生额外的子进程，导致服务管理复杂化。

改造后的main.py示例：

from fastapi import FastAPI import uvicorn app = FastAPI() @app.get("/") async def root(): return {"message": "Hello World"} if __name__ == "__main__": uvicorn.run( app="main:app", host="0.0.0.0", port=8000, reload=False, # 生产环境必须关闭reload workers=4 # 根据CPU核心数设置 )

关键改造点说明：

1. 将uvicorn配置从命令行参数转移到代码中
2. 确保__name__ == "main"判断存在
3. 生产环境必须设置reload=False
4. workers数量建议设置为CPU核心数的1-4倍

3. 使用NSSM创建Windows服务

3.1 基础服务安装

打开管理员权限的CMD或PowerShell，执行以下命令：

nssm install YourServiceName

这会弹出NSSM的图形化配置界面。需要填写的关键参数包括：

• Path: Python解释器路径（如C:\Python39\python.exe）
• Startup directory: 项目根目录
• Arguments: 主程序文件（如main.py）

重要提示：如果使用虚拟环境，Path应指向虚拟环境中的python.exe，例如：venv\Scripts\python.exe

3.2 高级参数配置

在NSSM界面切换到"Details"选项卡，建议配置：

• Display name: 服务的显示名称
• Description: 服务描述信息
• Startup type: Automatic (延迟启动)

切换到"Log on"选项卡：

• 建议选择"Local System account"
• 勾选"Allow service to interact with desktop"（如需调试）

切换到"I/O"选项卡配置日志：

• Output: 指定日志输出路径
• Error: 可与Output相同
• 勾选"Console rotation"

3.3 服务管理命令

安装完成后，可以通过以下命令管理服务：

# 启动服务 nssm start YourServiceName # 停止服务 nssm stop YourServiceName # 重启服务 nssm restart YourServiceName # 查看服务状态 nssm status YourServiceName # 删除服务 nssm remove YourServiceName confirm

4. 生产环境优化与故障排查

4.1 性能优化配置

在NSSM的"Process"选项卡中，建议设置：

• Priority: Normal或Above normal
• Affinity: 根据实际情况绑定CPU核心
• Process throttling: 根据内存情况设置

对于高并发场景，建议在uvicorn配置中增加：

uvicorn.run( ..., limit_concurrency=1000, timeout_keep_alive=30, backlog=2048 )

4.2 常见问题排查

服务启动后立即停止

1. 检查Python路径是否正确
2. 确认main.py中没有语法错误
3. 查看NSSM的日志输出
4. 尝试直接运行python main.py看是否有报错

端口冲突问题

netstat -ano | findstr :8000 taskkill /PID <pid> /F

权限问题

1. 确保服务账户有项目目录的读写权限
2. 防火墙放行相关端口
3. 检查SELinux策略（如果启用）

4.3 监控与维护

建议配置以下监控指标：

1. 服务运行状态（通过nssm status）
2. 内存占用（不超过系统内存的70%）
3. 请求吞吐量（通过FastAPI的/metrics端点）
4. 错误率（5xx响应占比）

可以使用如下命令创建每日重启任务：

schtasks /create /tn "RestartFastAPIService" /tr "nssm restart YourServiceName" /sc daily /st 03:00

5. 替代方案对比与进阶部署

5.1 与其他部署方式对比

5.2 多进程部署方案

对于高负载场景，可以在NSSM中配置多个服务实例，配合负载均衡器使用。具体步骤：

1. 复制多份main.py（如main_8000.py, main_8001.py）
2. 修改每个文件的监听端口
3. 为每个实例创建独立的NSSM服务
4. 使用Nginx进行负载均衡

示例Nginx配置：

upstream fastapi_cluster { server 127.0.0.1:8000; server 127.0.0.1:8001; } server { listen 80; location / { proxy_pass http://fastapi_cluster; } }

5.3 日志集中管理方案

建议采用ELK栈进行日志集中管理：

1. 配置NSSM将日志输出到文件
2. 使用Filebeat收集日志
3. 发送到Logstash进行预处理
4. 最终存储在Elasticsearch中
5. 通过Kibana进行可视化分析

对于小型项目，可以直接使用Python的logging模块配置日志轮转：

import logging from logging.handlers import RotatingFileHandler handler = RotatingFileHandler( 'app.log', maxBytes=1024*1024, backupCount=5 ) handler.setLevel(logging.INFO) app.logger.addHandler(handler)

在实际生产环境中，我通常会为每个FastAPI服务配置独立的日志目录，并设置每日轮转。同时建议在NSSM中启用控制台日志输出，这样可以通过Windows事件查看器查看实时日志。当服务出现异常时，第一时间检查日志文件中的错误信息往往能快速定位问题根源。