APP車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)設計與實現(xiàn)

摘要：隨著用戶對車聯(lián)網(wǎng)體驗要求的提高，APP 車聯(lián)網(wǎng)功能使用已成為很多車主的剛需。當其出現(xiàn)故障影響用戶使用時，會立即收到用戶大量投訴，降低用戶滿意度，因此需要搭建APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)。本文通過對當前業(yè)務存在的故障發(fā)現(xiàn)晚、故障排查慢、被動接受故障以及海量數(shù)據(jù)查詢慢等問題進行分析，針對性提出了故障實時監(jiān)控、及時預警、主動發(fā)現(xiàn)及大數(shù)據(jù)處理的系統(tǒng)設計與實現(xiàn)方法。經(jīng)過系統(tǒng)測試和業(yè)務實踐表明，該故障監(jiān)控系統(tǒng)的設計與實現(xiàn)能有效解決業(yè)務問題，實現(xiàn)了故障實時監(jiān)控預警，主動發(fā)現(xiàn)故障前兆并避免約50% 的批量故障發(fā)生。

關鍵詞：APP ；車聯(lián)網(wǎng)；故障監(jiān)控；大數(shù)據(jù)；報錯

中圖分類號： TP39 文獻標識碼：A

0 引言

近年來，隨著汽車電子技術的進步與發(fā)展，汽車的車載計算機處理器功能越來越強。許多車輛目前已經(jīng)具備強大的線下計算能力，以處理包括車輛控制、感知計算等各類業(yè)務[1]。而搭載車聯(lián)網(wǎng)功能的汽車日益增多，也使得用戶對車聯(lián)網(wǎng)的體驗要求也越來越高，APP 車聯(lián)網(wǎng)功能的使用已成為部分車主的剛需。如車主通過APP 遠程查看車輛位置、里程、電量和油量等，甚至使用遠程控制打開空調(diào)降溫、打開車窗透氣或者遙控開閉門鎖、起動車輛等用車強相關功能。

當APP 車聯(lián)網(wǎng)功能的用戶數(shù)量已經(jīng)達到了相當規(guī)模，該功能一旦出現(xiàn)故障，勢必會影響用戶的體驗，甚至會降低用戶的滿意度。因此，為了保障APP 車聯(lián)網(wǎng)功能穩(wěn)定運行，減少用戶投訴，給用戶持續(xù)帶來愉悅的APP 端用車體驗，需要搭建APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)，以便及時定位到故障，提前做好系統(tǒng)應對措施，減少故障發(fā)生率。

2 需求分析

2.1 APP 車聯(lián)網(wǎng)功能及團隊構成現(xiàn)狀

當前車聯(lián)網(wǎng)使用“云——管——端”的架構?！霸啤笔窃品?，包括云計算和大數(shù)據(jù)，它能夠基于收集到的大量數(shù)據(jù)實時進行智能處理和協(xié)同規(guī)劃，進而開展隊列控制等操作?！岸恕笔侵钢悄芙K端，包括汽車、手機（代表行人）和路側(cè)單元等各種交通參與實體，也是執(zhí)行云端指令的實體。而“管”則是連接“云”和“端”之間的各種管道，包括上、下行通信管道和直通管道，它將各種交通實體連接起來，并保證數(shù)據(jù)交互的順暢[2]。

用戶使用的手機APP 車聯(lián)網(wǎng)功能是車聯(lián)網(wǎng)的重要組成部分，涉及了“云——管——端”，主要包括登錄APP、綁定車輛、查看車輛狀態(tài)（位置、里程、電量和油量等）、遠程控制車輛解閉鎖（開關空調(diào)、開關窗或開關車燈）以及藍牙鑰匙連接（圖1）。要保障APP 車聯(lián)網(wǎng)功能穩(wěn)定運行，其實就是要保證以上功能持續(xù)正常使用。若不可避免會出現(xiàn)個別問題，也應該用盡可能短的時間排查并修復。

2.2 APP 車聯(lián)網(wǎng)功能故障排查難點

當前，APP 車聯(lián)網(wǎng)功能故障排查和修復業(yè)務存在以下問題。

（1）發(fā)生批量故障無法第一時間知曉，滯后于用戶投訴時間。同一時間段多個用戶投訴同一個問題，才知道APP 車聯(lián)網(wǎng)功能失效。

（2）收到用戶投訴后，問題定位慢。需要先聯(lián)系用戶上傳日志，然后開發(fā)人員再基于日志報錯對應時間分析問題，無法立即知道是哪個系統(tǒng)鏈路環(huán)節(jié)異常導致。

