数百万台车联网设备同时在线0故障,中瑞集团的云原生探索之路 | 云原生Talk

数百万台车联网设备同时在线0故障,中瑞集团的云原生探索之路 | 云原生Talk

作者:山猎,阿里云解决方案架构师

中瑞集团成立于2011年,是一家青岛本土的物联网独角兽企业。中瑞集团致力于利用物联网和人工智能技术,融合智慧出行、智慧物流、智慧风控、智慧审计、智慧车险、智慧校园、智慧零售等业务场景,为数万家政府和企业? V Q ( P W客户提供资产数字化管理解决方案。自2015年以来,集团业务营收年均复合增长率超过100%,2019年营收超过20亿人民币。

中瑞集团累计服务7000余家汽车经销商、200余家金融机构、20多家知名出行机构,是车联网技术和服务的领军企业。2020年5月平台累计在线车联网终端设备超过620万台,是全国车联网在线终端规模No.1的应用平台,每天产生约1TB的车联网原生数据,在网车辆的每天累计行驶里程超过1亿公里。

商用车辆数字化管理,以及汽车金融风控是中瑞集团u e x #的重要业务。在这两种业务场景下,都需要通过车联网技术连接大量客户端设备,实时收集并处理海量数据。以风控业务为例,车5 Z T p U S G L贷行业最大的风险, & l是车主恶意拖欠、骗贷,主要的行为是偷偷把车拿去做二次抵押、把车卖了或者把车藏起来,给车贷机构造成了大量的损失。中瑞的车联网方案对车辆加装实时数据上报系统,能够让车辆将GPS定位信息、车辆状态等数据实时发送到H [ S核心LCRM平台,并通过大数据技术基于多种维度进行聚合统计,帮助车贷企业时刻掌握车辆行踪。

数百万台车联网设备同时在线0故障,中瑞集团的云原生探索之路 | 云原生Talk

图:N k ~ v f B T y [中瑞LCRM平台技术架构

车联网设备实时上报的数据G w l,会同步流转到多个业务系统进行处理,其中包括中瑞建设的在线业务平台、离线分析平台和实时计算平台,d * ~ b u n还有一部分数据会通过API的方式进行透出,提o ] - T K供给下游的第三方合作伙伴使用。对于中瑞的技术团队T v z W {而言,每一条通过车联网上报的数据都是非常珍贵的,其背后蕴藏着巨大的业务价值。因此,在进行系统架构设计的时候,需要g % z a Y Y @考虑到如下几个重要的业务诉求:

1、 对于上报的数据,通过一个中间/ = R W $ L Z 4 o模块进j u } H行消息分发,交给不同的系统进行处理,减少消息复制的成本
2、 当下游业务模块的消息处理速度比较快的时候,要确保消息流转的低时延。这个需求对于大多9 w ] * S r G |数在线业务场景都是非常重要的,比如当车联网用户发M f y T + G P L起一个新的指令的时候,服务端需要尽可能快地对指令进行处理,并m r及时给予回复。
3、 当下游业务模块的消息处. ? f : p理速度跟不上数据上报速度的时候,需要消息能尽可能q l . n } G 7多的在中间模块进行暂存,并在双方速度拉平的时候,让之前暂存= / [ [的消息能够得到正确的处理。这是一种典型的异步化通讯思路,在绝大多数的离线分析场景,以及部分在线业务场景中被广泛的使用,能够显著提升系统整体的稳q A w h A =定性和吞吐量。

通过引入^ v f消息队列,能够比较顺利的实现这几大业务诉求,消息分发、暂存的工作都可以交给消息队列来完成,不需要在具体的业务模块中自行实现。
数百万台车联网设备同时在线0故障,中瑞集团的云原生探索之路 | 云原生Talk

在整个系统# h 5 d X架构中,所有消息的流转都需要通过消息队列来完成。在^ t | & g H 7 % _业务高峰期,会有超过100万台车联网设备同时在线,每秒的产生的消息数量,也会达到百万级别,因此消息队列的稳定性以及吞吐能力至关重要。

在消息队列的选型上,中瑞的技术团队针对业界主流的产品进行了深入探索。

首先要排除的是无法( , H l # - 7 z通过水平扩展的方式线性提升整体性能的消息队列产品@ B ] E 6 X 0。这类产品以ActiveMQ和RabbitMQ为代表,虽然在Q ) F ~ L业界得到了广泛使用,但根本无法支撑来自于海量设备的大吞吐量需求。最本质的原因是这类产品并不是按照原生的分布式理念进行设计,当性能无法满足业务需求的时候,只有通过垂直提升硬件性能的方式实现,升级过程中对业务有感知,而且性能提升的程度有限,不具备可操作性。

Kafka是一个比较好的选择,其原生的分布式设计理念能确0 P a P f O :保性能可以通过水平扩容而实现线性的提升。中瑞的技术团队对Kafka进行了大量技术预研,希望能够通过Kafka的水平扩展能z ^ ( o J力支撑起Y h _中瑞的高并发业务场景) 2 * y ] ? v ,

但随着研究的深入,中瑞的技术团队发现Kafka也存在一定的局限性。对于* W U 1 s 3 T E v流转到在线业务模块以及第三方合作伙伴的消息,需要确保[ # y v消息的可达性,也就是说不管系统的哪个环节出v a c m a现了异常情况,都应该确保重要的消息不丢失。这一点Kafka没有办法在协议层提供保证,并在测试过程中也得到了验证:当时Kafka与在线业务模块之间的网络出现了短暂抖动,这本来应该是一个很常见的异常情况,系统可以比f } j A L 1较快的时间内恢复运行。但实际L Q (使用过程中,这次网络抖动造成了一批消息的永久性丢失,这在一些跟风控相关的关键业务场景中是不能被接受的。

在测试的过程中,中瑞还~ B = G * : F发现往Kafka集群加入新的节点的时候,会造成集群的性能出现( Q , o }抖动情况,通常会持续1小N D v R 1 9 z P时以上。这个过程中虽然集群层面能确保高可用,但对于业务依然会造成一定的影响,这是由Kafka底层的ISR机制的实现原理导致的,, 4 S W Q整个技术界都没有太好的优化方向。

经过深入的评估,中瑞最终决定采用Rocke` f & F Z `tMQ来, | U D Z /建设消息队列集群。RocketMQ是阿里巴巴历经多年双11业务的: e S K C S L f j沉淀所构建的低延迟、高并发、高可用、高可靠的分布式消息中间件。最初RocketMQ的诞生,也参考了Kafka的分布式模型,但在Kafka的基础上围绕在线交易类业务场景进行了多项优化。对于中瑞来说,R0 Q S focketMQ建立在协议层的消息必达性,保证可以防止重要的数据在流转的过程中丢失,这种必达性保证通过了各种苛刻场景的验证,完全可以使用在金融相关业务中。对于每一个发往RocketMQ的消息,只要发送方收到了来自^ n | O于RocketMQ的回执,就能确保这条消息一定会被对应的消费方接收并正确的处理。
数百万台车联网设备同时在线0故障,中瑞集团的云原生探索之路 | 云原生Talk

图:RocketMQ架构

@ ; i R Q S 5 j G在2012年,RocketMQ就被捐献给了开源组织,并在随后成为Apache的顶级项目,因此RocketMQ在整个业界具有非常高的影响力,对于RocketMQ的实现原理、优化方案,都能在技术论坛找到大量的资料。但在到底使用开源RocketMQ进行自建,还是使用云上商业版RocketMQ的问题 2 r 4 0 h / y上,中瑞的技术团队倒是很快达成了一致:对于一支以业务发展为第一导向的技术团队而言,云上商y L n .业版在成本和效率上体现出来的优势是i Q 7 j显而易见的。5 k F U m O S E
数百万台车联网设备同时在线0故障,中瑞集团的云原生探索之路 | 云原生Talk

图:阿里云RocketMQ

RocketMQ天然具备高可用性,不管是m D K *Name Server集群还是Broker集群,当有节点宕机2 P a z ! s B的时候,整个集群依然可以对外提供服务,不会对业务造成影响。但在这种情况下,Rock1 c L 3 +e) ! } & x .tMQ集群处于一c g ^种比较脆弱的状态,需要使用者想办H n P法进行系统性的补救,以确保在下一次出现节点宕机的W 5 I $时候,RocketMQ集群依然能够稳定得运行。比如当一个Master Broker节点出现故障后,虽& K q L 然Slave Broker节点依然可以承担消息收发的任务,而且RocketMQ的消息同步机制Q 1 t ) L @确保了这个过程中的消息不丢失,但使用者需要尽快将Slave节点升级为MasterU d q # 2 )节点,并引入新的Slave节点。否则当原有的Slave节点再次遇到故障的时候,整个集群将停止工作,这会对业务造成非常严重的影响。在开源RocketMQ的实现中,并没有提供完善的机制来实现主从Broker的相互切换,需要使用者自行实现方案,风险非常大。在后期的版本中,虽然提供了Dledger多副本机制b R H Q实现主从切换,但操作难度很大,切换的过程中也并不能保证平滑过渡,会使I + l O S k /业务造成一定的抖动
RocketMQ集E | _ & 0 ) j群的扩容也是一项非常有挑战性的工作,在引入新节点的过程中,需要投入大量运维工作量,扩容所需要的时间也比较长。每一步的操作都必须小心谨慎,一旦出现操$ e j * Y # o H作失误,就会导致整个集群不可用。在中瑞的业务场景中] r 4 H ^ W / b,因用户z n F 5 q ? y H 3流量的突增而W ` T r F Y R引发系统紧急扩容的需求比较频繁。消息队列是整个系统的核心,必须保证每一次扩容都可以在保证业务不中断的前提下快速完成。

