固定链接 滴滴物联网下的基础架构

滴滴物联网下的基础架构

滴滴物联网下的基础架构

简述

随着物联网的蓬勃发展,万物互联已经不是新概念,滴滴物联网平台致力于车联网及交通相关领域,为各类场景提供物联网解决方案及基础服务。

平台服务支持包括设备的快速物联网化、设备管理、数据交通、直播/点播、地图服务、存储服务等能力。解决方案诸如车辆监控、运营管理、交通周边管理、交通运输安全、数据分析等。

特性

安全的通讯链路

采用分级的安全模式,设备厂商可根据设备计算能力选择,提供设备鉴权以及链路加密方式,保障数据不被篡改。

快速接入

针对设备端提供两种接入方案加速缩短设备厂商接入平台周期:

  1. 提供接入 SDK,可根据实际厂商接入情况作为 Demo 写代码。
  2. 与支持 MQTT 协议指令的通讯模组厂商合作,以原生支持物联网平台的接入,并通过简易的 AT 指令方式提供给厂商调用,省去厂商需要理解通讯协议的麻烦,从而提高接入速度。

稳定性

平台各个模块采用全分布式结构,无单点问题。SLA 保障消息 99.99% 的可用及 99.99% 服务稳定性。

消息延迟

全链路采用无阻塞结构,有消息则立即触发发送,即消息“即达即推送”。

多服务兼容

  1. 无缝对接存储服务,如 Fusion、Redis、Hbase、Hive、HDFS、Flink,后续产品持续开放中。
  2. 无缝对接基础服务,如坐标服务、直播/点播服务、AI 分析服务,更多服务对接中。

物联网是一种什么场景?

如上图各种物联网场景:地下停车场、高山电塔、拥挤的共享单车、共享汽车等等。总结几个特点:

  • 弱联网
  • 大量设备 24 小时在线
  • 实时控制
  • 通讯安全

平台架构

平台基础能力

维护设备与服务端的长连接;消息收发;保障与设备的安全通道;支持标准的 MQTT ( 同时兼容 v3.1 和 v3.1.1 两个版本 ) 以及 JT808 协议。

作为交通运输的大平台,我们更注重车联网的各种接入环境,目前很多车载、汽车、交通等相关设备的硬件产品以 JT808 协议为标准与服务端通讯。

对于传统设备厂商所面临得不熟悉车联网环境、不熟悉 MQTT 协议、现有的设备又已运行很多年验证了设备的稳定性、改造成本过大等各种问题,平台可提供 JT808 协议兼容存量设备的技术方案。

为什么选择 MQTT 协议?

  1. MQTT 基于订阅/发布模式,设备端可独立订阅一个 Topic 从而实现单点消息的发送实现点对点,如针对某辆共享汽车进行开锁。当设备量很多时可按组划分实现多对点,如同一型号共享汽车或同一批次发送自检指令可以“批次标识”作为 Topic 订阅,则针对该批次进行发一条消息实现批量控制。
  2. MQTT 协议流量小。头部字节以 bit 位为单位标记功能,且附加头信息字段作为可变头信息里,只有需要时才会占用字节以及 2 个字节的心跳等,协议主观设计上极大精简包的大小。
  3. MQTT 协议天然支持在公网下的弱网环境处理,比如网络延迟、掉线时的消息质量保障、1.5 倍的心跳保活机制等。

消息如何得到保障?

借助 MQTT 协议自带消息质量 ( QOS ) 的协议定义,平台暂支持 Qos=0、1 两个等级。

Qos=0: 最多一个消息送达,可能一条消息都没送达

Client CMD Server
存储消息 —-Publish—-> 发送给后端

Qos=1: 至少一条消息送达,可能会送达多条重复消息

Client CMD Server
存储消息 —-Publish—-> 1.持久存储消息;2.发送给后端;3.删除消息
丢弃消息 <—-PubAck—-

Qos 逻辑同时适用于上行/下行消息,Qos=0 时也会尽力将消息发送给对方,仅当发送消息时突然掉线才会丢失,若消息发送之前设备不在线则先存储起来,设备上线时发送下去。

Qos=1 时同样试用,优先持久化存储,再发送给设备,等待 PubAck 包,若超时 5 秒没收到则继续下发,直到收到 PubAck 报文。

如何保障通讯安全?

安全级别分为两级:

  1. 纯 TCP 链接,适用于计算能力较差,数据并非重要的场景,如隐藏式 GPS、阀门检测器等小型产品,本身体积较小、电量较低、功耗低不适于做过多计算。
  2. 带 TLS 链接,适用于有一定计算能力的设备,且数据保密性要求高的场景,如共享汽车车控、行车记录仪等,汽车开锁、熄火、行车记录仪录像传输等都是需要强力的安全控制及保密。