（3）無法提前發(fā)現(xiàn)批量故障征兆，每次都得等批量故障發(fā)生后才知曉。

（4）APP 車聯(lián)網(wǎng)功能接口調(diào)用記錄數(shù)每日增量＞ 1 000 萬條，直接存儲于mysql 數(shù)據(jù)庫中。隨著存儲數(shù)據(jù)量逐漸增大后，查詢效率變得很慢。

2.3 APP 車聯(lián)網(wǎng)功能故障解決方案

針對APP 車聯(lián)網(wǎng)功能故障排查難等問題，項目團隊提出如下解決方案。

（1）監(jiān)控APP 車聯(lián)網(wǎng)功能接口調(diào)用報錯次數(shù)。對每天的接口報錯次數(shù)排名，優(yōu)先解決報錯次數(shù)多的接口。當同一接口報錯次數(shù)≥ 10 輛車/min，通過郵件方式通知系統(tǒng)負責人。

（2）APP 車聯(lián)網(wǎng)功能接口調(diào)用報錯，實現(xiàn)可視化報表呈現(xiàn)。當收到用戶投訴APP 車聯(lián)功能不可用時，業(yè)務人員可登錄到系統(tǒng)后臺，直觀查看到接口報錯系統(tǒng)開發(fā)方，同時可進一步查看報錯詳情。因此，無需再聯(lián)系用戶上傳日志就能快速定位問題點。

（3）監(jiān)控APP 車聯(lián)網(wǎng)功能接口報錯趨勢。當一個接口調(diào)用報錯次數(shù)在某個時間段呈逐漸增長或者突增趨勢時，及時分析原因并解決，提前避免批量故障發(fā)生。

（4）引入大數(shù)據(jù)平臺提升數(shù)據(jù)處理能力和查詢效率，以保障隨著數(shù)據(jù)量持續(xù)增長至億級數(shù)據(jù)記錄數(shù)，仍能實現(xiàn)10 s 內(nèi)查詢出數(shù)據(jù)結果。

2.4 APP 車聯(lián)網(wǎng)功能故障解決技術方案

經(jīng)調(diào)研分析，項目團隊決定選用了Kafka（一種分布式的發(fā)布、訂閱消息系統(tǒng)） 接收來自APP 的云數(shù)據(jù)， 并對接StructuredStreaming 和StreamSets。這是因為Kafka 目前已經(jīng)定位為一個分布式流式處理平臺，它以高吞吐、可持久化、可水平擴展以及支持流數(shù)據(jù)處理等多種特性而被廣泛使用。越來越多的開源分布式處理系統(tǒng)，如Cloudera、Storm、Spark 和Flink 等，都支持與Kafka 集成[3]。

Apache Hadoop 是目前業(yè)界分析海量數(shù)據(jù)的首選工具[4]，因此，項目團隊選用Hadoop 分布式系統(tǒng)技術方案解決海量數(shù)據(jù)查詢慢問題。Hadoop 是以Hadoop 分布式文件系統(tǒng)（HadoopDistributed File System， 簡稱HDFS） 和MapReduce 分布式計算框架為核心，為用戶提供底層細節(jié)透明的分布式基礎設施。HDFS 具有高容錯性和高伸縮性等優(yōu)點，允許用戶將Hadoop 部署在廉價的硬件上，構建分布式系統(tǒng)。MapReduce 分布式計算框架則允許用戶在不了解分布式系統(tǒng)底層細節(jié)的情況下，開發(fā)并行、分布的應用程序，充分利用大規(guī)模的計算資源，解決傳統(tǒng)高性能單機無法解決的大數(shù)據(jù)處理問題。

項目團隊還選用FineBI 作為可視化編輯工具，供業(yè)務人員使用。這是因為FineBI 支持超過30 種以上的大數(shù)據(jù)平臺和SQL數(shù)據(jù)源， 包括Hadoop Hive、SPARK、Presto、Oracle、DB2、MySQL、SQLServer 和MongoDB 等，能滿足該系統(tǒng)的數(shù)據(jù)源對接需求。同時，F(xiàn)ineBI 的可視化功能面向業(yè)務人員設計，解構了制作可視化分析的流程，可以自定義配置可視化圖表，如常見的柱形圖、餅圖和折線圖等，輔以顏色、大小、提示和標簽，可以組合成豐富的可視化效果，降低業(yè)務人員制作分析的難度。

