kite服务启动处理请求的流程-1

Posted 2022-11-28 安然_随心

今天下面看了一下kite 的源码，并追了一个请求的处理过程，下面做一点简要的记录。

主要分为如下几个部分：

1. 服务请求链信息记录；
2. kite server 启动的流程；
3. kite server 从接受到请求到返回响应的过程；
4. 怎么做限流等处理；

服务请求链信息记录

1. 基本认识
   thrift通信是单向的，客户端发起请求，然后服务器响应。请求链的数据是用 客户端 代码进行组装，然后发送给服务器。

2. 数据的统一处理
   当进行了项目的服务化后，可能一次完整的情况 需要用户 请求服务A，然后服务A 请求 服务B，然后A在请求B 。那请求链的数据怎么搞？ 每个服务、每个接口都单独处理显然不合理。一般的思路是 客户端将 相关的信息，如请求ID，IP等数据放入到一个基本数据结构中，例如叫做 BaseRequestMeta ，然后每个服务的每个接口，将 该基础数据结构放入加入的请求参数中，作为一个字段。

服务段收到请求后，由统一的框架从请求中的 BaseRequestMeta 数据接口中读取到信息，然后放入到 context 中。上层业务如果有需求，则直接从context 中获取请求的meta 相关数据。

kite server 启动的流程

启动流程

1. kite 基础环境、配置初始化，并创建RPC Server;
2. 业务初始化；
3. 创建错误信号通道；
4. 起协程，启动RPC server 并开始监听，如果协程处理过程中发生错误，则将错误 发送到错误信号通道中；
5. 主协程监听错误信号通道，如果收到数据，则表示监听协程发生错误，则服务停止；

kite server 从接受到请求到返回响应的过程

总体过程

1. 在开始接受客户端请求前，先进一步进行初始化，包括起协程，进行如下任务：监听 debug 端口、监听 metrics 端口（做服务监控信息）（这个有点类似与Ambari 服务使用 java jmx的监控）、定时更新限流、流量控制（服务请求管理）

2. 开始监听；

3. 如果有链接进来，判定当前链接数量是否大于设置的最大值，如果大于，则直接丢弃请求，不处理。否则开启协程，处理该请求；

协程处理请求的过程

1. 通过 ReadMessageBegin 判定 请求函数名字，并根据 请求函数映射表，找到对应的处理函数；
2. 调用处理函数，返回处理结果；
3. 如果没有找到对应的处理函数，则返回直接写resp，包括写消息开始标志WriteMessageBegin、写异常数据NewTApplicationException、写消息结束标记WriteMessageEnd，然后将数据flush。处理完成。

处理函数处理请求的过程：

1. 创建对应请求的请求参数，开始从thrift 协议数据中构建应用请求数据；
2. 从 iprot 中读取填充请求参数；
3. 从请求中构造、填充 context 值；
4. 调用业务 处理函数；

注意：如果thrift 中idl 中字段 定义为required ，则从thrift iprot 中读取时，则必须读取到，否则会抛错

这里插一句对thrift 的认识。kite 根据 idl 文件生成协议读写代码时，是每个一个结构体都会生成对应的读写方法。 这个是完全绑定的。

怎么做限流等处理

基本思想：保证任何时候，正在处理的请求数 小于 阈值。一般的实现，使用一个原子变量CX，请求来时，如果 CX +1> Max ，则表示 当前正在处理的请求已经很多，故不接受此请求。否则，可以处理请求，将 CX 加1，请求处理完后，将CX-1