dubbo远程调用注解（怎么用注解的方式发布dubbo服务）

本文目录

• 怎么用注解的方式发布dubbo服务
• dubbo怎么实现rpc远程调用
• 小白也能看懂的dubbo3应用级服务发现详解
• dubbo端引入@Valid注解避坑
• 调用dubbo服务时事务配置在哪
• 7.Dubbo远程调用(要配合下一篇一起看)

怎么用注解的方式发布dubbo服务

使用 @com.alibaba.dubbo.config.annotation.Service 发布dubbo服务的时候,当服务类没有加入@Transactional的时候没有问题.
但是当加入事务后【@Transactional】, dubbo的 AnnotationBean 扫描 类执行下面的代码的时候就获取不到对应的注解,也就发布不了服务。
究其原因，是因为Dubbo提供的注解没有@Inherited元注解。
我们通过@Transactional标注过的Service产生一个代理类，这个代理类有两种生成方式。一种是jdk动态代理，一种是CGLib动态代理。
jdk动态代理生成的代理类与当前类共同实现相同的接口，所以与当前类也只是间接调用的关心，不在此次讨论范围。
CGLib生成的代理类为当前Service的子类，可以集成到当前Service的注解。
根据需求，我们需要更改Dubbo的源码
在Dubbo的Service注解上加上@Inherited，使这个注解变成可继承的。
然后再当前项目的spring的主配置文件中强制所有bean使用CGLib代理
这样服务即可正常发布。

dubbo怎么实现rpc远程调用

在消费者初始化的时候，会生成一个消费者代理注册到容器中，该代理回调中持有一个MockClusterInvoker实例，消费调用服务接口时它的invoke会被调用，此时会构建一个RpcInvocation对象，把服务接口的method对象和参数放到RpcInvocation对象中，作为MockClusterInvoker.invoke方法的参数，在这个invoke方法中，判断请求是否需要mock，是否配置了mock属性，是强制mock还是失败后mock，关于mock这里先不详细展开，这里只看下核心流程。 
MockClusterInvoker.invoke会调用FailfastClusterInvoker.invoke，大系统中为了服务高可用同一个服务一般会有多个应用服务器提供，要先挑选一个提供者提供服务。在服务接口消费者初始化时，接口方法和提供者Invoker对应关系保存在RegistryDirectory的methodInvokerMap中，通过调用的方法名称（或方法名称+第一个参数）改方法对应的提供者invoker列表，如注册中心设置了路由规则，对这些invoker根据路由规则进行过滤。 
com.alibaba.dubbo.registry.integration.RegistryDirectory.doList(Invocation) 
 
com.alibaba.dubbo.rpc.cluster.directory.AbstractDirectory.list(Invocation) 
 
读取到所有符合条件的服务提供者invoker之后，由LoadBalance组件执行负载均衡，从中挑选一个invoker进行调用，框架内置支持的负载均衡算法包括random（随机）、roundrobin（R-R循环）、leastactive（最不活跃）、consistenthash（一致性hash），应用可配置，默认random。 
methodInvokerMap保存的是持有DubboInvoker（dubbo协议）实例的InvokerDelegete对象，是Invoker-Filter链的头部，先激活Filter连然后最终调到DubboInvoker.invoke(RpcInvocation)，此时远程调用分三种类型： 
1. 单向调用，无需获取关注调用结果的，无需等待接口返回结果，注意调用结果不要单纯跟返回值混淆了，异常也是调用结果。 
2. 异步调用，需要关注返回结果，但是不会同步等待接口调用结束，会异步的获取返回返回结果，这种情况给调用者返回一个Future，但是不同步等待Future.get返回调用结果 
3. 同步调用，需要同步等待服务调用结束获取调用结果，给调用者返回一个Future并且Future.get等待结果，此时接口调用线程会挂起等待响应。 
 
我们大部分使用场景都是同步调用，所以主要看一下同步调用。如果使用者配置了多个connections按顺序选择一个ExchangeClient和服务器通信，同步调用时调用HeaderExchangeClient.request-》HeaderExchangeChannel.request。

com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeChannel.request(Object, int) 
 
这里的request参数是RpcInvocation对象，包含调用的方法、参数等信息，timeout参数是接口超时时间，把这些信息封装在Request对象中，调用channel.send，这个channel对象就是和服务端打交道的NettyClient实例，NettyClient.send调用NettyChannel.send。

