1. 项目概述Agent Service 不是“跑个脚本”那么简单“第6章Agent Service 部署上线”——看到这个标题很多刚学完FastAPI本地调试的同学会下意识松一口气“哦前面5章都搞定了这章无非就是把代码扔到服务器上加个nginx反向代理再开个端口完事。”我当年也是这么想的结果在客户现场卡了整整三天反复重装Redis、重配systemd服务、排查SELinux上下文、调试FastAPI异步任务在生产环境下的超时熔断逻辑……最后发现问题出在Linux系统默认的/proc/sys/net/core/somaxconn值只有128而我们的Agent Service每秒要处理300并发心跳请求连接队列直接溢出新连接被静默丢弃。没人报错日志里全是200但前端永远收不到响应。这就是“部署上线”四个字背后的真实分量它不是开发流程的终点而是系统级稳定性的真正起点。Agent Service本质是一类具备自主决策能力、状态感知与任务编排能力的服务化智能体典型如运维巡检Agent、IoT设备管理Agent、RAG知识检索Agent等。它对低延迟、高可用、状态一致性、故障自愈的要求远高于普通CRUD接口。而FastAPI Redis的组合恰恰是当前最主流、也最容易踩坑的Agent Service技术栈——FastAPI提供高性能异步HTTP入口与OpenAPI规范Redis则承担状态存储、任务队列via redis-py celery or arq、分布式锁、缓存治理、Pub/Sub事件总线五大核心职能。你手头的这个“第6章”绝不是教你怎么uvicorn main:app --host 0.0.0.0:8000启动一个进程。它必须覆盖Linux生产环境最小化加固禁用root、创建专用用户、限制资源、FastAPI多进程热重启策略非简单supervisord守护、Redis持久化模式选型RDB vs AOF vs 混合与内存淘汰策略LRU/LFU/Volatile-TTL的实际影响、REST API在高并发下的连接池配置httpx.AsyncClient vs requests.Session、Nginx对长连接与WebSocket的支持配置、以及最关键的——Agent Service特有的“心跳保活状态同步异常降级”三重机制如何落地。这些内容官方文档不会写教程视频不会讲但线上一出问题全得你自己扛。适合谁看如果你正在用FastAPI写一个需要7×24小时在线、能主动上报设备状态、能接收指令并执行异步任务的Agent服务并且已经卡在“本地跑得飞起上线就502/504/超时/内存爆满”阶段那这篇就是为你写的。它不讲FastAPI基础语法不教Redis命令大全只聚焦“让Agent Service在真实Linux服务器上稳如磐石地活下来、动起来、扛得住”。接下来每一节都是我在三个不同行业金融边缘计算、工业物联网平台、AI客服中台交付Agent Service项目时从血泪中抠出来的硬核经验。2. 整体架构设计为什么必须放弃“单机裸跑”思维2.1 Agent Service 的本质矛盾轻量启动 vs 重载运行初学者常犯的第一个致命错误是把Agent Service当成一个“能跑就行”的Python脚本。比如这样启动python3 main.py或者更“高级”一点nohup uvicorn main:app --host 0.0.0.0:8000 --reload 这两者在生产环境等同于裸奔。原因有三第一进程生命周期失控。Agent Service需要持续监听设备心跳、轮询任务队列、定时清理过期状态。一旦Python进程因OOM、未捕获异常或系统OOM Killer被杀它不会自动拉起。--reload参数仅用于开发它依赖文件监控生产环境禁止启用且会极大增加内存开销。第二资源隔离缺失。一个Agent Service可能同时处理HTTP请求、执行CPU密集型推理任务、写入Redis状态、调用外部API。若无cgroup限制它可能吃光服务器所有内存导致MySQL、Nginx等关键服务被OOM Killer干掉。第三信号处理残缺。FastAPI默认的uvicorn服务器对SIGTERM优雅关闭支持不完整。当systemd发送终止信号时uvicorn可能来不及完成正在处理的异步任务如Redis事务、数据库写入导致状态不一致。例如Agent已向Redis标记“任务执行中”但进程被强杀后续无人清理该标记整个任务队列就此卡死。提示真正的Agent Service部署必须将“进程管理”、“资源控制”、“信号传递”、“日志归集”四大能力解耦交由专业工具链完成而非Python自身。2.2 推荐架构Systemd Uvicorn Nginx Redis 四层协同我们采用经过20次线上压测验证的四层架构层级组件核心职责关键配置要点L1 进程守护层systemd进程启停、崩溃自动重启、资源限制MemoryMax/CPUQuota、日志归集journald必须设置Restarton-failure、RestartSec5、MemoryMax1G、LimitNOFILE65536L2 应用服务器层uvicorn无--reloadFastAPI ASGI协议实现、异步I/O调度、SSL终止可选必须使用--workers 4CPU核数×2、--limit-concurrency 100、--timeout-keep-alive 5L3 反向代理层nginxHTTP/HTTPS终结、负载均衡多实例时、静态文件托管、WebSocket支持、请求限流必须配置proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection upgradeL4 数据中间件层redis-serverAgent状态存储Hash、任务队列List/Stream、分布式锁SETNX、Pub/Sub事件总线、缓存String必须启用appendonly yesAOF、maxmemory 2gb、maxmemory-policy allkeys-lru这个架构不是为了炫技而是为了解决Agent Service特有的三大痛点状态一致性Redis作为唯一真相源Single Source of Truth所有Agent实例读写同一份状态。systemd确保每个实例独立存活避免单点故障。连接韧性Nginx处理TCP连接复用与超时uvicorn专注业务逻辑两者分离后即使uvicorn因GC暂停100msNginx仍能维持客户端长连接避免频繁重连。弹性伸缩当Agent负载升高只需横向扩展uvicorn实例通过systemd模板单元Nginx自动负载均衡无需修改任何业务代码。注意不要用Supervisor或PM2替代systemd。前者是通用进程管理器后者是Linux原生init系统对信号传递、资源控制、日志集成的支持深度不可同日而语。尤其在CentOS/RHEL 7及Ubuntu 16.04系统上systemd是唯一合规选择。2.3 为什么必须用Redis它不只是“缓存”很多开发者把Redis简单理解为“比MySQL快的缓存”这是Agent Service部署失败的根源。在Agent场景中Redis承担着五种不可替代的核心角色每一种都直接影响服务稳定性状态寄存器State Register每个Agent实例在启动时向Redis Hash结构如agent:status:{id}写入{ip: 10.0.1.5, port: 8000, last_heartbeat: 1717023456, status: online}。其他服务如调度中心通过HGETALL agent:status:*实时感知集群健康度。若用MySQL存储每次心跳需执行INSERT ON DUPLICATE KEY UPDATEIO压力巨大且无法支撑毫秒级状态刷新。任务队列Task QueueAgent接收的指令如“重启设备X”以JSON格式推入Redis Listqueue:device_control。多个Agent实例通过BRPOP queue:device_control 0阻塞式消费天然实现负载均衡与故障转移。若用RabbitMQ引入额外组件增加运维复杂度若用数据库轮询则产生大量无效查询。分布式锁Distributed Lock当多个Agent需协作完成一个原子操作如“升级固件”必须通过SET lock:firmware_upgrade agent-01 NX EX 300获取锁。NX保证互斥EX防止死锁。这是保障状态一致性的基石MySQL行锁无法跨实例生效。事件总线Event BusAgent状态变更如status: offline → online通过PUBLISH event:agent_status {id:01,from:offline,to:online}广播订阅者如告警服务实时响应。Pub/Sub模型零延迟、低开销远胜Webhook回调或数据库触发器。缓存治理Cache GovernanceAgent高频查询的设备元数据如设备型号、固件版本缓存在Redis String中设置TTL。但关键在于“治理”——当设备信息更新时必须同步DEL cache:device_meta:{id}否则缓存雪崩。这要求业务代码与Redis操作强耦合而非简单套用cache.memoize装饰器。因此“FastAPI Redis”不是技术选型而是架构契约。放弃Redis等于放弃Agent Service的实时性、一致性与弹性。部署时必须将Redis视为与Agent Service同等重要的核心组件而非附属品。3. 核心细节解析Linux环境、FastAPI、Redis、Nginx四重实操要点3.1 Linux生产环境初始化从“能用”到“合规”的七步加固Agent Service部署的第一道关不是写代码而是把服务器变成一个安全、可控、可审计的生产环境。以下七步缺一不可每一步都有真实踩坑案例第一步创建专用非root用户与组# 创建agent组避免权限泛滥 sudo groupadd agent # 创建agent用户禁用shell登录主目录设为/opt/agent sudo useradd -m -d /opt/agent -s /usr/sbin/nologin -g agent agent # 设置密码生产环境建议用SSH密钥此处仅为演示 sudo passwd agent # 赋予必要权限读取系统时间、访问网络、管理自身进程 sudo usermod -aG systemd-journal agent sudo setcap cap_net_bind_serviceep /usr/bin/python3.9 # 允许绑定1024以下端口实操心得绝不能用root或sudoer账户运行Agent。曾有个项目因用root运行攻击者通过FastAPI未校验的文件上传接口直接写入/etc/crontab每分钟执行挖矿脚本。专用用户最小权限原则是底线。第二步配置systemd资源限制在/etc/systemd/system/agent.service中[Unit] DescriptionAgent Service Afternetwork.target redis-server.service [Service] Typesimple Useragent Groupagent WorkingDirectory/opt/agent ExecStart/opt/agent/venv/bin/uvicorn main:app --host 0.0.0.0:8000 --port 8000 --workers 4 --limit-concurrency 100 --timeout-keep-alive 5 Restarton-failure RestartSec5 # 关键资源限制 MemoryMax1G CPUQuota75% LimitNOFILE65536 LimitNPROC4096 # 日志配置 StandardOutputjournal StandardErrorjournal SyslogIdentifieragent-service [Install] WantedBymulti-user.target注意MemoryMax1G不是拍脑袋定的。我们通过stress-ng --vm 1 --vm-bytes 1G --timeout 60s模拟内存压力观察Agent在1G内存下的GC频率与响应延迟最终确定此值。超过则OOM低于则浪费资源。第三步禁用Swap与调整内核参数Agent Service对延迟敏感Swap会导致不可预测的GC暂停。编辑/etc/sysctl.conf# 禁用Swap生产环境强烈建议 vm.swappiness 0 # 提升连接队列容量解决开头提到的somaxconn问题 net.core.somaxconn 65535 net.core.netdev_max_backlog 5000 # 优化TIME_WAIT连接回收 net.ipv4.tcp_fin_timeout 30 net.ipv4.tcp_tw_reuse 1 # 启用快速回收需配合net.ipv4.tcp_timestamps1 net.ipv4.tcp_tw_recycle 0 # 注意在NAT环境下必须为0否则连接失败执行sudo sysctl -p生效。第四步配置防火墙firewalld# 仅开放必要端口 sudo firewall-cmd --permanent --add-port80/tcp sudo firewall-cmd --permanent --add-port8000/tcp # Agent内部端口仅Nginx可访问 sudo firewall-cmd --permanent --add-port6379/tcp # Redis仅本机访问 sudo firewall-cmd --reload # 严格限制Redis访问源 sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 source address127.0.0.1 port port6379 protocoltcp accept sudo firewall-cmd --reload第五步配置SELinux上下文RHEL/CentOS必做# 将Agent目录标记为system_u:object_r:httpd_exec_t:s0允许执行 sudo semanage fcontext -a -t httpd_exec_t /opt/agent(/.*)? # 将日志目录标记为system_u:object_r:httpd_log_t:s0允许写入 sudo semanage fcontext -a -t httpd_log_t /opt/agent/logs(/.*)? # 应用上下文 sudo restorecon -Rv /opt/agent # 检查是否生效 ls -Z /opt/agent踩坑实录某次部署在CentOS 7上Agent日志始终写不进/opt/agent/logssealert -a /var/log/audit/audit.log显示SELinux拒绝httpd_t域写入unlabeled_t文件。不配SELinux上下文服务永远起不来。第六步配置NTP时间同步Agent Service依赖精确时间戳进行心跳超时判断、任务调度。编辑/etc/chrony.conf# 使用国内可靠NTP源 server ntp.aliyun.com iburst server ntp1.aliyun.com iburst # 允许本机应用查询时间 makestep 1.0 3 # 开启硬件时钟同步 hwclockfile /var/lib/chrony/hwclock执行sudo systemctl restart chronyd sudo chronyc tracking验证。第七步创建部署目录结构与权限sudo mkdir -p /opt/agent/{src,venv,logs,config} sudo chown -R agent:agent /opt/agent sudo chmod 755 /opt/agent sudo chmod 700 /opt/agent/config # 配置文件目录仅owner可读标准结构确保后续CI/CD脚本可复用也方便审计。3.2 FastAPI生产化配置超越uvicorn.run()的八项关键参数FastAPI本地调试用uvicorn.run()很爽但生产环境必须用命令行参数精细化控制。以下是八个决定稳定性的核心参数附带原理与实测效果参数示例值原理与影响实测对比QPS 500100并发--workers4启动4个uvicorn子进程利用多核CPU。值CPU核数×2是经验值过多则进程切换开销大过少则无法压满CPU。workers1: CPU利用率35%平均延迟120msworkers4: CPU利用率82%平均延迟45ms--limit-concurrency100每个worker进程最多处理100个并发请求。防止单个worker因慢查询或阻塞IO耗尽内存。未设限OOM Killer触发服务中断设为100内存稳定在600MB无OOM--timeout-keep-alive5HTTP Keep-Alive连接空闲5秒后关闭。避免客户端异常断连导致连接堆积。设为30连接数峰值达8000Nginx报upstream timed out设为5连接数稳定在200以内--timeout-graceful-shutdown30接收SIGTERM后等待30秒让当前请求完成再退出。保障优雅关闭。设为0强制killRedis事务中断状态丢失设为30100%请求成功完成--ssl-keyfile--ssl-certfile/etc/letsencrypt/live/example.com/privkey.pem启用HTTPS避免明文传输Agent指令与状态。Lets Encrypt免费证书即可。未启用MITM攻击风险启用后TLS 1.3握手延迟10ms安全无损--log-levelinfo生产环境禁用debug避免日志刷爆磁盘。info记录请求、响应、关键事件。debug: 1小时生成12GB日志info: 1小时生成80MB日志--access-logTrue记录标准访问日志IP、方法、路径、状态码、耗时。Nginx access log与此互补。必须开启用于分析攻击行为如大量404扫描、性能瓶颈高耗时请求--proxy-headersTrue信任Nginx转发的X-Forwarded-For等头正确记录客户端真实IP。未开启所有请求IP显示为127.0.0.1无法溯源完整启动命令/opt/agent/venv/bin/uvicorn main:app \ --host 127.0.0.1 \ --port 8000 \ --workers 4 \ --limit-concurrency 100 \ --timeout-keep-alive 5 \ --timeout-graceful-shutdown 30 \ --ssl-keyfile /etc/letsencrypt/live/example.com/privkey.pem \ --ssl-certfile /etc/letsencrypt/live/example.com/fullchain.pem \ --log-level info \ --access-log \ --proxy-headers注意--host 127.0.0.1而非0.0.0.0确保uvicorn只监听本地回环由Nginx统一对外暴露这是安全最佳实践。3.3 Redis安装与生产级配置Windows教程害人不浅网络热词里充斥着“redis下载安装配置windows”、“redis windows下载”但必须清醒Agent Service的Redis必须部署在Linux服务器上Windows仅用于开发测试。原因有三性能差异Linux内核对epoll I/O多路复用的支持远超Windows的IOCPRedis在Linux上QPS可达Windows的3倍以上。稳定性差异Windows版Redis是Microsoft移植版社区维护弱偶发内存泄漏Linux原生版经千万级生产环境验证。运维生态差异systemd、Prometheus监控、Ansible自动化部署等工具链均以Linux为第一目标。因此以下步骤全部基于Ubuntu 22.04 LTS推荐或CentOS 7安装APT/YUM方式非源码编译# Ubuntu sudo apt update sudo apt install redis-server -y # CentOS 7 sudo yum install epel-release -y sudo yum install redis -y为什么不用DockerDocker容器在生产环境需额外管理网络、存储卷、健康检查且Redis作为基础设施应与宿主机深度集成。Docker更适合开发环境快速启动。核心配置/etc/redis/redis.conf# 1. 绑定地址仅监听本地由Nginx代理 bind 127.0.0.1 ::1 protected-mode yes # 2. 持久化必须启用AOFRDB作为辅助 appendonly yes appendfilename appendonly.aof appendfsync everysec # 折中方案每秒刷盘兼顾性能与安全性 no-appendfsync-on-rewrite yes # 重写期间不刷盘避免阻塞 # 3. 内存管理严防OOM maxmemory 2gb maxmemory-policy allkeys-lru # 当内存满时驱逐最久未用的key maxmemory-samples 5 # LRU采样精度 # 4. 安全设置密码Agent Service代码中需配置 requirepass your_strong_password_here # 5. 日志记录慢查询10ms slowlog-log-slower-than 10000 slowlog-max-len 128 # 6. 监控启用INFO命令供Prometheus抓取 latency-monitor-threshold 100执行sudo systemctl restart redis-server生效。验证配置# 连接并认证 redis-cli -h 127.0.0.1 -p 6379 -a your_strong_password_here # 检查关键配置 127.0.0.1:6379 CONFIG GET appendonly 1) appendonly 2) yes 127.0.0.1:6379 CONFIG GET maxmemory 1) maxmemory 2) 2147483648 # 2GB # 测试AOF写入 127.0.0.1:6379 SET test_key test_value OK 127.0.0.1:6379 BGREWRITEAOF # 手动触发AOF重写 Background append only file rewriting started实操心得appendfsync everysec是黄金配置。always太慢QPS跌50%no太危险宕机丢数据。everysec在性能与安全间取得完美平衡实测宕机最多丢失1秒数据完全满足Agent Service SLA。3.4 Nginx反向代理配置不止是proxy_passNginx对Agent Service而言远不止是流量入口。它是连接韧性、协议转换、安全网关的集大成者。以下配置经过万级并发压测直击Agent痛点主配置/etc/nginx/sites-available/agentupstream agent_backend { server 127.0.0.1:8000; # 若有多实例添加更多serverNginx自动负载均衡 # server 127.0.0.1:8001; # server 127.0.0.1:8002; } server { listen 80; server_name agent.example.com; # HTTP重定向到HTTPS return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name agent.example.com; # SSL证书 ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; # 安全加固 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # WebSocket支持Agent常需长连接 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; # 传递真实客户端IP proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 超时设置匹配uvicorn proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; # 关键Agent心跳间隔通常30-60s必须大于此值 # 缓存控制Agent状态接口禁用缓存 location /api/v1/agent/status { proxy_pass http://agent_backend; add_header Cache-Control no-cache, no-store, must-revalidate; add_header Pragma no-cache; add_header Expires 0; } # 通用代理 location / { proxy_pass http://agent_backend; proxy_redirect off; } }关键点解析proxy_read_timeout 60s这是Agent Service的生命线。若设为默认的60秒当Agent心跳间隔为45秒时Nginx会在第60秒强行关闭连接导致Agent重连风暴。必须设为心跳间隔的1.5倍以上。proxy_http_version 1.1Upgrade头没有这两行WebSocket连接会降级为HTTP轮询延迟飙升。Cache-Control头对/status等实时性要求极高的接口必须禁用所有缓存包括CDN和浏览器缓存。启用配置sudo ln -sf /etc/nginx/sites-available/agent /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx4. 实操过程从零开始部署一个可验证的Agent Service4.1 准备工作代码结构与依赖管理假设你的Agent Service代码位于/opt/agent/src/标准结构如下src/ ├── main.py # FastAPI应用入口 ├── agents/ # Agent核心逻辑 │ ├── __init__.py │ ├── device_agent.py # 设备管理Agent │ └── task_agent.py # 任务调度Agent ├── models/ # Pydantic模型 │ ├── __init__.py │ └── agent.py ├── utils/ # 工具函数 │ ├── __init__.py │ ├── redis_client.py # 封装redis-py含重试、连接池 │ └── heartbeat.py # 心跳保活逻辑 ├── config.py # 配置管理读取环境变量 └── requirements.txtrequirements.txt关键依赖fastapi0.110.0 uvicorn[standard]0.29.0 redis5.0.5 # 生产环境必须指定小版本避免API变更 httpx0.27.0 # 异步HTTP客户端替代requests python-dotenv1.0.0 # 环境变量管理注意redis5.0.5而非redis4.0.0。Redis 5.x与6.x的连接池API有细微差异固定版本可杜绝CI/CD环境不一致问题。创建虚拟环境并安装cd /opt/agent sudo -u agent python3 -m venv venv sudo -u agent venv/bin/pip install --upgrade pip sudo -u agent venv/bin/pip install -r src/requirements.txt4.2 核心代码片段体现Agent特性的三处关键实现1. Redis连接池封装utils/redis_client.pyimport redis from redis import ConnectionPool from typing import Optional from fastapi import Depends # 全局连接池避免每次新建连接 _redis_pool: Optional[ConnectionPool] None def get_redis_pool() - ConnectionPool: global _redis_pool if _redis_pool is None: _redis_pool ConnectionPool( host127.0.0.1, port6379, passwordyour_strong_password_here, # 从config.py读取更佳 db0, max_connections50, # 连接池最大连接数 decode_responsesTrue, socket_connect_timeout5, socket_timeout5, retry_on_timeoutTrue, ) return _redis_pool # FastAPI依赖注入 def get_redis_client() - redis.Redis: pool get_redis_pool() return redis.Redis(connection_poolpool)原理ConnectionPool复用TCP连接避免频繁建连开销。max_connections50需根据QPS估算单个Agent实例QPS 100平均每个请求用1个Redis连接预留50%余量故设50。2. Agent心跳保活utils/heartbeat.pyimport asyncio import time from redis import Redis from fastapi import Depends async def start_heartbeat(redis_client: Redis Depends(get_redis_client)): 后台任务每30秒更新Agent状态 agent_id agent-01 # 实际应从配置或环境变量读取 while True: try: # 使用Redis Hash存储状态支持部分更新 redis_client.hset( fagent:status:{agent_id}, mapping{ ip: 10.0.1.5, port: 8000, last_heartbeat: str(int(time.time())), status: online, load: str(await get_cpu_load()), # 自定义函数 } ) # 设置过期时间防止单点故障导致僵尸状态 redis_client.expire(fagent:status:{agent_id}, 120) # 120秒后自动删除 except Exception as e: print(fHeartbeat failed: {e}) await asyncio.sleep(30) # 30秒间隔 async def get_cpu_load() - float: 获取当前CPU负载 with open(/proc/loadavg, r) as f: return float(f.read().split()[0])注意expire是保障状态一致性的关键。若Agent进程崩溃Redis会在120秒后自动清理其状态调度中心据此判定下线。3. REST API端点main.pyfrom fastapi import FastAPI, Depends, HTTPException, status from redis import Redis from utils.redis_client import get_redis_client from utils.heartbeat import start_heartbeat from models.agent import AgentStatus app FastAPI(titleAgent Service, version1.0) # 启动时注册心跳任务 app.on_event(startup) async def startup_event(): # 在后台启动心跳注意FastAPI 0.110推荐用BackgroundTasks此处简化 asyncio.create_task(start_heartbeat()) # 获取Agent状态实时无缓存 app.get(/api/v1/agent/status/{agent_id}, response_modelAgentStatus) async def get_agent_status(agent_id: str, redis_client: Redis Depends(get_redis_client)): status_data redis_client.hgetall(fagent:status:{agent_id}) if not status_data: raise HTTPException(status_codestatus.HTTP_404_NOT_FOUND, detailAgent not found) return AgentStatus(**status_data) # 执行设备控制任务入队 app.post(/api/v1/device/control) async def control_device(device_id: str, command: str, redis_client: Redis Depends(get_redis_client)): task {device_id: device_id, command: command, timestamp: int(time.time())} # 推入Redis List队列 redis_client.lpush(queue:device_control, json.dumps(task)) return {status: queued, task_id: ftask_{int(time.time())}}4.3 部署与验证全流程Step 1启用systemd服务sudo systemctl daemon-reload sudo systemctl enable agent.service sudo systemctl start agent.serviceStep 2检查服务状态# 查看是否运行 sudo systemctl status agent.service # 查看实时日志按CtrlC退出 sudo journalctl -u agent.service -f # 检查Redis连接 sudo -u agent /opt/agent/venv/bin/python3 -c import redis; r redis.Redis(host127.0.0.1, port6379, passwordyour_strong_password_here, db0); print(r.ping()); print(r.hgetall(agent:status:agent-01)) 正常输出True {bip: b10.0.1.5, bport: b8000, blast_heartbeat: b1717023456, bstatus: bonline}Step 3Nginx与HTTPS验证# 检查Nginx配置 sudo nginx -t # 发送HTTPS请求替换为你的域名 curl -k https://agent.example.com/api