3. 远程运维系统总体设计
远程运维系统不是把 SSH 和 VNC 搬到浏览器里那么简单。在 Ryzen Embedded 平台上，它要同时面对三类现实：一是设备通常部署在无人值守的现场，网络质量不可控；二是嵌入式 CPU 的算力、内存和功耗预算有限，不能像服务器那样随意堆叠中间件；三是运维动作往往涉及固件、BIOS、操作系统和业务应用多个层面，任何一层失联都可能导致设备“变砖”。因此总体设计的第一步不是选技术栈，而是把需求拆成可验证的条目。
需求分析：从运维场景反推系统能力
需求分析应围绕“谁在什么条件下要完成什么动作”展开。以典型的 Ryzen Embedded 边缘节点为例，可归纳为四类需求：
- 可达性需求：设备位于 NAT 或防火墙之后，运维端需在无公网 IP 的情况下建立反向通道；断网重连后应自动恢复会话，重连时间目标可设为 ≤30 秒。
- 可观测性需求：需采集 CPU 温度、核心电压、内存占用、磁盘 SMART、网口链路状态等指标，采样周期示例为 5 秒，异常时提升到 1 秒。
- 可操作性需求：支持远程命令执行、文件传输、屏幕查看、电源控制（软复位/硬复位），其中硬复位必须经过二次确认。
- 安全与审计需求：所有操作需绑定设备身份与操作者身份，指令与结果留存日志，敏感操作需审批或双人确认。
这些需求之间存在冲突：可观测性越强，采样越频繁，CPU 与网络开销越大；安全审计越严格，操作路径越长，故障恢复越慢。因此需求分析必须给出优先级和量化边界，例如“在 1 Mbps 上行带宽下，指标上报占用不超过 200 kbps，屏幕查看帧率不低于 5 fps”。没有量化边界的需求无法指导后续架构分层。
架构分层：把变化隔离在层内
推荐采用五层架构，自下而上为：设备接入层、数据采集层、传输通道层、平台服务层、运维应用层。分层的核心目的是让“设备差异”和“业务差异”互不穿透。设备接入层封装 Ryzen Embedded 平台的 GPIO、SMBus、看门狗和 BMC 接口；数据采集层把原始寄存器值转换为带单位、带时间戳的指标；传输通道层负责反向隧道、断线重连和消息队列；平台服务层提供设备注册、指令路由、日志存储和权限校验；运维应用层面向具体角色提供 Web 控制台、告警面板和批量任务。
图中把传输通道层单独标出，是因为它是唯一跨越公网的边界。工程上应保证：设备侧只主动外连，不开放入站端口；平台侧不直接访问设备内网地址；所有跨层调用都经过通道层封装的会话标识，而不是裸 IP。这样即使某一层被替换，其他层不需要改动。
功能模块划分：按职责而非按页面切分
功能模块划分常见误区是按 UI 页面切分，导致“设备详情页”里塞入采集、指令、日志三套逻辑。更合理的做法是按职责划分，每个模块有明确的输入、输出和失败模式。建议至少包含以下模块：
| 模块 | 核心职责 | 关键输入 | 关键输出 | 典型失败模式 |
|---|---|---|---|---|
| 设备代理 Agent | 运行在 Ryzen 设备侧，执行采集与指令 | 平台下发的指令、本地传感器 | 指标消息、执行结果 | Agent 崩溃、看门狗未喂 |
| 通道网关 | 维护反向隧道与消息路由 | Agent 连接、平台指令 | 会话、转发消息 | 隧道断开、消息积压 |
| 指标服务 | 解析、存储、聚合指标 | 原始指标消息 | 时序数据、阈值告警 | 时间戳错乱、磁盘写满 |
| 指令服务 | 校验、下发、跟踪指令 | 运维操作请求 | 指令状态、审计记录 | 指令超时、重复执行 |
| 身份与权限 | 设备与用户双向认证 | 证书、令牌 | 会话授权 | 证书过期、越权 |
模块之间通过明确定义的消息契约通信。例如指标消息可约定为 JSON：{"dev":"edge-07","ts":1710000000,"cpu_temp":62.5,"fan_rpm":3200}。指令消息则必须带唯一 cmd_id，Agent 侧对相同 cmd_id 做幂等处理，避免重连后重复执行硬复位这类危险动作。
工程约束：把边界写进设计
Ryzen Embedded 平台的工程约束直接决定架构取舍。首先是资源约束：Agent 常驻内存建议控制在 30 MB 以内，CPU 占用在空闲时低于 2%，否则会与业务负载争抢。其次是网络约束：现场可能只有 4G 或窄带专线，上行 1 Mbps、时延 80 ms 是常见假设，因此屏幕查看必须支持按需开启和降帧，指标上报要支持批量压缩。第三是电源与可靠性约束：设备可能被直接断电，Agent 需依赖看门狗，且本地要保留最近 10 分钟的指标缓存，待网络恢复后补传。
安全边界：硬复位、固件刷新、BIOS 参数修改属于不可逆或高风险操作，必须满足三个条件才允许下发：操作者具备对应角色、指令经过二次确认、设备处于可维护状态（非业务高峰）。这三条应作为指令服务的硬编码校验，而不是仅靠界面提示。
最后是版本与兼容约束。Ryzen Embedded 不同型号的传感器接口和 BMC 命令集存在差异，Agent 应通过设备型号和能力描述文件（capability profile）动态加载采集插件，而不是在代码里写死型号判断。平台侧则要求 Agent 与通道协议保持向后兼容：新平台能管理旧 Agent，旧平台至少能识别新 Agent 的心跳并提示升级。把这些约束在总体设计阶段写清楚，后续的功能开发和现场排障才有共同依据。