一、背景与需求分析

随着物联网技术的普及，智能语音播报设备已被广泛应用于各类场景——餐厅订单提醒、工厂工位呼叫、停车场余位播报、加油站安全提示、学校广播通知等。然而，当播报设备规模达到10万台级时，传统的逐条推送或简单轮询方式将面临严峻挑战：

• 并发处理能力：高峰期能否支撑每秒数千条播报请求？

• 设备状态管理：如何感知设备在线/离线状态？离线期间的播报任务是否需要补发？

• 播报防冲突：同一设备短时间内收到多条播报时，是排队、覆盖还是打断？

• 运维可观测性：10万台设备分布在各地，如何快速定位某台设备的播报失败原因？

芯步的智能云播报喇叭产品线（智能语音喇叭3、智能语音音柱、智能语音壁挂音箱等）均提供统一的HTTP接口，单次播报响应耗时约80-120ms。本方案将基于这一开放能力，设计一套可支撑10万级设备规模、高可用、易运维的语音提醒通知系统。

二、整体设计

2.1 核心架构分层

┌─────────────────────────────────────────────────────────────┐
│                      业务应用层                              │
│  (订单系统/安防平台/OA系统/自定义SaaS)                        │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                    通知中台(自建)                             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐       │
│  │ API网关  │→│ 任务队列 │→│ 下发引擎 │→│ 状态追踪 │       │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘       │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                    │
│  │ 设备注册 │ │ 熔断降级 │ │ 重试补偿 │                    │
│  └──────────┘ └──────────┘ └──────────┘                    │
└─────────────────────────────────────────────────────────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
      ┌────────────┐  ┌────────────┐  ┌────────────┐
      │   HTTP     │  │   HTTP     │  │   HTTP     │
      │  api.yoyo  │  │  api.yoyo  │  │  api.yoyo  │
      └────────────┘  └────────────┘  └────────────┘
              │               │               │
              ▼               ▼               ▼
      ┌────────────┐  ┌────────────┐  ┌────────────┐
      │ 喇叭设备-1  │  │ 喇叭设备-2  │  │ 喇叭设备-N  │
      └────────────┘  └────────────┘  └────────────┘

2.2 各层职责

三、接口对接规范

3.1 核心接口说明

芯步开放平台提供统一的设备控制接口，所有型号喇叭均使用相同的调用方式

3.2 签名生成规则

签名算法为双重MD5加密，这是接口安全性的关键保障：

sign = md5( md5(AppSecret) + ts )

其中：

• AppSecret：在芯步控制台获取的开发者密码

• ts：当前Unix时间戳（秒级）

• md5()：标准的MD5哈希函数

• +：字符串拼接

示例（假设AppSecret = abc123，ts = 1704067200）：

第1次MD5:md5("abc123") = "e99a18c428cb38d5f260853678922e03"
字符串拼接: "e99a18c428cb38d5f260853678922e03" + "1704067200"
第2次MD5:sign = md5("e99a18c428cb38d5f260853678922e031704067200")

3.3 播报命令格式

播报文本（最常用）

带前置提示音的播报

其中[message_3]为内置提示音，系统内置5种提示音可供选择。

控制参数类命令

四、10万级设备对接关键设计

4.1 设备管理与映射

10万台设备需要有清晰的管理策略：

设备ID管理

• 芯步为每台设备分配唯一数字ID（如820720）

• 在自己的系统中建立业务标识 ↔ 设备ID的映射表

• 例如：门店ID_001 → 820720，便于业务层按门店定位设备

批量下发

• 单次请求最多支持100台设备同时下发命令

• 对于全量广播场景（如“全厂紧急疏散”），需分批调用，每批≤100台

• 超出100台需业务层自行分片处理

4.2 高并发处理策略

流量削峰

• 采用消息队列（如RocketMQ/Kafka）承接业务请求，避免直接冲击下游接口

• 队列长度根据业务峰值预估，配置为峰值QPS的3-5倍容量

下发限流

• 芯步接口服务端有限流保护，需在客户端实现自适应限流

• 采用令牌桶算法，初始设置为500 QPS，根据响应状态动态调整

• 收到限流错误码时，随机间隔（或逐次增大间隔）重试

连接池配置（以Java为例）：

4.3 可靠性保障机制

异步结果确认根据官方文档说明，code:200仅表示平台收到了指令，不代表设备实际执行成功。设备可能处于离线状态。

的可靠性方案：

1. 开启消息推送：在芯步控制台配置消息接收地址，平台会将设备执行结果异步推送回来

2. 支持extra字段：下发命令时可携带extra字段（如订单号），平台在异步推送时会原样返回，便于业务关联

   {"play:gbk:16": "新订单来了", "extra": "ORDER_12345"}

3. 离线补偿：对于返回502（设备不存在/离线）的场景，将任务存入延迟队列，待设备上线后补发

4.4 播报策略与冲突处理

10万台设备分布在不同的业务场景中，播报策略需因地制宜：

五、开发实现要点

5.1 语言与框架选择

芯步接口基于HTTP，任何支持HTTP请求的编程语言均可对接。推荐方案：

5.2 核心代码模板

Java版本（使用Unirest）

5.3 多设备批量下发示例

六、运维与监控

6.1 关键指标监控

6.2 常见问题排查

6.3 设备选型

七、核心注意事项

1. 签名算法准确性：双重MD5签名是接口调用的基础，封装成独立工具函数并在上线前充分测试。ts需使用秒级时间戳，前后时间差过大会导致签名失效。

2. 200≠播报成功：接口返回200仅代表指令被平台接收，设备实际执行结果需通过异步消息推送获取。关键业请一定要须依赖回调确认。

3. 设备离线处理：10万级规模下设备离线是常态，需设计离线任务队列，待设备上线后补发。离线任务保留时效为24小时。

4. 批量下发限制：单次请求最多100台设备，全量广播需业务层分片处理。同时在请求间加入50-100ms的间隔，避免触发服务端限流。

5. 环境区分：生产环境和测试环境使用不同的AppId和AppSecret，避免测试流量污染生产数据。

6. 私有化部署选项：如对数据安全或网络延迟有比较高要求，芯步支持私有化部署方案，接口协议不变。