本地开发好的AI回答采集系统，在个人电脑上运行正常，但一旦迁移到云上，往往会遇到API调用超时、数据库连接不稳定、进程意外退出等问题。本文以Python + FastAPI构建的采集服务为例，介绍如何将其部署到阿里云ECS，使用RDS PostgreSQL存储采集结果，OSS保存原始回答，并通过systemd实现进程守护。最终实现一个可长期运行、可监控、成本可控的云上采集服务。本文适合有AI应用开发经验、需要将系统部署到云上的开发者。前提是拥有阿里云账号，并开通ECS、RDS、OSS等服务。本文不涉及具体业务逻辑，只关注部署和运维。
业务任务与云上约束
本地原型通常运行在个人电脑上，依赖本地数据库和API Key。迁移到云上需要考虑：
稳定性：云上环境需要长期运行，需考虑进程守护、自动重启。
可扩展性：采集任务可能增加，需支持水平扩展。
安全性：API Key不能明文存储，需使用密钥管理服务。
成本：资源规格和调用量直接影响费用，需合理规划。
环境和资源准备
技术选型与理由
操作系统：Ubuntu 22.04 LTS，云服务器常用版本，社区支持好。
编程语言：Python 3.10+，AI应用开发主流语言，生态丰富。
框架：FastAPI，异步支持好，适合IO密集型采集任务；相比Flask，FastAPI原生支持异步，性能更高。
数据库：RDS PostgreSQL，托管数据库，自动备份，高可用；相比自建数据库，减少运维负担。
对象存储：OSS，存储原始回答JSON，成本低，适合海量非结构化数据。
计算服务：ECS，适合长期运行的常驻服务，可控性强；相比函数计算，无冷启动问题，适合持续采集。
阿里云资源规划
资源 规格建议 用途
ECS 2核4G 运行应用服务
RDS PostgreSQL 2核4G 存储采集结果
OSS 标准存储 存储原始回答JSON
密钥管理服务 托管API Key 安全存储凭证
具体规格和计费请以阿里云控制台为准。资源规格的选择取决于采集频率、数据量和并发量。例如，对于日均采集1000次、每次回答约10KB的场景，2核4G的ECS足够；如果采集量更大，建议升级到4核8G或使用负载均衡。
问题现象或目标
本地原型在个人电脑上运行正常，但迁移到云上后可能遇到以下问题：
API调用超时或限流
数据库连接不稳定
进程意外退出
数据丢失
本文的目标是解决这些问题，实现稳定运行。
方案对比与选择
部署方式选择
ECS + systemd：适合长期运行，可控性强，但需要自己管理进程守护。
函数计算：按调用计费，自动伸缩，适合任务型采集，但冷启动可能影响延迟。
容器服务（ACK）：适合微服务架构，但运维复杂。
根据系统特点（持续采集、需要常驻），选择ECS + systemd守护进程。
数据库选择
RDS PostgreSQL：托管数据库，自动备份，高可用。
自建数据库：成本低，但需自己维护。
选择RDS，减少运维负担。
核心实现
- 应用代码调整
本地原型可能使用SQLite，迁移到PostgreSQL需要修改连接配置。同时，API Key从环境变量读取，而不是硬编码。
config.py
import os
database_url = os.getenv("DATABASE_URL", "postgresql://user:pass@host:5432/dbname")
api_key = os.getenv("DASHSCOPE_API_KEY", "")
- 数据库迁移
使用Alembic进行数据库迁移。首先初始化Alembic：
alembic init alembic
然后修改alembic.ini中的sqlalchemy.url为RDS的连接地址：
sqlalchemy.url = postgresql://user:pass@host:5432/dbname
生成迁移脚本并执行：
alembic revision --autogenerate -m "init"
alembic upgrade head
迁移前，建议备份现有数据；迁移后，检查表结构和数据完整性。如果迁移失败，可以使用alembic downgrade base回滚。
- 对象存储集成
将原始回答保存到OSS，使用阿里云SDK。
import oss2
auth = oss2.Auth(access_key_id, access_key_secret)
bucket = oss2.Bucket(auth, endpoint, bucket_name)
def save_to_oss(key, data):
bucket.put_object(key, data)
- 进程守护
创建systemd服务文件。
[Unit]
Description=AI Answer Collector
After=network.target
[Service]
User=ubuntu
WorkingDirectory=/opt/collector
EnvironmentFile=/etc/collector.env
ExecStart=/usr/bin/python3 main.py
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
关键代码或配置
环境变量文件
/etc/collector.env
DATABASE_URL=postgresql://user:pass@host:5432/dbname
DASHSCOPE_API_KEY=sk-xxx
OSS_ENDPOINT=oss-cn-hangzhou.aliyuncs.com
OSS_BUCKET=my-bucket
数据库连接池
使用SQLAlchemy连接池，避免连接耗尽。
from sqlalchemy import create_engine
engine = create_engine(database_url, pool_size=10, max_overflow=20)
重试机制
调用大模型API时，加入重试和退避。
import time
from tenacity import retry, stop_after_attempt, wait_exponential
@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=2, max=10))
def call_model(prompt):
# 调用API
pass
测试与监控结果
验证方式
部署后，访问健康检查端点/health，正常情况下应返回{"status": "ok"}。
手动触发一次采集任务，检查数据库answers表中是否出现新记录，字段包括id, question, answer, created_at。
检查OSS中是否出现以answers/2026/08/05/xxx.json命名的对象。
查看日志，正常情况下应包含[INFO] 采集成功等关键字。
监控
使用云监控或自建Prometheus。
采集任务成功率
API调用延迟
数据库连接数
资源使用率
成本、稳定性和安全分析
成本控制
使用按量付费，避免包月浪费。
设置预算警报。
定期清理OSS过期数据。
稳定性
使用systemd自动重启。
数据库自动备份。
多可用区部署（可选）。
安全
API Key存储在密钥管理服务，不写入代码。
数据库访问使用最小权限。
网络访问控制（安全组）。
踩坑与适用边界
常见问题
API限流：增加重试和退避，或申请更高配额。
数据库连接超时：调整连接池参数。
进程崩溃：检查日志，增加异常捕获。
适用边界
本文适用于中小规模采集，若需高并发，需采用消息队列和分布式架构。
不同地域和产品版本可能影响配置，请以官方文档为准。
可复用清单
[ ] 环境变量配置
[ ] 数据库迁移
[ ] OSS集成
[ ] systemd服务
[ ] 重试机制
[ ] 监控告警
总结
本文从本地原型到云上生产，介绍了AI回答采集系统的部署过程。关键步骤包括资源规划、代码调整、数据库迁移、进程守护和监控。通过合理配置，可以实现稳定运行，并控制成本。希望本文能为你的云上部署提供参考。
