前言
滴滴自建Kafka云管控平台从2019年4月份计划开源到2021月1月14号完成开源，内部迭代了3个大版本，历时22个月修成正果，一经开源便获得了社区用户广泛的认可，截止当前项目Star达到1.9k，钉钉用户突破688人。
（长按上方二维码即可查看Github项目详情）
感兴趣的可以点个Star✨收藏一下
01、滴滴Logi-KafkaManager发展历程
在滴滴内部使用Kafka的过程中出现了很多问题，例如：集群、Topic数量众多，业务场景复杂，不易管理；超高的消息量给集群造成巨大压力；用户操作、运维操作高频且复杂，使用成本较高。
与此同时，社区同类产品，在运维管控能力、指标监控能力、平台角色视角、用户使用体验等方面都不能满足我们的需求。
所以滴滴最终选择自建Kafka运维管控平台。
经过近五年的沉淀，多个版本的迭代。现在滴滴Logi-KafkaManager承载着滴滴内部几十个Kafka 集群，近千台机器，超过20k的 Kafka Topic，每天超过2w亿的消息量。并且在集群服务稳定性、运维能力完善性、界面使用友好性等方面都有着出色表现。
02、滴滴Logi-KafkaManager设计理念
滴滴Logi-KafkaManager围绕着“一点三化”的产品设计理念：
一点： 指的是以数据安全为核心点。建立多租户隔离模型，生产/消费鉴权；
平台化：指的是提炼用户和运维的高频操作。运维操作平台化；
可视化：指的是监控Topic/集群核心指标。监控指标可视化；
专家化：指的是沉淀日常集群运维的经验。资源治理专家化。
滴滴Logi-KafkaManager在架构上采用业务分层架构，分别是：
资源层：只依赖zookeeper与mysaql，依赖精简，部署方便；
引擎****层：使用的滴滴 2.5版本的Kafka 是在完全兼容开源社区版本Kafka引擎的基础上开发了一些自己的引擎特性，如磁盘过载保护等；
网关层：引擎层之上我们设计了网关层，主要提供：安全管控、Topic 限流、服务发现、降级能力等；
服务层：基于Kafka gateway 我们在 Kafka manager 上提供了丰富的功能，主要有：Topic 管理、监控管理、集群管理等；
平台层：对外提供了一套 web 平台，分别针对普通用户和运维用户，提供不同的功能页面，将一些日常使用中的高频操作在平台上进行承接，降低用户的使用成本。
滴滴Logi-KafkaManager基于滴滴加强版引擎设计，具备以下几个特点：
集群服务稳定性：拥有磁盘过载保护、生产消费降级限流能力，保障服务持久高效稳定。避免用户无限制的使用集群的流量。因为，流量大的用户会耗尽系统资源从而影响其他用户的使用，容易造成集群的节点故障；
问题定位高效性：拥有Topic级别的实时、历史耗时统计，方便当前问题准确定位，历史问题快速回溯；
服务发现敏捷性：对元数据统一管理，简化各客户端对bootstrap地址的依赖。集群地址变更时，对客户端无影响。
亮点设计：
-
通过Appid+password定义租户，实现租户隔离；
-
通过Topic+AppID进行生产消费鉴权；
-
按Region定义资源划分单位，将部分Broker划分为Region，部分Topic异常时，影响范围会被限制在所属Region里，不会造成大面积影响；
-
按照业务、保障能力划分逻辑集群，提升管控效率。
在滴滴Logi-KafkaManager中建立了基于分角色、多场景视角的体验地图。
分别是普通用户进行Kafka生产消费及监控报警操作的用户体验地图、运维人员进行集群管理、集群监控等运维操作的运维体验地图、和帮助企业建立Kafka运营体系、资源治理体系的运营体验地图。
在用户体验地图中：
-
用户需进行平台租户申请。申请AppID作为Kafka中的用户名，并用 AppID+password作为身份验证。
-
再对集群资源进行申请。用户按需申请、按需使用。可使用平台提供的共享集群，也可为应用申请独立的集群。
-
再进行Topic创建。用户可根据AppID创建Topic，或者申请其他Topic的读写权限。
-
创建完之后，可进行Topic运维操作，例如Topic数据采样、调整配额、申请分区等操作。
-
在生产消费的过程中，基于Topic生产消费各环节耗时统计，监控不同分位数性能指标。帮助用户更加准确的定位问题。
03、滴滴Logi-KafkaManager体验地图
在运维体验地图中，平台集成了集群部署、集群监控、集群运维、版本管理、资源治理等运维模块。提炼运维人员高频运维操作，例如，集群部署、Topic迁移、Topic资源治理、Broker的leader rebalance等。将高频操作平台化，简化用户操作，大大降低运维成本
在运营体验地图中，平台根据滴滴内部多年的运营经验，沉淀资源治理方法。针对Topic分区热点、分区不足等高频常见问题，沉淀资源治理方法，实现资源治理专家化。
独创了工单体系，将Topic创建、调整配额、申请分区等操作，由专业运维人员审批，规范资源使用，保障平台平稳运行。
建立账单体系，Topic资源、集群资源按需申请、按需使用。根据流量核算费用，帮助企业进行成本控制，建设大数据成本核算体系。
04、Logi-KafkaManager对比同类产品
与社区同类的产品相比，滴滴Logi-KafkaManager具有明显的优势，分别可以体现在集群监控、运维体验、用户体验、数据安全这四个方面：
01、在集群监控方面：
-
同类产品的缺少指标的历史数据信息、缺少部分关键性指标、普遍不支持告警。
-
滴滴Logi-KafkaManager支持展示关键指标的历史数据，便于问题的排查；并增加展示Broker关键指标，如Broker刷新日志时间、按不同分位展示实时耗时等；同时自定义监控指标上报渠道，创建监控告警规则。
02、在运维体验方面：
-
同类产品普遍不支持Broker维度的优先副本选举、不支持重置消费偏移、缺少流量陡增的分析与发现能力、不具备Topic隔离能力。
-
而滴滴Logi-KafkaManager可以支持Topic分区粒度的迁移；并支持集群Broker维度的优先副本选举及消费偏移的重置；还可以查看Broker上主要Topic的流量等占比情况；在运维管控上引入Region与逻辑集群的概念，对不同业务的Topic进行隔离。
03、在用户体验方面：
-
同类产品的视角比较单一，普遍是管理员视角，缺少用户视角。并且在平台的使用成本较高，页面上缺少直观表达的图形界面。
-
而滴滴Logi-KafkaManager，兼顾了用户视角和管理员视角，并沉淀高频操作，将高频操作平台化。
04、在数据安全方面：
-
同类产品往往无任何安全管控，登陆即可进行运维操作，这存在数据泄露、数据篡改等安全风险。
-
而滴滴Logi-KafkaManager，使用Appid+Passwd定义租户，生产消费时通过Topic+App ID进行身份鉴权，数据更加安全。并结合角色权限进行分类管控，集群运维由管理员角色进行操作，平台运行更规范。
05、滴滴Logi-KafkaManager未来规划
在未来，会针对以下几个问题进行思考和优化
1.基于MirrorMaker + KafkaGateWay打造Topic跨集群平滑迁移能力建设。
2.进一步的支持 Kafka 2.5+ 最新版本的管控，提供更加丰富的关键性指标监控。
3.在开源版本的基础上拓展更多的企业级特性。与各企业部门共建Kafka生态。
我们将潜心打磨产品，持续回馈开源社区！
如果大家在使用滴滴Logi-KafkaManager的过程中出现问题，或者有疑问需要与开发者交流的，都可以扫描下方二维码进入滴滴logi的开源用户群，在群中提问。
群内有滴滴Logi-KafkaManager项目负责人：滴滴高级专家工程师—张亮等技术大咖，在线为大家解答问题，欢迎大家用钉钉扫码进群。
滴滴Logi-KafkaManager免费体验地址：
账号/密码：
admin/admin。
GitHub项目地址：
