通讯步骤#

1
用户点"开始采集"
2
      ↓
3
A. 云端准备(采集主服务的启动方法)
4
   1. 前置校验:车在不在线、任务冲突、磁盘状态
5
   2. 生成执行实例号、落库状态=下发运行中
6
      (用独立短事务,毫秒级释放数据库连接)
7
      ↓
8
B. 建立 SSH 连接(车辆连接工具类的建连方法)—— 关键步骤
9
   1. 从 Redis 查车在线信息
10
      - 拿到车的内网穿透地址 + 跳板机端口映射
11
      - 校验"在线":上报时间必须在最大在线间隔内,否则算掉线
12
   2. 两跳 SSH 隧道(注意是两跳,不是直连):
13
      第一跳:连跳板机(公网可达的服务器)
14
      第二跳:从跳板机连到 127.0.0.1 的某端口(跳板机转发到车内网)
15
   3. 强制开心跳保活,每 30 秒一次
16
      (这是治理时加的,原来心跳间隔为零等于不发,5G 静默断连要干等 3 分钟)
17
   4. 双板车(车上有两块计算板)要 ping 另一块板确认通,30 秒超时
18
      ↓
19
C. 执行 shell 脚本(异步执行方法)
20
   1. 从对象存储拉采集脚本,SFTP 上传到车端临时目录
21
   2. SSH 执行脚本,脚本内部干一堆事:挂载外置盘、校验磁盘、启动录制进程
22
   3. 同步等结果(几十秒到几分钟,SSH 通道全程占着)
23
   4. 成功落"下发成功",失败落"下发失败"
24
   5. SSH 输出全程记到 Redis,前端轮询看日志

SSH 版的硬约束#

两个踩过的坑,是面试能讲的差异化:

• 行尾必须 LF。车端 bash 要求 LF 行尾,Windows 开发机上的 CRLF 会让车端 bash 报 command not found。仓库用 .gitattributes 强制 shell 脚本为 LF,不能用会改写行尾的工具处理这些脚本。
• 磁盘路径按车型解析。不同车型外挂盘设备名不同(有的是 /dev/sda,有的是 /dev/nvme0n1),挂载、进目录、取容量三处必须用同一个解析函数按车型解析,写死会格式化错误设备。
• 停止采集绝不”只改库不通知车”。历史上前端”强制结束”入口直接跳过车端下发,造成”库里已结束、车端仍在录”的幽灵录制。停止一律尽力真实停车,停不下来按采集失败收尾。
• 无论停止车端成败,下发状态一律保持成功。这是和上一条配套的红线:停止车端失败时,若把”下发状态”回写成失败,会把”采集阶段失败”误标成”下发失败”,前端会错出”重新下发”按钮——对已在收尾的任务重复下发,等于在幽灵录制上又叠一层重复下发。

通讯步骤#

1
用户点"开始采集"
2
      ↓
3
A. 云端准备(链路服务的启动方法)—— 提交即返回,不等车端
4
   1. 前置校验(同 SSH 版)
5
   2. 生成确定性任务号 = "DC:start:{任务ID}"
6
      - 幂等:同一任务重复提交得到同一任务号,任务管理器见已活跃直接忽略
7
      - 无状态回查:监听器从任务号反解出任务ID,不用在任务表加字段
8
   3. 构建 manifest(执行清单)—— 核心创新,下文专讲
9
   4. 落库状态=下发运行中(短事务)
10
   5. 任务管理器提交下发命令 → 立即返回任务号给前端
11
      (到这里云端动作结束,前端已拿到响应,不等车端)
12
      ↓
13
B. 下行通道(下行发送器 → mars 平台 → 车端 agent)
14
   1. 云端把下行消息发到 Kafka 下行主题
15
      - 消息包 mars 信封(因为走 mars/iot 平台中转,下文专讲)
16
   2. mars 平台(车联网中台)把消息推到车端 agent
