Kafka 2.0 升级，看看携程怎么操作！

早在 2014 年，携程的一些业务部门开始引入 Kafka 作为业务日志的收集处理系统。2015 年，基于 Kafka 的高并发、大数据的特点，携程框架研发部在 Kafka 之上设计了 Hermes Kafka 消息系统，作为大规模的消息场景的统一的中间件。随着业务量的迅速增加，以及具体业务、系统运维上的一些误用，Kafka 现有系统变得不稳定，经历了多次 down 机，故障期间完全不可用，持续时间长达 5 小时以上，恢复缓慢。Kafka 还能用多久？成为一个迫切棘手的问题。问题严重又难以解决，必须做出改变。

笔者在携程框架研发部任职，2018 年 5 月起负责 Kafka 消息系统。重点解决 Kafka 运维使用中的关键问题，建设 Kafka 消息系统应用架构体系。本文分享携程的 Kafka 应用实践。

Kafka 0.9.0 => 2.0 升级之旅

升级的紧迫性

2016 年初，携程 Kafka 升级到了 0.9.0 这一里程碑式的版本。在这个版本里，客户端去除了 zookeeper 依赖，大大提升了系统稳定性。自此以后，到 2018 年 5 月，Kafka 经历了 0.10.x，0.11.x，1.x，1.1 4 个大版本。0.9.0 之上的运维工具，如 Kafka Manager、Kafka Offset Monitor、exhibitor 等，要么停止维护，要么不再有新的功能更新。对于运维中暴露出来的问题，缺少解决方案。

• 消息发送异步变同步: producer 内部使用了一个内存池，消息进来从池上分配 1 块内存，消息发送后回收。一旦 broker 负载过重，写磁盘慢，producer 的内存池消耗快，回收慢，就会使客户端的异步的消息发送变成同步堵塞，严重影响用户的业务。

• broker 进程 crash 后无法启动: 进程有时会 crash。由于没有优雅关闭，一些磁盘数据会毁坏，导致无法再次启动。必须手工删除毁坏的数据才能启动。

• broker under replicated：发现 broker 处于 under replicated 状态，但不确定问题的产生原因，难以解决。（其实是 broker 过载，但难以排查是哪些 topic 导致，应迁移哪些 topic 的数据）

• 单副本：为缓解 under replicated 问题，采用了一个牺牲可靠性的办法，topic 从多副本变为单副本。但又引发了新的问题，broker 重启、crash，都会导致消息丢失，broker 硬件故障，更会导致 broker 相关的 topic 长期无法使用。

• 缺少历史监控：Kafka Manager 只提供运行时的指标，无历史指标，出问题后，难以分析事故原因。

• 监控指标不完善：如 topic、partition、broker 的数据 size 指标。

• 数据迁移困难：topic 一般在多个 broker 上，当某个 broker 负载重时，需要把这个 broker 上的某个（某几个）topic 的分区迁移到其它 broker。无 UI 工具可用，需要到 broker 机器上执行脚本。费力度高，低效。也缺少把 1 个 broker 上的数据整体迁移到新的 broker 上的能力。

• broker 负载不均衡：有的