簡(jiǎn)介：?在保持對(duì)業(yè)界趨勢(shì)調(diào)度關(guān)注的同時(shí)，始終選用最適合自身的技術(shù)，這可能是中瑞能在車聯(lián)網(wǎng)領(lǐng)域引領(lǐng)行業(yè)的重要原因之一，正如中瑞CTO所說“阿里云云原生產(chǎn)品體系帶給我們的，不是單純的IT工具，而是整個(gè)團(tuán)隊(duì)?wèi)?zhàn)斗力的提升”。

中瑞集團(tuán)成立于2011年，是一家青島本土的物聯(lián)網(wǎng)獨(dú)角獸企業(yè)。中瑞集團(tuán)致力于利用物聯(lián)網(wǎng)和人工智能技術(shù)，融合智慧交通、智慧城管、智慧出行、智慧物流、智慧風(fēng)控、智慧審計(jì)、智慧車險(xiǎn)、智慧校園、智慧零售等業(yè)務(wù)場(chǎng)景，為數(shù)萬(wàn)家政府和企業(yè)客戶提供資產(chǎn)數(shù)字化管理解決方案。自2015年以來，集團(tuán)業(yè)務(wù)營(yíng)收年均復(fù)合增長(zhǎng)率超過100%，2019年?duì)I收超過20億人民幣。中瑞集團(tuán)累計(jì)服務(wù)7000余家汽車經(jīng)銷商、200余家金融機(jī)構(gòu)、20多家知名出行機(jī)構(gòu)。2020年10月平臺(tái)累計(jì)在線車聯(lián)網(wǎng)終端設(shè)備超過678萬(wàn)臺(tái)，是全國(guó)車聯(lián)網(wǎng)在線終端規(guī)模No.1的應(yīng)用平臺(tái)。

商用車輛數(shù)字化管理是中瑞集團(tuán)的核心業(yè)務(wù)之一，在這個(gè)領(lǐng)域，中瑞集團(tuán)已聯(lián)動(dòng)包括整車廠、銀行、汽車金融機(jī)構(gòu)、保險(xiǎn)公司、基礎(chǔ)技術(shù)提供方等十?dāng)?shù)家機(jī)構(gòu)，形成以傳感器、人工智能算法、數(shù)據(jù)管理平臺(tái)為核心的整體解決方案，為客戶提供高度定制個(gè)性化服務(wù)，同時(shí)輔以汽車金融、保險(xiǎn)、標(biāo)準(zhǔn)制定、平臺(tái)運(yùn)營(yíng)等衍生功能板塊，業(yè)務(wù)能力涵蓋數(shù)字化管理項(xiàng)目設(shè)計(jì)、建設(shè)和運(yùn)營(yíng)的各個(gè)階段。

商用車輛數(shù)字化管理，通過車聯(lián)網(wǎng)技術(shù)連接大量終端裝備，實(shí)時(shí)收集并處理海量數(shù)據(jù)。智能車載傳感設(shè)備會(huì)根據(jù)不同行業(yè)屬性，如物流、出行、工程作業(yè)、農(nóng)業(yè)作業(yè)等，產(chǎn)生人、車、貨、設(shè)備等數(shù)據(jù)。中瑞集團(tuán)基于對(duì)車聯(lián)網(wǎng)行業(yè)實(shí)踐的深度積累，將物聯(lián)網(wǎng)與移動(dòng)互聯(lián)網(wǎng)技術(shù)相結(jié)合，依靠云計(jì)算、大數(shù)據(jù)等技術(shù)的支持，自主研發(fā)中瑞車聯(lián)云平臺(tái)。通過對(duì)在線運(yùn)營(yíng)車輛數(shù)據(jù)的收集、處理和分析，反饋到整車廠研發(fā)、設(shè)計(jì)、采購(gòu)、生產(chǎn)、銷售及售后各個(gè)環(huán)節(jié)，有效改善了整車設(shè)計(jì)水平，提升了零部件質(zhì)量，優(yōu)化了銷售策略，提高了售后實(shí)時(shí)性及準(zhǔn)確度。

