听说ES网络层很难？今天来卷它😄

前言

ES网络层比较复杂，分为两个部分：

1. 基于HTTP协议的REST服务端
2. 基于TCP实现的PRC框架

插件化设计的网络层模块（NetworkModule）

入口还是上一章的创建Node构造方法的地方：

一直往下会找到之前说的加载module和服务的地方：

NetworkModule：

NetworkModule属性

有两个map，一个map存放tcp层的实现，一个map存放http层的实现

NetworkModule构造方法

上面的参数分别为：

1. settings：settings配置
2. transportClient: 一般为false
3. plugins：NetworkPlugin 提供了获取TCPTransport和HTTPTransport的接口，NetworkModule通过遍历全部networkPlugin来加载所有的网络层实现，也就说说，ES的网络层不一定就是一种实现。你也可以通过实现NetworkPlugin去提供网络层实现。我们主要看的网络层是Netty4Plugin
4. threadPool：线程池
5. bigArrays：大数组，通信的时候会使用它的空间
6. pageCacheRecycler：和核心流程没关系，跳过
7. circuitBreakerService：和核心流程没关系，跳过
8. namedWritableRegistry：
9. xContentRegistry：
10. networkService：网络服务，主要是将host地址转换为 Java Network地址对象，解析地址使用
11. dispatcher：它的实现是RestController，RestController内部注册了很多处理器，对外提供访问路由的功能，也就说Http请求会转换为RestRequest，RestRequest最终会交给RestController去找到合适的handler，然后去访问最终的义务层逻辑，（后面源码会分析到）
12. clusterSettings：集群配置

我们来看这里做了几件事（我们这里看的是Netty4Plugin）：

1. plugin.getHttpTransports：获取Http网络层的实现，这里返回的是一个map，key是netty4，value是一个Netty4Plugin lambda表达式

2. 遍历httpTransportFactory，将key和value值放到之前的transportHttpFactories

3. 后面的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方法


总结一下一共做了这几件事：

1. �读取RestRequest请求路径（rawPath）及Method（GET、POST、DELETE…）等信息
2. 根据rawPath等信息到PathTrie（字典树结构）中找到提供服务的Handler
3. 调用BaseRestHandler->handleRequest(restRequest, restChannel, nodeClient) （BaseRestHandler为所有Rest*Action的父类…），比如我这里debug用的是写索引数据的rest请求，实际请求到的是RestIndexAction

#### BaseRestHandler.handleRequest 
总结一下这里做了几件事：

1. BaseRestHandler的prepareRequest是模版方法，最终会调用到RestIndexAction里面的prepareRequest方法，里面就是负责解析restRequest请求为具体的 业务请求对象，并生成一个lambda表达式
2. BaseRestHandler调用action.accept 调用之前的lambda表达式
   

TCP通信层（ES内置RPC 实现，Netty4Transport）