读源代码

上一篇我们把地图铺开了，这一篇开始走主链路第一站：CLI启动。
毕竟无论你是跑openclaw gateway还是openclaw agent，第一步都绕不开CLI入口。

最近打算系统性地啃一下OpenClaw源码，顺手也开个系列记录一下自己的理解过程。
这一篇是第1篇，目标很简单：先把地图摊开，搞清楚这个项目大致由哪些模块组成，消息是怎么流动的，后面再按模块逐个击破。

这应该是Pingora源码阅读的最后一篇文章，之前介绍了Pingora中两个比较重要的概念, Server和Service, 本篇文章着重于监听服务的钩子函数, 这也是我们主要写业务代码的地方。

上次主要阅读了Pingora的Server部分的代码, 本文阅读Pingora另一个比较重要的部分Service, Pingora内置两种服务background(后台)和Listening(监听), 本文着重后者。

要想深入Pingora应该是需要阅读源代码的，所以分析一下源代码，虽然Pingora没有提供丰富的示例，但是提供了一些不错的文档，比如它的internals.md文档，提供了很多细节和示意图，本系列文章会引用很多其中的示意图，Pingora的源码分析应该会分为2篇文章或更多。

这篇文章主要是阅读reqwest的源代码, 而底层关于hyper的实现这篇文章浅尝辄止, 仅仅只是过一下hyper请求的大致流程，以后对rust的掌握程度更高之后在看hyper的源代码。

阅读kube-apiserver的过程中，会发现很多的AddPostStartHook的代码，这部分代码用于执行kube-apiserver启动之后的逻辑，因为他们放在启动后执行更适合，所以就提供了两种钩子(Hook), PostStartHook和PreShutdownHook。这里只看PostStartHook，并且只看bootstrap-controller对应的钩子函数。

从前文我们已经了解到kube-apiserver内部有三个组件，分别是apiExtensionsServer,kubeAPIServer,aggregatorServer, 为了方便用户扩展，所以存在apiExtensionsServer, 因为k8s有自己的核心资源，所以需要kubeAPIServer, 为了将两者结合起来所以需要aggregatorServer, 那么aggregatorServer怎么两者的资源集中在一起并提供给用户查询呢? 本文尝试从k8s的源代码中找到问题的答案。

之前看过kube-apiserver请求处理链的相关内容，知道一些通用逻辑，如认证，鉴权，审计之类的内容都以一种链条的方式组合在一起依次调用，但是这些处理函数中并不包含准入的业务逻辑，之所以这样，我想是因为准入只针对修改请求，所以放在通用的处理链中会不太和谐，再者就是准入是比较重要的抽象，所以单独抽离出来了。

这里一节主要看kube-apiserver的路由注册和最终映射到后端存储的处理函数是怎么构造的，kube-apiserver中一共有三个组件，apiExtensionsServer,kubeAPIServer, aggregatorServer，每个组件都有路由注册，但其实核心逻辑是差不多的。