com.alibaba.dubbo.remoting.transport.netty.NettyChannel.send(Object, boolean) 
 
这里的sent参数决定是否等待请求消息发出，sent=true 等待消息发出，消息发送失败将抛出异常，sent=false 不等待消息发出，将消息放入IO队列，即刻返回。默认情况下都是false。NettyChannel中有channel属性，这个channel是Netty框架中的组件，负责客户端和服务端链路上的消息传递，channel.write把请求消息写入，这里的message是上面封装的Request对象。这里的IO模型是非阻塞的，线程不用同步等待所有消息写完，而是直接返回。调用Netty框架的IO事件之后会触发Netty框架的IO事件处理链。

小白也能看懂的dubbo3应用级服务发现详解

dubbo 是一款开源的 RPC 框架，主要有3个角色： 提供者（provider） 、 消费者（consumer） 、 注册中心（registry）

提供者启动时向注册中心注册服务地址，消费者启动时订阅服务，并通过获取到的提供者地址发起调用，当提供者地址变更时，通过注册中心向消费者推送变更。这就是 dubbo 主要的工作流程。

在2.7.5之前，dubbo 只支持接口级服务发现模型，》=2.7.5的版本提供了接口级与应用级两种服务发现模型，3.0之后的版本应用级服务发现更是非常重要的一个功能。

本文将从为什么需要引入应用级服务发现，dubbo 实现应用级服务发现的难点以及dubbo3 是如何解决这些问题这三个部分进行讲解。

开始前，我们先了解下 dubbo 最初提供的接口级服务发现是怎样的。

dubbo 服务的注册发现是以 接口 为最小粒度的，在 dubbo 中将其抽象为一个 URL ，大概长这样：

看着很乱？捋一捋：

无论是存储还是变更推送压力都可能遇到瓶颈，数据多表现在这两个方面：

这个问题好解决： 拆！

dubbo 在 2.7 之后的版本支持了 元数据中心 与 配置中心 ，对于URL的参数进行分类存储。持久不变的（如application、method等）参数存储到元数据中心中，可能在运行时变化（timeout、tag）的存储到配置中心中

无论是增加一台机器还是增加一个接口，其增长都是线性的，这个问题比单条数据大更严重。

当抹去注册信息中的 interface 信息，这样数据量就大大减少

只用过 dubbo 的同学可能觉得这很主流。

但从服务发现的角度来看：

无论是用的最多的服务注册发现系统 DNS ，又或者是 SpringCloud 体系、 K8S 体系，都是以应用为维度进行服务注册发现的，只有和这些体系对齐，才能更好地与之进行打通。

在我了解的范围里，目前只有 dubbo 、 SOFARPC 、 HSF 三个阿里系的 RPC 框架支持了接口级的服务发现。

provider端暴露服务：

consumer端引用服务：

本地调用远程的方法时，只需要配置一个 reference ，然后直接使用 interface 来调用，我们不必去实现这个 interaface，dubbo 自动帮我们生成了一个代理进行 RPC 调用，屏蔽了通信的细节，让我们有种 像调用本地方法一样调用远程方法的感觉 ，这也是 dubbo 的优势。

从这里我们能看出为什么 dubbo 要设计成接口级服务发现，因为要为每一个 interface 生成一个代理，就必须定位到该 interface 对应服务暴露的服务地址，为了方便，dubbo 就这么设计了。

如果让我来设计应用级服务发现，注册不必多说，按应用名注册即可。

至于订阅，在目前 dubbo 机制下，必须得告诉消费者消费的每个接口是属于哪个应用，这样才能定位到接口部署在哪里。

实现 dubbo 应用级服务发现，难点在于

保留接口级服务发现，且默认采取双注册方式，可配置使用哪种服务发现模型，如下配置使用应用级服务发现

名词有点高大上，但道理很简单，让 dubbo 自己去匹配，提供者注册的时候把接口和应用名的映射关系存储起来，消费者消费时根据接口名获取到部署的应用名，再去做服务发现。

数据存储在哪里？显然元数据中心非常合适。该方案用户使用起来和之前接口级没有任何不同，但需要增加一个元数据中心，架构变得复杂。

且有一个问题是，如果接口在多个应用下部署了，dubbo 查找的策略是都去订阅，这可能在某些场景下不太合适。

