云控系统架构设计与部署：同时管理上百台设备的远程方案

所谓云控系统，就是一个跑在服务器上的管理后台：设备连上来，你在网页里发任务、看状态、收数据。这里要解决的，是同时管理上百台设备的远程方案。

为什么要自建，成本账怎么算

市面上 SaaS 群控产品不少，但很多团队最后选择自建，理由很实际。

一是数据完全可控。设备日志、脚本内容、执行记录都留在自己服务器上，不经过第三方。跨境电商、金融测试等对数据安全敏感的场景，这就是刚需。二是深度定制自由，可以对接内部 ERP、CRM 系统，实现自然语言控制、自定义 AI Agent 工作流，甚至为特定 App 编写专属自动化模板，这些 SaaS 产品做不到。三是长期成本更低，设备量到 50 台以上时，按台付费的 SaaS 总成本远高于一次性自建；自建是一次性硬件投入加少量运维人力，规模越大边际成本越低。

架构怎么拆，从服务器一路搭到后端

一个完整的云控系统，核心组件如下：

组件	作用	选型
API 网关	处理登录、设备管理、任务调度请求	Node.js / Python FastAPI / Go
关系型数据库	存储设备信息、用户信息、任务记录	MySQL 8.0 / PostgreSQL
缓存层	高频读写缓存、设备心跳检测	Redis
消息队列	指令队列、断线重传、异步任务	Redis Queue / RabbitMQ
实时通道	WebSocket/H.264 视频流转发投屏	Nginx RTMP / WebRTC
进程守护	服务异常退出自动重启	Supervisor / PM2

架构可简化为三层：

Web 浏览器 → Nginx(反代+TLS) → API 网关 → Redis/MySQL
                                    ↓ WSS/UDP
                              ┌───┴───┐
                          Agent 手机 1   Agent 手机 N

服务器准备上，国内环境建议用阿里云、腾讯云或华为云的 ECS/CVM。单台设备投屏上行约 1-3 Mbps，20 台至少需要 40-60 Mbps 公网带宽，预算有限可以用带宽包加中转加速摊薄成本；CPU 和内存方面，4 核 8G 支撑 50 台以内，100 台以上建议 8 核 16G 起步；地域选离业务主力区域最近的机房，延迟越低投屏体验越好。

系统初始化（Ubuntu 22.04）：

# 1. 更新系统
apt update && apt upgrade -y

# 2. 安装常用工具
apt install -y curl git wget htop net-tools unzip jq

# 3. 创建非 root 用户
adduser cloudadmin
usermod -aG sudo cloudadmin

# 4. SSH 密钥登录+禁用密码登录
ssh-keygen -t ed25519
cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

# 5. 防火墙只开放必要端口
ufw allow 22/tcp && ufw allow 443/tcp && ufw enable

域名解析则买好域名后添加 A 记录指向服务器公网 IP：

*.yourdomain.com  →  服务器 IP  （通配符方便后续扩展子域名）
cloud.yourdomain.com → 服务器 IP  （控制台专用）

部署有两种方式。Docker Compose 适合需要严格隔离环境的团队，先装 Docker：

curl -fsSL https://get.docker.com | sh
systemctl enable docker
docker compose version

项目目录下创建 docker-compose.yml：

version: '3.8'

services:
  # MySQL 数据库
  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: your-strong-password
      MYSQL_DATABASE: easyclick_cloud
      MYSQL_USER: clouduser
      MYSQL_PASSWORD: another-strong-password
    volumes:
      - mysql_data:/var/lib/mysql
    ports:
      - "127.0.0.1:3306:3306"  # 仅本机可访问

  # Redis 缓存与消息队列
  redis:
    image: redis:7-alpine
    restart: always
    command: redis-server --requirepass your-redis-password
    volumes:
      - redis_data:/data
    ports:
      - "127.0.0.1:6379:6379"

  # API 后端服务
  api:
    build: ./backend
    restart: always
    environment:
      DB_HOST: db
      DB_PORT: 3306
      REDIS_URL: redis://:your-redis-password@redis:6379/0
    depends_on:
      - db
      - redis
    ports:
      - "8080:8080"

  # Nginx 反向代理 + 静态文件
  nginx:
    image: nginx:alpine
    restart: always
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./frontend/dist:/usr/share/nginx/html:ro
    ports:
      - "80:80"
      - "443:443"
    depends_on:
      - api