監(jiān)控系統(tǒng)不僅要有故障報錯數(shù)據(jù)呈現(xiàn)，更重要的功能是告警和故障處理，這對及時解決問題和故障自愈非常重要[5]。因此，項目團隊選用了郵件服務方式作為告警通知提醒，郵件綁定微信后，可以實現(xiàn)微信通知。

3 系統(tǒng)設計與實現(xiàn)

3.1 功能設計

根據(jù)需求分析結果，用戶需要主動登錄系統(tǒng)查看監(jiān)控數(shù)據(jù)用于發(fā)現(xiàn)問題，同時能夠被動收到故障告警通知提醒。因此，將APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)功能分為登錄、監(jiān)控和預警3 個主要模塊，包括賬號密碼登錄、車聯(lián)網(wǎng)接口調(diào)用明細、車聯(lián)網(wǎng)接口報錯次數(shù)- 接口排名、車聯(lián)網(wǎng)接口報錯次數(shù)- 系統(tǒng)開發(fā)方排名、車聯(lián)網(wǎng)接口報錯趨勢以及車聯(lián)網(wǎng)接口報錯告警等功能（圖2）。

3.2 數(shù)據(jù)設計

APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)在可視化呈現(xiàn)方面，使用了第三方數(shù)據(jù)分析工具FinelBI，因此在數(shù)據(jù)設計方面，可以根據(jù)APP車聯(lián)網(wǎng)問題排查及監(jiān)控預警的數(shù)據(jù)字段需要，重點關注車聯(lián)網(wǎng)接口調(diào)用明細的數(shù)據(jù)表。數(shù)據(jù)表內(nèi)容包括用戶ID、用戶手機號、車架號、系統(tǒng)平臺、設備型號、系統(tǒng)版本、APP 版本、調(diào)用系統(tǒng)渠道、車型名單、車系名稱、事件名稱、事件頁面、事件位置、接口名稱、接口地址、接口調(diào)用時間、報錯信息、操作結果以及操作參數(shù)等字段，具體表結構設計如圖3 所示。

3.3 軟件設計與實現(xiàn)

3.3.1 數(shù)據(jù)處理方案分析APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)的難點在于億級數(shù)據(jù)的統(tǒng)計分析處理，其數(shù)據(jù)處理方案考慮從2 個方面做調(diào)研分析。一方面是選擇沿用當前APP 云微服務的MySQL 數(shù)據(jù)庫，該方案系統(tǒng)改動最小，成本最低，但需評估數(shù)據(jù)處理效率是否能滿足業(yè)務需求。另一方面是接入Hadoop 大數(shù)據(jù)平臺，該方案能保證大數(shù)據(jù)處理效率，但系統(tǒng)改動較大，成本更高。

不過調(diào)研發(fā)現(xiàn)，選擇MySQL 數(shù)據(jù)庫做數(shù)據(jù)統(tǒng)計分析處理，當數(shù)據(jù)小于1 000 萬條時，數(shù)據(jù)查詢耗時能保持10 s 以內(nèi)，可滿足業(yè)務需求；但隨著查詢數(shù)據(jù)量超過10 億條時，查詢耗時超過60 s，甚至出現(xiàn)報錯，無法滿足業(yè)務需求。而選擇Hadoop 大數(shù)據(jù)平臺在處理超過10 億條數(shù)據(jù)統(tǒng)計時，查詢耗時小于10 s，可滿足業(yè)務需求。從公司未來大數(shù)據(jù)發(fā)展角度出發(fā)，也需要一個大數(shù)據(jù)平臺用于存儲和處理公司所有系統(tǒng)產(chǎn)生的大數(shù)據(jù)。綜合以上分析，確定了選擇Hadoop 大數(shù)據(jù)平臺作為APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)數(shù)據(jù)處理方案。

3.3.2 系統(tǒng)鏈路分析

APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)鏈路涉及APP 客戶端、APP云、大數(shù)據(jù)平臺和APP 車聯(lián)網(wǎng)功能故障監(jiān)控預警系統(tǒng)。當用戶登錄APP 綁車、查看車輛狀態(tài)、遠程控制車輛以及連接藍牙鑰匙時，會調(diào)用相應功能的系統(tǒng)接口。此時APP 客戶端會產(chǎn)生一條接口調(diào)用數(shù)據(jù)記錄，并上傳至APP 云，再由APP 云將數(shù)據(jù)轉(zhuǎn)發(fā)至大數(shù)據(jù)平臺。最后APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)訪問大數(shù)據(jù)平臺的數(shù)據(jù)集，實現(xiàn)可視化監(jiān)控報表呈現(xiàn)和郵件告警（圖4）。