本文从接口级服务发现讲到应用级服务发现，包含了为什么 dubbo 设计成接口级服务发现，接口级服务发现有什么痛点？基于 dubbo 现状如何设计应用级服务发现，应用级服务发现实现有什么难点等等问题进行解答，相信看完的小伙伴一定有所收获。

dubbo端引入@Valid注解避坑

dubbo Provider端引入@Valid校验不生效

1.检查@Service注解是否开启validation

2.SpringMVC配置,引入

注意,这里的bean id 不能命名为validator,会报错

3.引入validator jar包
顺便解决掉maven冲突,若存在冲突,可能会报一些奇怪的错误,且找原因比较困难

4.引入后若产生如下报错

解决方案:引入如下jar包

5.使用:

调用dubbo服务时事务配置在哪

dubbo实现了分布式远程调用框架，多运行节点既能提高可靠性，又能提升负载能力。dubbo配置主要有注册中心（推荐zookeeper或redis）、提供者provider、消费者consumer，注册中心是第三方实现，所以主要配置好服务提供者和消费者就可以了。实际上服务接口和实现都是需要我们自己设计和实现的，dubbo做的事情就是将服务实现发布到注册中心，然后消费者从注册中心订阅服务接口，之后对接口的调用就由dubbo调度提供者去执行并返回结果。以下配置都有源码，见右侧“免费资源”。
提供者provider的配置：提供者是独立运行的节点，可以多实例运行，将服务注册到注册中心
必须要有application name，注册中心配置zookeeper，协议dubbo，超时6秒失败不重试，提供者加载repository和service层bean，然后发布接口service。
《dubbo:application name="ite-provider" /》
《dubbo:registry address="zookeeper://127.0.0.1:2181"/》
《dubbo:protocol name="dubbo" port="20880" /》
《dubbo:provider timeout="6000" retries="0"/》
《import resource="classpath:cache.xml"/》
《import resource="classpath:ite-repository.xml"/》
《import resource="classpath:ite-service.xml"/》
《import resource="classpath:ite-provider.xml"/》
ite-provider.xml，ref引用的bean是ite-service.xml已经定义好的接口实现，dubbo:service就是把接口实现发布到注册中心
《dubbo:service ref="codeListService" interface="com.itecheast.ite.domain.service.CodeListService" /》
《dubbo:service ref="idService" interface="com.itecheast.ite.domain.service.IdService" /》
《dubbo:service ref="passwordService" interface="com.itecheast.ite.domain.service.PasswordService" /》
《dubbo:service ref="rolePermissionService" interface="com.itecheast.ite.domain.service.RolePermissionService" /》
provider是可以独立运行的，dubbo.jar里面有assembly目录，运行mvn assembly:directory就可以生成能直接运行的provider目录
assembly.xml内容，可以切换dir或tar.gz两种格式
《assembly》
《id》assembly《/id》
《formats》
《!-- 《format》tar.gz《/format》 --》
《format》dir《/format》
《/formats》
《includeBaseDirectory》true《/includeBaseDirectory》
《fileSets》
《fileSet》
《directory》src/main/assembly/bin《/directory》
《outputDirectory》bin《/outputDirectory》
《fileMode》0755《/fileMode》
《/fileSet》
《fileSet》
《directory》src/main/assembly/conf《/directory》
《outputDirectory》conf《/outputDirectory》
《fileMode》0644《/fileMode》
《/fileSet》
《fileSet》
《directory》src/test/resources《/directory》
《outputDirectory》conf《/outputDirectory》
《fileMode》0644《/fileMode》
《/fileSet》
《/fileSets》
《dependencySets》
《dependencySet》
《outputDirectory》lib《/outputDirectory》
《/dependencySet》
《/dependencySets》
《/assembly》
dubbo.properties，运行start.bat或start.sh时，将从属性文件读取dubbo配置信息，provider节点可以多处复制并运行。
dubbo.container=log4j,spring
dubbo.application.name=ite-provider
dubbo.registry.address=zookeeper://127.0.0.1:2181
dubbo.monitor.protocol=registry
dubbo.protocol.name=dubbo
dubbo.protocol.port=20880
dubbo.spring.config=provider.xml
dubbo.log4j.file=logs/ite-provider.log
dubbo.log4j.level=WARN
消费者consumer的配置，使用dubbo:reference订阅注册中心里的服务即可，然后就可以@Autowired注入服务接口了。
《dubbo:application name="ite-consumer" /》
《dubbo:registry address="zookeeper://127.0.0.1:2181"/》
《dubbo:reference id="codeListService" interface="com.itecheast.ite.domain.service.CodeListService" /》
《dubbo:reference id="idService" interface="com.itecheast.ite.domain.service.IdService" /》
《dubbo:reference id="passwordService" interface="com.itecheast.ite.domain.service.PasswordService" /》
《dubbo:reference id="rolePermissionService" interface="com.itecheast.ite.domain.service.RolePermissionService" /》
如果前端项目是一个消费者，就可以在web.xml里直接加载consumer.xml订阅服务了。
《listener》
《listener-class》org.springframework.web.context.ContextLoaderListener《/listener-class》
《/listener》
《context-param》
《param-name》contextConfigLocation《/param-name》
《param-value》classpath:consumer.xml,classpath:cache.xml,classpath:shiro.xml,classpath:front.xml《/param-value》
《/context-param》
实际上本地调试开发时，可以不必启用分布式配置，只需要更改web.xml即可，所有的服务都已经是配置好了的。
《listener》
《listener-class》org.springframework.web.context.ContextLoaderListener《/listener-class》
《/listener》
《context-param》
《param-name》contextConfigLocation《/param-name》
《param-value》classpath:ite-repository.xml,classpath:ite-service.xml,classpath:cache.xml,classpath:shiro.xml,classpath:front.xml《/param-value》
《/context-param》
zookeeper的配置很简单，
***隐藏网址***
tar -zxvf zookeeper-3.4.6.tar.gz
cd zookeeper-3.4.6/conf
cp zoo_sample.cfg zoo.cfg
vi zoo.cfg #配置zookeeper参数
单机配置（集群配置待研究）
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/home/dubbo/zookeeper-3.3.3/data
clientPort=2181
运行或停止zookeeper
sh zkServer.sh start | stop