車聯(lián)網(wǎng)智能設(shè)備實(shí)時(shí)上報(bào)的數(shù)據(jù)，會(huì)同步流轉(zhuǎn)到多個(gè)業(yè)務(wù)系統(tǒng)進(jìn)行處理，其中包括中瑞自建的在線業(yè)務(wù)平臺(tái)、離線分析平臺(tái)和實(shí)時(shí)計(jì)算平臺(tái)，還有一部分?jǐn)?shù)據(jù)會(huì)通過API的方式進(jìn)行透出，提供給裝備所屬機(jī)構(gòu)和政府監(jiān)管部門使用。中瑞集團(tuán)根據(jù)政府監(jiān)管政策要求，承建智慧城市出行平臺(tái)，通過部署車載聯(lián)網(wǎng)終端設(shè)備，匯集符合當(dāng)?shù)乇O(jiān)管要求和技術(shù)標(biāo)準(zhǔn)的車輛作業(yè)數(shù)據(jù)，上傳歸集至當(dāng)?shù)卣當(dāng)?shù)據(jù)中心，同時(shí)建立遵循國(guó)家標(biāo)準(zhǔn)的開放數(shù)據(jù)接口，提供給各部委調(diào)用。

對(duì)于中瑞的技術(shù)團(tuán)隊(duì)而言，每一條通過車聯(lián)網(wǎng)上報(bào)的數(shù)據(jù)都是非常珍貴的，其背后蘊(yùn)藏著巨大的業(yè)務(wù)價(jià)值。因此，在進(jìn)行系統(tǒng)架構(gòu)設(shè)計(jì)的時(shí)候，需要考慮到如下幾個(gè)重要的業(yè)務(wù)訴求：

1、 對(duì)于上報(bào)的數(shù)據(jù)，通過一個(gè)中間模塊進(jìn)行消息分發(fā)，交給不同的系統(tǒng)進(jìn)行處理，減少消息復(fù)制的成本。
2、 當(dāng)下游業(yè)務(wù)模塊的消息處理速度比較快的時(shí)候，要確保消息流轉(zhuǎn)的低時(shí)延。這個(gè)需求對(duì)于大多數(shù)在線業(yè)務(wù)場(chǎng)景都是非常重要的，比如當(dāng)車聯(lián)網(wǎng)用戶發(fā)起一個(gè)新的指令的時(shí)候，云端需要盡可能快的對(duì)指令進(jìn)行處理，并及時(shí)給予回復(fù)。
3、 當(dāng)下游業(yè)務(wù)模塊的消息處理速度跟不上數(shù)據(jù)上報(bào)速度的時(shí)候，需要消息能盡可能多的在中間模塊進(jìn)行暫存，并在雙方速度拉平的時(shí)候，讓之前暫存的消息能夠得到正確的處理。這是一種典型的異步化通訊思路，在絕大多數(shù)的離線分析場(chǎng)景，以及部分在線業(yè)務(wù)場(chǎng)景中被廣泛的使用，能夠顯著提升系統(tǒng)整體的穩(wěn)定性和吞吐量。

通過引入消息隊(duì)列，能夠比較順利的實(shí)現(xiàn)這幾大業(yè)務(wù)訴求，消息分發(fā)、暫存的工作都可以交給消息隊(duì)列來完成，不需要在具體的業(yè)務(wù)模塊中自行實(shí)現(xiàn)。

