导读：LogI-KafkaManager 脱胎于滴滴外部多年的 Kafka 经营实践经验，是面向 Kafka 用户、Kafka 运维人员打造的共享多租户 Kafka 云平台。专一于 Kafka 运维管控、监控告警、资源治理等外围场景，经验过大规模集群、海量大数据的考验。外部满意度高达 90% 的同时，还与多家知名企业达成商业化单干。

滴滴外部对立应用 kafka 作为大数据的数据通道，以后滴滴共有几十个 kafka 集群，450+ 的节点，20k+ 的 kafka topic，每天 2w 亿 + 的音讯量；每周 500+UV 用户，须要实现 topic 创立、申请、指标查看等操作；每天运维人员还有大量集群、topic 运维操作。因而咱们须要构建一个 Kafka 的管控平台来承载这些需要。

在平台建设的初期，咱们调研了社区同类产品的应用状况，在调研中发现，内部同类产品无论在监控指标的欠缺水平、运维管控的能力亦或是应用的体验、还是整体的平安管控上都无奈很好的满足咱们的需要，因而自建滴滴 kafka 云管控平台势在必行。

通过后期产品同学的重复调研和设计、中期研发同学高质量的实现、前期针对用户体验反馈的继续迭代，kafka 云平台上线后广受外部用户和运维人员的好评，应用满意度达到 90 分。与此同时，还进行了开源 (https://github.com/didi/Logi-…，并被多家企业用户胜利洽购。
收费体验地址：http://117.51.150.133:8080/kafka，账户 admin/admin。

1. 需要剖析

=========
在 Kafka 云平台建设的初期，咱们对之前所面临的问题和需要进行了演绎剖析，次要有以下几点：

数据安全性

因为绝大多数用户应用的 kafka topic 都会由公共集群来承载数据的生产和生产，而以后 kafka 引擎在 topic 级别的平安管控伎俩较为单薄，任何人只有晓得 kafka 集群地址和相应的 topic 便可进行生产。这无疑会造成数据透露的平安危险，因而数据的安全性成首要被解决的问题。

服务的稳定性

滴滴外部绝大部分的 topic 是在共享集群上，共享集群下多 topic 之间存在着相互影响的问题。如某个 topic 的流量突增可能会大面积地影响其余 topic，从而导致业务的抖动和集群的不稳固。因而在共享集群下，kafka 服务的稳定性也成为了一个必须被解决的问题。

用户应用敌对性

滴滴外部每周有大量的用户须要进行 topic 的创立、生产、扩 partiton、指标查看等操作，用户高频应用的性能须要做的足够的敌对和容易上手，这样能力最大的简化用户的操作和减低日常开发和运维人员的答疑老本。因而用户高频操作的平台化撑持，则成为接下来须要解决的问题。

问题定位高效性

在日常应用 kafka topic 的过程中，会有大量的问题须要查看和定位，如：音讯生产和生产的速度、音讯沉积的水平、partition 的均匀度、topic 的散布信息、broker 的负载信息、正本的同步信息等，如何使用户和运维人员疾速高效的定位问题、解决问题，是重点须要解决的问题。

运维管控便利性

在日常的运维中，会存在着大量的集群、topic 的运维操作，如：集群的部署、降级、扩缩容、topic 的迁徙、leader rebalance 等高频高危的操作，怎么样在晋升运维操作效率的同时，还要保障高危操作不会影响集群稳定性，这个也是须要去重点思考。

1. 整体设计

=========
从以上的需要剖析能够看出，滴滴 kafka 云平台建设须要解决的问题比拟多元，因而在设计之初就须要对整体有一个清晰的思路和布局，为此咱们定义了一个外围设计准则，并对业务进行了正当的分层用以领导咱们后续的产品设计和代码开发。

▍1. 外围设计准则

在平台的整体设计上，咱们制订了“一点三化”的设计准则：

·一点：以平安和稳固为外围点，建设 kafka 的网关零碎，针对 topic 的生产 / 生产提供平安校验，同时提供多租户的隔离计划解决共享集群下多 topic 相互影响的问题；

·平台化：着重建设 kafka 云平台，重复进行需要调研和产品设计，提炼用户和运维的高频操作，将这些操作都通过平台实现，升高用户的应用老本；

·可视化：晋升 topic/ 集群监控、运维过程中指标的可察看性，所有指标尽量能在平台上能够直观体现，不便使用者及时感知集群运行状态，疾速定位问题；

·专家化：将日常集群运维的教训积淀在平台上，造成专家服务能力和智能化能力，进一步升高 kafka 集群的保护老本，晋升整体稳定性。

▍2. 业务分层架构

在滴滴 kafka manager 具体的业务设计上，咱们采取分层设计，从下至上分为以下几层：

·资源层：滴滴 kafka 引擎和 kafka manager 除了 zookpeer 之外只依赖 msyql，依赖精简，部署不便；

·引擎层：以后滴滴 kafka 引擎版本是 2.5，咱们在此基础上开发了一些本人的个性，如磁盘过载爱护，并且齐全兼容开源社区的 kafka；

·网关层：引擎层之上咱们设计了网关层，网关层的设计十分奇妙，次要提供：平安管控、topic 限流、服务发现、降级能力，具体详见后文“安全性”的内容；

·服务层：基于 kafka gateway 咱们在 kafka manager 上提供了丰盛的性能，次要有：topic 治理、监控治理、集群治理等；

·平台层：对外提供了一套 web 平台，别离针对普通用户和运维用户，提供不同的性能页面，尽可能的将一些日常应用中的高频操作在平台上进行承接，升高用户的应用老本。

▍3. 应用逻辑架构

在理论的利用部署和关联上，整体的 kafka manager 和 kafka 引擎、kafka gateway 之间的逻辑关系比较简单，具体如下图所示：

·kafka gateway 包含两大块性能：服务发现、元数据网关，具体介绍见前面的元数据网关设计一节。

·kafka manager 提供咱们开发的特色性能，如：topic 治理、监控治理、集群治理，以及相应的 web 平台，普通用户和研发运维人员日常操作接触最多，最高频的操作都将这下面实现。

1. 安全性

=========
以 kafka 数据的安全性和集群应用过程中的稳定性保障是咱们在构思和设计整个 kafka 云平台时首要思考的问题，为此咱们设计了一套 kafka 元数据网关和多租户的隔离模型来解决这些问题。

▍1. 元数据网关设计

用户在接入原始的 kafka 集群时没有平安管控，无奈无效的治理用户的应用行为，对数据安全和集群稳定性造成重大的危险，因而咱们设计了一套 kafka 集群元数据网关零碎来解决平安问题。

kafka gateway 零碎除了解决数据的平安危险还附带了以下作用：

·提供 kafka 集群的服务发现服务节点，这样用户在应用 kafka 集群服务时，当 kafka cluster boostrap 地址变更时，则不须要用户改变 kafka 的连贯地址，不必重启 kafka client，保障集群的变更对用户通明；

·提供 kafka topic 生产和生产的限流能力，防止用户无限度的应用集群的流量，流量大的用户会耗尽系统资源从而影响其余用户的应用，造成集群的节点故障；

须要注明阐明一点，kafka gateway 的设计很奇妙的将这些性能实现在 kafka 引擎外部。因为 kafka 作为一个音讯零碎，其自身流量是十分的微小，如果 kafka gateway 作为一个独自利用存在，所有流量都先通过 gateway 再进入 kafka 引擎，则对 kafka gateway 机器资源的耗费是十分微小的，根本等同于须要增加一倍的机器资源，并且整个流程的耗时也会减少。所以在设计之初，就把 kafka gateway 和 kafka 引擎合在一起，这便是滴滴 kafka 引擎的特色能力所在。

搭建好 kafka gateway 零碎之后，用户应用 kafka topic 的流程变为如下：

·在 kafka manager 上申请租户(appid)，获取到对应的租户明码(app-password)；

·利用 appid 申请创立新的 topic，或者申请已存在的 topic 的生产和生产权限；

·应用 kafka client 时设置好对应的 appid 和 app-password，相应的 topic 鉴权，限流都在 kafka broker 端实现。

▍2. 多租户隔离模型

在滴滴外部，绝大部分的 topic 是在共享集群上的，在没有管控的状况下，topic 的各个分区是随机的散布在不同的 broker 上，随着集群中 topic 数量的减少，topic 流量的变大，某个具体 topic 的抖动有可能会影响到其余的 topic，因而共享集群下的 topic 隔离就是十分必要的，为此咱们联合 kafka gateway 在 kafka manager 上设计了一套多租户隔离模型来解决这个问题，具体操作如下：

·对将 kafka 集群中的各个 broker 进行划分，一组 broker 被分成一个 region，这个 region 在业务上被形象为一个逻辑集群；

·用户在申请创立新的 topic 时须要抉择一个逻辑集群，这样 topic 的分区只能创立在一个逻辑集群上，也就是一组 broker 上；

·具体 topic 音讯的生产和生产就只会和一组 broker 产生关系，如果某个 topic 的抖动也只会影响特定 broker 上的其余 topic，从而将影响限定在肯定的范畴内。

1. 平台化

=========
滴滴 kafka manager 平台建设之初就把易用性作为次要指标，因而在产品设计上十分重视用户的应用体验，后期通过重复的用户调研和外部探讨，最终提炼出普通用户和运维用户的高频操作，将这些操作都通过平台实现，升高用户的应用老本。

·不便的日常用户应用

用户只关注本人的 Topic 的信息(默认)，以缩小不必要信息的烦扰；

足够的指标信息，以保障用户能自助解决问题的同时缩小不必要信息的烦扰；

·高效的运维操作

提炼用户、运维人员创立 Topic、调整配额、扩大分区、集群迁徙、集群重启等高频运维操作，将高频操作平台化，简化用户操作，大大降低运维老本。

提供整体集群直观的全局视角，以进步排查问题的效率以及对集群规模的直观感知，并提供详尽的部分视角，以进步排查问题的效率；

·敌对的生态

外部版本与滴滴监控零碎买通，开源版本与滴滴开源的夜莺监控告警零碎买通，集成监控告警、集群部署、集群降级等能力，造成运维生态，凝练专家服务，使运维更高效。

·体贴的细节

kafka 云平台的建设，它有着本人的设计理念，如：利用、权限、限流等；kafka 集群的 broker 和 topic 的上也存在着各种指标，操作工作，审批流程等，这些都会对用户的应用造成困惑。尽管产品同学在重复的体验和继续的优化迭代，然而为了进一步的不便用户应用，咱们在各种用户可能感觉到困惑指标含意的中央，设置了大量的提醒阐明，让用户不必出页面就能够根本解决问题，整个应用过程力争如丝般顺滑。

·出众的颜值

常见的外部工具型产品往往都是以满足性能和需要为主，很多都是性能在页面上的堆砌，kafka 云平台在建设之初，在产品设计和前端开发上也力求更高的规范，最终整体的格调相比以往晋升微小，一上线就被用户称誉为“大厂出品”，相比目前几款支流开源的 kafka 治理平台，在页面好看水平上大大超出其余同类产品，能够说是“我花开后百花杀”。

1. 可视化

=========

运维人员在日常进行 kafka 集群保护和稳定性保障过程中，对集群和 topic 的各项指标都十分关注，因而指标采集展现的准确性和及时性变得十分重要。为此咱们将指标的可视化也作为 kafka manager 建设的外围指标。

·黄金指标定义

针对 broker 和 topic 日常监控和诊断问题过程中最次要的指标进行筛选，这些指标被定义为黄金指标，如：topic 的 messageIn、byteIn 等，并在平台的相干页面上进行高优高亮展现，便于用户在日常应用过程中，疾速诊断和定位集群可能存在的问题。同时咱们还依据 broker 和 topic 的指标监控，制订了一套用于疾速辨认其运行状态的衰弱分算法，将多个指标进行加权计算，最终失去一个衰弱分数值，衰弱分的高下则直观的展现了 broker 和 topic 理论运行过程中的状态，便于用户和运维疾速从多个 broker 和 topic 中辨认。

·业务过程数据化

减少基于 topic 生产生产各环节的耗时统计，反对动静开启与敞开，帮忙用户自助排查问题；要害指标业务运行过程化，不同分位数性能指标的监控，不便历史问题回溯诊断。

·服务端强管控

服务端记录客户端连贯版本和类型，连贯强感知，集群强管控，元信息的基石；controller 强管控，指定的主机列表，记录 controller 历史运行节点；记录 topic 的压缩格局，利用与业务元信息，业务强感知。

1. 专家化

=========

基于之前全面的 kafka 数据采集，和运维同学在日常操作过程中的一些经验总结，咱们将高频的问题和操作积淀造成特有的专家服务，来智能诊断 kafka 集群和 topic 的衰弱状态，并提供对应的解决计划。

kafka manager 的专家服务能提供了以下性能：

·分区热点迁徙

a.背景：Kafka 只具备 Topic 迁徙的能力，然而不具备主动平衡的能力，Region 内局部 Broker 压力十分大，然而局部 Broker 压力又很低，高下不均。如果不立刻解决，轻则无奈持续承接用户的需要，重则因为局部 Broker 压力过大导致集群呈现稳定性问题。

b.解决方案：

i. 在滴滴 kafka 引擎上减少 topic 在不同磁盘上散布的指标；

ii. kafka manager 通过定时采集的 topic 指标来剖析 topic 在不同磁盘上的散布均匀度；

iii. 针对不平均的 topic 发动迁徙操作，并在迁徙时进行流量管制，保障迁徙不会影响集群的稳定性。

·分区有余扩容

a.背景：kafka 集群的 topic 相干的元信息存储在 zookpeer 上，最终由 controller 将其同步到各个 broker。如果元信息过大，controller 同步的压力就会随之回升成为整个集群的瓶颈点，如果遇到某台 broker 呈现问题，整个集群的数据同步就十分慢，从而影响稳定性。

b.解决方案：

i. 在用户申请创立 topic 的时候，平台进行分区数的管控，分区数不能设置的特地大，然而随着 topic 流量的回升，topic 分区可能有余。如果遇到 topic 流量突增，超过了单分区能承载的能力，会导致分区所在的 Broker 呈现压力，如 cpu 和 load 升高等问题，客户端也会呈现发送沉积的状况。

ii. 基于现有的机型以及客户端的生产发送能力的压测，咱们定义了单分区的承载流量，同时咱们实时对每个 topic 的流量进行监控，当某个 topic 的峰值流量继续的达到和超过阈值之后，会对该 topic 进行标记或者告警，定义为分区有余的 topic。

iii. 针对监控发现进去的分区有余的 topic，由运维人员手动进行扩分区，或者 kafka manager 依据以后集群整个容量状况主动进行扩分区。

·topic 资源治理

a.背景：公共集群中用户申请创立的 topic，它们的应用状况是各不相同的，还存在着局部 topic 基本不应用还占据集群元数据的状况，这对原本就非常拥挤的公共集群造成很大的资源节约和稳定性危险，因而针对集群中的不应用的 topic 进行治理就十分必要。

b.解决方案：

i. 实时对集群中所有 topic 的流量进行采集监控，智能的剖析 topic 的流量趋势，如果发现 topic 的流量继续在一段时间内为 0，则进行标记或者告警。

ii. 针对监控发现的肯定周期无流量、无生产生产链接的 topic，进行告诉和下线清理操作。

1. 同类比照

=========

咱们来和内部相似的产品进行一个简要的性能比照如下：

通过简略的比照，咱们能够看到，通过平台化、可视化、智能化、平安建设之后，滴滴 kafka manager 在安全性、用户体验、监控、运维管控上都有着显著的劣势，也提供了很多特色的性能，极大的不便了用户和运维人员的日常应用，欢送大家 Star 和体验 https://www.didiyun.com/produ…

1. 瞻望

=========

Logi-Kafka-Manager 已在滴滴外部上线应用，将来咱们除了在平台化、可视化、智能化根底上继续改良，还会在以下几个方面继续致力：

·平滑的跨集群迁徙

咱们将基于 MirrorMaker + KafkaGateWay 打造一套 kafka Topic 跨集群平滑迁徙能力，在 kafka manager 平台上为 kafka topic 运维管控提供更为高效的迁徙能力，进一步晋升运维效率。

·更多的指标监控

进一步的反对 kafka 2.5+ 最新版本的管控，并且新增更多的要害指标的监控，从而让 kafka manager 指标展现和问题定位的能力更弱小。

·继续回馈开源社区

作为在滴滴外部通过大量简单场景验证过的 kafka 管控平台，咱们会继续对其进行外围业务形象，剥离滴滴外部依赖，回馈社区，咱们也心愿热心的社区同学和咱们交换想法，独特晋升滴滴 Logi-KafkaManager 的性能和体验

开源团队

本文由博客群发一文多发等经营工具平台 OpenWrite 公布