导读从2019年4月计划开源到2021年1月14日开源完成，历时22个月最终取得积极成果。一路走来并不容易。没有前端，没有设计，没有产品，就找实习生，找合作伙伴，找外部资源支持。滴滴卡夫卡服务团队也进行了数次调整。它在内部迭代了三个主要版本。我们终于克服重重困难大功告成了！一经开源得到社区用户的广泛认可，截至目前Star数达到1150，钉钉用户突破540，滴滴开源Logi-KafkaManager一站式Kafka监控平台阅读1W+紫外线。01滴滴Logi-KafkaManager简介Kafka作为滴滴的大数据消息队列，承载着每天万亿条消息的生产和消费。面对100GB/S+的峰值采集流量，Kafka服务于公司近千名Kafka用户，托管数十个KafkaCluster，上万个KafkaTopic，单集群>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+节点，每周UV用户500+。需要完成主题创建、申请、指标查看等操作；每天还是有很多运维人员在做Topic的管控、治理、集群运维操作。因此，我们需要搭建一个Kafka管控平台来承载这些需求。我们调研过社区同类产品，无论是在监控指标的完善程度、运维管控的能力、服务运营的理念上，都不能很好地满足我们的需求。03滴滴Logi-KafkaManager功能亮点产品设计关注点分离业界开源的KafkaManager定位为运维人员的监控工具。在滴滴，我们将其定位为一个全托管的Kafka服务工具平台产品。目标人群分为Kafka用户、Kafka运维。Kafka用户：关注主题相关操作，主题资源申请扩容，主题指标监控，主题消费告警，主题消息采样，主题消费重置等Kafka运维：关注Kafka集群相关操作，集群监控、集群安装、集群升级、集群主题迁移、集群容量规划等。作为消息中间件，Kafka的核心能力是消息的生产和消费。频繁的用户问题与此有关。作为服务提供者，我们需要详细了解服务器端主题的生产和消费。每个环节都比较耗时，快速判断是服务端问题还是客户端问题。如果是服务端问题，是哪个环节的问题，如下图：请求队列排队时间（RequestQueueTimeMs）Broker本地处理时间（LocalTime）请求等待远程完成时间（RemoteTimeMs）请求节流时间（ThrottleTimeMs)响应队列排队时间(ResponseQueueTimeMs)响应返回客户端时间(ResponseSendTimeMs)从收到请求到完成的总时间(TotalTimeMs)通过以Topic的粒度呈现这些服务器运行指标，显着提高了服务用户的效率，如下图所示：Kafka具有强大的服务保障和强大的管控能力。各种语言的Kafka客户端版本很多，官方只能专注于维护Java版的SDK。通过版本控制，服务端扩展实现了对客户端元信息的强控制能力。拓展服务端能力，强感知客户端的链接地址和协议类型，便于后续引擎对用户行为的感知和强控。扩展并实现Kafka服务器的安全认证能力，通过账户机制记录应用元信息，包括人员信息、业务信息、权限信息；通过Topic创建管控，记录压缩类型、Partiton、Quota等元信息，实现客户端在服务端对生产和消费的强大控制。最佳实践的专家服务我们积累了多年的Kafka服务运营经验。我们积累了大量的服务保障最佳实践。结合应用场景，目前我们已经构建了以下专家服务，未来我们会不断打磨完善。主题集群分布不均的迁移：不同broker上的leader数量不均；同一个broker的不同磁盘上的领导者分布不均；同一主题在代理的不同磁盘上分布不均。我们需要发现热点并向用户推荐迁移方案。InsufficientPartitont扩容提示：根据单个Partition承载的流量，根据业务场景和底层硬件资源，提供主动扩容提示。扩展标准：滴滴的做法是TPS场景：单个Partition3MB/S；IOPS场景：单Partition10entries/S。话题无效资源下线：对于话题1个月无流量且无生产消费环节的在线资源，通知用户主动释放资源。04滴滴Logi-KafkaManager架构平台在设计之初，我们就基于开源的理念构建平台，遵循精简依赖、分层架构、API能力、100%兼容历史开源的原则版本。整体架构如下：资源层：滴滴Kafka引擎和KafkaManager除了zooppeer外只依赖msyql，精简部署方便；引擎层：滴滴Kafka引擎目前版本为2.5，我们在此基础上开发了一些自己的特性，如磁盘过载保护、IO线程池分离、主题创建资源分配优化等功能，并完全兼容与开源社区的0.10.Xkafka版本；网关层：在引擎层之上，滴滴设计了网关层，提供安全控制、主题限流、服务发现和降级能力；服务层：基于kafkaGateway，我们在滴滴Logi-KafkaManager上提供了丰富的功能，主要包括：主题管理、集群监控、集群管控能力；平台层：针对普通用户和运维用户，提供不同的功能集，日常使用中的一些高频操作尽可能在平台上进行，降低用户的使用成本。同时核心能力API化，方便用户对接生态。说到底，开源项目只是万里长征的第一步。产品还需要不断的打磨和建设，但做好事就不要为未来担忧。这是非常艰难的一年，开源技术的梦想让我们紧紧团结在一起。本文向开源带头人张文松致敬！滴滴日志-KafkaManager是团队2021年开源梦想的一小步，是滴滴日志服务套件整体开源计划的重要组成部分。欢迎关注Obsuite公众号或加入罗技滴滴用户钉钉群，并给我们的产品提出宝贵意见，欢迎小橙子推荐给有需要的技术童鞋！