在整個(gè)系統(tǒng)架構(gòu)中，所有消息的流轉(zhuǎn)都需要通過消息隊(duì)列來完成。在業(yè)務(wù)高峰期，會(huì)有超過100萬(wàn)臺(tái)車聯(lián)網(wǎng)設(shè)備同時(shí)在線，每秒的產(chǎn)生的消息數(shù)量，也會(huì)達(dá)到百萬(wàn)級(jí)別，因此消息隊(duì)列的穩(wěn)定性以及吞吐能力至關(guān)重要。在消息隊(duì)列的選型上，中瑞的技術(shù)團(tuán)隊(duì)針對(duì)業(yè)界主流的產(chǎn)品進(jìn)行了深入探索。

在消息隊(duì)列產(chǎn)品選型過程中，我們排除了是無(wú)法通過水平擴(kuò)展的方式線性提升整體性能的消息隊(duì)列產(chǎn)品。這類產(chǎn)品以ActiveMQ和RabbitMQ為代表，雖然在業(yè)界得到了廣泛使用，但無(wú)法支撐來自于海量設(shè)備的大吞吐量需求。最本質(zhì)的原因是這類產(chǎn)品并不是按照原生的分布式理念進(jìn)行設(shè)計(jì)，當(dāng)性能無(wú)法滿足業(yè)務(wù)需求的時(shí)候，只有通過垂直提升硬件性能的方式實(shí)現(xiàn)，升級(jí)過程中對(duì)業(yè)務(wù)有感知，而且性能提升的程度有限，不具備可操作性。

Kafka是一個(gè)比較好的選擇，其原生的分布式設(shè)計(jì)理念能確保性能可以通過水平擴(kuò)容而實(shí)現(xiàn)線性的提升。中瑞的技術(shù)團(tuán)隊(duì)對(duì)Kafka進(jìn)行了大量技術(shù)預(yù)研，希望能夠通過Kafka的水平擴(kuò)展能力支撐起中瑞的高并發(fā)業(yè)務(wù)場(chǎng)景。但隨著研究的深入，中瑞的技術(shù)團(tuán)隊(duì)發(fā)現(xiàn)Kafka也存在一定的局限性。對(duì)于流轉(zhuǎn)到在線業(yè)務(wù)模塊以及第三方合作伙伴的消息，需要確保消息的可達(dá)性，也就是說不管系統(tǒng)的哪個(gè)環(huán)節(jié)出現(xiàn)了異常情況，都應(yīng)該確保重要的消息不丟失。這一點(diǎn)Kafka沒有辦法在協(xié)議層提供保證，并在測(cè)試過程中也得到了驗(yàn)證：當(dāng)時(shí)Kafka與在線業(yè)務(wù)模塊之間的網(wǎng)絡(luò)出現(xiàn)了短暫抖動(dòng)，這本來應(yīng)該是一個(gè)很常見的異常情況，系統(tǒng)可以比較快的時(shí)間內(nèi)恢復(fù)運(yùn)行。但實(shí)際使用過程中，這次網(wǎng)絡(luò)抖動(dòng)造成了一批消息的永久性丟失，這在一些金融風(fēng)險(xiǎn)控制相關(guān)的關(guān)鍵業(yè)務(wù)場(chǎng)景中是不能被接受的。

在測(cè)試的過程中，中瑞還發(fā)現(xiàn)往Kafka集群加入新的節(jié)點(diǎn)的時(shí)候，會(huì)造成集群的性能出現(xiàn)抖動(dòng)情況，通常會(huì)持續(xù)1小時(shí)以上。這個(gè)過程中雖然集群層面能確保高可用，但對(duì)于業(yè)務(wù)依然會(huì)造成一定的影響，這是由Kafka底層的ISR機(jī)制的實(shí)現(xiàn)原理導(dǎo)致的，整個(gè)技術(shù)界都沒有太好的優(yōu)化方向。

