听说ES网络层很难?今天来卷它😄
前言
ES网络层比较复杂,分为两个部分:
- 基于HTTP协议的REST服务端
- 基于TCP实现的PRC框架
插件化设计的网络层模块(NetworkModule)
入口还是上一章的创建Node构造方法的地方:
一直往下会找到之前说的加载module和服务的地方:
NetworkModule:
NetworkModule属性
有两个map,一个map存放tcp层的实现,一个map存放http层的实现
NetworkModule构造方法
上面的参数分别为:
- settings:settings配置
- transportClient: 一般为false
- plugins:NetworkPlugin 提供了获取TCPTransport和HTTPTransport的接口,NetworkModule通过遍历全部networkPlugin来加载所有的网络层实现,也就说说,ES的网络层不一定就是一种实现。你也可以通过实现NetworkPlugin去提供网络层实现。我们主要看的网络层是Netty4Plugin
- threadPool:线程池
- bigArrays:大数组,通信的时候会使用它的空间
- pageCacheRecycler:和核心流程没关系,跳过
- circuitBreakerService:和核心流程没关系,跳过
- namedWritableRegistry:
- xContentRegistry:
- networkService:网络服务,主要是将host地址转换为 Java Network地址对象,解析地址使用
- dispatcher:它的实现是RestController,RestController内部注册了很多处理器,对外提供访问路由的功能,也就说Http请求会转换为RestRequest,RestRequest最终会交给RestController去找到合适的handler,然后去访问最终的义务层逻辑,(后面源码会分析到)
- clusterSettings:集群配置
我们来看这里做了几件事(我们这里看的是Netty4Plugin):
- plugin.getHttpTransports:获取Http网络层的实现,这里返回的是一个map,key是netty4,value是一个Netty4Plugin lambda表达式
- 遍历httpTransportFactory,将key和value值放到之前的transportHttpFactories
- 后面的RPC逻辑类似,直接过😄
�
�
HTTP通信层**(Netty4HttpServerTransport)**
Netty4HttpServerTransport构造方法
和之前NetworkModule的参数基本差不多,多了一个sharedGroupFactory:这里是一个netty NioEventGroup。学过netty源码应该都懂,如果不懂,可以看我写的netty源码解析。
Netty4HttpServerTransport.doStart方法
入口:
Node->start() => injector.get(HttpServerTransport.class).start()=>Netty4HttpServerTransport.doStart
在node节点启动的时候,会存在 ,这个httpServerTransport实现了AbstractLifecycleComponent,在它的start最终会调用到子类Netty4HttpServerTransport的doStart方法
�
�
doStart方法
�
都是netty服务端常规的配置,如果看不懂,还是要学一下netty源码的。学过netty的都知道,肯定是有一个服务端的请求入口Handler类的,这个类才是我们最要注意看的:Netty4HttpRequestHandler
Netty4HttpRequestHandler.channelRead0
请求处理入口:Netty4HttpRequestHandler->channelRead0(ctx, httpRequest)
又把请求转接给了Netty4HttpServerTransport.incomingRequest
Netty4HttpServerTransport.incomingRequest
请求处理入口: Netty4HttpServerTransport->incomingRequest(httpRequest, httpChannel
这里的核心逻辑就是:解析HttpRequest为RestRequest,包装HttpChannel为RestChannel。包装之后,最终交给 Dispatcher 方法
�
RestController.dispatchRequest
会接着调用RestController.tryAllHandlers方法
总结一下一共做了这几件事:
- �读取RestRequest请求路径(rawPath)及Method(GET、POST、DELETE...)等信息
- 根据rawPath等信息到PathTrie(字典树结构)中找到提供服务的Handler
- 调用BaseRestHandler->handleRequest(restRequest, restChannel, nodeClient) (BaseRestHandler为所有Rest*Action的父类...),比如我这里debug用的是写索引数据的rest请求,实际请求到的是RestIndexAction
BaseRestHandler.handleRequest ![image.png](https://img-blog.csdnimg.cn/img_convert/4415eb016166c65ad43bc4a09b57ef01.png)
![image.png](https://img-blog.csdnimg.cn/img_convert/7ce72cd7f91d788b21329c44389f03b0.png)
总结一下这里做了几件事:
- BaseRestHandler的prepareRequest是模版方法,最终会调用到RestIndexAction里面的prepareRequest方法,里面就是负责解析restRequest请求为具体的 业务请求对象,并生成一个lambda表达式
- BaseRestHandler调用action.accept 调用之前的lambda表达式