volumes:
  mysql_data:
  redis_data:

启动全部服务：

docker compose up -d

宝塔面板则适合快速上手、运维深度要求不高的场景，一键安装：

yum install -y wget && wget -O install.sh https://download.bt.cn/install/install_6.0.sh && sh install.sh ed8484bec

再装上 MySQL 8.0、Redis、Nginx 1.24、Supervisor 四件套即可。选哪个？看团队平时怎么运维就行。

数据库核心是两张表。设备表：

字段	类型	说明
id	BIGINT AUTO_INCREMENT	主键
name	VARCHAR(100)	设备昵称/编号
status	ENUM(‘online’,‘offline’,‘error’)	在线状态
platform	ENUM(‘android’,‘ios’,‘harmonyos’)	设备平台
agent_version	VARCHAR(20)	Agent 客户端版本号
last_seen_at	DATETIME	最后心跳时间
created_at	DATETIME	注册时间
properties	JSON	设备属性（品牌、型号、系统版本等）

任务表：

字段	类型	说明
id	BIGINT AUTO_INCREMENT	主键
title	VARCHAR(200)	任务名称
script_content	TEXT	脚本内容/JSON 参数
target_devices	JSON	目标设备 ID 列表
status	ENUM(‘pending’,‘running’,‘completed’,‘failed’)	任务状态
progress	INT	进度百分比
started_at	DATETIME	开始时间
finished_at	DATETIME	结束时间

建表 SQL 在项目仓库的 sql/ 目录里有初始迁移脚本，生产环境推荐用 Flyway 或类似工具管理数据库版本迭代。

后端最容易踩坑的有三个模块。一是设备心跳检测：每个 Agent 客户端按固定间隔（建议 10-30 秒）向云端发心跳，云端后台进程轮询数据库，把超过阈值（比如 3×心跳间隔）没发消息的设备标记离线：

import time

def heartbeat_monitor():
    while True:
        now = datetime.now()
        offline_threshold = now - timedelta(seconds=90)  # 3 × 30s
        
        cursor.execute("""
            UPDATE devices 
            SET status = 'offline' 
            WHERE status = 'online' 
              AND last_seen_at < %s
        """, (offline_threshold,))
        
        time.sleep(10)  # 每 10 秒检查一次

这就是 EasyClick 实际的状态监控面板，左侧能看到中控服务、桥接服务和 AI Agent 的在线状态，设备掉线时右侧列表会实时更新最后心跳时间戳，点「查看日志」直接跳到底层日志页，不用再翻服务器文件。

二是指令队列设计：指令进入 Redis 消息队列，由 Agent 主动拉取，断线重连后不丢指令：

device_queue = f"task:{device_id}"
payload = json.dumps({
    "task_id": task_id,
    "action": "run_script",
    "params": {...},
    "timestamp": int(time.time())
})
r.lpush(device_queue, payload)

Agent 端定期 LPOP 自己的队列消费指令，队列为空就阻塞等待一小段时间再重试，这个模式叫「推拉结合」，兼顾实时性和可靠性。为什么不干脆让服务器直接推？设备断线那一秒，指令就丢了。

三是 WebSocket 实时投屏：网页上的屏幕镜像最佳方案是 WebRTC 或 WebSocket+H.264。Agent 端持续录屏并编码成 H.264 流通过 WebSocket 发给服务端，再转发到所有订阅了该设备画面的浏览器。关键在于按需推送，只有有人打开某台设备的投屏页面时才建立视频流，没人看就关掉编码省 CPU。这部分实时通信优化复杂，建议用成熟的开源方案做基座再二次开发。

