全链路异步Rest客户端 ESA RestClient

ESA Stack(Elastic Service Architecture) 是OPPO云计算中心孵化的技术品牌，致力于微服务相关技术栈，帮助用户快速构建高性能，高可用的云原生微服务。产品包含高性能Web服务框架、RPC框架、服务治理框架、注册中心、配置中心、调用链追踪系统，Service Mesh、Serverless等各类产品及研究方向。

当前部分产品已经对外开源：

开源主站：

https://www.esastack.io

Github: 

https://github.com/esastack

RestClient 项目地址：

https://github.com/esastack/esa-restclient

RestClient 文档地址：

https://www.esastack.io/esa-restclient

ESA RestClient

Step2: 构建RestClient并发送请求处理响应

2.1.1.2 使用ProtoBuf Encoder

指定contentType为ProtoBufCodec.PROTO_BUF，且Entity类型为com.google.protobuf.Message的子类时，将自动使用ProtoBuf Encoder来对Entity来进行Encode。示例如下：

2.1.1.3 使用File Encoder

当Entity类型为File时，将自动使用File Encoder来对Entity来进行Encode。示例如下：

2.1.1.4 自定义Encoder

当RestClient内置的Encoder无法满足用户需求时，用户可以自定义Encoder，示例如下：

用户可以将自定义的Encoder直接绑定到请求或者Client上，同时也支持用户通过SPI的方式加载Encoder，具体参见文档：《RestClient 配置Encoder》

2.1.1.5 Encode执行时机

见请求处理完整流程中的Encoder。

2.1.2 EncodeAdvice

用户可以通过EncodeAdvice在Encode前后插入业务逻辑，来对要Encode的 Entity 或者 Encode后的RequestContent 进行修改替换等操作。

2.1.2.1 示例

2.2.1.2 使用ProtoBuf Decoder

当Response的contentType为

ProtoBufCodec.PROTO_BUF，

且response.bodyToEntity()传入的类型为com.google.protobuf.Message的子类时，将自动使用ProtoBuf Decoder来进行Decode。

2.2.1.3 自定义Decoder

当RestClient内置的Decoder无法满足用户需求时，用户可以自定义Decoder，示例如下：

用户可以将自定义的Decoder直接绑定到请求或者Client上，同时也支持用户通过SPI的方式加载Decoder，具体参见文档：《RestClient 配置Decoder》

2.2.1.4 执行时机

见请求处理完整流程中的Decoder。

2.2.2 DecodeAdvice

用户可以通过DecodeAdvice在Decode前后进行来插入业务逻辑，来对要解码的 ResponseContent 或者 Decode后的对象 进行修改替换等操作。

2.2.2.1 示例

用户可以将自定义的DecodeAdvice直接绑定到Client上，同时也支持用户通过SPI的方式加载DecodeAdvice，具体参见文档：《RestClient 配置DecodeAdvice》

2.2.2.2 执行时机

见请求处理完整流程中的DecodeAdvice。

2.3 RestInterceptor

用户可以使用RestInterceptor在请求发送前和响应接收后来插入业务逻辑。RestClient支持通过builder配置和SPI加载两种方式配置RestInterceptor。

2.3.1 Builder配置

在构造RestClient时传入自定义的RestInterceptor实例，如：

2.3.2 SPI

2.3.2.1 普通SPI

RestClient支持通过SPI的方式加载RestInterceptor接口的实现类，使用时只需要按照SPI的加载规则将自定义的RestInterceptor放入指定的目录下即可。

2.3.2.2 RestInterceptorFactory

如果用户自定义的RestInterceptor对于不同RestClient的配置有不同的实现，则用户可以实现RestInterceptorFactory接口，并按照SPI的加载规则将自定义的RestInterceptorFactory放入指定的目录下即可。

在RestClient构建时将调用

RestInterceptorFactory.interceptors(RestClientOptions clientOptions)，该方法返回的所有RestInterceptor都将加入到构建好的RestClient中。

2.3.2.3 执行时机

见请求处理完整流程中的RestInterceptor。

2.4 大文件发送