平台支持设备端、服务端双向鉴权。设备端鉴权服务端采用 SSL 证书,通过 TLS 链接加密传输。服务端鉴权设备端通过设备携带 username、password 校验。

平台会为每一个设备生成独立的 DeviceSecret,通过 HMAC-SHA1 签名算法得到密码。为保障密码随机性,签名内容包含设备的唯一 DeviceName 以及用户自定义的唯一 CientId。

但只有这两个条件签名还不够,因为签名的内容为固定内容总有一天会泄露出去,泄露后就相当于给了别人一张永久的通行证。因此需要再在设备里加一个随机码使签名得到的密码每次都不一样,我们这里采用时间戳 ( timestamp ) 作为随机码,通过该时间戳服务端可以拦截过早时间的密码,如只允许一天内的有效密码可以授权通过。

流媒体服务

物联网平台提供基础的视频直播/点播能力,结构图如下:

视频编码传输裸流到 Connsvr 并经过推流服务器处理(如需要转码则进行转码,不需要则透传),一方面进行实时推流起到直播作用,一方面存储到存储服务起到录制作用。

在该结构中直播流是在播放时才进行转码而非写入时转码,因此适用于传输量大,但播放量少的场景,例如:有大量设备在给服务端上报音视频数据,播放端监控调用指定的设备实时画面,以及查看历史画面。

推流服务器可支持 RTMP、HTTP 两种拉流方式。

配置中心

在许多应用场景中,开发者需要更新设备的配置信息,包括设备的系统参数、网络参数等等。一般情况下更新设备的配置信息是通过固件升级的方式完成的,但这将加大固件版本的维护成本,并且需要设备中断运行以完成更新。

为了解决以上问题,物联网平台提供了配置中心以解决远程配置更新的问题,设备无需重启或中断运行即可在线完成配置信息的更新。

OTA

设备固件升级又称 OTA,是物联网通信服务的重要组成部分。当物联设备有新功能或者需要修复漏洞时,设备可以通过 OTA 服务快速的进行固件升级。

在实际的物联网应用场景中,一般会部署百万、千万甚至亿级别的物联网设备。这些设备部署到生产系统后,如何安全管理设备,例如如何远程升级设备这些常见操作会成为一个难题。

物联网设备往往没有屏幕,也没有工作人员在设备前进行手动管理。升级操作如何触发?升级失败后如何回滚,并上报升级状态?

针对这种场景需要提前设计一套 OTA 管理系统,自动进行设备管理。通过 OTA 管理系统,可以监控设备,快速查找设备,排查设备功能故障,远程更新设备固件,远程重新启动、修复以及将设备恢复到出厂设置,大大降低管理大量物联网设备的成本和工作量。

物模型

车辆越来越普及,越来越多人喜欢在车内安装各种设备,娱乐设备、安全设备、车控设备、监控设备等等,这些设备零散安装在车里各有各的功能作用,对于用户管理是个麻烦的事情,因此平台抽象出来一个“物模型”概念,目的是把一辆车里的所有设备抽象成一个“物”,将设备的功能作为“物”的一项功能或属性。

车载安装时设备作为车的一个组件加入到“物模型”里。如下图:

通过物模型,管理端只需要指定“物名称”( 例子中的车牌号 ) 进行诸如获取 GPS、油量、电量、行车记录视频以及对车的开锁、关锁、关车窗控制等。至于在车里面是什么设备上报的信息并不需要关心。管理交互如下:

物模型有个特性:当用户想给设备端发送一个状态改变消息时,有可能这个设备不在线,下行消息无法下发给设备,此时物模型会记录状态等待设备上线下发下去,对于用户来说只需要知道消息是否送达以及当前的最新状态。即使设备不在线,设备所有上报的状态也可通过物模型查询。在弱网环境下这样有个好处,当查询设备状态时,并不需要实质设备在线也可查询到近期的状态。

数据交通 ( DTS )

DTS 作为网关与后端存储和基础服务的数据传输中间件,基于 DDMQ 实现数据配置化的多线路的分发,把同一份数据无缝对接到不同存储及后端服务支持业务处理。

数据交通支持简易的数据处理:

  1. 依据关键词过滤。
  2. 消息格式化,实现到后端的协议统一或者定制。
  3. 写入限速,保护后端负载等。

总结

滴滴物联网平台的架构考虑从设备端到接入层再到后端数据 + 服务一站式打通,结合各个基础服务能力一起打造车联、交通领域的方案输出,为业务快速的接入以及稳定性的保障打基础,同时未来在后端连接更多的服务生态,提供丰富的业务形态支持。

本文作者:刘丁

您的留言将激励我们越做越好

用户评论(1)

  1. 185*****181

    太厉害了。。。受益匪浅呀。