APP 客戶端：當用戶有登錄APP、綁車、查看車輛狀態(tài)、遠程控制車輛以及藍牙鑰匙連接等操作時，APP 客戶端調(diào)用APP 云端提供的車聯(lián)網(wǎng)功能接口調(diào)用明細API，傳入用戶ID、手機號、車架號、系統(tǒng)平臺、設備型號、系統(tǒng)版本、APP 版本、調(diào)用系統(tǒng)渠道、車型名稱、車系名稱、事件名稱、事件頁面、事件位置、接口名稱、接口地址、接口調(diào)用時間、報錯信息、操作參數(shù)、操作結果以及狀態(tài)（成功傳1，失敗傳0）。

APP 云：收到APP 客戶端車聯(lián)網(wǎng)功能接口調(diào)用明細的API請求時，APP 云端通過nginx 代理服務器進行負載均衡，經(jīng)過網(wǎng)關服務轉(zhuǎn)發(fā)至車聯(lián)網(wǎng)功能微服務，最后將數(shù)據(jù)轉(zhuǎn)發(fā)至大數(shù)據(jù)平臺。大數(shù)據(jù)平臺：大數(shù)據(jù)平臺通過Kafka 接收來自APP 云的數(shù)據(jù)，用StreamSets 實時采集Kafka 數(shù)據(jù)，并寫入HDFS。

APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)：系統(tǒng)基于HDFS 分布式存儲和Presto 分布式SQL 查詢的大數(shù)據(jù)處理平臺，通過FinelBI 對數(shù)據(jù)進行靈活編輯并可視化呈現(xiàn)，實現(xiàn)批量故障監(jiān)控可視化報表。最終通過StructuredStreaming 實時流式處理，調(diào)用公有云郵件服務實現(xiàn)告警通知（圖5）。

3.4 硬件設計與實現(xiàn)

根據(jù)上述分析，APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)的硬件由承載APP 客戶端的移動終端（如手機或平板電腦）、APP 云服務器集群以及大數(shù)據(jù)平臺服務器集群組成（圖6）。當前具有APP 車聯(lián)網(wǎng)功能版塊服務的網(wǎng)聯(lián)車已超過100 萬輛，車聯(lián)網(wǎng)相關功能接口每天調(diào)用次數(shù)超過3 400 萬次，每月調(diào)用超過10 億次。那么APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)的硬件如何設計，才能更好地支撐業(yè)務開展。

3.4.1 移動端

由于當前車主用戶大部分使用的是蘋果、華為、小米、VIVO以及OPPO 手機，因此APP 客戶端要求支持Android 和iOS 操作系統(tǒng)的手機及平板安裝使用。

3.4.2 APP 云

APP 云主要面向用戶承接流量，為了保證用車高峰期用戶也都能訪問APP 云，同時兼顧業(yè)務高可用，避免單臺服務器異常導致業(yè)務中斷，因此該系統(tǒng)一共選用了12 臺服務器。其中，4 臺服務器搭建nginx 集群，用于負載均衡；4 臺服務器搭建網(wǎng)關服務器集群，用于微服務業(yè)務轉(zhuǎn)發(fā)；還有4 臺服務器搭建微服務器集群，用于基礎功能微服務、車聯(lián)網(wǎng)微服務、電商微服務以及內(nèi)容微服務業(yè)務處理。由于該APP 云不涉及大量數(shù)據(jù)讀寫，因此選擇了性價比較高的4 核CPU、16G 內(nèi)存、普通IO 磁盤和linux 操作系統(tǒng)的服務器。

3.4.3 大數(shù)據(jù)平臺

Kafka 服務器主要用于接收來自APP 云的接口調(diào)用數(shù)據(jù)并進行轉(zhuǎn)發(fā)。該業(yè)務出現(xiàn)中斷不影響用戶端業(yè)務運行，且不涉及大數(shù)據(jù)計算，因此選用1 臺4 核CPU、8G 內(nèi)存、普通IO 磁盤和linux 操作系統(tǒng)的服務器即可。StreamSets 服務器用于采集Kafka 數(shù)據(jù)寫入HDFS，也不涉及大數(shù)據(jù)計算，因此選用與Kafka相同配置的服務器即可。

