上一章，我讲到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 类的要点。
- handle 方法封装了所有 RPC 请求的具体处理逻辑。每当社区新增 RPC 协议时，增加对应的 handle×××Request 方法和 case 分支都是首要的；
- sendResponse 系列方法负责发送 Response 给请求发送方。发送 Response 的逻辑是将 Response 对象放置在 Processor 线程的 Response 队列中，然后交由 Processor 线程实现网络发送；
- authorize 方法是请求处理前权限校验层的主要逻辑实现。你可以查看一下官方文档，了解一下当前都有哪些权限，然后对照着具体的方法，找出每类 RPC 协议都要求 Clients 端具备什么权限。
二、总结
KafkaApis的整体结构是非常清晰的，本章我就不过多展开了，读者完全可以自己打开KafkaApis.scala的源码去看下它的具体功能。
