03-北向集成与数据链路的最后一公里
7.3 北向集成与数据链路的最后一公里
本节摘要：数据从设备到网关、再到网络服务器之后，还要通过北向接口进入业务系统。本节讲 MQTT/HTTP 两种主流北向方式、数据格式与安全要求。位置：7.2 完成了解析与调度，本节打通"到应用"的最后一段。
两种北向方式
| 方式 | 原理 | 适用 | 注意 |
|---|---|---|---|
| MQTT | NS 作为 broker，应用订阅主题 | 实时性要求高、多消费者 | 订阅过滤、QoS 等级 |
| HTTP（Webhook/回调） | NS 主动 POST 到应用接口 | 低频、简单集成 | 重试与幂等 |
MQTT 是社区主流（TTN、ChirpStack 都支持）：应用按设备或应用标识订阅主题，上行数据实时推送，下行数据通过发布主题下发。主题设计要支持按设备、按应用过滤，避免无关数据全量推送。
数据格式与字段
典型的上行数据载荷（JSON）：
{ "dev_eui": "0004A30B001C0530", "device_name": "sewage-001", "f_port": 1, "f_cnt": 234, "confirmed": false, "payload": "base64编码的密文", "rx_info": [ { "gateway_id": "gw-03", "rssi": -88, "snr": 9.2, "time": "..." } ], "decoded_payload": { "水位": 3.2, "电压": 3.8 } }
工程要点：payload 是密文，应用侧要用 AppSKey 解密（NS 与应用服务器分担密钥，见 4.2）；rx_info 含多网关数据（去重后可能仍保留多条），可用于定位与覆盖分析；decoded_payload 由应用服务器解析，NS 不解析业务字段。
安全与可靠性
北向链路的安全三条：TLS 加密（MQTT over TLS、HTTPS）、认证（应用订阅凭证或 API 密钥，逐应用隔离）、下行鉴权（只有授权应用能下发，防伪造指令）。可靠性两条：应用处理失败要能重试（NS 的重试策略与应用的幂等配合）、下行确认回执（关键指令要求设备确认，链路端到端可追踪）。
易错点清单
- 应用直接处理密文：没有 AppSKey 的应用只能看到密文，要提前规划密钥的分发与存储；
- 用固定 QoS 跑所有业务：QoS0 丢消息、QoS2 延迟高，按业务重要性分级（告警 QoS1、遥测 QoS0）；
- 下行不校验设备在线状态：设备长期离线还一直发下行，白白占网关与 NS 资源，先查在线状态再下发；
- 忽略多网关 rx_info 的价值：多网关数据是免费的覆盖诊断信息，存下来用于第 8 章场测分析。
要点回顾：北向走 MQTT 或 HTTP，payload 密文由应用侧解密；主题、认证、TLS 是安全三件套；可靠性与幂等决定业务稳定性。数据链路到此打通，下一章进入测试与部署——把前面所有账本验证一遍。
北向接口的契约管理
北向接口一旦对外开放，就是一份契约：版本管理（接口变更要带版本号，向后兼容）、字段文档（每个字段的含义、单位、示例写清楚）、示例载荷（上行/下行各给一份完整示例）、变更通知（破坏性变更要提前公告并给迁移期）。契约管理的成本低，收益高——集成方的排错时间大多花在"字段对不上"上。
数据质量与治理
数据到应用侧之后，质量治理才开始：异常值检测（水位突然跳变是设备故障还是业务事件？）、缺失补全（设备离线时段的数据怎么标记）、时序入库（时序数据库 vs 关系库的选型）。LoRaWAN 场景数据稀疏（小时级），时序库的降采样与聚合功能很合适。数据的可解释性要留给业务侧：NS 转发的原始 JSON 与解析后的业务字段要能双向追溯。
易错点补充
- 接口无鉴权裸奔：北向接口没有鉴权，任何能访问 NS 网络的人都能订阅数据或下发指令，TLS + 凭证是底线；
- 载荷解析与应用逻辑耦合：decoder 与业务逻辑混在一个服务里，升级 decoder 要重启业务，拆开部署更稳；
- 缺少端到端链路监控：设备→网关→NS→应用 的每一跳都要有指标（时延、成功率），链路哪段断了要能定位。
关键实现清单
- 北向接口带版本号与字段文档，破坏性变更提前公告
- MQTT over TLS + 每应用独立凭证；下行要鉴权
- payload 为密文，应用侧持 AppSKey 解密
- 关键指令要求设备确认，端到端可追踪
典型故障与处置
| 现象 | 原因 | 处置 |
|---|---|---|
| 应用收到乱码 | 未解密或密钥不匹配 | 核对 AppSKey 与设备会话 |
| 消息丢失 | QoS 级别过低或消费端未幂等 | 按业务分级 QoS 并做幂等 |
| 下行无效 | 设备离线仍下发 | 先查在线状态再下发 |
小结
小结：北向链路的关键是契约与安全：接口版本化、字段文档化、TLS+凭证、下行鉴权、端到端可追踪。建议交付时给集成方一份完整的示例载荷与解密说明，把排错成本压到最低——集成故障大多不是协议问题，而是字段与密钥对不上。
北向接口设计示例
主题设计（MQTT，按应用与设备两级过滤）： v3/{app_id}/up/{dev_eui} 上行 v3/{app_id}/down/{dev_eui} 下行 v3/{app_id}/events/{dev_eui} 生命周期事件（入网/离线） 应用侧订阅 v3/{app_id}/up/# 即可收到该应用全部上行，按 dev_eui 分流处理。
下行载荷格式与上行对称：{ f_port, confirmed, payload, priority }，payload 同样加密。
补充：北向链路的时延指标要提前约定并实测——从设备上行到应用收到，端到端时延受上行周期、网关转发、NS 处理、MQTT 投递多环节影响，业务侧按最坏情况设计超时与重试，而不是按单环节的理想值。
北向链路的三级监控
北向链路不是"接上就完"，需要三级监控才能定位问题：第一级，链路级——应用与 NS 的连接状态、消息队列积压量、投递时延，用 NS 的运维面板或自建探针监控；第二级，数据级——上行消息数、解密成功率、解码成功率、字段缺失率，任何一项异常都说明协议或契约出了问题；第三级，业务级——业务字段的合理性（数值范围、时间连续性），业务级异常往往指向设备或传感器而非链路。
| 监控级 | 指标示例 | 异常含义 |
|---|---|---|
| 链路级 | 连接状态、队列积压 | NS 或网络故障 |
| 数据级 | 解密/解码成功率 | 密钥或 decoder 问题 |
| 业务级 | 数值范围、连续性 | 设备或传感器异常 |
三级监控配合告警，才能把"数据不对"快速定位到"链路、协议还是设备"，避免逐层排查浪费时间。这也是大型 LoRaWAN 项目运维体系的标配。
安全事件的三道防线
北向链路是攻击面最大的入口，安全事件要按三道防线设计：第一道，网络层——TLS 加密、IP 白名单、防火墙，挡住外部直接访问；第二道，应用层——MQTT 凭证、API 密钥、每应用隔离，挡住"合法连接但越权访问"；第三道，数据层——设备级授权（应用只能操作自己的设备）、指令审计（下行指令留痕可追溯），挡住"拿到连接后的横向渗透"。三道防线各自独立，任何一道被突破都不会导致全盘失守。