阿里云版本的RocketMQ完美的解决了高可用和D ? T弹性伸缩这两个方面的挑战。这样的能力来自@ e . ( {m { | ! 1 _ %阿里巴巴自身业务场景的沉淀和历练,尤其是每年双11活动的极端考验。随着阿里云的飞速发展,RocketMQ成为了阿里D b e K h ; Y云消息队列产品家族的核心组成部分。云上的商业版RocketMQ完整保留了在阿里集团自身业务场景中沉淀的高吞吐量、堆积能力、高Z + l可用性、高安全性、低延迟性,并针对云上的使用者在易用性方面进行了大量增强。中瑞的技术团队在系统架构中全面使用阿里云版RocketMQ作为消息队列后,对集群进行了多次水平扩容,以满足更大用户量更高并发的需求。在业务值峰期间,数百万台车联网设备同时在线,给系统带来了巨大的压力? Q e ! g 9,但阿里云版RocketMQ作为消息流转的核心组& M ,件,一直保持稳定进行,至今为止0故障。

当一支技术团队的工作内容从复杂的底层技术细节中解放出来后,他们就有了更多的精力来实现业务~ h ( ( l o M l领域的创新,这也是云计算以及云原生理念为广大企业带来的巨大价值。随着业务的飞速发展8 X *,中瑞的技术团队还会继续围绕云原生技术,探索更多节省IT成本、提升业务效率的新方向。当前,中瑞正在将现有的微服务应用进行容器化改造,并全面接入阿里云实时应用w ` b P监控ARMS,以实现全栈式的性能监控和端到端的全链路追踪诊断。此外,中瑞还积z 2 I W &极尝试通过函数计算FC的方式对部分业务系统进行Serverles] A s i ? A ! B -s化改造,从而全面的降低计算资源成本,更充分的利用云计算的弹性能力。

在保持对业界趋势调度关注的同时,始终选用最适合自身的技术,这可能是中瑞能在车联网领域引领行业的重要原因之一,正如中瑞CTO所说“阿里云云原生产品体系带给我们的,不是单纯的IT工具,而是整个团队战斗; N p力的提升”。