前端控制台、设备接入与上线加固

Web 控制台是用户唯一操作入口，四块功能缺一不可。设备管理页用卡片或表格展示所有已注册设备，显示设备名、在线状态、平台图标、电量，支持筛选、搜索、分页和批量下发指令。实时监控大屏类似指挥中心：左侧是设备树状结构，右侧是选中设备的实时画面缩略图墙，点缩略图可展开全屏，顶部放总设备数、在线数、今日执行任务数、成功率等聚合指标。任务编排页是可拖拽的编辑器，能创建「打开 App A → 点击按钮 B → 等待 3 秒 → 滑动 100px」这样的步骤，设置条件分支（如弹出弹窗 C 则点取消）、循环次数和并发策略（顺序/并行），并保存模板复用。数据分析看板展示近 7 天/30 天活跃趋势、脚本执行成功率 Top/Bottom、设备掉线频率分布，用来评估自动化投入产出比。

设备接入靠 Agent 客户端，它负责定时上报心跳和设备信息、接收并执行云端脚本指令、采集屏幕画面推视频流、回报执行结果和异常日志。Android 端通常是一个 APK，扫码下载或云控后台 OTA 静默安装；iOS/HarmonyOS 走各自平台的分发机制。装完在 Web 控制台刷新设备列表，看到状态变「在线」就基本成了，再确认四件事：设备能否被正常选中、心跳是否持续更新（last_seen_at 在变化）、能否成功下发一条简单指令（比如打开一个 App）、投屏画面是否流畅无严重卡顿。四步都过，接入链路就完全正常。

上线之后安全防护必须跟上：强制全站 TLS 1.2 以上并做 HTTP→HTTPS 跳转；所有接口用 Token/JWT 鉴权，过期时间不超过 24 小时；Agent 连接携带设备指纹或共享密钥，防止伪造设备接入；上线前装个免费 WAF 挡掉 XSS、SQL 注入等常见攻击；记录所有管理员操作日志且不可篡改；设备账号密码、API Key 等敏感信息在数据库里加密存储；对登录和 API 调用频率做限流，防爆破和滥用。

FAQ

Q1：云控系统搭建大概需要多少成本？ A：纯自建方案最低配置（4 核 8G 云主机+免费 SSL+MySQL 开源版+自制前端）大约每月 200-400 元服务器费用。带宽是主要变动因素，设备越多需要的上行带宽越大。

Q2：有没有开箱即用的云控系统产品？ A：市面上有几个选择但大多是 SaaS 模式而非私有化部署。如果需要完全自主可控（数据在自己服务器上），自建是唯一选项。自建的优点是完全掌控代码、可以随时定制功能、不存在第三方数据泄露风险。

Q3：搭建难度如何？需要什么技术水平？ A：中等偏上水平即可胜任。需要具备的能力：Linux 服务器管理、Docker/宝塔部署经验、后端服务开发（Node.js/Python/Go 任一语言）、数据库设计和基本的前端知识。如果一个团队里有 1 名全栈工程师，大约 2-3 周可以跑通 MVP（最小可用版本）。

Q4：能不能在家庭 NAS 或小机上运行？ A：理论上可以但有明显的硬件瓶颈。NAS 的小机通常 CPU 和内存都很有限，跑几台设备的轻量管理还凑合，但如果要实时投屏的话几乎扛不住。建议至少保证 2 核 4G 的配置。

Q5：多久需要维护和升级？ A：正常使用下每周做一次数据库备份就够了。系统本身更新频率取决于你选的框架：主流框架一般每月发布安全补丁，建议及时跟进。

---

关于 EasyClick：EasyClick 是手机自动化 AI 智能体平台，覆盖安卓免 root、iOS 免越狱、鸿蒙 Next 三大生态，提供脚本开发、苹果群控、本地中控投屏与云控系统。→ 了解全部产品

---