Kafka源码分析（十七）——Broker：API层——KafkaApis

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

上一章，我讲到KafkaRequestHandlerPool最终会将请求交给API层的KafkaApis处理。本章，我们就来看下KafkaApis的整体架构。

KafkaApis 类定义在源码文件 KafkaApis.scala 中：

    class KafkaApis(val requestChannel: RequestChannel,
                    val replicaManager: ReplicaManager,
                    val adminManager: AdminManager,
                    val coordinator: GroupCoordinator,
                    val controller: KafkaController,
                    val zkUtils: ZkUtils,
                    val brokerId: Int,
                    val config: KafkaConfig,
                    val metadataCache: MetadataCache,
                    val metrics: Metrics,
                    val authorizer: Option[Authorizer],
                    val quotas: QuotaManagers,
                    val clusterId: String,
                    time: Time) extends Logging {
    //...
    }

它的内部封装了许多核心组件：

一、整体架构

KafkaApis 可以看成是一个门面类，是 Broker 端所有功能的入口，同时关联了超多的 Kafka 组件。如果你翻开 KafkaApis 类的代码，你会发现，它封装了很多以 handle 开头的方法。每一个这样的方法都对应于一类请求类型，而它们的总方法入口就是 handle 方法。

实际上，你完全可以在 handle 方法间不断跳转，去到任意一类请求被处理的实际代码中。

我们总结一下 KafkaApis 类的要点。

1. handle 方法封装了所有 RPC 请求的具体处理逻辑。每当社区新增 RPC 协议时，增加对应的 handle×××Request 方法和 case 分支都是首要的；
2. sendResponse 系列方法负责发送 Response 给请求发送方。发送 Response 的逻辑是将 Response 对象放置在 Processor 线程的 Response 队列中，然后交由 Processor 线程实现网络发送；
3. authorize 方法是请求处理前权限校验层的主要逻辑实现。你可以查看一下官方文档，了解一下当前都有哪些权限，然后对照着具体的方法，找出每类 RPC 协议都要求 Clients 端具备什么权限。

二、总结

KafkaApis的整体结构是非常清晰的，本章我就不过多展开了，读者完全可以自己打开KafkaApis.scala的源码去看下它的具体功能。