一种面向 AIoT 定制化场景的服务架构设计方案
一种面向 AIoT 定制化场景的服务架构设计方案
背景问题
在开发面向工业、制造等领域的 AIoT (智能物联网) 系统时，一个常见的问题是客户现场的需求变化非常快。例如，一个基于视觉的质检服务，可能因为生产线上更换了新的物料面板，导致原有的检测区域 (ROI) 和判断标准全部失效。
传统的开发模式通常是将服务的代码逻辑、配置文件、AI 模型等资源打包成一个整体。在这种模式下，即使只是更换一张模板图片或调整一个判断阈值，也需要走完“修改代码 -> 重新打包 -> 测试 -> OTA 升级”的全流程。这个流程不仅效率低，而且在设备数量多时，管理和维护成本非常高。
本文提出一种旨在解决该问题的架构设计，其核心是分离服务的执行逻辑与业务配置。
核心设计：分离执行与配置
此方案将系统划分为四个主要部分，各自承担清晰的职责：
- 云平台 (SaaS Backend)：作为配置和决策中心，负责管理服务的业务配置、执行业务规则、存储和分析数据。
- 设备客户端 (Client)：作为设备上的通用代理，负责与云端通信、同步配置、管理本地服务的启停，但不参与具体业务。
- 原子化服务 (Service)：作为设备上的具体功能执行单元 (例如，视觉检测服务)，负责运行核心算法，并上报原始的检测结果。
- 数据总线 (Data Bus)：作为标准的数据传输通道，推荐使用 MQTT 协议。
下图展示了这四部分之间的协作关系：
关键实现机制
1. 服务资产的远程配置与同步
我们将服务的配置文件、模板图片、模型文件等非代码部分定义为“服务资产”，并使其可以被远程动态更新。
- 云端管理：在云平台上为每个服务实例提供资产管理功能，允许用户上传和修改这些资产文件。
- 同步指令：云平台通过 WebSocket 向设备客户端发送一个标准指令，例如
update_service_assets。该指令包含一个资产列表，列表中每个条目都指明了文件需要存放在服务目录下的相对路径以及一个临时的文件下载地址。 - 客户端执行：设备客户端接收到指令后，其任务是下载指令中列出的所有文件，并根据指定的相对路径，将它们准确地写入对应服务的目录下。写完后，通过预设的机制（例如发送一个本地消息）通知该服务重新加载配置。
整个过程客户端仅充当“搬运工”，不解析文件内容，保证了其通用性。
2. 业务规则引擎置于云端
为了获得最大的业务灵活性，我们将最终的业务决策逻辑从设备端移至云端。
-
设备端：上报原始事实
设备上的服务只执行核心算法，并输出客观的原始结果。例如，一个质检服务只需要识别出“1号检测点状态为OK”、“2号检测点状态为NG”，然后将这些原始数据通过 MQTT 上报。 -
云端：进行业务决策
云平台的规则引擎订阅 MQTT 数据。根据用户在平台上预设的业务规则（例如：“如果1号点OK且2号点OK，则总状态为合格”），对上报的原始数据进行计算，得出最终的业务结论。
通过这种方式，当业务需求（如合格标准）变化时，只需在云平台修改规则即可，设备端的服务代码无需任何变动。
3. 使用 MQTT 作为标准数据总线
规定所有服务都通过 MQTT 上报其运行时数据，可以形成统一的数据流，便于后端处理。
- 标准主题（Topic）：设计一套统一的主题命名规范，例如
devices/{device_id}/services/{service_name}/events/{event_type}。这使得后端服务可以方便地订阅、过滤和路由来自不同设备、不同服务的数据。 - 服务实现: 每个原子服务负责连接 MQTT 并上报自己的数据。为了简化开发，可以在设备端的基础框架（例如
liteboty）中提供一个标准的 MQTT 发布工具类，服务可以直接调用，而无需关心连接管理的细节。
方案总结
该设计方案通过将服务逻辑、服务资产（配置）和业务规则三者分离，解决了 AIoT 领域常见的定制化需求与快速迭代问题。
- 提升了灵活性：业务配置和规则可以由用户在云端随时调整，无需开发人员介入和软件版本更新。
- 降低了维护成本：设备端客户端和服务的职责更加单一，代码更稳定，减少了因业务变更导致的频繁升级。
- 清晰的系统架构：各组件职责分明，便于开发和问题定位，也为后续的数据分析和功能扩展打下了良好基础。