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 负载不均衡：有的 broker 负载重，有的负载轻。无法自动调配。有新的工具（如 cruise-control），但由于 Kafka 版本低，无法使用。
新的 feature 无法使用：如事务消息、幂等消息、消息时间戳、消息查询等。

升级方案

Kafka 官网上明确说明高版本兼容低版本，可以从低版本透明升级。鉴于 Kafka 集群数据量大，broker 数目多，升级失败后的影响大，决定从小到大，分批次灰度升级。

测试环境升级：2 个 3 节点小集群，分 2 批次进行，持续 1 周，运行正常。
生产小集群升级：13 台机器，分 2 批次（5 台,8 台）进行，持续 1 周，运行正常。
生产大集群升级：63 台机器，分 5 批次进行（5 台，8 台，10 台，13 台，27 台），持续 3 周，运行正常。

从调研、测试到实施完成，8 月下旬到九月底，共 6 周时间，从 0.9.0 直升 2.0。升级步骤完全按照官方规范进行，感谢 Kafka 产品的优秀的兼容性。

踩到的坑

共踩到 2 个坑，都在测试环境发现。

kafka-server-stop.sh 脚本失效问题：2.0 改变了 -cp 的格式，从 lib/* 变成了 /lib/xx.jar:…，由于依赖项很多，导致命令行非常长。在 centos 7.3 上，ps 命令可以正常显示，但在 centos 6.4 和 7.1 上，会被截断，导致 grep 无法抓取到末尾的 kafka.Kafka 特征，无法定位进程。通过修改脚本解决问题。
单副本 partition 全部 offline（leader 为 -1）)：2.0 改变了配置 unclean.leader.election.enable 的默认值（从 true 变为 false），多副本时，无影响。由于 2.0 与 0.9.0 的 leader 选举的处理机制不同，升级过程中，同时存在 2.0 与 0.9.0 的 broker，对于单副本的 partition，isr 会被清空（leader 为 -1）且无法恢复。通过在 server.properties 里加入配置 unclean.leader.election.enable=true 解决。全部 broker 升级完成后，此项配置可以去除。这是一个严重的不兼容变更，如果在生产环境发现，会导致严重事故。

另外，官方文档里特别说明了应保持数据格式为 0.9.0，不要使用 2.0 格式，以免数据格式转换导致 broker cpu 利用率过高。需在 server.perperties 里加入配置：log.message.format.version=0.9.0。

常见问题的解决

broker 进程 crash 后无法启动: 升级后未再遇到此问题。并且重启（stop/start）速度更快，部分负载重的机器，升级前重启一次要花 10 分钟左右，升级后重启一般在 3 分钟以内完成。
broker under replicated：升级后可通过后文中的监控方案快速定位到流量大的 topic，迁移流量大的 topic 数据到空闲 broker，可快速降低负载。
单副本：由于升级后容易定位和解决 under replicated 问题，单副本再无必要，可恢复为正常的多副本。
缺少历史监控：升级后通过后文中的监控方案解决。
监控指标不完善：2.0 有丰富的监控指标。如关键的 Size 指标。
数据迁移困难：2.0 提供了 Admin Client。基于 Admin Client 和 Kafka Core，自研了 ops service，能方便地进行日常的 topic/partition/broker 数据迁移运维。如降低机器负载（把 1 个 broker 上部分 topic 数据迁移到其它 broker）、下线旧机器（把 1 个 broker 上的全部数据迁移到其它 broker）等。
broker 负载不均衡：新的自动 rebalance 开源工具 cruise-control（https://github.com/linkedin/cruise-control）。
新的 feature：事务消息、幂等消息、消息时间戳、消息查询（KSQL）等。
消息发送异步变同步：客户端比较分散，短期难以统一升级。但可通过后文中的服务端多集群架构改善 broker 负载，避免此问题。

基于 Prometheus 和 Grafana 的 Kafka 集群监控方案

Kafka 监控现状

0.9.0 时，broker 端主要使用 kafka-manager 作为监控工具，能看到实时的 metrics，并做了一些聚合。但数据不落地，无法进行历史数据回放。同时缺少 size 指标，无法查看 topic、partition、broker 的数据量情况。其它的工具如 Kafka Offset Monitor 和 trifecta，在数据量大时查询缓慢，基本不可用。

新的运维工具（如 cruise-control、KSQL 等），无法在 0.9.0 上使用。

Kafka JMX Metrics

Kafka broker 的内部指标都以 JMX Metrics 的形式暴露给外部。2.0 提供了丰富的监控指标，完全满足监控需要。后文中的监控截图里有常见的监控指标，完全的指标列表可通过 JConsole 查看 Kafka 的 MBeans。

可用的开源组件

Prometheus：Prometheus 是一个云原生的 metrics 时间序列数据库，具备 metrics 采集、查询、告警能力。笔者今年 3 月接触到，非常喜爱。
Grafana： metrics 可视化系统。可对接多种 metrics 数据源。
JMX Exporter：把 JMX metrics 导出为 Promethues 格式。https://github.com/prometheus/jmx_exporter
Kafka Exporter：汇聚常见的 Kafka metrics，导出为 Prometheus 格式。https://github.com/danielqsj/kafka_exporter

监控方案

JMX Exporter：部署到每台 broker 上。
Kafka Exporter：部署到任意 1 台 broker 上。
Prometheus：部署到 1 台独立机器上，采集 JMX Exporter 和 Kafka Exporter 上的数据。
Grafana：部署到 1 台独立机器上，可视化 Prometheus Kafka metrics 数据。对于 cluster、broker、topic、consumer 4 个角色，分别制作了 dashboard。

监控截图示例

Kafka 多集群解决方案

为什么要多集群

15 年，生产只搭建了 1 个集群，不到 10 个节点，但随着业务的大量接入和某些业务的不合理使用，以及驾驭能力不足（有问题加机器），生产集群扩大到 63 个节点。全公司业务混杂在一起，部分业务数据量极大。1 个 topic 数据量激增，或某个 broker 负载过重，都会影响到多个不相干业务。甚至某些 broker 的故障导致整个集群，全公司业务不可用。集群节点数目过大，也导致运维、升级过程漫长，风险极大。

迫切需要从多个不同维度把大集群分拆为小集群，进行业务隔离和降低运维复杂度。

多集群架构

原生的单集群架构

引入 1 个 meta service，改造为多集群架构

同时仍然提供统一的 client 给用户，封装多集群相关的配置（如哪个 topic 在哪个集群上），用户仍然以原生的单集群的方式使用。可以通过调整路由规则，动态地把 topic 从 1 个集群迁移到另一个集群，对用户透明。

多集群路由

单机群模式下，只需要 topic 便可进行消息的生产、消费。多集群模式下，需要知道 1 个 <cluster, topic> 二元组。客户端、topic、consuemer 的元数据，构成了影响路由的因子。根据这些路由因子，可灵活制定路由规则。

寻址过程

当路由规则变化时，client 可以近实时地感知到 (2 分钟左右），自动重启使路由规则生效。

实际案例

携程量最大的 topic，流量峰值入口 250m/s，出口 8g/s。出口流量远大于入口流量，写少读多。入口流量稳定，但出口流量经常飙升（消费者增加）。出口流量飙升，导致磁盘利用率升高，反过来大幅降低写入速度，使消息生产异步变同步，严重影响业务。由于业务设计不合理，只消费部分数据的用户，必须消费全量数据，需要把原始的 topic 数据进行处理，分拆为专用的 topic 以减少无效消费。

基于多集群架构，从 1 个集群变为读写分离的 3 个集群，降低数据写入的风险，减少无效消费。2 周左右实施完成。对消费者透明。

企业级 Kafka 应用架构

Kafka 原生的集群模式使用简单，能满足少量业务的需要。但对于大型企业（网站），大量的业务使用 Kafka，数据量、流量极大，必然同时存在多个集群，需要对用户的接入、运行时监控、集群运维提供统一的解决方案。下图是携程正在研发的解决方案，部分架构元素已开发完成并投产。将来会开源出来，回馈社区。

说明

Console UI/Service：面向用户。用于 topic/consumer/cluster 注册、配置管理、集群运维的统一的治理系统。数据落地到 DB 持久存储。待开发。
Meta Service：面向 client（producer/consumer）。从 console service 加载元数据信息（路由规则等），供 client 寻址用。已投产。
Ops Service：基于 Kafka admin client 和 Kafka core，把运维服务化，降低运维复杂度。已开发基本功能，待投产。
Kafka Clusters：按多个维度搭建的多个集群。可灵活搭建和运维变更。
Monitoring （Prometheus + Grafana）：集群监控解决方案。已投产。