当文件较小时，可通过直接将文件内容写入请求body来发送文件。但是当文件内容过大时，直接写入会有OOM风险。

为了解决这个问题，RestClient借助底层的Netty使用NIO以零拷贝的方式发送文件，避免了OOM的同时又减少了数据的多次拷贝。 

用户只需要简单的接口调用便可使用该功能：

2.5 读超时

RestClient支持请求级别的读超时，同时也支持Client 级别的读超时。默认读超时为6000L。

2.5.1 Client级别读超时

Client级别的读超时将对该Client下的所有请求生效，具体配置方式如下：

2.5.2 Request级别读超时

当Request设置了读超时，其数据将覆盖Client设置的读超时，具体配置方式如下:

2.6 重试

RestClient支持请求级别的重试，同时也支持Client 级别的重试。

默认情况下，RestClient仅会对所有抛出连接异常的请求进行重试(防止服务端的服务为非幂等)，其中：最大重试次数为3（不包括原始请求），重试间隔时间为0。使用时，可以通过自定义RetryOptions参数更改重试次数、重试条件、重试间隔时间等。

2.6.1 Client级别重试

Client级别的重试将对该Client下的所有 Request 生效，使用时，可以通过自定义RetryOptions参数更改重试次数、重试条件、重试间隔时间等。具体配置方式如下

2.6.2 Request级别重试

当Request设置了重试次数，其数据将覆盖Client设置的重试次数，具体配置方式如下:

2.7.2 Request设置重定向覆盖Client的设置

当Request设置了重定向次数，其数据将覆盖Client设置的重定向次数，具体配置方式如下:

2.8 其它功能

如果用户想对RestClient的功能有进一步了解，可以参考：《RestClient 功能文档》。

3 性能表现

3.1 测试场景

服务端为一个Echo服务器，客户端分别使用RestClient、Apache HttpAsyncClient 、 OK Httpclient均使用POST请求，请求体内容为固定字符串: OK，响应体内容也为固定字符串：OK。

3.2 机器配置

3.3 JVM参数

3.4 客户端版本

3.5 测试方法

如何测试异步客户端的性能？这是我们在性能测试前要面对的第一个问题，下面是我们对于该问题的一些思考：

能否for循环发起同步请求，同时使用多线程来达到框架的请求处理极限，并将该极限视为客户端的最佳TPS？

一般来说，用户既然选择异步客户端，肯定大部分时间都会使用异步的方式去发起请求，使用同步方式进行测试的结果并不能代表异步时客户端的性能。因此对于异步客户端的用户而言，同步方式测试的最终结果并没有很大的参考价值。

因此这种方式并不适合用来对异步客户端进行性能测试。

能否使用单线程for循环异步发起请求，直接将这个时候的TPS视为客户端的最佳TPS？

异步客户端异步发起请求时，发起请求的方法返回的非常快(因为请求执行的过程主要在IO线程池中进行)。尽管只使用单线程，如果一直for循环异步发起请求，请求发起的速度也会比IO线程池处理请求的速度快得多，这会导致大量请求在程序中的某个地方(如获取连接)堆积，从而导致程序报错，或性能低下。

因此这种方式也并不适合用来对异步客户端进行性能测试。

那么应该如何测试异步客户端的性能呢？

异步客户端专为异步而生，用户既然选择异步客户端，肯定大部分时间都会使用异步的方式发起请求，因此对于异步客户端而言，使用异步的方式去测试其性能是一种更加合适的方式。

问题的关键在于在测试过程中，如何避免过快地发起异步请求导致发起请求的速度超过框架的处理能力。

主要问题确定了，那么答案基本也就确定了。要避免过快地发起异步请求，我们可以想办法调整异步请求发起的速度，对于调整异步请求的发起速度，我们可以尝试用以下两种方式：

 · for循环周期性地发送一定次数的异步请求后，sleep一会儿，然后再继续发起异步请求。我们可以通过 控制sleep的时间 和 控制多少个请求间隔进行sleep 两个变量来控制异步请求的发起速率。

 · for循环周期性地发送一定次数的异步请求后，发送一个同步请求，然后再继续发起异步请求。用同步请求去代替sleep的时间，该同步请求执行完恰好说明了请求队列中的请求都已经排队结束。其实原理是相同的，但这样控制的变量更少一些，仅需要控制发起多少个异步请求后发起一次同步请求(即：一个周期内异步请求次数与同步请求次数的比例)。

