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

覃天威 張劍亮 胡俊威 劉嵩巖 李思江

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

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

中圖分類號： TP39 文獻(xiàn)標(biāo)識碼：A

0 引言

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

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

2 需求分析

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

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

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

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

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

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

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

（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)功能故障排查難等問題，項(xiàng)目團(tuán)隊(duì)提出如下解決方案。

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

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

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

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

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

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

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

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

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

3 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

3.1 功能設(shè)計(jì)

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

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

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

3.3 軟件設(shè)計(jì)與實(shí)現(xiàn)

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

不過調(diào)研發(fā)現(xiàn)，選擇MySQL 數(shù)據(jù)庫做數(shù)據(jù)統(tǒng)計(jì)分析處理，當(dāng)數(shù)據(jù)小于1 000 萬條時(shí)，數(shù)據(jù)查詢耗時(shí)能保持10 s 以內(nèi)，可滿足業(yè)務(wù)需求；但隨著查詢數(shù)據(jù)量超過10 億條時(shí)，查詢耗時(shí)超過60 s，甚至出現(xiàn)報(bào)錯(cuò)，無法滿足業(yè)務(wù)需求。而選擇Hadoop 大數(shù)據(jù)平臺在處理超過10 億條數(shù)據(jù)統(tǒng)計(jì)時(shí)，查詢耗時(shí)小于10 s，可滿足業(yè)務(wù)需求。從公司未來大數(shù)據(jù)發(fā)展角度出發(fā)，也需要一個(gè)大數(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)控預(yù)警系統(tǒng)。當(dāng)用戶登錄APP 綁車、查看車輛狀態(tài)、遠(yuǎn)程控制車輛以及連接藍(lán)牙鑰匙時(shí)，會調(diào)用相應(yīng)功能的系統(tǒng)接口。此時(shí)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ù)集，實(shí)現(xiàn)可視化監(jiān)控報(bào)表呈現(xiàn)和郵件告警（圖4）。

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

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

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

3.4 硬件設(shè)計(jì)與實(shí)現(xiàn)

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

3.4.1 移動端

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

3.4.2 APP 云

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

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

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

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

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

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

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

5 結(jié)束語

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

【參考文獻(xiàn)】

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

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

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

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

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

作者簡介：

覃天威，本科，工程師，研究方向?yàn)槠囶愊嚓P(guān)APP 系統(tǒng)設(shè)計(jì)與開發(fā)。