Pinterest是一个进行图片分享的社交站点。他们使用Kafka作为中心化的消息传输工具，用于数据摄取、流处理等场景。随着用户数量的增加，Kafka集群也越来越庞大，对它的管理日趋复杂，并变成了运维团队的沉重负担，因此他们研发了Kafka集群自愈和工作负载均衡工具DoctorKafka，最近他们已经在GitHub上将该项目开源。
根据Pinterest的数据工程师Yu Yang的博客文章介绍，该网站已经有1.75亿以上的用户，Pin图片的数量超过了1000亿，目前，他们在云端运行了1000个以上的Kafka broker。
在这样的规模下，每周他们都会遇到Kafka broker的故障，有时候一天之内就会遇到好几次。当broker出现故障时，待命的工程师需要及时将已经处于死亡状态的broker替换掉，从而尽可能减少数据丢失的风险。他们有时候还需要在broker之间转移工作负载，以保证整体负载的均衡。在替换broker和重新平衡工作负载时，需要非常小心地创建和编辑分区重分配文件（partition reassignment file）并手动执行Kafka脚本命令。这些操作会明显增加团队的负担。
为了扩展Kafka服务的运维规模，Pinterest构建了DoctorKafka，这是一项Kafka集群自愈和工作负载均衡的服务。DoctorKafka能够探测到Kafka broker的故障并自动将故障broker的负载转移给健康的broker。现在，Pinterest已经在GitHub上将该项目开源。
高层架构
DoctorKafka由三部分组成，如下图所示：
![20170904111535377.png]()
图1 DoctorKafka的高层架构
部署在每个broker上的指标收集器（metrics collector），它会定期收集Kafka进程和主机的指标，并将其发布到一个Kafka主题上。在这里，使用了Kafka作为broker的状态存储，这样的话，能够简化DoctorKafka的搭建过程并减少对其他系统的依赖；中心化的DoctorKafka服务会管理多个集群，分析broker的状态指标以探测broker的故障，执行集群自愈和负载均衡的命令。DoctorKafka会将执行的命令记录在另外一个名为“Action Log”主题上；用于浏览Kafka集群状态和执行流程的Web UI页面。图2展现了两个测试集群的管理界面，图3展现了其中一个集群的详细视图。
![20170904111535933.png]()
图2 DoctorKafka的前端页面
![20170904111535739.png]()
图3 DoctorKafka的集群视图
需要注意的是，DoctorKafka只会采取有把握的操作，对于不确定的情况，它会给出告警。
DoctorKafka的实际运行过程
每个broker上都会运行一个指标收集器，它会收集Kafka broker输入和输出的网络流量指标以及每个副本（replica）的状态。图4展现了指标收集器所收集的broker的部分状态。即便采用副本配额配置（replication quota setting，在Kafka 0.10.1之后可用的特性），主题分区的重分配通常也会带来额外的网络流量并且会影响到指标，因此，指标收集器在收集指标时会明确报告某个主题分区正在进行重分配。
![20170904111535242.png]()
图4 指标收集器所收集到的broker状态
DoctorKafka服务启动之后，它会首先读取broker最近24到48小时的状态，基于此，DoctorKafka会推断每个副本工作负载所需的资源。因为Kafka工作负载主要是网络密集型的，DoctorKafka主要关注副本的网络带宽使用情况。
DoctorKafka在启动之后，会阶段性地检查每个集群的状态。当探测到broker出现故障时，它会将故障broker的工作负载转移给有足够带宽的broker。如果在集群中没有足够的资源进行重分配的话，它会发出告警。与之类似，当DoctorKafka进行工作负载平衡时，它会识别出网络流量超出配置的broker，并将工作负载转移给流量更少的broker，或者是执行更优的领导者选举（leader election）方案来转移流量。
DoctorKafka已经在Pinterest运行了数月之久，并帮助其运维人员管理着1000个以上的集群。现在，他们将其开源，对于Pinterest的工程师来说，开源是非常重要的事情。读者可以访问该项目的GitHub地址获取源码和相关文档。
本文转自d1net（转载）
