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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?

?

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

總結

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

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