經(jīng)過深入的評(píng)估，中瑞最終決定采用RocketMQ來建設(shè)消息隊(duì)列集群。RocketMQ是阿里巴巴在歷年雙11業(yè)務(wù)的沉淀下，構(gòu)建的低延遲、高并發(fā)、高可用、高可靠的分布式消息中間件。最初RocketMQ的誕生，也參考了Kafka的分布式模型，但在Kafka的基礎(chǔ)上圍繞在線交易類業(yè)務(wù)場(chǎng)景進(jìn)行了多項(xiàng)優(yōu)化。對(duì)于中瑞來說，RocketMQ建立在協(xié)議層的消息必達(dá)性保證可以防止重要的數(shù)據(jù)在流轉(zhuǎn)的過程中丟失，這種必達(dá)性保證通過了各種苛刻場(chǎng)景的驗(yàn)證，完全可以使用在金融相關(guān)業(yè)務(wù)中。對(duì)于每一個(gè)發(fā)往RocketMQ的消息，只要發(fā)送方收到了來自于RocketMQ的回執(zhí)，就能確保這條消息一定會(huì)被對(duì)應(yīng)的消費(fèi)方接收并正確的處理。

早在2012年，RocketMQ就被捐獻(xiàn)給了開源組織，并在隨后成為Apache的頂級(jí)項(xiàng)目，因此RocketMQ在整個(gè)業(yè)界具有非常高的影響力，對(duì)于RocketMQ的實(shí)現(xiàn)原理、優(yōu)化方案，都能在技術(shù)論壇找到大量的資料。但在到底使用開源RocketMQ進(jìn)行自建，還是使用云上商業(yè)版RocketMQ的問題上，中瑞的技術(shù)團(tuán)隊(duì)倒是很快達(dá)成了一致：對(duì)于一只以業(yè)務(wù)發(fā)展為第一導(dǎo)向的技術(shù)團(tuán)隊(duì)而言，云上商業(yè)版在成本和效率上體現(xiàn)出來的優(yōu)勢(shì)是顯而易見的。

RocketMQ天然具備高可用性，不管是Name Server集群還是Broker集群，當(dāng)有節(jié)點(diǎn)宕機(jī)的時(shí)候，整個(gè)集群依然可以對(duì)外提供服務(wù)，不會(huì)對(duì)業(yè)務(wù)造成影響。但在這種情況下，RocketMQ集群處于一種比較脆弱的狀態(tài)，需要使用者想辦法進(jìn)行系統(tǒng)性的補(bǔ)救，以確保在下一次出現(xiàn)節(jié)點(diǎn)宕機(jī)的時(shí)候，RocketMQ集群依然能夠穩(wěn)定得運(yùn)行。比如當(dāng)一個(gè)Master Broker節(jié)點(diǎn)出現(xiàn)故障后，雖然Slave Broker節(jié)點(diǎn)依然可以承擔(dān)消息收發(fā)的任務(wù)，而且RocketMQ的消息同步機(jī)制確保了這個(gè)過程中的消息不丟失，但使用者需要盡快將Slave節(jié)點(diǎn)升級(jí)為Master節(jié)點(diǎn)，并引入新的Slave節(jié)點(diǎn)。否則當(dāng)原有的Slave節(jié)點(diǎn)再次遇到故障的時(shí)候，整個(gè)集群將停止工作，這會(huì)對(duì)業(yè)務(wù)造成非常嚴(yán)重的影響。在開源RocketMQ的實(shí)現(xiàn)中，并沒有提供完善的機(jī)制來實(shí)現(xiàn)主從Broker的相互切換，需要使用者自行實(shí)現(xiàn)方案，風(fēng)險(xiǎn)非常大。在后期的版本中，雖然提供了Dledger多副本機(jī)制實(shí)現(xiàn)主從切換，但操作難度很大，切換的過程中也并不能保證平滑過渡，會(huì)使業(yè)務(wù)造成一定的抖動(dòng)。

