虽然开源的kafka 已经很完善了，但是在我们落地的时候还会出现很多需求无法满足的情况。比如，主题迁移，消息轨迹，消息治理，可观测等功能，企业级落地需求需要满足。要想满足以上功能，需要一个后台管理和可观测平台，同时需要对 kakfa的一些组件 进行二次开发。
后台管理
后台管理粗略的分为 命名空间管理，主题管理，消息管理，监控管理，授权管理。后台管理的权限按照项目或生产线进行分配，生产线上的
命名空间
命名空间是资源管理概念。用户不同的业务场景都可以通过命名空间做逻辑隔离。不同命名空间之间的 Topic 相互隔离，订阅相互隔离，角色权限相互隔离。可以满足多租户的需求。
在Namespace管理页面可以进行Namespace的创建。
主题管理
分为创建主题，订阅主题，删除或管理主题。
创建主题
订阅主题
创建消费组和主题的消费关系。
删除和管理主题
包括删除主题，授权，发送暂停，接收暂停，全部暂停，重置消费位点
重置消费位点
消息管理
包括消息查询，消息轨迹，手动发送新消息，重发消息
消息查询
提供了三种消息查询的方式：按Business ID，按Message ID，以及按Topic时间范围查询。
按Business ID查询
按Message ID查询
按日期查询
消息轨迹
消息轨迹指的是一条消息从生产方发出到消费方消费处理，整个过程中的各个相关节点的时间地点等数据汇聚而成的完整链路信息。可以帮助用户解决因为生产和消费解耦，导致生产者与消费者无法确定消息状态的问题，并且帮助用户定位问题了解消息的详细状态。
生产者端在发送消息前、后；消费者在消费前、后；消息确认前、后都进行取点记录，将这些点发给JCQ进行统计、计算出轨迹信息。
手动发送消息
有时候线上数据不一致，需要消息队列发个消息来追平差异，这时需要高效的方法来完成这个功能：
重发消息（死信队列）
普通消息类型的Topic,在超过最大尝试推送次数后会将消息发送到死信队列，可将其作为无法成功处理 (使用) 消息的目标队列。在死信队列中留出和隔离这些消息以确定其处理失败的原因。可按照Topic和ConsumerGroup ID进行搜索。
监控信息
包括主题，消息，生产者，消费者都需要监控，并赋予一定的管理能力。
主题与订阅关系监控
操作步骤
-
登录控制台。
-
在"Topic管理"页面，选择目标topic，点击 topic名称，进入"topic详情"页面。
-
在"topic详情"页面，点击 监控，查看监控信息。
- 您可以快速选择查看1小时至14天的数据，也可以输入日期范围查看，时间范围最长可选择1个月。
- 支持查看Topic和topic下某个Consumer Group的监控信息
监控项说明
| 类型 | KPI | 说明 |
|---|---|---|
| Topic | 生产的TPS（条/秒） | 每秒钟生产的消息数量 |
| Topic | 已发布消息的数量(个) | 生产者发送消息到主题的消息数量 |
| Topic | 已发布消息的请求量(次) | 生产者发送消息到主题的API请求数量 |
| Topic | 已发布消息的大小(byte) | 生产者发送消息到主题的消息大小 |
| Consumer Group | 消费的TPS（条/秒） | 每秒钟消费的消息数 |
| Consumer Group | 堆积消息数量（个） | 订阅关系中堆积的消息数量 |
| Consumer Group | 接收消息请求量(次) | 订阅关系中消费者拉取的请求数量 |
| Consumer Group | 接收的消息数量（个） | 订阅关系中消费者拉取的消息总数量 |
| Consumer Group | 成功接收消息数量（个） | 订阅关系中消费者拉取成功的消息数量 |
| Consumer Group | 接收消息的大小（byte） | 订阅关系中消费者消费的消息大小 |
生产者和消费者监控
Kafka 二次开发
要实现以上的后台功能需要在 kakfa 源码的基础上做二次开发。
首先，要有个整体的数据上报机制，具体方案是通过监听zookeeper 的数据变化来实现，具体下图详细描述：
涉及客户端改造：
生产者和消费者客户端会加上向上通报的机制，把客户端项目名和主题上报到 NameNode(M), 而且通过心跳上报健康状态。
除了查看的功能还有管理的功能，如禁止某个客户端对某个主题的生产和消费，指定某个partition的leader节点等功能。
消息轨迹开发
需要定制开发一个轨迹类型的broker,改变的并不多，只要定义好message的格式，就可以了， 和常规消息的 broker 几乎没任何区别。生产者消费者会在生产和消费时异步向消息轨迹broker 发送轨迹信息。
