正文
1）校验前置：打点数据在进入计费逻辑前，先进行规则校验，保证问题发现及时性。
2）规则可配置：校验规则可随时配置、随时更新，保证规则检测的全覆盖。
3）自助排查：提供自助查询看板，包括数据错误条数，问题发生原因等信息，研发可自助查询对应团队的相关信息，提高问题定位效率。
4）自动告警：检测发现不合规数据（如字段缺失、数据类型错误等）时，向数据来源的团队发送告警，明确问题治理责任。
图1-2
二、设计与核心实现
2.1 Kafka的相关背景知识
为了实现Kafka代理服务的数据校验功能，需要解决以下两个问题：
1）如何根据Kafka协议对消息进行解码。
2）如何处理Kafka客户端，服务端和代理之间的连接关系。
2.1.1 通讯协议
图2-1
如图2-1所示，Kafka请求只能由Client主动发到Broker，Broker针对每个请求回复响应给Client。
Kafka使用基于TCP的自定义二进制协议。它定义了客户端和服务器之间的消息格式、消息传递方式和处理逻辑。所有消息都是通过长度来分隔，并且由基本类型组成。请求由请求类型(ApiKey),版本号(ApiVersion),相关性标识(CorrelationId)，客户端标识(ClientId)和请求消息(RequestMessage)组成。响应由相关性标识(CorrelationId)和响应消息组成(ResponseMessage)组成。
ApiKey用于确认Request的类型，以通过不同类型的数据格式解析请求。Request和Response通过CorrleationId来一一对应。
由于发送生产消息，仅包含两种API--元数据(Metadata)和生产(Produce)，本文仅关注这两种API的请求和响应，协议格式见图2-2。
图2-2
Metadata
是用于获取元数据的API。元数据请求在携带topic_name时会返回topic相关的数据，如果为空则返回所有主题。元数据响应返回的数据包括一串broker的数据信息，以及topic名、分区信息等。图中省略部分内容，仅展示和本文相关的部分。
Produce
是用于将消息集发送到服务器的API。生产请求将携带目标topic，以及分区信息，其中分区信息中包含所要发送的具体消息记录集合。生产响应返回的数据包括具体的请求结果。图中省略部分内容，仅展示和本文相关的部分。
通过了解以上两种API的格式，可以基于协议格式进行解码。
2.1.2 交互流程
处理连接关系，还需要了解Metadata、Produce协议的交互流程。
元数据请求
可以发往任意broker。Kafka集群会提供Bootstrap地址，由此地址负载均衡到某一服务器并返回。客户端提供一组topic，服务端返回元数据响应，包含所有的broker信息和相关的topic信息。broker信息中包括节点的IP地址，即客户端真正发送生产信息的服务器地址。
生产请求
将会发送到元数据请求中返回的某一服务器上，服务器端将会返回请求结果。
图2-3
如图2-3所示，将集群简化为一个Broker，Produce的具体流程：
1）Client向Bootstrap地址发送元数据请求，查询集群当前Broker列表。
2）Bootstrap真实响应的Server其实是（某一个）Broker，Broker返回了所有的信息包含在元数据响应中。
3）Client向真实的Broker地址发送生产请求。
4）Broker处理请求，并回复响应。
通过了解Kafka生产的基本流程，可以实现代理，接管并处理其中的连接关系。
2.2 Kafka Gatekeeper的设计和实现
Gatekeeper作为Kafka客户端和服务端之间的代理，接受客户端的请求对于指定内容做数据校验，并转发给服务器，同时将服务器的响应返回给客户端。
对于
客户端
来说，仅需要将原本配置的Boostrap地址改成Gatekeeper的地址。
对于
Gatekeeper
来说，需要做到：
1）设计解码器和解码方案：解码Kafka消息，从而进一步进行处理。
