作者：山獵，阿里雲解決方案架構師
中瑞集團成立於2011年，是一家青島本土的物聯網獨角獸企業。中瑞集團致力於利用物聯網和人工智能技術，融合智慧出行、智慧物流、智慧風控、智慧審計、智慧車險、智慧校園、智慧零售等業務場景，為數萬家政府和企業客戶提供資產數字化管理解決方案。自2015年以來，集團業務營收年均複合增長率超過100%，2019年營收超過20億人民幣。
中瑞集團累計服務7000餘家汽車經銷商、200餘家金融機構、20多家知名出行機構，是車聯網技術和服務的領軍企業。2020年5月平臺累計在線車聯網終端設備超過620萬臺，是全國車聯網在線終端規模No.1的應用平臺，每天產生約1TB的車聯網原生數據，在網車輛的每天累計行駛里程超過1億公里。
商用車輛數字化管理，以及汽車金融風控是中瑞集團的重要業務。在這兩種業務場景下，都需要通過車聯網技術連接大量客戶端設備，實時收集並處理海量數據。以風控業務為例，車貸行業最大的風險是車主惡意拖欠、騙貸，主要的行為是偷偷把車拿去做二次抵押、把車賣了或者把車藏起來，給車貸機構造成了大量的損失。中瑞的車聯網方案對車輛加裝實時數據上報系統，能夠讓車輛將GPS定位信息、車輛狀態等數據實時發送到核心LCRM平臺，並通過大數據技術基於多種維度進行聚合統計，幫助車貸企業時刻掌握車輛行蹤。
圖：中瑞LCRM平臺技術架構
車聯網設備實時上報的數據，會同步流轉到多個業務系統進行處理，其中包括中瑞建設的在線業務平臺、離線分析平臺和實時計算平臺，還有一部分數據會通過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的回執，就能確保這條消息一定會被對應的消費方接收並正確的處理。
圖：RocketMQ架構
早在2012年，RocketMQ就被捐獻給了開源組織，並在隨後成為Apache的頂級項目，因此RocketMQ在整個業界具有非常高的影響力，對於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工具，而是整個團隊戰鬥力的提升”。