由于HDFS+YARN+Presto 涉及大量數(shù)據(jù)存儲和計算處理，除了車聯(lián)網(wǎng)數(shù)據(jù)還包含公司其他業(yè)務系統(tǒng)大數(shù)據(jù)存儲與計算服務。為保證其穩(wěn)定性和高效的數(shù)據(jù)處理能力，需要大內(nèi)存和高IO硬件投入。因此，選用了1 個主節(jié)點和20 個工作節(jié)點的架構方案，

4 系統(tǒng)測試與結果

為了驗證系統(tǒng)登錄、監(jiān)控和告警模塊功能有效性，在測試環(huán)境開通測試賬號登錄系統(tǒng)，使用APP 測試。綁定測試車輛并查看車輛狀態(tài)，執(zhí)行遠程控制車輛和藍牙鑰匙連接操作。再關閉測試環(huán)境查看車輛狀態(tài)接口，并在1 min 內(nèi)查看10 輛車的狀態(tài)。結果是測試賬號成功登錄系統(tǒng)，能正常查看到車輛的APP 車聯(lián)網(wǎng)功能調(diào)用明細和可視化報表（圖8）。當同一接口報錯次數(shù)≥ 10 輛車/min 時，能正常收到了告警郵件通知（圖9）。該功能在實際生產(chǎn)環(huán)境中可以屏蔽數(shù)據(jù)回傳延遲和高峰消息阻塞的影響，通過具體事件發(fā)生時間統(tǒng)計出該時間窗口內(nèi)有多少車輛調(diào)用報錯，而不是將當前時間回傳數(shù)據(jù)都算在當前時間窗口內(nèi)，避免了用戶訪問高峰期產(chǎn)生的誤差問題，從而實現(xiàn)精準報警。由于大數(shù)據(jù)平臺億級數(shù)據(jù)查詢效率在測試環(huán)境模擬測試成本過高，因此未在測試環(huán)境驗證查詢效率，直接到生產(chǎn)驗證。系統(tǒng)上生產(chǎn)環(huán)境運行1 個月，產(chǎn)生數(shù)據(jù)大于10 億條，數(shù)據(jù)量達到3.2T，查詢結果并成功展示小于10 s（圖10）。

實踐表明，該系統(tǒng)設計與實現(xiàn)能讓系統(tǒng)運維人員快速定位排查問題，第一時間收到告警通知，并基于接口報錯趨勢分析提前做出系統(tǒng)優(yōu)化措施，減少50% 批量故障發(fā)生。同時，隨著數(shù)據(jù)量增大，依然能保持數(shù)據(jù)報表在10 s 內(nèi)查詢到結果，80% 查詢結果小于5 s。

5 結束語

本文基于APP 車聯(lián)網(wǎng)功能故障的需求分析，發(fā)現(xiàn)業(yè)務問題并提出系統(tǒng)解決方案。通過APP 車聯(lián)網(wǎng)功能故障監(jiān)控系統(tǒng)的設計與實現(xiàn)，能夠?qū)PP 車聯(lián)網(wǎng)功能故障進行有效的監(jiān)控和告警通知，面對億級數(shù)據(jù)處理時仍能保持高效查詢效率，避免了50% 批量故障發(fā)生。但在可視化報表跨月查詢時發(fā)現(xiàn)，耗時是當月查詢的2～3 倍，下一步將繼續(xù)研究報表跨月查詢效率提升的方法。

【參考文獻】

[1] 李儼， 曹一卿， 陳書平， 等. 5G 與車聯(lián)網(wǎng)：基于移動通信的車聯(lián)網(wǎng)技術與智能網(wǎng)聯(lián)汽車[M]. 北京： 電子工業(yè)出版社，2019.

[2] 王平， 王超， 劉富強， 等. 車聯(lián)網(wǎng)權威指南： 標準、技術及應用[M]. 北京：機械工業(yè)出版社，2018.

[3] 朱忠華. 深入理解Kafka ：核心設計與實踐原理[M]. 北京： 電子工業(yè)出版社，2019.

[4] 蔡斌， 陳湘萍. Hadoop 技術內(nèi)幕：深入解析Hadoop Common 和HDFS 架構設計與實現(xiàn)原理[M]. 北京： 機械工業(yè)出版社，2013.

[5] 吳兆松.Zabbix 企業(yè)級分布式監(jiān)控系統(tǒng)[M]. 電子工業(yè)出版社，2014.

作者簡介：

覃天威，本科，工程師，研究方向為汽車類相關APP 系統(tǒng)設計與開發(fā)。