上面两种方法都可以控制异步请求的发起速率，最终我们选择使用第二种方法来控制异步请求的发起速率，因为第二种方式需要控制的变量更少，这样我们的测试过程也会更加简单。

因此最终我们的测试方法为：

使用异步与同步交替的方式来发起请求，不断调整一个周期内异步请求与同步请求的比例，在每个比例下调整客户端的各项配置，使其达到最佳的TPS，记录每个比例下，框架的最佳TPS，直到找到增加 异步请求与同步请求的比例 时，框架的TPS不再上升，甚至下降的拐点，该拐点即为框架的性能极限点。

3.6 测试结果

4 架构设计

4.1 设计原则

 · 高性能：持续不懈追求的目标 & 核心竞争力。

 · 高扩展性：开放扩展点，满足业务多样化的需求。

 · 全链路异步：基于CompletableStage提供完善的异步处理能力。

4.2 结构设计

上图为RestClient的结构图，我们由上到下依次介绍一下各个部分的含义：

4.2.1RestInterceptorChain

RestInterceptorChain为RestInterceptor的集合，用户调用请求时，将依次经过RestInterceptorChain中的所有RestInterceptor。用户可以通过实现RestInterceptor中的getOrder()方法来指定其在RestInterceptorChain中的排序。

4.2.2EncodeAdviceChain

EncodeAdviceChain为EncodeAdvice的集合，在Encode前，将依次经过EncodeAdviceChain中的所有EncodeAdvice。用户可以通过实现EncodeAdvice中的getOrder()方法来指定其在EncodeAdviceChain中的排序。

4.2.3 EncoderChain

EncoderChain为Encoder的集合，在Encode时，将依次经过EncoderChain中的所有Encoder，直到某个Encoder直接返回Encode的结果（即：其可以Encode该请求）。用户可以通过实现Encoder中的getOrder()方法来指定其在EncoderChain中的排序。

4.2.4DecodeAdviceChain

DecodeAdviceChain为DecodeAdvice的集合，在Decode前，将依次经过DecodeAdviceChain中的所有DecodeAdvice。用户可以通过实现DecodeAdvice中的getOrder()方法来指定其在DecodeAdviceChain中的排序。

4.2.5DecoderChain

DecoderChain为Decoder的集合，在Decode时，将依次经过DecoderChain中的所有Decoder，直到某个Decoder直接返回Decode的结果（即：其可以Decode该响应）。用户可以通过实现Decoder中的getOrder()方法来指定其在DecoderChain中的排序。

4.2.6NettyTransceiver

NettyTransceiver 是 RestClient与其底层框架Neety之间连接的桥梁，在介绍其之前，需要一些预备知识，我们先来简单介绍一下这些预备知识：

4.2.6.1Channel & ChannelPool &ChannelPools

Channel ：Channel是Netty网络操作抽象类，它聚合了一组功能，包括但不限于网络的读、写，客户端发起连接、主动关闭连接，链路关闭，获得通信双方的网络地址等。它也包含了Netty框架相关的一些功能，包括获取该Channel的EventLoop,获取缓冲分配器ByteBufAllocator和pipeline等。

ChannelPool：ChannelPool用于缓存Channel，它允许获取和释放Channel，并充当这些Channel的池，从而达到复用Channel的目的。在RestClient中，每一个Server host对应一个ChannelPool。

ChannelPools：ChannelPools用于缓存ChannelPool。在RestClient中，当一个Server host长时间没有被访问时，其所对应的ChannelPool将会被视作缓存过期，从而被回收资源。

4.2.6.2EventLoop & EventLoopGroup

EventLoop：EventLoop在Netty中被用来运行任务来处理在Channel的生命周期内发生的事件。在RestClient中，一个EventLoop对应了一个线程。

