：在及时掌握行业动态和调度的同时，始终选择最适合自己的技术，这可能是中瑞能在车联网领域引领行业的重要原因之一。正如中锐CTO所言，“阿里云的云原生产品体系带给我们的不仅仅是IT工具，而是整个团队战斗力的提升。”中锐集团成立于2011年，是青岛本土的物联网独角兽企业。中瑞集团致力于利用物联网和人工智能技术，融合智慧交通、智慧城管、智慧出行、智慧物流、智慧风控、智慧审计、智慧车险、智慧校园、智慧零售等业务场景，服务数万政府为企业客户提供资产数字化管理解决方案。2015年以来，集团业务收入年复合增长率超过100%，2019年收入超过20亿元。中瑞集团服务了7000多家汽车经销商、200多家金融机构、20多家知名旅行社。2020年10月，平台累计在线车联网终端设备超过678万台，成为国内第一的车联网在线终端应用平台。商用车数字化管理是中瑞集团的核心业务之一。在该领域，中瑞集团联合整车厂、银行、汽车金融机构、保险公司、基础技术提供商等十余家机构，形成以传感器、人工智能算法、数据管理平台为核心以整体解决方案为核心，为客户提供高度定制化、个性化的服务，并辅以汽车金融、保险、标准制定、平台运营等衍生功能板块。业务能力涵盖数字化管理项目设计、建设和运营的各个阶段。商用车数字化管理通过车联网技术连接大量终端设备，实时采集和处理海量数据。智能车载传感设备将根据物流、出行、工程作业、农业作业等不同行业的属性，生成人、车、货、设备的数据。基于对车联网行业实践的深入积累，中瑞集团将物联网和移动互联网技术相结合，依托云计算、大数据等技术支撑，自主研发中瑞车联网。车辆云平台。通过对在线运营车辆数据的采集、处理和分析，反馈到整车厂的研发、设计、采购、生产、销售和售后各个环节，有效提高了整车设计水平，提高了整车质量。零件，并优化销售策略。,提高售后的实时性和准确性。车联网智能设备上报的实时数据，将传输到多个业务系统进行处理，包括中锐搭建的线上业务平台、线下分析平台和实时计算平台，部分数据将通过通过API透明。提供给设备所属机构和政府监管部门使用。根据政府监管政策要求，中瑞集团承建智慧城市出行平台。通过部署车载联网终端设备，采集符合当地监管要求和技术标准的车辆运行数据，上传采集至当地政府数据中心，建立符合国家标准的网络。向各部委提供开放数据接口。对于中瑞的技术团队来说，通过车联网上报的每一条数据都非常珍贵，背后蕴藏着巨大的商业价值。因此，在设计系统架构时，需要考虑以下重要的业务需求：1.对于上报的数据，通过中间模块将消息分发到不同的系统进行处理，减少消息重复的成本。2、当下游业务模块的消息处理速度比较快时，需要保证消息流的低延迟。这个需求对于大多数在线业务场景来说是非常重要的。例如，当车联网用户发起新命令时，云端需要尽快处理该命令并及时回复。3、当下游业务模块的消息处理速度跟不上数据上报速度时，需要在中间模块中暂存尽可能多的消息，待双方速度拉平后，将之前的可以更正存储的消息。加工。这是一种典型的异步通信思想，广泛应用于大部分离线分析场景和部分在线业务场景，可以显着提高系统的整体稳定性和吞吐量。通过引入消息队列，可以比较顺利的实现这些主要的业务需求。消息分发和暂存的工作可以交给消息队列来完成，不需要在具体的业务模块中实现。在整个系统架构中，所有消息的流转都需要通过消息队列来完成。在业务高峰期，同时在线的车联网设备将超过100万台，每秒产生的消息数将达到百万级。因此，消息队列的稳定性和吞吐量非常重要。在消息队列的选型上，中锐的技术团队对业界主流产品进行了深入的探索。在消息队列产品的选型过程中，我们排除了不能通过横向扩展线性提升整体性能的消息队列产品。此类产品以ActiveMQ和RabbitMQ为代表。尽管它们在行业中得到广泛应用，但它们无法支持海量设备的大吞吐量需求。最本质的原因是这类产品并不是按照原来分布式的理念设计的。当性能不能满足业务需求时，只能通过垂直提升硬件性能来实现。升级过程中，业务感知和性能提升程度有限，不可操作。卡夫卡是更好的选择。其原生的分布式设计理念，可以保证通过水平扩展，性能得到线性提升。中锐的技术团队对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，中瑞两国的技术团队很快达成了一致：对于一个把业务发展放在第一位的技术团队，cloud商业版在成本和效率上的优势很明显。RocketMQ天生就具备高可用。无论是NameServer集群还是Broker集群，当某个节点宕机时，整个集群仍然可以对外提供服务，不影响业务。但在这种情况下，RocketMQ集群处于比较脆弱的状态，用户需要想办法进行系统性补救，以保证在下一个节点宕机时RocketMQ集群仍能稳定运行。例如，当一个MasterBroker节点出现故障时，虽然SlaveBroker节点仍然可以承担发送和接收消息的任务，并且RocketMQ的消息同步机制保证了这个过程中的消息不丢失，但是用户需要升级Slave节点尽快成为Master节点。,并引入一个新的Slave节点。否则，当原来的Slave节点再次遇到故障时，整个集群就会停止工作，对业务造成非常严重的影响。开源的RocketMQ在实现中，没有完善的机制来实现主从broker的相互切换，需要用户自行实现方案，风险很大。在后面的版本中，虽然提供了Dledger多副本机制来实现主从切换，但是操作起来难度很大，切换过程中无法保证平滑过渡，会在业务上造成一定的抖动。RocketMQ集群的扩容也是一项非常具有挑战性的工作。在引入新节点的过程中，需要投入大量的运维工作量，扩容时间长。每一步操作都必须小心谨慎，一旦出现操作错误，整个集群将不可用。在中锐的业务场景中，由于用户流量骤增导致系统紧急扩容的需求比较频繁。消息队列是整个系统的核心，必须保证每次扩容都能在不中断业务的情况下快速完成。阿里云版RocketMQ完美解决了高可用和弹性伸缩的挑战。这种能力来自于阿里巴巴自身业务场景的沉淀和经验，是一年一度的双十一的极限考验。随着阿里云的快速发展，RocketMQ已经成为阿里云消息队列产品家族中最重要的一员。云上RocketMQ商用版充分保留了阿里巴巴集团自有业务场景中积累的高吞吐量、堆叠能力、高可用、高安全、低延迟，并在易用性方面针对云上用户进行了优化.很多增强功能。中锐技术团队在系统架构上充分使用了阿里云版RocketMQ作为消息队列，并进行了集群的多次横向扩展，以满足更大用户数和更高并发的需求。业务高峰期，百万车联网设备同时在线，给系统带来巨大压力。而作为消息流核心组件的阿里云版RocketMQ运行稳定，目前没有出现故障。当一个技术团队的工作内容从复杂的底层技术细节中解放出来时，他们就有更多的精力去实现业务领域的创新。这也是云计算和云原生理念给广大企业带来的巨大价值。随着业务的快速发展，中锐的技术团队将继续专注于云原生技术，为节约IT成本、提升业务效率探索更多新方向。目前，中锐正在将现有的微服务应用进行容器化改造，全面接入阿里云实时应用监控ARMS，实现全栈性能监控和端到端全链路跟踪诊断。此外，他们也在积极尝试通过函数计算FC将部分业务系统转为Serverless，全面降低计算资源成本，充分利用云计算的弹性。在关注行业趋势的同时，我们始终选择最适合自己的技术。这或许是中瑞能在车联网领域领跑行业的重要原因之一。正如中锐CTO杨少杰所说：“阿里云的云原生产品体系带给我们的不仅仅是一个简单的IT工具，而是整个团队战斗力的提升。”原文链接本文为阿里云原创内容，未经许可不得转载。