17
   3. 车端 agent 收到 → 拉 manifest(按指针 URL 从对象存储下载)
18
   4. 校验 sha256(防篡改/防传输损坏)
19
   5. 按 manifest 的 steps 顺序执行每一步
20
   6. 每完成一步 → 上报进度到 Kafka 上行主题
21
   7. 全部完成 → 上报最终结果(成功/失败)到 Kafka 上行主题
22
      ↓
23
C. 上行回收(上行监听器 → 消息分发器 → 业务监听器)
24
   1. Kafka 消费者从上行主题读车端上报消息
25
   2. 消息分发器按关联标识(=任务号)路由到对应的任务状态机
26
   3. 状态机推进:已确认 → 执行中 → 最终结果
27
   4. 业务监听器监听终态 → 从任务号解析出任务ID → 回写采集任务状态
28
   5. 失联兜底:看门狗定期扫活跃任务,下文专讲

为什么不直接发命令#

Kafka 有单条消息大小限制(默认 1MB)。采集流程是多步的——挂载盘、校验磁盘、校验通道帧率、启动录制、生成摘要、上传产物——每步带具体 shell 命令,全展开可能很大。直接塞 Kafka 会被拒或被截断。

怎么做#

1. 云端把多步流程生成成一份 JSON 清单(步骤数组 + 每步 shell 命令 + 每步超时),序列化后写入对象存储。
2. 算 sha256 摘要。
3. 下行消息只带指针:{schemaVersion, op, taskId, exeId, carId, vin, totalSteps, manifestOssName, manifestKey, manifestSha256, manifestUrl}——消息极小。
4. 车端 agent 收到指针 → 下载清单 → 校验 sha256 → 按步骤执行。

这个设计带来的好处#

• 绕开 Kafka 大消息限制:下行消息永远是几 KB 的指针。
• 完整性校验 防传输损坏、防篡改。
• 可审计:清单留在对象存储,任何一次下发的完整步骤都能回溯。
• 云端编排、车端执行:云端决定流程,车端只管执行退出码——判定逻辑塞进命令(脚本退出码非零即本步失败),车端只看退出码,职责干净。
• 凭证不下发车端:脚本下载统一用预签名 URL,访问密钥不下发车端,安全面收敛。

一个精度换可靠性的取舍#

注释里写了个诚实的设计取舍:链路版把磁盘路径用云端可推断的默认值(默认外置盘),不再像 SSH 版那样实时探测车端状态。这是用精度换可靠性——少一次实时探测就少一次失败点。后续可由车端 agent 在执行前先跑磁盘检查子命令再拼最终路径。

为什么需要看门狗#

注释写得很清楚:同步 RPC(SSH)里”对端没响应”由 socket 超时直接暴露;异步消息(Kafka)里没人推就永远静默——车端进隧道断了,云端不知道,任务永远挂”运行中”。必须由云端主动判定。

状态机全貌#

1
CREATED ──SENT──▶ SENT ──ACK──▶ ACKED ──PROGRESS──▶ RUNNING ──RESULT_SUCCESS──▶ SUCCESS
2
   │                │              │                   │  ▲                       (终态)
3
   │                │              │            心跳超时│  │ 进度/心跳
4
   │                │              │                   ▼  │
5
   │                │              │                STALLED
6
   │ 投递失败       │ 投递失败     │ 总截止              │ 总截止
7
   ▼                ▼              ▼                   ▼
8
DELIVERY_FAILED  DELIVERY_FAILED  TIMEOUT            TIMEOUT
9
(终态)          (终态)          (终态)              (终态)
10

11
任意 ACKED/RUNNING/STALLED ──车端报错──▶ FAILED (终态)

九个状态,四个终态(成功/失败/超时/投递失败)。终态后所有事件被忽略——这是”至少一次投递”下重复消息不出错的关键(同一结果上报多次不会把已成功的任务改回运行中)。

看门狗的扫描逻辑#

看门狗是个周期调度任务,扫描所有活跃任务,做三件事:

