通用 OTA 设计方案

背景
简介
方案
- 角色
- 流程
总结

背景

随着年龄的增长，很多曾经烂熟于心的技术原理已被岁月摩擦得愈发模糊起来，技术出身的人总是很难放下一些执念，遂将这些知识整理成文，以纪念曾经努力学习奋斗的日子。本文内容并非完全原创，大多是参考其他文章资料整理所得，感谢每位技术人的开源精神。

简介

本文介绍通用的 OTA 设计方案。OTA（Over The Air）即空中下载技术，基于无线网络对设备固件、软件或驱动进行更新。

方案

角色

本文说明的 OTA 方案中包含 6 个参与角色：

管理员（ADMIN）：维护使用 OTA 服务的设备信息及固件版本信息。
设备（DEVICE）：使用到 OTA 服务的设备。
网关（GATEWAY）：过滤来自管理员和设备的请求。
认证服务（AUTH SERVICE）：对管理员身份做鉴权。
OTA 服务（OTA SERVICE）：存储使用 OTA 服务的设备信息，并为这些设备提供 OTA 服务。
文件服务（FILE SERVICE）：负责实际存储固件版本文件。

流程

整个流程分为 4 个阶段：

A：管理员维护 OTA 设备信息。
- $A-1$ 管理员（ADMIN）发送设备管理请求到网关（GATEWAY），设备管理请求可能包含创建设备、更改设备信息、删除设备等操作；
- $A-2$ 网关（GATEWAY）接收到请求后，首先验证请求人（即管理员）身份合法性，从请求中提取关键信息，如 HTTP Header 中的 token，并发送身份合法性校验请求到认证服务（AUTH SERVICE）；
- $A-3$ 认证服务（AUTH SERVICE）确认合法后通知网关（GATEWAY）；
- $A-4$ 网关（GATEWAY）收到认证服务（AUTH SERVICE）返回的身份校验通过结果后，将管理员（ADMIN）的设备管理请求发送到 OTA 服务（OTA SERVICE）；
- $A-5$ OTA 服务（OTA SERVICE）处理完设备管理请求后返回给网关（GATEWAY）；
- $A-6$ 网关（GATEWAY）将设备管理请求处理结果返回给管理员（ADMIN）。至此 OTA 服务（OTA SERVICE）已有设备相关信息。
B：设备上线注册，与 OTA 服务建立长连接。
- $B-1$ 设备（DEVICE）发送上线注册请求到 OTA 服务（OTA SERVICE）；
- $B-2$ OTA 服务（OTA SERVICE）校验设备合法性，处理合法设备的注册请求；
- $B-3$ OTA 服务（OTA SERVICE）校验设备合法后返回给设备一个标识（如：token），设备后续请求都需携带这个标识；
- $B-4$ 设备（DEVICE）收到注册成功结果响应后，紧接着发送一个设备固件版本上报请求到网关（GATEWAY）；
- $B-5$ 网关（GATEWAY）收到设备（DEVICE）的固件版本上报请求后，首先从请求中取出设备身份标识（如：token），发送设备身份验证请求到 OTA 服务（OTA SERVICE）；
- $B-6$ OTA 服务（OTA SERVICE）返回设备身份验证通过结果给网关（GATEWAY）；
- $B-7$ 网关（GATEWAY）再次将设备（DEVICE）的固件版本上报请求转发给 OTA 服务（OTA SERVICE）；
- $B-8$ OTA 服务（OTA SERVICE）处理固件版本上报请求，更新设备的固件版本信息；
- $B-9$ OTA 服务（OTA SERVICE）将设备固件版本上报处理结果返回给网关（GATEWAY）；
- $B-10$ 网关（GATEWAY）将设备固件版本上报处理结果返回给设备（DEVICE）。
C：管理员上传固件升级包。
- $C-1$ 管理员（ADMIN）发送固件升级包上传请求到网关（GATEWAY）；
- $C-2$ 网关（GATEWAY）接收到请求后，首先验证请求人（即管理员）身份合法性，从请求中提取关键信息，如 HTTP Header 中的 token，并发送身份合法性校验请求到认证服务（AUTH SERVICE）；
- $C-3$ 认证服务（AUTH SERVICE）确认合法后通知网关（GATEWAY）；
- $C-4$ 网关（GATEWAY）收到认证服务（AUTH SERVICE）返回的身份校验通过结果后，将管理员（ADMIN）的固件升级包上传请求发送到 OTA 服务（OTA SERVICE）；
- $C-5$ OTA 服务（OTA SERVICE）调用文件服务（FILE SERVICE）执行实际的固件升级包文件存储操作；
- $C-6$ 文件服务（FILE SERVICE）存储完成固件升级包后，将固件升级包的 URL 返回给 OTA 服务（OTA SERVICE）；
- $C-7$ OTA 服务（OTA SERVICE）收到固件升级包 URL 响应后存储固件升级包信息到数据库（通常是关系型数据库）；
- $C-8$ OTA 服务（OTA SERVICE）将固件升级包上传成功结果返回给网关（GATEWAY）；
- $C-9$ 网关（GATEWAY）将固件升级包上传成功结果返回给管理员（ADMIN）。
D：管理员创建 OTA 升级任务并执行。
- $D-1$ 管理员创建 OTA 升级任务，将请求发送给网关（GATEWAY）；
- $D-2$ 网关（GATEWAY）接收到请求后，首先验证请求人（即管理员）身份合法性，从请求中提取关键信息，如 HTTP Header 中的 token，并发送身份合法性校验请求到认证服务（AUTH SERVICE）；
- $D-3$ 认证服务（AUTH SERVICE）确认合法后通知网关（GATEWAY）；
- $D-4$ 网关（GATEWAY）收到认证服务（AUTH SERVICE）返回的身份校验通过结果后，将管理员（ADMIN）创建 OTA 升级任务的请求发送到 OTA 服务（OTA SERVICE）；
- $D-5$ OTA 服务（OTA SERVICE）解析管理员下发的升级任务，计算并查找到需要升级的设备（DEVICE）以及对应的固件升级包信息；
- $D-6$ OTA 服务（OTA SERVICE）通过长连接通知设备（DEVICE）执行 OTA 升级，通知中包含固件升级包 URL 及其签名信息；
- $D-7$ 设备（DEVICE）收到 OTA 升级通知后，根据通知中的固件升级包 URL 下载文件；
- $D-8$ 设备（DEVICE）下载固件升级包的请求首先到达网关（GATEWAY），网关（GATEWAY）从请求中取出设备身份标识（如：token），发送设备身份验证请求到 OTA 服务（OTA SERVICE）；
- $D-9$ OTA 服务（OTA SERVICE）返回设备身份验证通过结果给网关（GATEWAY）；
- $D-10$ 网关（GATEWAY）将设备（DEVICE）的下载固件升级包请求发送给文件服务（FILE SERVICE）；
- $D-11$ 文件服务（FILE SERVICE）返回固件升级包二进制流给设备（DEVICE）；
- $D-12$ 设备（DEVICE）下载固件升级包过程中可以持续上报下载进度给 OTA 服务（OTA SERVICE）；
- $D-13$ OTA 服务（OTA SERVICE）可以通过控制台展示设备（DEVICE）下载固件升级包的实时进度；
- $D-14$ 设备（DEVICE）下载固件升级包完成后，首先通过 $D-6$ 中拿到的签名信息验证固件升级包完整性，确认后执行本地升级操作；
- $D-15$ 设备（DEVICE）升级过程中可以持续上报升级进度给 OTA 服务（OTA SERVICE）；
- $D-16$ OTA 服务（OTA SERVICE）可以通过控制台展示设备（DEVICE）升级的实时进度；
- $D-17$ 设备（DEVICE）升级完成后将升级结果上报给 OTA 服务（OTA SERVICE）；
- $D-18$ OTA 服务（OTA SERVICE）收到设备（DEVICE）升级结果上报信息后，更新设备固件信息；
- $D-19$ OTA 服务（OTA SERVICE）可以通过控制台展示设备（DEVICE）升级的结果。

总结

本文只展示了一个通用的 OTA 设计方案，为什么说是通用，因为应用到具体项目时需要根据实际需求情况做调整，譬如：

本文方案中的 OTA 服务（OTA SERVICE）既负责固件版本信息维护，又负责设备信息维护，但在一些 ToB 项目中存在一个专门的服务用于维护设备信息，即 MDM（Mobile Device Management，移动设备管理），在这种情况下设备信息维护由 MDM 服务负责，而固件版本信息维护由 OTA 服务负责，本方案中展示的设备身份认证请求应该发送给 MDM 服务而非 OTA 服务；
本文方案中的文件服务（FILE SERVICE）其实混合了文件管理和文件存储这两个概念，通常在稍大规模的系统设计中，文件管理和文件存储服务是分离开的；
本文方案只说明了整体业务流程，并未怎么提及实现细节，这其中还有很多具体的关键技术：
- 设备与 OTA 服务器之间的长连接管理；
- 管理员及设备的身份鉴权；
- 服务间鉴权；
- 固件包签名及合法性校验；
- 固件包下载协议：HTTP(S) / MQTT；
- 固件包版本号规则；
- 固件包分组传输；
- 固件包断点续传。