7.Dubbo远程调用(要配合下一篇一起看)

如果我们手动写一个简单的RPC调用，一般需要把服务调用的信息传递给服务端，包括每次服务调用的一些共用信息包括服务调用接口、方法名、方法参数类型和方法参数值等，在传递方法参数值时需要先序列化对象并经过网络传输到服务端，在服务端接受后再按照客户端序列化的顺序再做一次反序列化，然后拼装成请求对象进行服务反射调用，最终将调用结果传给客户端。Dubbo的实现也基本是相同的原理，下图是Dubbo一次完整RPC调用中经过的步骤：

首先在客户端启动时，会从注册中心拉取和订阅对应的服务列表，Cluster会把拉取的服务列表聚合成一个Invoker，每次RPC调用前会通过Directory#list获取providers地址(已经生成好的Invoker地址)，获取这些服务列表给后续路由和负载均衡使用。对应上图①中将多个服务提供者做聚合。在框架内部实现Directory接口的是RegistryDirectory类，它和接口名是一对一的关系(每一个接口都有一个RegistryDirectory实例)，主要负责拉取和订阅服务提供者、动态配置和路由项。
在Dubbo发起服务调用时，所有路由和负载均衡都是在客户端实现的。客户端服务调用首先会触发路由操作，然后将路由结果得到的服务列表作为负载均衡参数，经过负载均衡后会选出一台机器进行RPC调用，这3个步骤一次对应图中②③④。客户端经过路由和负载均衡后，会将请求交给底层IO线程池(如Netty)进行处理，IO线程池主要处理读写、序列化和反序列化等逻辑，因此这里一定不能阻塞操作，Dubbo也提供参数控制(decode.in.io)参数，在处理反序列化对象时会在业务线程池中处理。在⑤中包含两种类似的线程池，一种是IO线程池(Netty)，另一种是Dubbo业务线程池(承载业务方法调用)。
目前Dubbo将服务调用和Telnet调用做了端口复用，子啊编解码层面也做了适配。在Telnet调用时，会新建立一个TCP连接，传递接口、方法和json格式的参数进行服务调用，在编解码层面简单读取流中的字符串(因为不是Dubbo标准头报文)，最终交给Telnet对应的Handler去解析方法调用。如果不是Telnet调用，则服务提供方会根据传递过来的接口、分组和版本信息查找Invoker对应的实例进行反射调用。在⑦中进行了端口复用，Telnet和正常RPC调用不一样的地方是序列化和反序列化使用的不是Hessian方式，而是直接使用fastjson进行处理。
讲解完主要调用原理，接下来开始探讨细节，比如Dubbo协议、编解码实现和线程模型等，本篇重点主要放在⑤⑥⑦。

