KBear: A Kafka Enterprise Solution

License

Features

Deploy & Usage

Cluster Deploy

KBear Solution

Production Case

携程Kafka 2.0升级实战

Developers

目录

背景

早在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等,要么停止维护,要么不再有新的功能更新。对于运维中暴露出来的问题,缺少解决方案。

升级方案

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

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

踩到的坑

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

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

常见问题的解决

基于 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。

可用的开源组件

监控方案

监控截图示例

kafka-cluster

kafka-broker

kafka-topic

kafka-consumer

Kafka 多集群解决方案

为什么要多集群

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

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

多集群架构

原生的单集群架构

simple-cluster

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

multi-cluster

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

多集群路由

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

route-rule

寻址过程

routing

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

实际案例

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

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

multi-cluster-topicA

企业级 Kafka 应用架构

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

kafka-enterprise-arch

说明