EventLoopGroup：EventLoopGroup为一组EventLoop，其保证将多个任务尽可能地均匀地分配在多个EventLoop上。

4.2.6.3Epoll

Epoll是Linux内核的可扩展I/O事件通知机制，包含下面这三个系统调用。

int epoll_create(int size);

在内核中创建epoll实例并返回一个epoll文件描述符(对应上图中 EpollEventLoop中的epollFD)。在最初的实现中，调用者通过 size 参数告知内核需要监听的文件描述符数量。如果监听的文件描述符数量超过 size, 则内核会自动扩容。而现在 size 已经没有这种语义了，但是调用者调用时 size 依然必须大于 0，以保证后向兼容性。

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

向 epfd 对应的内核epoll 实例添加、修改或删除对 fd 上事件 event 的监听。op 可以为 EPOLL_CTL_ADD, EPOLL_CTL_MOD, EPOLL_CTL_DEL 分别对应的是添加新的事件，修改文件描述符上监听的事件类型，从实例上删除一个事件。

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

当 timeout 为 0 时，epoll_wait 永远会立即返回。而 timeout 为 -1 时，epoll_wait 会一直阻塞直到任一已注册的事件变为就绪。当 timeout 为一正整数时，epoll 会阻塞直到计时 timeout 毫秒终了或已注册的事件变为就绪。因为内核调度延迟，阻塞的时间可能会略微超过 timeout 毫秒。

Epoll运作流程:

1、进程先通过调用epoll_create来创建一个epoll文件描述符(对应上图中 EpollEventLoop中的epollFD)。epoll通过mmap开辟一块共享空间，该共享空间中包含一个红黑树和一个链表(对应上图epollFD中对应的Shared space)。

2、进程调用epoll的epoll_ctl add，把新来的链接的文件描述符放入红黑树中。

3、当红黑树中的fd有数据到了，就把它放入一个链表中并维护该数据可写还是可读。

上层用户空间(通过epoll_wait)从链表中取出所有fd，然后对其进行读写数据。

4.2.6.4NettyTransceiver初始化

当RestClient刚完成初始化时，NettyTransceiver也刚完成初始化，其初始化主要包含下面两部分：

 · 初始化 ChannelPools，刚初始化的ChannelPools为空，其内部不含有任何ChannelPool。

 · 初始化EpoolEventLoopGroup，

EpoolEventLoopGroup包含多个EpoolEventLoop。每个EpoolEventLoop都包含下面这三个部分：

  executor：真正执行任务的线程。

  taskQueue：任务队列，用户要执行的任务将被加入 到该队列中，然后再被executor执行。

  epollFD：epoll的文件描述符，在EpoolEventLoop创建时，调用epoll_create来创建一个epoll的共享空间，其对应的文件描述符就是epollFD。

4.2.6.5NettyTransceiver发送请求

当第一次发送请求时：NettyTransceiver将会为该Server host创建一个ChannelPool（如上图中的ChannelPool1），并缓存到channelPools中（默认10分钟内该Server host没有请求则视为缓存过期，其对应的ChannelPool将被从channelPools中删除）。ChannelPool在初始化时，主要包含下面两部分：

 · 初始化channelDeque，用于缓存channel，获取channel就是从channelDeque中拿出一个channel。

 · 在EventLoopGroup中选定一个EventLoop作为executor，该executor用来执行获取连接等操作。之所以ChannelPool需要一个固定的executor来执行获取连接等操作，是为了避免出现多个线程同时获取连接的情况，从而不需要对获取连接的操作进行加锁。

ChannelPool初始化完成后，则将由executor从ChannelPool中获取channel，初次获取时，由于ChannelPool中还没有channel，则将初始化第一个channel，channel的初始化步骤主要包含下面几步：

 · 创建连接，将连接封装为channel。

 · 将channel对应的连接通过epoll_ctl add方法加入到EpollEventLoopGroup中的一个EpollEventLoop的epollFD对应的共享空间的红黑树中。

· 将channel放到对应ChannelPool的channelDeque中。

