【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

Kafka 2.0 升级,携程的实战经验有何可借鉴之处?

  • 2018-12-27
  • 本文字数:4477 字

    阅读完需:约 15 分钟

Kafka 2.0升级,携程的实战经验有何可借鉴之处?

AI 前线导读:这是 InfoQ 特别策划《Kafka 的七年之痒》专题系列文章的第三篇,前两篇文章回顾见《Kafka 从 0.7 到 1.0:过去 7 年我们踩过哪些坑?》《杠上Spark、Flink?Kafka为何转型流数据平台》

背景

早在 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):集群监控解决方案。已投产。

作者介绍

赵强,携程框架研发部技术专家。曾负责 SOA 框架,主导携程大规模服务体系架构建设。现负责 Kafka 消息系统。专注于服务、配置、消息、监控等领域。


2018-12-27 08:008387

评论 3 条评论

发布
用户头像
赞了,很多是业务逼出来的;
2018-12-27 22:34
回复
用户头像
很棒
2018-12-27 10:31
回复
没有更多了
发现更多内容

关于 SAP ABAP 字符变量和字符串变量字符个数的一个知识点,和一个血案

Jerry Wang

后台开发 abap Netweaver 字符串处理 6 月 优质更文活动

Nautilus Chain测试网迎阶段性里程碑,模块化区块链拉开新序幕

西柚子

华为云数据库GaussDB:数字化转型的可信之选

YG科技

DEVONthink Pro 3 for Mac:Mac强大的文档管理工具

背包客

macos 文档管理软件 Mac软件 DEVONthink Pro DEVONthink

深度学习应用篇-元学习[16]:基于模型的元学习-Learning to Learn优化策略、Meta-Learner LSTM

汀丶人工智能

人工智能 深度学习 元学习 元强化学习 6 月 优质更文活动

WWDC2023 Session系列:探索XCode15新特性 | 京东云技术团队

京东科技开发者

xcode wwdc session WWDC 2023 企业号 6 月 PK 榜

聚焦企业实践一线与个体职业成长|2023开放原子全球开源峰会OSPO分论坛成功举办

开放原子开源基金会

开源 开放原子全球开源峰会 OSPO 开放原子

【Netty】「萌新入门」(三)ChannelFuture 与 CloseFuture

sidiot

Java 后端 Netty 6 月 优质更文活动

重拾梦想!语音交友源码平台搭建技术知识:在线KTV功能的实现

山东布谷科技

软件开发 在线KTV 源码搭建 语音交友源码

激活SBOM内生价值 推动供应链体系建设健康有序|2023开放原子全球开源峰会软件物料清单(SBOM)分论坛成功举办

开放原子开源基金会

开源 开放原子全球开源峰会 开放原子 软件物料清单(SBOM)

深度学习应用篇-元学习[15]:基于度量的元学习:SNAIL、RN、PN、MN

汀丶人工智能

人工智能 深度学习 元学习 元强化学习 6 月 优质更文活动

NestJs 管道(Pipe)

小鑫同学

typescript 后端 nestjs 6 月 优质更文活动

中兴交换机如何配置?有哪些常用的配置命令,本文值得收藏!

wljslmz

6 月 优质更文活动

2023开放原子全球开源峰会OpenCloudOS社区年会顺利举行

开放原子开源基金会

开源 开放原子 OpenCloudOS社区

阿里资深专家撰写出的Nginx底层与源码分析手册,GitHub已爆赞

互联网架构师小马

nginx

【C/C++】extern 的一些注意事项

sidiot

c 6 月 优质更文活动

Sentinel适配Reactor+WebFlux框架的实现原理

互联网架构师小马

Java reactor sentinel WebFlux

Spring的核心概念:Spring基础框架及技术生态

互联网架构师小马

Java spring 框架

SUSE:强化零信任、自动化和易用性,筑牢云原生安全防线

Rancher

k8s security Kubernets

这项国家级安全检测,腾讯云慧眼安全能力再获认可!

牵着蜗牛去散步

人工智能 腾讯云 网络安全 腾讯云AI 腾讯云慧眼人脸核身

华为云数据库GaussDB:数字化转型和可持续发展的更优选择

YG科技

ChatGPT+Mermaid自然语言流程图形化产出小试 | 京东云技术团队

京东科技开发者

流程图 ChatGPT 企业号 6 月 PK 榜 Mermaid

飞桨携手第二届GitLink开源夏令营,邀你参与顶尖开源项目!

飞桨PaddlePaddle

人工智能 百度 飞桨

Alibaba官方上线!SpringBoot+SpringCloud全彩指南

互联网架构师小马

Java 微服务 Spring Cloud Spring Boot

华为云数据库GaussDB:给世界一个更优选择

YG科技

行业翘楚论道未来想象|2023开放原子全球开源峰会云原生分论坛圆满落幕

开放原子开源基金会

开源 云原生 开放原子

STM32L0 ADC使用HAL库关于校准问题的说明

矜辰所致

STM32L051 ADC 6 月 优质更文活动

混沌演练状态下,如何降低应用的MTTR(平均恢复时间) | 京东云技术团队

京东科技开发者

混沌工程 系统安全 MTTR 企业号 6 月 PK 榜

软件测试/测试开发丨Python 闭包函数&装饰器

测试人

Python 程序员 软件测试 装饰器 函数

VSD Viewer for Mac:Visio绘图文件阅读器

背包客

macos Mac软件 Visio文件查看工具 Visio Viewer for Mac VSD Viewer

深入理解 ABAP Reference 变量

Jerry Wang

SAP abap Netweaver 6 月 优质更文活动

Kafka 2.0升级,携程的实战经验有何可借鉴之处?_语言 & 开发_赵强_InfoQ精选文章