滴滴物聯網下的基礎架構
隨著物聯網的蓬勃發展，萬物互聯已經不是新概念，滴滴物聯網平臺致力於車聯網及交通相關領域，為各類場景提供物聯網解決方案及基礎服務。
平臺服務支援包括裝置的快速物聯網化、裝置管理、資料交通、直播 / 點播、地圖服務、儲存服務等能力。解決方案諸如車輛監控、運營管理、交通周邊管理、交通運輸安全、資料分析等。
01 特性
安全的通訊鏈路
採用分級的安全模式，裝置廠商可根據裝置計算能力選擇，提供裝置鑑權以及鏈路加密方式，保障資料不被篡改。
快速接入
針對裝置端提供兩種接入方案加速縮短裝置廠商接入平臺週期：
1）提供接入 SDK，可根據實際廠商接入情況作為 Demo 寫程式碼。
2）與支援 MQTT 協議指令的通訊模組廠商合作，以原生支援物聯網平臺的接入，並通過簡易的 AT 指令方式提供給廠商呼叫，省去廠商需要理解通訊協議的麻煩，從而提高接入速度。
穩定性
平臺各個模組採用全分散式結構，無單點問題。SLA 保障訊息 99.99% 的可用及 99.99% 服務穩定性。
訊息延遲
全鏈路採用無阻塞結構，有訊息則立即觸發傳送，即訊息“即達即推送”。
多服務相容
無縫對接儲存服務，如 Fusion、Redis、Hbase、Hive、HDFS、Flink，後續產品持續開放中。
無縫對接基礎服務，如座標服務、直播 / 點播服務、AI 分析服務，更多服務對接中。
02 物聯網是一種什麼場景?
如上圖各種物聯網場景：地下停車場、高山電塔、擁擠的共享單車、共享汽車等等。總結幾個特點：
-
弱聯網
-
大量裝置 24 小時線上
-
實時控制
-
通訊安全
03 平臺架構
04 平臺基礎能力
維護裝置與服務端的長連線，訊息收發，保障與裝置的安全通道。支援標準的 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 邏輯同時適用於上行 / 下行訊息，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 流媒體服務
物聯網平臺提供基礎的視訊直播 / 點播能力，結構圖如下：
視訊編碼傳輸裸流到 Connsvr 並經過推流伺服器處理（如需要轉碼則進行轉碼，不需要則透傳），一方面進行實時推流起到直播作用，一方面儲存到儲存服務起到錄製作用。
在該結構中直播流是在播放時才進行轉碼而非寫入時轉碼，因此適用於傳輸量大，但播放量少的場景，例如：有大量裝置在給服務端上報音視訊資料，播放端監控呼叫指定的裝置實時畫面，以及檢視歷史畫面。
推流伺服器可支援 RTMP、Http 兩種拉流方式。
06 配置中心
在許多應用場景中，開發者需要更新裝置的配置資訊，包括裝置的系統引數、網路引數等等。一般情況下更新裝置的配置資訊是通過韌體升級的方式完成的，但這將加大韌體版本的維護成本，並且需要裝置中斷執行以完成更新。為了解決以上問題，物聯網平臺提供了配置中心以解決遠端配置更新的問題，裝置無需重啟或中斷執行即可線上完成配置資訊的更新。
07OTA
裝置韌體升級又稱 OTA，是物聯網通訊服務的重要組成部分。當物聯裝置有新功能或者需要修復漏洞時，裝置可以通過 OTA 服務快速的進行韌體升級。
在實際的物聯網應用場景中，一般會部署百萬、千萬甚至億級別的物聯網裝置。這些裝置部署到生產系統後，如何安全管理裝置，例如遠端升級裝置這些常見操作，會成為一個難題。物聯網裝置往往沒有螢幕，也沒有工作人員在裝置前進行手動管理。升級操作如何觸發？升級失敗後如何回滾，並上報升級狀態？這種場景需要提前設計一套 OTA 管理系統，自動化進行裝置管理。通過 OTA 管理系統，可以監控裝置，快速查詢裝置，排查裝置功能故障，遠端更新裝置韌體，遠端重新啟動、修復以及將裝置恢復到出廠設定，大大降低管理大量物聯網裝置的成本和工作量。
物模型
車輛越來越普及，越來越多人喜歡在車內安裝各種裝置，娛樂的、安全的、車控的、監控的，這些車裝零散安裝在車裡各有各自的功能作用，對於使用者管理是個麻煩的事情，因此平臺抽象出來一個“物模型”概念，目的是把一輛車裡的所有裝置抽象成一個“物”，將裝置的功能作為“物”的一項功能或屬性。車載安裝時裝置作為車的一個元件加入到 " 物模型 " 裡。如下圖：
通過物模型，管理端只需要指定 " 物名稱 "(例子中的車牌號) 進行諸如獲取 GPS、油量、電量、行車記錄視訊以及對車的開鎖、關鎖、關車窗控制等。至於在車裡面是什麼裝置上報的資訊並不需要關心。管理互動如下：
物模型有個特性：當用戶想給裝置端傳送一個狀態改變訊息時，有可能這個裝置不線上，下行訊息無法下發給裝置，此時物模型會記錄狀態等待裝置上線下發下去，對於使用者來說只需要知道訊息是否送達，以及當前的最新狀態，裝置所有的上報的狀態也可通過物模型查詢，即使裝置不線上。在弱網環境下這樣有個好處，當查詢裝置狀態時，並不需要實質裝置線上也可查詢到近期的狀態。
08 資料交通 (DTS)
DTS 作為閘道器與後端儲存和基礎服務的資料傳輸中介軟體，基於 DDMQ 實現資料配置化的多線路的分發，把同一份資料無縫對接到不同儲存及後端服務支援業務處理。
資料交通支援簡易的資料處理：
1）依據關鍵詞過濾。
2）訊息格式化，實現到後端的協議統一或者定製。
3）寫入限速，保護後端負載等。
總結
滴滴物聯網平臺的架構考慮從裝置端到接入層再到後端資料 + 服務一站式打通，結合各個基礎服務能力一起打造車聯、交通領域的方案輸出，為業務快速的接入以及穩定性的保障打基礎，同時未來在後端連線更多的服務生態，提供豐富的業務形態支援。
轉載來自公眾號“滴滴技術”： https://mp.weixin.qq.com/s/BHdKQWtOuuE9DHEn3_TFwQ