Dubbo协议参考了现有的TCP/IP协议，每一次RPC调用包括协议头和协议体两部分。16字节长的报文头部主要包含魔数(0xdabb)，以及当前请求报文是否是Request、Response、心跳和事件的信息，请求时也会携带当前报文体内序列化协议编号。除此之外，报文头还携带了请求状态，以及请求唯一标识和报文体长度。

在消息体中，客户端严格按照序列化顺序写入消息，服务端也会遵循相同的顺序读取消息，客户端发起的请求消息体一次依次保存下列内容：Dubbo版本号、服务接口名、服务接口版本、方法名、参数类型、方法参数值和请求额外参数(attachment)。
服务端返回的响应消息体主要包含回值状态标记和返回值，其中回值状态标记包含6中：

我们知道在网络通信中(TCP)需要解决网络粘包/解包的问题，常用的方法比如用回车、换行、固定长度和特殊分隔符进行处理，而Dubbo是使用特殊符号0xdabb魔法数来分割处理粘包问题。
在实际场景中，客户端会使用多线程并发调用服务，Dubbo如何做到正确响应调用线程呢？关键在于协议头的全局请求id标识，先看原理图：

当客户端多个线程并发请求时，框架内部会调用DefaultFuture对象的get方法进行等待。在请求发起时，框架内部会创建Request对象，这时候会被分配一个唯一id，DefaultFuture可以从Request中获取id，并将关联关系存储到静态HashMap中，就是上图中的Futures集合。当客户端收到响应时，会根据Response对象中的id，从Futures集合中查找对应DefaultFuture对象，最终会唤醒对应的线程并通知结果。客户端也会启动一个定时扫描线程去探测超时没有返回的请求。

先了解一下编解码器的类关系图：

如上，AbstractCodec主要提供基础能力，比如校验报文长度和查找具体编解码器等。TransportCodec主要抽象编解码实现，自动帮我们去调用序列化、反序列化实现和自动cleanup流。我们通过Dubbo编解码继承结构可以清晰看到，DubboCodec继承自ExchageCodec，它又再次继承了TelnetCodec实现。我们前面说过Telnet实现复用了Dubbo协议端口，其实就是在这层编解码做了通用处理。因为流中可能包含多个RPC请求，Dubbo框架尝试一次性读取更多完整报文编解码生成对象，也就是图中的DubboCountCodec，它的实现思想比较简单，依次调用DubboCodec去解码，如果能解码成完整报文，则加入消息列表，然后触发下一个Handler方法调用。

编码器的作用是将Java对象转成字节流，主要分两部分，构造报文头部，和对消息体进行序列化处理。所有码层实现都应该继承自ExchangeCodec，当Dubbo协议编码请求对象时，会调用ExchangeCodec#encode方法。我们来看下这个方法是如何对请求对象进行编码的：

如上，是Dubbo将请求对象转成字节流的过程，其中encodeRequestData方法是对RpcInvocation调用对象的编码，主要是对接口、方法、方法参数类型、方法参数等进行编码，在DubboCodec#encodeRequestData中对此方法进行了重写：

如上，响应编码与请求编码的逻辑基本大同小异，在编码出现异常时，会将异常响应返回给客户端，防止客户端只能一直等到超时。为了防止报错对象无法在客户端反序列化，在服务端会将异常信息转成字符串处理。对于响应体的编码，在DubboCodec#encodeResponseData方法中实现：

注意不管什么样的响应，都会先写入1个字节的标识符，具体的值和含义前面已经讲过。

解码相对更复杂一些，分为2部分，第一部分是解码报文的头部，第二部分是解码报文体内容并将其转换成RpcInvocation对象。我们先看服务端接受到请求后的解码过程，具体解码实现在ExchangeCodec#decode方法：

可以看出，解码过程中需要解决粘包和半包问题。接下来我们看一下DubboCodec对消息题解码的实现：