1. 总截止时间判定(优先级最高):当前时间 > 任务总截止时刻 → 判超时。无论任务在哪个中间态,超总时限一律超时收尾。
2. 失联判定:任务在”已确认”或”执行中”且当前时间 > 心跳容忍截止 → 判疑似失联。这个状态可恢复——车端恢复上报进度就回”执行中”,不直接判死。
3. 退避重发判定:任务在”退避等待”且到了重发时刻 → 触发重发回”已投递”。

ACK 超时快速重发#

一个精细设计:任务在”已投递”久未确认(最后一公里丢包),不等总截止,快速重发。看门狗注释写:阈值、白名单、预算判定收敛在任务管理器,避免死等到总截止。

为什么 STALLED 不是终态#

这是设计的关键:疑似失联(STALLED)可恢复。车进隧道 30 秒没心跳判疑似失联,出隧道恢复上报,任务继续。只有超总截止才判超时收尾。这给了网络抖动足够的容忍,不误杀。

下面这个图可以点——点任意状态看它的所有转移和触发条件:

data 字段的编码契约(踩过的坑都在这)#

注释里写了好几个坑,都是真实踩出来的:

1. 类型固定为字符串,不是字节数组。为什么?避免 Jackson 默认字节数组 Base64 行为被业务方误配 ObjectMapper 关掉时,线上静默变成整数数组。显式字符串字段,协议契约由本类自身收口、不依赖框架默认。
2. 用标准 Base64(带 padding 的 RFC 4648 字母表),与车端解码端(Java 的 Base64 解码器、Python 的 base64.b64decode)默契一致。
3. 空负载 → data 为空字符串。Base64 编码空字节就是空串,与”无负载”语义自然吻合,避免 null 让车端解析 NPE。
4. 统一构建入口:业务侧走公用包装方法,避免各自构造字段错位。

为什么要包信封#

mars 平台是个通用中台,接多种设备、多种产品。信封结构把”产品标识 + 操作类型 + 设备名 + 业务数据”标准化,mars 只看信封路由到对应车端,不关心业务数据内容。云端业务侧只管业务消息,转信封的事收口在一个 codec 类——这是典型的协议分层:业务层和网络传输层解耦。

优缺点总结#

SSH 版:

• 优点:实现简单直接、调试容易(SSH 进去就能看);不依赖额外中间件,车端只要开了 SSH 就能用;适合早期、车少、网络稳的场景。
• 缺点:①同步阻塞占资源,长操作持数据库事务会搞垮连接池(真实事故);②失联只能干等超时;③单点阻塞,同车操作串行;④网络抖动易整链失败,产生幽灵录制;⑤无法支撑大规模车队。

链路版(Kafka):

• 优点:①异步解耦,提交即返回;②失联有看门狗主动判死,不干等;③Kafka 天然削峰,支撑大规模车队;④状态机 + 进度上报,可观测性好;⑤幂等设计防重复。
• 缺点:①复杂度高——状态机、看门狗、监听器、清单、上下行 codec 一大堆;②依赖重——要 mars 平台、Kafka、车端 agent,任一环挂都影响;③灰度并存期有双写双读的复杂性(两套都要落痕,否则操作历史断档);④排障难——出问题要跨 Kafka/mars/车端三处查。

三个能加分的追问点#

1. “manifest 指针模式为什么不直接发命令?” → Kafka 有大消息限制,清单可能很大,只传指针绕开限制还能 sha256 校验完整性。云端编排、车端执行,职责干净。
2. “看门狗的疑似失联为什么不是终态?” → 可恢复。车进隧道 30 秒没心跳判疑似失联,出隧道恢复就继续,不误杀。只有超总截止才判超时收尾。
3. “两套灰度并存怎么保证操作历史不断?” → 两套都要落操作留痕(只记人工动作),否则前端按开关切换后,操作历史会突然断档——这是上一版留痕被回滚的头号问题。