中瑞集團成立于2011年，是一家青島本土的物聯網獨角獸企業。中瑞集團緻力于利用物聯網和人工智能技術，融合智慧交通、智慧城管、智慧出行、智慧物流、智慧風控、智慧審計、智慧車險、智慧校園、智慧零售等業務場景，為數萬家政府和企業客戶提供資産數字化管了解決方案。自2015年以來，集團業務營收年均複合增長率超過100%，2019年營收超過20億人民币。中瑞集團累計服務7000餘家汽車經銷商、200餘家金融機構、20多家知名出行機構。2020年10月平台累計線上車聯網終端裝置超過678萬台，是全國車聯網線上終端規模No.1的應用平台。
商用車輛數字化管理是中瑞集團的核心業務之一，在這個領域，中瑞集團已關聯包括整車廠、銀行、汽車金融機構、保險公司、基礎技術提供方等十數家機構，形成以傳感器、人工智能算法、資料管理平台為核心的整體解決方案，為客戶提供高度定制個性化服務，同時輔以汽車金融、保險、标準制定、平台營運等衍生功能闆塊，業務能力涵蓋數字化管理項目設計、建設和營運的各個階段。
商用車輛數字化管理，通過車聯網技術連接配接大量終端裝備，實時收集并處理海量資料。智能車載傳感裝置會根據不同行業屬性，如物流、出行、工程作業、農業作業等，産生人、車、貨、裝置等資料。中瑞集團基于對車聯網行業實踐的深度積累，将物聯網與移動網際網路技術相結合，依靠雲計算、大資料等技術的支援，自主研發中瑞車聯雲平台。通過對線上營運車輛資料的收集、處理和分析，回報到整車廠研發、設計、采購、生産、銷售及售後各個環節，有效改善了整車設計水準，提升了零部件品質，優化了銷售政策，提高了售後實時性及準确度。
車聯網智能裝置實時上報的資料，會同步流轉到多個業務系統進行處理，其中包括中瑞自建的線上業務平台、離線分析平台和實時計算平台，還有一部分資料會通過API的方式進行透出，提供給裝備所屬機構和政府監管部門使用。中瑞集團根據政府監管政策要求，承建智慧城市出行平台，通過部署車載聯網終端裝置，彙集符合當地監管要求和技術标準的車輛作業資料，上傳歸集至當地政府資料中心，同時建立遵循國家标準的開放資料接口，提供給各部委調用。
對于中瑞的技術團隊而言，每一條通過車聯網上報的資料都是非常珍貴的，其背後蘊藏着巨大的業務價值。是以，在進行系統架構設計的時候，需要考慮到如下幾個重要的業務訴求：
1、 對于上報的資料，通過一個中間子產品進行消息分發，交給不同的系統進行處理，減少消息複制的成本。
2、 當下遊業務子產品的消息處理速度比較快的時候，要確定消息流轉的低延遲時間。這個需求對于大多數線上業務場景都是非常重要的，比如當車聯網使用者發起一個新的指令的時候，雲端需要盡可能快的對指令進行處理，并及時給予回複。
3、 當下遊業務子產品的消息處理速度跟不上資料上報速度的時候，需要消息能盡可能多的在中間子產品進行暫存，并在雙方速度拉平的時候，讓之前暫存的消息能夠得到正确的處理。這是一種典型的異步化通訊思路，在絕大多數的離線分析場景，以及部分線上業務場景中被廣泛的使用，能夠顯著提升系統整體的穩定性和吞吐量。
通過引入消息隊列，能夠比較順利的實作這幾大業務訴求，消息分發、暫存的工作都可以交給消息隊列來完成，不需要在具體的業務子產品中自行實作。
在整個系統架構中，所有消息的流轉都需要通過消息隊列來完成。在業務高峰期，會有超過100萬台車聯網裝置同時線上，每秒的産生的消息數量，也會達到百萬級别，是以消息隊列的穩定性以及吞吐能力至關重要。在消息隊列的選型上，中瑞的技術團隊針對業界主流的産品進行了深入探索。
在消息隊列産品選型過程中，我們排除了是無法通過水準擴充的方式線性提升整體性能的消息隊列産品。這類産品以ActiveMQ和RabbitMQ為代表，雖然在業界得到了廣泛使用，但無法支撐來自于海量裝置的大吞吐量需求。最本質的原因是這類産品并不是按照原生的分布式理念進行設計，當性能無法滿足業務需求的時候，隻有通過垂直提升硬體性能的方式實作，更新過程中對業務有感覺，而且性能提升的程度有限，不具備可操作性。
Kafka是一個比較好的選擇，其原生的分布式設計理念能確定性能可以通過水準擴容而實作線性的提升。中瑞的技術團隊對Kafka進行了大量技術預研，希望能夠通過Kafka的水準擴充能力支撐起中瑞的高并發業務場景。但随着研究的深入，中瑞的技術團隊發現Kafka也存在一定的局限性。對于流轉到線上業務子產品以及第三方合作夥伴的消息，需要確定消息的可達性，也就是說不管系統的哪個環節出現了異常情況，都應該確定重要的消息不丢失。這一點Kafka沒有辦法在協定層提供保證，并在測試過程中也得到了驗證：當時Kafka與線上業務子產品之間的網絡出現了短暫抖動，這本來應該是一個很常見的異常情況，系統可以比較快的時間内恢複運作。但實際使用過程中，這次網絡抖動造成了一批消息的永久性丢失，這在一些金融風險控制相關的關鍵業務場景中是不能被接受的。
在測試的過程中，中瑞還發現往Kafka叢集加入新的節點的時候，會造成叢集的性能出現抖動情況，通常會持續1小時以上。這個過程中雖然叢集層面能確定高可用，但對于業務依然會造成一定的影響，這是由Kafka底層的ISR機制的實作原理導緻的，整個技術界都沒有太好的優化方向。
經過深入的評估，中瑞最終決定采用RocketMQ來建設消息隊列叢集。RocketMQ是阿裡巴巴在曆年雙11業務的沉澱下，建構的低延遲、高并發、高可用、高可靠的分布式消息中間件。最初RocketMQ的誕生，也參考了Kafka的分布式模型，但在Kafka的基礎上圍繞線上交易類業務場景進行了多項優化。對于中瑞來說，RocketMQ建立在協定層的消息必達性保證可以防止重要的資料在流轉的過程中丢失，這種必達性保證通過了各種苛刻場景的驗證，完全可以使用在金融相關業務中。對于每一個發往RocketMQ的消息，隻要發送方收到了來自于RocketMQ的回執，就能確定這條消息一定會被對應的消費方接收并正确的處理。
早在2012年，RocketMQ就被捐獻給了開源組織，并在随後成為Apache的頂級項目，是以RocketMQ在整個業界具有非常高的影響力，對于RocketMQ的實作原理、優化方案，都能在技術論壇找到大量的資料。但在到底使用開源RocketMQ進行自建，還是使用雲上商業版RocketMQ的問題上，中瑞的技術團隊倒是很快達成了一緻：對于一隻以業務發展為第一導向的技術團隊而言，雲上商業版在成本和效率上展現出來的優勢是顯而易見的。
RocketMQ天然具備高可用性，不管是Name Server叢集還是Broker叢集，當有節點當機的時候，整個叢集依然可以對外提供服務，不會對業務造成影響。但在這種情況下，RocketMQ叢集處于一種比較脆弱的狀态，需要使用者想辦法進行系統性的補救，以確定在下一次出現節點當機的時候，RocketMQ叢集依然能夠穩定得運作。比如當一個Master Broker節點出現故障後，雖然Slave Broker節點依然可以承擔消息收發的任務，而且RocketMQ的消息同步機制確定了這個過程中的消息不丢失，但使用者需要盡快将Slave節點更新為Master節點，并引入新的Slave節點。否則當原有的Slave節點再次遇到故障的時候，整個叢集将停止工作，這會對業務造成非常嚴重的影響。在開源RocketMQ的實作中，并沒有提供完善的機制來實作主從Broker的互相切換，需要使用者自行實作方案，風險非常大。在後期的版本中，雖然提供了Dledger多副本機制實作主從切換，但操作難度很大，切換的過程中也并不能保證平滑過渡，會使業務造成一定的抖動。
RocketMQ叢集的擴容也是一項非常有挑戰性的工作，在引入新節點的過程中，需要投入大量運維工作量，擴容所需要的時間也比較長。每一步的操作都必須小心謹慎，一旦出現操作失誤，就會導緻整個叢集不可用。在中瑞的業務場景中，因使用者流量的突增而引發系統緊急擴容的需求比較頻繁。消息隊列是整個系統的核心，必須保證每一次擴容都可以在保證業務不中斷的前提下快速完成。
阿裡雲版本的RocketMQ完美的解決了高可用和彈性伸縮這兩個方面的挑戰。這樣的能力來自于阿裡巴巴自身業務場景的沉澱和曆練，也就是每年雙11活動的極端考驗。随着阿裡雲的飛速發展，RocketMQ成為了阿裡雲消息隊列産品家族的最重要組成部分。雲上的商業版RocketMQ完整保留了在阿裡集團自身業務場景中沉澱的高吞吐量、堆積能力、高可用性、高安全性、低延遲性，并針對雲上的使用者在易用性方面進行了大量增強。中瑞的技術團隊在系統架構中全面使用阿裡雲版RocketMQ作為消息隊列後，對叢集進行了多次水準擴容，以滿足更大使用者量更高并發的需求。在業務值峰期間，數百萬台車聯網裝置同時線上，給系統帶來了巨大的壓力，但阿裡雲版RocketMQ作為消息流轉的核心元件，一直保持穩定進行，至今為止0故障。
當一支技術團隊的工作内容從複雜的底層技術細節中解放出來後，他們就有了更多的精力來實作業務領域的創新。這也是雲計算以及雲原生理念為廣大企業帶來的巨大價值，随着業務的飛速發展，中瑞的技術團隊還會繼續圍繞雲原生技術，探索更多節省IT成本、提升業務效率的新方向。目前，中瑞正在将現有的微服務應用進行容器化改造，并全面接入阿裡雲實時應用監控ARMS，以實作全棧式的性能監控和端到端的全鍊路追蹤診斷。此外，他們還積極嘗試通過函數計算FC的方式對部分業務系統進行Serverless化改造，進而全面的降低計算資源成本，更充分的利用雲計算的彈性能力。
在保持對業界趨勢排程關注的同時，始終選用最适合自身的技術，這可能是中瑞能在車聯網領域引領行業的重要原因之一，正如中瑞CTO楊少傑所說：“阿裡雲雲原生産品體系帶給我們的，不是單純的IT工具，而是整個團隊戰鬥力的提升”。