背景与挑战
关于吉利汽车
吉利汽车集团(股票代码: HK.0175) 是吉利控股集团旗下一家集汽车整车、动力总成和关键零部件设计、研发、生产、销售和服务于一体的汽车集团，现有员工 7 万余人，连续四年排名中国品牌乘用车销量第一，持续引领中国品牌自信向上。
吉利汽车集团在中国上海、宁波，瑞典哥德堡、西班牙巴塞罗那、美国加州、德国法兰克福、马来西亚吉隆坡等地建有造型设计和工程研发中心，设计研发人员超过 20,000 人，拥有大量发明创新专利。在中国、马来西亚建有世界一流的现代化整车和动力总成制造工厂，拥有各类销售网点超过 1400 多家，产品销售及服务网络遍布世界各地。
秉承“人本、创新、卓越”的价值观，吉利汽车集团将“创造超越期待的出行体验”作为使命，致力成为最具竞争力和受人尊敬的中国汽车品牌。
AutoMQ 在吉利汽车车联网混合云架构中的应用
吉利大数据平台（简称：GDMP）具备数据采集、低代码开发、任务调度、数据地图、质量监控、数据服务等能力，是吉利汽车大数据基座与数据开发治理平台，承载了研、产、供、销、服全链路业务线。在汽车电动化、智能化、网联化、共享化发展潮流下，车联网数据年度以 PB 级增长，业务场景覆盖面越来越广。Kafka 作为企业车联网数据的核心数据基础设施，汽车业务快速的发展对 Kafka 的弹性能力、成本都提出了更高的要求。AutoMQ 作为新一代的 Kafka 完美解决了吉利汽车当前最为关切的 Kafka 扩缩容问题，保障了车联网核心系统的正常运行。
吉利汽车的车联网系统当前采用混合云的架构，主要是考虑以下几种原因：
成本 ：吉利汽车在私有云拥有大量存量的数据基础设施，采用混合云的架构在整体上会拥有更好的成本效益。
核心方案
数据安全 ：一些关键数据保存在吉利汽车自己的数据中心具有更好的数据隐私性和安全性。
数据上报：汽车的终端设备会将车联网所需的核心数据会通过MQTT协议发往云端的 MQTT Server 用于 TSP。TSP 将汽车与车企提供的车联网服务能力结合起来，为车主提供救援、娱乐、救援、自动驾驶、固件升级等众多服务能力。在吉利汽车公有云上，会部署一个 AutoMQ 集群，用于承接和分发来自公有云上车联网TSP应用的数据。AutoMQ 会作为车联网数据上报的核心数据总线，提供强大的吞吐、可靠的持久化存储和读写性能。
数据流入 GDMP 的 AutoMQ 集群：公有云上TSP的数据会进一步通过专线流入吉利私有云大数据平台 GDMP 中的AutoMQ集群。该 AutoMQ 集群中 Topic 的数据包含来自极氪汽车、领克汽车、吉利汽车等吉利集团旗下不同汽车品牌的车联网数据，例如车辆数据、驾驶信息、GB/T32960国标规定的车联网数据等。这些关键的车联网数据会被下游的 Flink、Spark 以及 Kafka 消费者读取和处理。数据最终会写入数据湖，应用在吉利汽车的BI、数据分析和报表等场景。
TSPTSP（Telematics Service Provider）汽车远程服务提供商。在Telematics产业链居于核心地位，上接汽车、车载设备制造商、网络运营商，下接内容提供商。Telematics服务集合了位置服务、Gis服务和通信服务等现代计算机技术，为车主和个人提供强大的服务：导航、娱乐、资讯、安防、SNS、远程保养
为什么选择 AutoMQ
吉利汽车旗下拥有众多汽车品牌，近些年来随着各品牌业务的强劲发展，车联网的数据量也日益膨胀。在这种背景下，Kafka 难以扩缩容的问题变得日益严峻：
关键时候无法扩容，业务受损 ：Apache Kafka 的扩缩容是一件高风险、重运维、长耗时的运维操作。Kafka 集群容量评估和管理在实际生产环境中是一件很困难的事情。如果产生突发的峰值负载，Kafka 集群没有预留足够的资源，这时候只能对已有集群的服务能力进行降级，才能“硬扛”过去，这直接对我们正常的业务产生影响，影响车主们实际的车联网体验以及正常的运营工作。例如，过去因为不能很好地处理 Kafka 集群的扩容，我们只能将原本的保留时间从5天降低至2天。保留时间的降低，也对我们数据回溯等一些消费历史数据的场景产生了一些影响。
Kafka 集群容量管理困难，运维成本高 ：Kafka 由于其计算强耦合存储，依赖本地存储。扩缩容的时候需要制定周全的迁移计划对已有的分区数据进行复制，执行复杂度很高，同时耗时长。例如，过去吉利汽车使用的 Kafka 集群，如果容量不足时就需要去挂载新的数据卷。一方面，计算实例可以挂载的数据卷是有上限的。如果达到挂载上限，就不得不同时对计算和存储进行扩容，造成大量的资源浪费。新的成本增长也需要重新在内部申请预算和审批，实施起来很复杂成本高昂。另外一方面，对 Broker 挂载新的数据卷对 Kafka 集群的存储扩容本身就是一件非常复杂的事情，涉及新增磁盘、挂载、修改配置、迁移分区引流等操作，需要在业务低峰时期在重点保障的情况下才可以实施，是既复杂、又危险的运维操作。也正是因为 Kafka 集群扩缩容困难，倒逼 Kafka 运维人员提前做好 Kafka 集群的容量管理。然而，容量管理在实际生产实践中常常也会让运维同学左右为难。如果为 Kafka 集群预留来太多的资源，则会导致业务低峰时大量的成本浪费。如果资源不足，则在企业流量迅速增长时无法及时扩容，只能接受业务有损。
由于 Kafka 本身缺乏弹性所带来的痛点使得我们开始寻求新的 Kafka 替代产品。AutoMQ 将持久性卸载至云存储、利用 EBS WAL 和 S3 这类对象存储构建了新一代低成本、高性能、极速弹性的 Kafka。这些优秀的特性迅速吸引了我们的注意。当时我们的集群正因为 Kafka 缺乏弹性难以扩容而不得不降低保留时间。AutoMQ 的出现让我们非常兴奋。我们随即立即联系了 AutoMQ 团队，并且进行了 PoC。实际应用以后，我们确认 AutoMQ 确实真正解决了我们以往关心的几个痛点问题：
零运维极速扩缩容 ：AutoMQ 的极速扩容主要还是得益于其创新的流存储架构。由于将数据持久性卸载至云存储，AutoMQ内部不再像 Kafka 一样需要配置多副本，因为云存储本身内部已经有多副本并且提供了很高的持久性。这除了是对成本的节约以外，更重要的一点在于其在扩缩容的时候无需再像 Kafka 一样进行分区数据的复制，因此可以提供秒级的分区迁移能力。此外，其内置持续运行的重平衡组件可以保证新加入的节点自动在保证集群利用率最优的前提下完成安全可靠地引流。因此，整个极速扩容无需人工干预，完全自动化。这与过去运维 Kafka 的体验形成了天壤之别。
无需容量评估，降低运维成本 ：Kafka 的成本不仅仅体现在其IaaS资源的消耗，还有很大一部分比重在于组织上人力的投入。AutoMQ 本身基于 S3 提供了无限容量的流存储能力，计算和存储完全解耦，这意味着我们再也不需要担心设置较长的保留时间引起的存储空间不足问题。如果集群需要承载更大的吞吐需要扩容，AutoMQ 也可以在非常短的时间自动化地完成扩缩容，因此我们也无需像过去一样先要准备预案、协调上下游应用、制定迁移计划并在业务低峰时期进行扩容、迁移和引流。这将 Kafka 运维同学彻底从复杂、高风险的扩缩容运维、容量评估等工作中解放出来，从而可以执行具有更大价值的运维任务。
100% 的 Kafka 兼容性 ：AutoMQ 对 Apache Kafka 的完全兼容也是我们放心选择的关键原因。这意味着我们无需对已有围绕Kafka建设的所有应用、工具甚至Client端的配置做任何改造，即可完成迁移。未来，吉利汽车也仍然可以利用 Kafka 强大的生态进一步去改进和迭代我们的数据基础设施。
实践效果
AutoMQ 生产应用的效果
当前，AutoMQ 已经正式应用到吉利汽车车联网核心系统的生产环境。下图是其中一个生产集群的监控图表。应用 AutoMQ 以后，完美解决了我们过去 Kafka 遇到的所有痛点问题，还额外帮助我们节约了大量IaaS层的成本，表现远远超出预期。在未来，我们也将进一步继续和 AutoMQ 团队保持合作，利用现代化、先进的流存储技术为我们的客户提供最好的车联网服务。
