关于小鹏汽车
小鹏汽车成立于2014年，是一家专注未来出行的科技公司。该公司一直坚持饱和式研发投入，构建全栈自研的核心能力。如今，小鹏汽车已经成为中国领先的智能电动汽车公司之一。
小鹏汽车的业务背景
小鹏汽车使用 Apache Kafka 解决云平台各应用系统的日志收集、加工和分析处理。各业务应用的日志数据，经过统一的采集通道，投递到 Kafka，再由 Kafka 分发到下游的基础组件进行消费和处理。
当前这一链路支撑了线上的 监控报警 、 日志检索 、业务 运营数据分析 、 安全审计合规 等多个核心场景和系统。
在使用 AutoMQ 之前，云平台业务使用的是 Kafka，随着业务的持续增长，逐步暴露出两方面的问题比较严重：
资源成本高 ：在云上使用 Kafka，随着业务规模的增长，集群的云账单逐渐膨胀。
扩缩容运维负担重 ：业务在快速增长，会经常产生扩容需求，频繁的运维变更对于 Kafka 来说负担非常重，需要考虑 Kafka 的分区迁移、流量重平衡等细节。
评估和选择 AutoMQ
正是由于成本和运维的负担，小鹏汽车云平台业务开始对数据流领域的项目进行调研，期望能够找到成本低、易运维的 Kafka 平替。
成本优化
在评估过程中，小鹏汽车团队分析，Kafka 的成本主要源自以下两个方面：
存储成本高 ：Kafka 采用 ISR（In-Sync Replicas）机制来保证数据的可靠性，需要存储多个副本。在公有云环境中，基于 ESSD 云盘构建三副本的成本非常高。具体来说，对象存储的单价是 ESSD 云盘的 1/6，考虑到 ISR 机制需要三副本，存储成本相差了更多。
闲置成本浪费 ：随着业务的变化，Kafka 集群需要频繁扩容和缩容。如果无法及时缩容，按峰值预留资源，会产生较大的闲置浪费，这种浪费会随着时间逐渐放大。
数据：云上 ESSD 云盘单价 vs. 对象存储单价
AutoMQ 正是基于这样的思路，将 Kafka 的存储层使用对象存储来替换，实现了计算无状态、秒级分区迁移、自动弹性和流量重平衡等优势。参考 AutoMQ 的官网数据，存储相同的消息数据，相比原生 Kafka 有数量级的成本优势。
秒级分区迁移和 Autoscaling
如成本优化部分所述，云平台日志应用中存在显著的流量波动。例如，业务数据写入量在非高峰期可能为80MB/s，但在高峰期可能增至120-150MB/s，差距接近2倍。如果仅以峰值来预留资源，会导致大量资源浪费；另一方面，频繁的扩缩容对架构和运维团队挑战极大。
Apache Kafka 这类本地存储框架，将消息数据分片存储到各个 Broker 节点，扩缩容需人工介入进行数据迁移。迁移所需时间因数据规模而异，可能是分钟甚至小时级别，这种时间和操作成本无法满足快速、自动的扩缩容需求。
AutoMQ 利用对象存储进行数据卸载，使 Broker 近乎无状态。在扩缩容或故障 Failover 等场景下，只需变更元数据并完成少量的 WAL 数据上传和恢复，即可秒级完成分区迁移。
由于计算层近乎无状态，AutoMQ 可以在云端配置弹性伸缩组，并基于 CPU、内存、网络吞吐等指标设置自动弹性规则，从而实现自动水平扩缩容。在此过程中，分区迁移和平衡都是自动完成的，无需人工干预。
AutoMQ 秒级分区迁移
AutoMQ 自动缩扩容
AutoMQ 在小鹏汽车的落地和实施
迁移方案
得益于 AutoMQ 的架构只是替换了存储层，计算层完全复用了 Apache Kafka 的代码，小鹏汽车将现有的 Kafka 业务集群迁移到 AutoMQ 没有发现任何兼容性问题。
因为目前的应用场景对消费延迟不太敏感，因此迁移方案非常简单可靠：
上游切生产 ：日志收集端直接切换写 Kafka 的接入点，将写流量直接导向 AutoMQ。
等待源集群消费完成 ：下游业务继续消费源集群，确保消息消费完成。
下游切消费 ：等下游全部消费完成后，可以直接切 Kafka 的接入点，从 AutoMQ 集群继续消费。
运维 & 可观测
AutoMQ 在云上提供开箱即用的 Prometheus Metrics 数据，可以一键配置将集群的 Metrics 数据导出到 Prometheus 集群，配合 Grafana 和报警模板就可以完成集群的生产级可观测建设。
AutoMQ 还可以基于云厂商弹性伸缩组 ESS，在高峰期弹出云服务器作为 Broker，在低峰期缩回，实现按业务负载波动进行弹性伸缩的能力。
收益和展望
迁移到 AutoMQ 后，相比此前在使用的 Kafka 托管服务，计算/存储方面的成本均有很多节省。同等规模的实例可以支撑更大的业务流量，整体可以节省约 50%+ 的费用；
未来，我们计划逐步扩大 AutoMQ 的业务范围，提供车辆数据上报等场景使用。在车辆数据上报的场景中，会产生约 300MB/s-500MB/s 的消息吞吐量，且流量峰谷更为明显，因此对 AutoMQ 自动弹性伸缩的能力诉求也更加强烈。