如上，如果默认配置在IO线程解码，直接调用decode方法；否则不做解码，延迟到业务线程池中解码。这里没有提到的是心跳和事件的解码，其实很简单，心跳报文是没有消息体的，事件又消息体，在使用Hessian2协议的情况下默认会传递字符R，当优雅停机时会通过发送readonly事件来通知客户端当前服务端不可用。
接下来，我们分析一下如何把消息体转换成RpcInvocation对象，具体在DecodeableRpcInvocation#decode方法中：

解码请求时，严格按照客户端写数据的顺序处理。
解码响应和解码请求类似，调用的同样是DubboCodec#decodeBody，就是上面省略的部分，这里就不赘述了，重点看下响应体的解码，即DecodeableRpcResult#decode方法：

如果读者熟悉Netty，就很容易理解Dubbo内部使用的ChannelHandler组件的原理，Dubbo内部使用了大量的Handler组成类似链表，依次处理具体逻辑，包括编解码、心跳时间戳和方法调用Handler等。因为Nettty每次创建Handler都会经过ChannelPipeline，大量的事件经过很多Pipeline会有较多开销，因此Dubbo会将多个Handler聚合成一个Handler。(个人表示，这简直bullshit)

Dubbo的Channelhandler有5中状态：

Dubbo针对每个特性都会实现对应的ChannelHandler，在讲解Handler的指责之前，我们Dubbo有哪些常用的Handler：

Dubbo提供了大量的Handler去承载特性和扩展，这些Handler最终会和底层通信框架做关联，比如Netty等。一次完整的RPC调用贯穿了一系列的Handler，如果直接挂载到底层通信框架(Netty)，因为整个链路比较长，则需要大量链式查找和事件，不仅低效，而且浪费资源。
下图展示了同时具有入站和出站ChannelHandler的布局，如果一个入站事件被触发，比如连接或数据读取，那么它会从ChannelPipeline头部一直传播到ChannelPipeline的尾端。出站的IO事件将从ChannelPipeline最右边开始，然后向左传播。当然ChannelPipeline传播时，会检测入站的是否实现了ChannelInboundHandler，出站会检测是否实现了ChannelOutboundHandler，如果没有实现，则自动跳过。Dubbo框架中实现这两个接口类主要是NettyServerHandler和NettyClientHandler。Dubbo通过装饰者模式包装Handler，从而不需要将每个Handler都追加到Pipeline中。因此NettyServer和NettyClient中最多有3个Handler，分别是编码、解码和NettyHandler。

讲完Handler的流转机制后，我们再来探讨RPC调用Provider方处理Handler的逻辑，在DubboProtocol中通过内部类继承自ExchangeHandlerAdapter，完成服务提供方Invoker实例的查找并进行服务的真实调用。

如上是触发业务方法调用的关键，在服务暴露时服务端已经按照特定规则(端口、接口名、接口版本和接口分组)把实例Invoker存储到HashMap中，客户端调用过来时必须携带相同信息构造的key，找到对应Exporter(里面持有Invoker)然后调用。
我们先跟踪getInvoker的实现，会发现服务端唯一标识的服务由4部分组成：端口、接口名、接口版本和接口分组。

如上，Dispatcher是线程池的派发器。这里需要注意的是，Dispatcher真实的职责是创建有线程派发能力的ChannelHandler，比如AllChannelHandler、MessageOnlyChannelHandler和ExecutionChannelHanlder，其本身并不具备线程派发能力。
Dispatcher属于Dubbo中的扩展点，这个扩展点用来动态产生Handler，以满足不同的场景，目前Dubbo支持一下6种策略调用：

具体需要按照使用场景不同启用不同的策略，建议使用默认策略，如果在TCP连接中需要做安全或校验，则可以使用ConnectionOrderedDispatcher策略。如果引入新的线程池，则不可避免的导致额外的线程切换，用户可在Dubbo配置中指定dispatcher属性让具体策略生效。

在Dubbo内部，所有方法调用都被抽象成Request/Response，每次调用都会创建一个Request，如果是方法调用则返回一个Response对象。HeaderExceptionExchangeHandler就是用了处理这种场景，主要负责4中事情：
(1) 更新发送和读取请求时间戳。
(2) 判断请求格式或编解码是否有错，并响应客户端失败的具体原因。
(3) 处理Request请求和Response正常响应。
(4) 支持Telnet调用。
我们先来看一下HeaderExchangeHandler#received实现：