滴滴物联网下的基础架构

最新推荐文章于 2023-07-19 09:30:28 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2023-07-19 09:30:28 发布

阅读量357

点赞数

本文链接：https://blog.csdn.net/cpongo4/article/details/89123351

版权

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

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

01特性

安全的通讯链路

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

快速接入

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

1）提供接入SDK，可根据实际厂商接入情况作为Demo写代码。

2）与支持MQTT协议指令的通讯模组厂商合作，以原生支持物联网平台的接入，并通过简易的AT指令方式提供给厂商调用，省去厂商需要理解通讯协议的麻烦，从而提高接入速度。

稳定性

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

消息延迟

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

多服务兼容

无缝对接存储服务，如Fusion、Redis、Hbase、Hive、HDFS、Flink，后续产品持续开放中。

无缝对接基础服务，如坐标服务、直播/点播服务、AI分析服务，更多服务对接中。

02物联网是一种什么场景?

$\"image\"$

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

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

03平台架构

$\"image\"$

04平台基础能力

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

作为交通运输的大平台，我们更注重车联网的各种接入环境，目前很多车载、汽车、交通等相关设备的硬件产品以JT808协议为标准与服务端通讯。传统设备厂商面临不熟悉车联网环境，不熟悉MQTT协议，现有的设备又已运行很多年验证了设备的稳定性，改造成本过大的各种问题，平台可提供JT808协议兼容存量设备的技术方案。

为什么选择MQTT协议?

1）MQTT基于订阅/发布模式，设备端可独立订阅一个Topic从而实现单点消息的发送实现点对点，如针对某辆共享汽车进行开锁。当设备量很多时可按组划分实现多对点，如同一型号共享汽车或同一批次发送自检指令可以“批次标识”作为Topic订阅，则针对该批次进行发一条消息实现批量控制。

$\"image\"$
2）MQTT协议流量小。头部字节以bit位为单位标记功能，且附加头信息字段作为可变头信息里，只有需要时才会占用字节，以及2个字节的心跳等，协议主观设计上极大精简包的大小。

3）MQTT协议天然支持在公网下的弱网环境处理，比如网络延迟、掉线时的消息质量保障、1.5倍的心跳保活机制等。

消息如何得到保障？

$\"image\"$

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

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

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

如何保障通讯安全?

安全级别分为两级：

1）纯TCP链接，适用于计算能力较差，数据并非重要的场景，如隐藏式GPS、阀门检测器等小型产品，本身体积较小、电量较低、功耗低不适于做过多计算。

2）带TLS链接，适用于有一定计算能力的设备，且数据保密性要求高的场景，如共享汽车车控、行车记录仪等，汽车开锁、熄火、行车记录仪录像传输等都是需要强力的安全控制及保密。

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

//password签名算法

hmacsha1(deviceSecret, “clientId+deviceName+productKey+timestamp”)

平台会为每一个设备生成独立的deviceSecret，通过hmacsha1签名算法得到密码。为保障密码随机性，签名内容包含设备的唯一deviceName以及用户自定义的唯一clientId，但只对这两个条件签名还不够，因为签名的内容为固定内容总有一天会泄露出去，当泄露后将是一个永久有效的密码，就像给了别人一张永久的通行证。因此需要再在设备里加一个随机码使签名得到的密码每次都会变，我们这里采用时间戳(timestamp)作为随机码，通过该时间戳服务端可以通过时间戳拦截过早时间的密码，如只允许一天内的有效密码可以授权通过。

05流媒体服务

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

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

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

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

06配置中心

在许多应用场景中，开发者需要更新设备的配置信息，包括设备的系统参数、网络参数等等。一般情况下更新设备的配置信息是通过固件升级的方式完成的，但这将加大固件版本的维护成本，并且需要设备中断运行以完成更新。为了解决以上问题，物联网平台提供了配置中心以解决远程配置更新的问题，设备无需重启或中断运行即可在线完成配置信息的更新。

$\"image\"$

07OTA

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

在实际的物联网应用场景中，一般会部署百万、千万甚至亿级别的物联网设备。这些设备部署到生产系统后，如何安全管理设备，例如远程升级设备这些常见操作，会成为一个难题。物联网设备往往没有屏幕，也没有工作人员在设备前进行手动管理。升级操作如何触发？升级失败后如何回滚，并上报升级状态？这种场景需要提前设计一套OTA管理系统，自动化进行设备管理。通过OTA管理系统，可以监控设备，快速查找设备，排查设备功能故障，远程更新设备固件，远程重新启动、修复以及将设备恢复到出厂设置，大大降低管理大量物联网设备的成本和工作量。

$\"image\"$

物模型

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

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

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