RocketMQ集群的擴(kuò)容也是一項(xiàng)非常有挑戰(zhàn)性的工作，在引入新節(jié)點(diǎn)的過程中，需要投入大量運(yùn)維工作量，擴(kuò)容所需要的時(shí)間也比較長(zhǎng)。每一步的操作都必須小心謹(jǐn)慎，一旦出現(xiàn)操作失誤，就會(huì)導(dǎo)致整個(gè)集群不可用。在中瑞的業(yè)務(wù)場(chǎng)景中，因用戶流量的突增而引發(fā)系統(tǒng)緊急擴(kuò)容的需求比較頻繁。消息隊(duì)列是整個(gè)系統(tǒng)的核心，必須保證每一次擴(kuò)容都可以在保證業(yè)務(wù)不中斷的前提下快速完成。

阿里云版本的RocketMQ完美的解決了高可用和彈性伸縮這兩個(gè)方面的挑戰(zhàn)。這樣的能力來自于阿里巴巴自身業(yè)務(wù)場(chǎng)景的沉淀和歷練，也就是每年雙11活動(dòng)的極端考驗(yàn)。隨著阿里云的飛速發(fā)展，RocketMQ成為了阿里云消息隊(duì)列產(chǎn)品家族的最重要組成部分。云上的商業(yè)版RocketMQ完整保留了在阿里集團(tuán)自身業(yè)務(wù)場(chǎng)景中沉淀的高吞吐量、堆積能力、高可用性、高安全性、低延遲性，并針對(duì)云上的使用者在易用性方面進(jìn)行了大量增強(qiáng)。中瑞的技術(shù)團(tuán)隊(duì)在系統(tǒng)架構(gòu)中全面使用阿里云版RocketMQ作為消息隊(duì)列后，對(duì)集群進(jìn)行了多次水平擴(kuò)容，以滿足更大用戶量更高并發(fā)的需求。在業(yè)務(wù)值峰期間，數(shù)百萬(wàn)臺(tái)車聯(lián)網(wǎng)設(shè)備同時(shí)在線，給系統(tǒng)帶來了巨大的壓力，但阿里云版RocketMQ作為消息流轉(zhuǎn)的核心組件，一直保持穩(wěn)定進(jìn)行，至今為止0故障。

當(dāng)一支技術(shù)團(tuán)隊(duì)的工作內(nèi)容從復(fù)雜的底層技術(shù)細(xì)節(jié)中解放出來后，他們就有了更多的精力來實(shí)現(xiàn)業(yè)務(wù)領(lǐng)域的創(chuàng)新。這也是云計(jì)算以及云原生理念為廣大企業(yè)帶來的巨大價(jià)值，隨著業(yè)務(wù)的飛速發(fā)展，中瑞的技術(shù)團(tuán)隊(duì)還會(huì)繼續(xù)圍繞云原生技術(shù)，探索更多節(jié)省IT成本、提升業(yè)務(wù)效率的新方向。當(dāng)前，中瑞正在將現(xiàn)有的微服務(wù)應(yīng)用進(jìn)行容器化改造，并全面接入阿里云實(shí)時(shí)應(yīng)用監(jiān)控ARMS，以實(shí)現(xiàn)全棧式的性能監(jiān)控和端到端的全鏈路追蹤診斷。此外，他們還積極嘗試通過函數(shù)計(jì)算FC的方式對(duì)部分業(yè)務(wù)系統(tǒng)進(jìn)行Serverless化改造，從而全面的降低計(jì)算資源成本，更充分的利用云計(jì)算的彈性能力。

在保持對(duì)業(yè)界趨勢(shì)調(diào)度關(guān)注的同時(shí)，始終選用最適合自身的技術(shù)，這可能是中瑞能在車聯(lián)網(wǎng)領(lǐng)域引領(lǐng)行業(yè)的重要原因之一，正如中瑞CTO楊少杰所說：“阿里云云原生產(chǎn)品體系帶給我們的，不是單純的IT工具，而是整個(gè)團(tuán)隊(duì)?wèi)?zhàn)斗力的提升”。

?

?

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的数百万台车联网设备同时在线0故障，中瑞集团的云原生探索之路 | 云原生Talk的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。