初始化channel完成后，executor则将初始化好的channel返回，由绑定该channel的EpollEventLoop(即初始化channel第二步中所选定的EpollEventLoop)继续执行发送请求数据的任务。

4.2.6.6NettyTransceiver接收响应

4.2.7.1 线程模型的进一步优化

上面的线程模型为我们当前版本的线程模型，也是Netty自带连接池的线程模型。但是这种线程模型的性能一定是最高的吗?

这个问题的答案应该是否定的，因为尽管 ChannelPool 中指定一个 EventLoop 作为 executor 来执行获取 Channel 的操作可以使得 获取Channel 的过程无多线程争抢，但是却引入了下面这两个问题：

 · 获取Channel到Channel.write()之间大概率会进行一次EventLoop 切换 (有可能会将 获取Channel 与 Channel.write() 分配到同一个EventLoop ，如果分配到同一个EventLoop，则不需要进行EventLoop 切换 ，所以这里说大概率会切换),这次切换是有一定的性能成本的。

 · EventLoopGroup中的 EventLoop任务分配不均匀。因为channelPool中获取连接的那个 EventLoop在获取连接的同时还要处理数据的收发，比其他EventLoop多做一些工作，该EventLoop也成为了性能瓶颈点。在我们实际测试当中，也的确发现有一个EventLoop的线程CPU利用率较其它EventLoop更高一些。

那么更优越的线程模型是怎样的呢？通过上面的分析，我们觉得它应该要满足下面两点：

 · 获取Channel 到 Channel.write() 之间无线程切换。

 · 每个EventLoop的任务分配均匀。

基于我们的需求，我们可以得出最佳的结构模型与线程模型应该为下面这种：

优化后的结构模型：

如上图所示：一个 ChannelPool 由多个 ChildChannelPool 构成（个数 = IO线程个数），一个ChildChannelPool与一个 EventLoopGroup绑定，该EventLoopGroup仅含有一个 EventLoop (即一个ChildChannelPool对应一个EventLoop)。 

优化后的线程模型：

FastThreadLocal结构图

如上图所示，比起ThreadLocalMap，InternalThreadLocalMap直接根据 index 来获取值、设置值的做法更加简单，且直接使用数组的复杂度更低（虽然 ThreadLocalMap也是数组结构，但是其在数组的存取操作外还封装了大量hash计算以及防止hash碰撞的相关操作）。因此FastThreadLocal获得了更高的性能。

RestClient中均使用FastThreadLocal代替ThreadLocal以获取更高的性能。

5.7 Encode & Decode

与大多数Http客户端框架不同，RestClient不仅支持将Java对象Encode成byte[]，还支持将Java对象Encode成其他底层Netty支持的对象，如：File、MultipartBody等，未来还将会支持ChunkInput用来支持将请求体比较大的请求分块发送。

之所以这么设计，是因为如果我们仅仅支持将Java对象Encode成byte[]，那么当Encode后的byte[]数据过大时，将会出现OutOfMemoryException。用户在发送大文件或者本身请求体较大的请求时，都会出现这个问题。

为了解决这个问题，RestClient通过让用户可以将Java对象Encode成File或者ChunkInput来解决这一类问题。当用户将Java对象Encode成File时，RestClient将会借助底层的Netty使用NIO以零拷贝的方式发送文件，避免了OOM的同时又减少了数据的多次拷贝。 

同理当用户将Java对象Encode成ChunkInput时，RestClient将会分块发送数据，避免数据一次性全部加载进内存，从而避免OOM的情况。（PS：ChunkInput当前版本暂不支持，但已留出扩展点，将在下一版本支持）

Decode时也做了同样的优化，由于原理相同这里就不再展开讲解了。

6、结语

尽管RestClient主要只涉及发起请求这个简单的功能，但是“麻雀虽小，五脏俱全”，它考虑到了性能优化的方方面面，同时在 接口设计、代码整洁、功能完善 几个方面上也尽量做到了毫不妥协。

它还是一个年轻的项目，欢迎各路技术爱好者们加入，一同探讨学习与进步。

推荐阅读