导读
从2019年4月份计划开源到2021月1月14号完成开源，历时22个月终于修成正果，一路走来实属不易，没有前端、设计、产品，我们找实习生、合作方、外部资源支持，滴滴Kafka服务团队人员也几经调整，内部迭代了3个大版本，我们最终还是克服重重困难做到了！一经开源获得了社区用户广泛的认可，截止当前Star达到1150，钉钉用户突破540人，滴滴开源Logi-KafkaManager一站式Kafka监控与管控平台阅读1W+UV。
01滴滴Logi-KafkaManager简介
Kafka作为滴滴大数据消息队列，每天承载万亿级消息的生产与消费，面对100GB/S+峰值采集流量，服务了公司内近千Kafka用户，托管了数十Kafka集群，数万Kafka Topic，单集群>300+Broker。历经四年打磨沉淀，围绕滴滴Logi-KafkaManager打造了滴滴Kafka平台服务体系，内部满意度达到90分。
滴滴LogI-KafkaManager是面向Kafka用户、Kafka运维人员打造的共享多租户Kafka云平台，专注于Kafka资源申请、运维管控、监控告警、资源治理等核心场景。一经开源广受社区用户喜爱，免费体验地址：http://117.51.150.133:8080/kafka，账户admin/admin，欢迎Star。
02为什么要开发
滴滴Logi-KafkaManager
滴滴内部有几十个kafka集群，450+的节点，每周500+UV用户，需要完成topic创建、申请、指标查看等操作；每天运维人员还有大量topic管控、治理、集群运维操作。因此我们需要构建一个Kafka的管控平台来承载这些需求。我们调研了社区同类产品，在监控指标的完善程度、运维管控的能力、服务运营的理念都无法很好的满足我们的需求。
03滴滴Logi-KafkaManager功能亮点
产品化设计之关注点分离
业界开源的KafkaManager定位是一个面向运维人员的监控工具，在滴滴我们定位是全托管Kafka服务工具型平台产品，针对的人群区分为Kafka用户、Kafka运维。
Kafka用户：关注的是Topic相关的操作，Topic资源申请与扩容、Topic指标监控、Topic消费告警、Topic消息采样、Topic消费重置等。
Kafka运维：关注的是Kafka集群相关的操作，集群监控、集群安装、集群升级、集群Topic迁移、集群容量规划等。
Kafka业务运行过程数据化
作为消息中间件，Kafka最核心的能力就是消息的生产、消费，用户高频的问题都与此相关，作为服务提供方，我们需要详细的感知Topic的生产消费在服务端各个环节耗时，快速界定到底是服务端还是客户端问题，如果是服务端问题，出在哪个环节，如下图所示：
请求队列排队时间(RequestQueueTimeMs)
Broker本地处理时间(LocalTime)
请求等待远程完成时间(RemoteTimeMs)
请求限流时间(ThrottleTimeMs)
响应队列排队时间(ResponseQueueTimeMs)
响应返回客户端时间(ResponseSendTimeMs)
接收到请求到完成总时间(TotalTimeMs)
通过将这些服务端运行指标，以Topic粒度呈现，显著的提升了服务用户的效率，如下图所示：
Kafka服务保障强管控
Kafka各语言客户端版本众多，官方也只有精力维护Java版的SDK，滴滴受限于服务人力，没有进行客户端版语言与版本管控，服务端拓展实现强管控客户端元信息的能力。
拓展服务端能力，强感知客户端的链接地址，协议类型，方便后续引擎对用户行为的感知与强管控。
拓展实现Kafka服务端的安全认证能力，通过账号机制记录应用元信息，包括人员信息、业务信息、权限信息；通过Topic创建管控，记录压缩类型、Partiton、Quota等元信息，在服务端实现了对客户生产、消费能的强管控。
最佳实践之专家服务沉淀
多年Kafka服务运营经验，我们沉淀了大量的服务保障最佳实践，结合应用场景，截止目前构建了以下几项专家服务，后续我们会持续打磨与完善。
Topic集群分布不均迁移：不同broker上leader数目不均；同一个broker上不同磁盘leader分布不均；同一个topic在broker上不同磁盘分布不均。我们需要发现热点，给用户推荐迁移计划。
Partitont不足扩容提示：根据单Partition承载流量，按照业务场景与底层硬件资源进行主动扩容提示，扩容标准：滴滴的实践是TPS场景：单Partition 3MB/S；IOPS场景：单Partition 10条/S。
Topic无效资源下线：针对线上持续一个月Topic无流量，无生产消费链接的资源，通知用户进行主动资源释放。
04滴滴Logi-KafkaManager架构
平台设计之初，我们就基于开源的理念进行平台建设，遵循了依赖精简、分层架构、能力API化、100%兼容历史开源版本的原则，整体架构如下：
资源层：滴滴Kafka引擎和KafkaManager除了 zookpeer之外只依赖msyql，依赖精简，部署方便；
引擎层：当前滴滴kafka引擎版本是2.5，我们在此基础上开发了一些自己的特性，如磁盘过载保护、IO线程池分离、Topic创建资源分配优化等功能，并且完全兼容开源社区的 0.10.X kafka版本；
网关层：引擎层之上滴滴设计了网关层，提供了安全管控、topic 限流、服务发现、降级能力；
服务层：基于kafkaGateway我们在滴滴Logi-KafkaManager上提供了丰富的功能，主要有：topic管理、集群监控、集群管控能力；
平台层：分别针对普通用户和运维用户，提供不同的功能集合，尽可能的将一些日常使用中的高频操作在平台上进行承接，降低用户的使用成本，同时核心能力API化，方便用户生态对接。
写在最后
项目开源只是万里长征的第一步，产品还需要持续的打磨与建设，但行好事莫问前程，感谢那些曾经为这个项目付出努力的童鞋们，特别是当前团队的兄弟们，过去一年非常不容易，开源的技术梦想让我们紧密的团结在一起，以此文向开源的领路人章文嵩致敬！