作者：曹操出行 消息中间件负责人 王智洋
01
关于曹操出行
曹操出行创立于 2015 年 5 月 21 日，是吉利控股集团布局“新能源汽车共享生态”的战略性投资业务，目前已经发展为中国领先的共享出行平台，曹操出行以“科技重塑绿色共享出行”为使命，将全球领先的互联网、车联网、自动驾驶技术以及新能源科技，创新应用于共享出行领域，以“用心服务国民出行”为品牌主张，致力于打造服务口碑最好的出行品牌。
02
为什么选择使用 AutoMQ
曹操出行属于出行类业务，业务数据量和时间呈现明显的关联关系。对于节假日、早晚高峰、天气影响、特定活动（例如演唱会）等生活场景，出行相关的数据量会显著增长。此外，曹操出行经过多年的发展每天也会产生大量的出行数据用于分析。
在这样的背景下，过去曹操出行使用 Kafka 产生的主要问题在于其缺乏弹性的存算一体化架构。由于 Apache Kafka 的架构本身缺乏弹性，在实际生产应用中，我们遇到了如下的一些问题：
- 云盘存储空间有限，难以扩展：Kafka 的存储强依赖本地存储。曹操出行存量 Kafka 集群默认是 MBR 的磁盘格式，至多只能支持 2.2 TB 的存储，不能直接修改磁盘格式，否则可能会引发数据丢失。在这样的客观限制下，我们只能选择降低 Topic 的保存时间或者在 EC2 上挂载多个云盘。原先使用的方式是挂载多个云盘，但是这给我们带来了很大的运维负担。每一次扩容都是一次“提心吊胆”的过程，除了要应对 Kafka 本身扩容的问题，还得人工挂盘、配置、确认生效。
- Kafka 集群扩容时运维复杂并且风险高：Kafka 集群自己进行扩容是一件很复杂并且高危的操作。曹操出行为了避免计算资源浪费，存储资源不足时我们采用的是在单个 Broker 上挂载多个云盘。集群扩容需要按 Broker 和 磁盘制定 Topic 的迁移和分配，整个过程不仅复杂并且风险较高，需要协调好上下游应用在业务地方时期操作，避免影响业务。
在充分调研 AutoMQ 以后，我们发现其创新的共享存储架构可以完全解决 Kafka 的弹性问题：
- 极速扩缩容，快速响应业务变化：AutoMQ 的设计理念是将数据的持久性卸载至对象存储、云盘这样的云存储之上，因此其内部在扩缩容时不再像 Apache Kafka 一样涉及分区数据复制，计算和存储层也得以完全分离。AutoMQ 中的分区迁移行为仅仅是元数据的变更，这使得其可以做到秒级分区迁移的能力。在秒级分区迁移的支持下，AutoMQ 可以在 Broker 节点新增或者缩减时在秒级内将分区迁移至新节点或者从待缩容的节点上迁移至其他节点，从而保证整个扩缩容可以极速完成。
- 自动化弹性，降低扩缩容运维复杂度：由于 AutoMQ 内置了持续重平衡的组件不停歇地运行，使得其可以通过观测 Metric 来实时生成调度计划来帮助用户自动迁移分区。这也意味着对 AutoMQ 进行扩缩容时，用户无需再自己制定 Topic 和 分区的迁移计划，整个过程是完全自动化的。AutoMQ 将 Kafka 高风险、高复杂度的扩缩容操作变成一个了一个低风险可以常态化自动执行的操作是在 Kafka 上的重大创新。过去我们内部在对 Kafka 扩容时，还遇到过 Topic 过期删除任务与扩容时 Topic 迁移协同产生的故障，在使用 AutoMQ 以后我们都无需再担心这些问题。
- 持续自平衡，解放运维：AutoMQ 内置了一个持续工作的自平衡组件，这对 Kafka 集群的运维人员来说是一个真正的福音。自平衡组件会自动观测 AutoMQ 集群内部的 Metric 信息，通过这些 Metric 信息以及内置的规则引擎会自动生成实时的分区调度计划并且进行执行，带来以下好处：
- 节点故障自愈：当 Broker 节点故障时，依靠自平衡组件，故障节点的分区会自动调度到其他健康的节点。
- 提升集群容量利用率：自平衡组件会自动调度分区，确保整个集群内各个 Broker 的吞吐能力都被彻底利用，避免资源浪费。
- Broker 热点自愈：分区热点是 Kafka 中的常见现象。自平衡组件可以自动识别热点 Broker，将热点 Broker 的分区按照规则引擎处理后迁移至其他 Broker 上，在保证容量高效利用的前提下自动打散热点分区。
此外，选择 AutoMQ 的另外一个非常重要的原因是其在保证 Apache Kafka 100% 兼容的前提下解决了过去 Kafka 的弹性痛点问题。由于我们已经存在大量 Kafka 的周边数据基础设施，这种兼容性使得我们可以非常平滑的过渡到 AutoMQ，无需对周边数据基础设施做任何改动。
03
AutoMQ 在曹操出行的应用
以下架构图说明了 AutoMQ 在曹操出行数据栈中的位置以及说明了其是如何发挥作用的。
曹操出行的数据源主要来自 RDS、应用埋点写入以及 ilogtail 采集的日志数据。这些数据主要包含出行相关的核心数据例如订单、驾驶员、乘客数据等。数据主要会流向 3 个集群：
- 大数据集群：该集群的 Topic 主要用于大数据相关的分析。例如用户行为分析、漏斗分析等，从而来更好的指导出行业务的一些商业决策与运营。
- 可观测集群：搜集 Trace，Metric 等信息，存入 ElasticSearch ，主要用于故障诊断、实时报警，可以尽早发现应用问题以及业务风险。
- 业务集群：业务应用埋点发送的数据，用于 Flink 处理后生成一些报表
04
AutoMQ 助力曹操出行应对中秋、国庆流量高峰
目前为止，AutoMQ 已经帮助曹操出行成功度过了中秋和国庆的流量高峰，整个扩缩容体验非常丝滑。下图是曹操出行在中秋期间的某个生产环境的 AutoMQ 集群。可以看到出行业务在早高峰（早 7 点）、晚高峰（晚 6 点）以及中秋最后一天返程（晚 21 点）呈现与时间强关联的周期性特征。使用 AutoMQ 以后，在面对这样的一些出行高峰时，我们再也不需要像过去运维 Kafka 一样如坐针毡。当我们需要扩容时，AutoMQ 可以快速将集群扩容到指定的容量，并且保证集群可以稳定承载生产流量，不仅解决了过往 Kafka 弹性的痛点，也大大降低了我们运维的复杂度和风险，提升了 Kafka 运维同学的幸福指数。
总的而言，AutoMQ 在 Kafka 上的创新在全球来看都具有领先的技术优势，是一款能够在于 Kafka 保证完全兼容的基础上同时将成本、弹性发挥到极致的 Kafka 产品。在未来，我们将继续和 AutoMQ 保持合作，持续推广和深化 AutoMQ 在曹操出行中的应用。
