作者 | 山猎
中瑞集团成立于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工具，而是整个团队战斗力的提升”。
