Kafka近年来日渐流行，LinkedIn的1800台Kafka服务器每天处理2万亿个消息。虽说Kafka运行得十分稳定，但要大规模运行Kafka，在运维方面仍然面临巨大的挑战。每天都会有broker崩溃，导致集群工作负载不均衡。SRE团队需要花费大量的时间和精力来重分配分区，以便让集群重新恢复均衡。
自动化因此变得十分重要，这也就是为什么我们要开发Cruise Control：持续监控Kafka集群，自动调整分配给服务器的资源，达到预期的性能目标。用户设定目标，Cruise Control对集群的工作负载进行分析，并自动执行一些操作来达成目标。
Cruise Control即日起在GitHub上开源。在这篇文章里，我们将介绍Cruise Control的使用场景、它的架构以及我们在开发Cruise Control过程中面临的挑战。
设计目标
可靠的自动化： Cruise Control要准确地分析集群的工作负载，生成无需人工介入的执行计划。资源有效性： Cruise Control要智能地执行操作，不会影响集群处理正常的工作负载。可扩展性： Kafka用户对可用性和性能会有不同的需求，还可能使用各种不同的部署工具、管理端点和度量指标收集机制。Cruise Control必须能够满足用户定义的各种目标，并执行用户定义的操作。通用性：尽管很多现有的产品可以用于均衡集群的资源，但它们大部分都与应用程序毫无关联，需要通过迁移整个应用进程来恢复均衡。这类产品对于无状态的系统来说是没有问题的，但对于有状态的系统来说就会显得有点力不从心，因为这类系统的很多状态与应用进程相关联。因此，我们希望Cruise
Control会是一个能够了解应用程序的通用性框架，在恢复均衡时只需要进行一小部分状态迁移。
Cruise Control在LinkedIn的应用
Cruise Control在LinkedIn主要解决以下几个问题。
保证Kafka集群资源的均衡：磁盘、网络和CPU。如果有broker崩溃，自动将副本重新分配给其他broker，并重置复制系数。识别出消耗资源最多的主题分区。在扩展集群或broker退役时只需要少量的人工介入。支持异构的Kafka集群以及单台主机部署多个broker实例。
Cruise Control的工作原理
Cruise Control遵循的是“监控——分析——行动”这样的工作流程。下图是Cruise Control的架构图。大部分组件都是可插拔的，如度量指标取样器（metric sampler）、分析器（analyzer）等。
REST API
Cruise Control为用户提供了一组REST API，可以用于查询Kafka集群的工作负载情况或触发管理操作。
负载监控器
负载监控器从集群收集Kafka的度量指标和每个分区的资源度量指标，并生成集群工作负载模型，包括磁盘使用情况、CPU使用情况、流量流入速率、流量流出速率等，然后把模型发送给探测器和分析器。
分析器
分析器是Cruise
Control的“大脑”，它根据用户提供的优化目标和来自负载监控器的工作负载模型来生成优化计划。用户可以配置优化计划的优先级，还可以分别设定硬性目标和软性目标。硬性目标是指必须达成的目标（例如必须根据机架来分配副本的位置），软性目标是指在优先满足硬性目标的前提下有可能得不到满足的目标。
硬性目标
根据机架来安排副本的位置，即同一个分区的副本必须被放在不同的机架上，这样可以减少硬件崩溃给Kafka集群带来不利的影响。broker的资源使用必须处在预定义的阈值内。网络使用不能超过预定义的容量。如果一个broker的所有副本都成为首领，那么所有的消费者流量都会被重定向到这个broker上，导致网络流量膨胀。
软性目标
让集群所有的broker使用相同的资源。让所有broker的首领分区达到相同的流量流入速率。让主题的分区均匀地分布在所有broker上。在所有broker上均匀地分布分区副本。
探测器
探测器主要用于探测两种类型的异常。
broker失效：比如一个非空闲的broker离开集群，导致分区不同步。因为这种情况在集群正常重置时也会发生，所以探测器在触发告警之前会预留一段时间，如果不是正常重置，就会触发告警并进行修复。偏离目标：如果启用了自愈功能，Cruise Control会尝试通过分析工作负载并执行优化计划解决问题。
执行器
执行器负责执行由分析器生成的优化计划。Kafka集群的再均衡通常会涉及重新分配分区，执行器要对资源保持感知，避免拖垮broker。分区重分配可能需要很长时间，一个大型的集群可能需要几天时间才能完成一次分区重分配。有时候，用户希望能够停止正在进行的分区重分配，所以执行器需要确保能够安全地中断执行计划。
有趣的挑战
在开发和使用Cruise Control时，我们遇到了很多有意思的挑战。
为Kafka构建可靠的集群工作负载模型
这个比看上去的要难得多，需要考虑到很多细节。例如，从broker上收集CPU度量指标是很容易的，但我们该如何量化每个分区的CPU使用情况？这个Wiki页对这个问题进行了解释。
你们愿意花多少时间在一个优化计划上？
分析器组件经历了一个漫长的演化过程。我们最开始使用了一个具有复杂配置功能的通用优化器，它需要几周的时间才能得到一个中型Kafka集群的优化计划。后来，我们改用现在的优化器，可以在几分钟之内得到一个较好的结果。
内存与速度的权衡
Cruise
Control是一个内存密集型的应用，因为它需要在内存里保存度量指标一段时间，以便分析流量模式。同时，它也是一个CPU密集型的应用，因为它需要大量的计算来生成优化计划。这两者之间存在冲突关系。为了加快生成优化计划，我们需要缓存更多的数据，进行更多的并行计算，但这样会使用更多的内存。我们需要在这两者之间做出权衡。例如，我们会预计算优化计划并缓存起来，当用户发起查询时就不需要等待那么长时间。另外，我们会交错执行内存密集型的任务，避免同时消耗大量内存。
未来的工作
更多的集群优化目标
Cruise Control的优化组件是可插拔的，用户有可能会根据实际需要提出各种复杂的优化目标。作为一个开源项目，我们鼓励用户创建自己的优化目标，并把它们贡献给社区。
与云管理系统集成
目前，Cruise Control通过移动失效broker的分区让集群保持正常运行。我们希望后续能够与云管理系统集成起来，实现自动集群扩展，或者使用空闲实例替换失效的broker实例。
增强运维洞见
Cruise Control分析从Kafka收集而来的度量指标，帮助SRE团队量化各种资源度量指标的影响程度，提升容量规划和性能调优的能力。
通用性
我们在开发Cruise
Control时就意识到动态负载均衡器对于分布式系统来说是非常重要的。用于聚合度量指标、分析资源使用情况、生成优化计划的Cruise
Control组件同样适用于其他分布式系统。从长远来看，我们想把这些核心组件抽象出来，用在其他的项目上。
本文转自d1net（转载）