网关基于Netty 在Http 协议的实践

注:更多netty相关文章请访问博主专栏: netty专栏

网关基于Netty 在Http 协议的实践

我们网关现在完全基于netty 实现http 协议,包含客户端和服务端,http 客户端有很多选择,比如 HttpClient ,jdk 自带的等,都能模拟http ,但是和netty 相比,netty 支持堆外内存,而且内存自己管理,不需要频繁的申请和回收,可以减少GC的压力,以及极致的优化。所以netty http 协议是实现http client的首选。

我们网关服务用Netty 实现http 协议,主要是下面几点

  • 编解码
  • 引用次数释放
  • Head 请求
  • 连接池
  • 连接复用
  • Netty http 服务端
  • 完全异步

http编解码

网上有很多文章说到了netty的http 编解码,都只是一个demo,并没有在生产环境实践过的。

channelPipeline.addLast("idleStateHandler", new SouthgateReadIdleStateHandler(readIdleSec, 0, 0, TimeUnit.MILLISECONDS));
channelPipeline.addLast("httpEncode",new HttpRequestEncoder());
//channelPipeline.addLast("httpDecode",newHttpResponseDecoder());
//SouthgateHttpObjectAggregator 支持southgate channel 复用 和 HEAD 请求
channelPipeline.addLast("httpDecode",newSouthgateHttpResponseDecoder());
channelPipeline.addLast("aggregator", new HttpObjectAggregator(MAX_CONTENT_LENGTH));

httpEncode 和 httpDecode 必不可少,这是http协议的核心,
我们除了这两个外,还加了一个空闲超时管理的handler,来负责连接不用时,主动关闭连接,防止资源不释放

还有一个主要的聚合的handler HttpObjectAggregator,没有该HttpObjectAggregator跑个简单的http demo 可以,因为HttpObjectAggregator 是负责多个chunk的http 请求和响应的。他让我们的handler 处理看到的是一个完整的fullHttpResponse,不需要考虑是Content 是否是 LastHttpContent,netty的LastHttpContent代表body结束部分。一个chunk 代表一个HttpContent,最后一个chunk 由 LastHttpContent 表示。

Head 请求

http head 请求时,响应是没有响应头的,如果我们按上面设置的编解码,那我们还不能正常解析head 请求,因为netty HttpRequestEncoder 没有缓存请求的method,所以每次解析body部分时都,都是去读body,导致解析出错,netty 官方是通过HttpClientCodec来解决该问题,缓存每次请求的method,通过判断如果method 为head,则不读body,直接返回一个LastHttpContent 即空的body来表示body部分。

encode 前,先缓存当前请求的metod

if (msg instanceof HttpRequest && !done) {
   queue.offer(((HttpRequest) msg).method());
}

在收到响应做decode时:

// Get the getMethod of the HTTP request that corresponds to the
// current response.
HttpMethod method = queue.poll();

可以看出,用HttpClientCodec 必须是一个连接对应一个,否则method 回乱掉,如果想在http 上做类似rpc的连接复用,提供并发性能,那这个是不实现是不行的,需要自己实现,我们是自己重写了HttpResponseDecoder的isContentAlwaysEmpty 方法,HttpClientCodec里面的decode也是重写了该方法。

ByteBuf 释放,防止内存泄漏

引用计数

netty 的bytebuffer 从内存池里取出来用时,对应的relCnt是1,有些需要自己释放比如读操作,为了怕忘了释放release操作,netty 有个检查机制,有些会自动释放比如写请求,netty 在做完encode后发送完后,netty会对httpContent做一次release,即relCnt变为0,那么所对应的byteBuff会被回收,以便重用,只要relCnt 即引用次数为0,就不能再对其进行任何操作,因为已经被回收,Netty 的MessageToMessageEncoder encode如下:

try {
       //这里是具体的http 协议编码    
       encode(ctx, cast, out);
  } finally {
      //编码完后主动release
      ReferenceCountUtil.release(cast);
 }

netty 在inbound 操作时,需要自己主动释放,即你在handler 处理完后就主动调用release释放,如果在handler还没有处理完,需要交给业务线程继续处理的,你就在业务线程里release,release 可以通过netty提供的工具类ReferenceCountUtil来做

ReferenceCountUtil.release(httpResponse);

如果你是继承Netty的SimpleChannelInboundHandler,那处理就不样,因为SimpleChannelInboundHandler是帮你主动做了release,所以你在异步处理的时候,你先需要retain一次,否则你业务线程里操作时回报relCnt已经为0的不合法异常。

还有个需要注意的是,网络应用程序都有重试机制,如果encode后,发送失败,重试时如果没有在发送之前做retain操作,则会出现引用次数relCnt为0的不合法异常。所以在正常发之前,最好先retain操作。

((FullHttpRequest)httpRequest).retain(event.getMaxRedoCount());

这样增加了引用次数relCnt 后,如果一次就发送成功,不需要重试时,则需要自己主动释放

int refCnt = ((FullHttpResponse)httpResponse).refCnt();
if(refCnt > 0){
        ReferenceCountUtil.release(httpResponse,refCnt);
}

PoolThreadCache

Netty 默认启用线程本地缓存,所以在分配和释放的时候,都看该线程的PoolThreadCache 是否有可用的buffer,如果没有再从该线程绑定的arena 中分配,释放也是一样,先释放到该线程的PoolThreadCache 的对应的MemoryRegionCache的MpscArrayQueue里,如果queue 放不下了,才放回pool里,所以特别需要注意的是:申请和释放就需要在同一个线程里,我们在解码的时候申请是IO 线程,如果我们在业务线程里才释放,更重要的是如果业务没有申请buffer的话,这样就泄漏了。因为业务线程的PoolThreadCache 对应的MemoryRegionCache 的queue里的buffer都不能用,你dump的话,会发现很多MpscArrayQueue queue对象,有些业务异步处理的话,必须要在业务线程里释放,比如网关系统,所以一定要忌用ThreadLocalCache,可以通过如下设置:

System.setProperty("io.netty.recycler.maxCapacity","0");
System.setProperty("io.netty.allocator.tinyCacheSize","0");
System.setProperty("io.netty.allocator.smallCacheSize","0");
System.setProperty("io.netty.allocator.normalCacheSize","0");

ThreadLocalCache 虽然可以减少锁竞争的开销,因为io线程都在自己的地盘分配buffer,所以不需要到arena中去竞争,非常高效,但是这样非常容易触发内存泄漏,是把双刃剑。

连接池

http 协议是独占协议,一个请求独占一个连接,如果没有连接池,在高并发时,会出现连接用爆的情况,把系统压垮了。

netty 自带了连接池和一般的连接池,除了完全异步外,无其他的区别,实现了如下功能:

  • 固定连接数,没有连接可用,而且连接数没有达到最大值时,就会创建新的连接。
  • 有限队列,没有连接可用,而且连接数达到上限,则进入队列等待。
  • 超时机制,不可能让等待连接的请求一直等,这样资源得不到释放,所以一定要有超时机制,即等待一定的时间还时获取不到时,则超时,获取失败。
  • 补救措施,如果想在获取超时还时不甘心就此罢休,还支持去建立一个新的连接。失败补救措施,可以自己定义。默认支持两种策略,报超时和建新的连接
    代码如下:
final SouthgateChannelPool fixedChannelPool = new SouthgateChannelPool(bootstrap, nettyClientChannelPoolHandler, new ChannelHealthChecker() {

            @Override
            public io.netty.util.concurrent.Future<Boolean> isHealthy(Channel channel) {
                // 保证拿到的连接是可用的, 避免由于 slow receivers 造成oom(从pool中取channel 总会checkHealth)
                // http://normanmaurer.me/presentations/2014-facebook-eng-netty/slides.html#10.0
                // TODO 是否启动check before borrow, 以及如何check
                EventLoop loop = channel.eventLoop();
                return channel.isOpen() && channel.isActive() && channel.isWritable() ? loop.newSucceededFuture(Boolean.TRUE)
                        : loop.newSucceededFuture(Boolean.FALSE);
            //http 连接是独占的,再高并发下,获取连接超时时,直接创建新的连接,等空闲时会自动关闭
            }},
            FixedChannelPool.AcquireTimeoutAction.NEW, nettyConfig.getAcquireConnectionTimeout(), nettyConfig.getMaxConnections(),nettyConfig.getMaxPendingAcquires(),
                true,hostProfile);

需要注意的是,或者连接时的健康检查,我们需要保证拿到的连接时是可用的,判断可用除了需要 open 和 active,还最后加上isWritable。

isWritable 是防止把连接对应的发送链表写太多,导致内存溢出或者full gc,我们一般通过设置写水位上线。

bootstrap.option(ChannelOption.WRITE_BUFFER_WATER_MARK, new WriteBufferWaterMark(LOW_WATER_MARK, HIGH_WATER_MARK));

通过WRITE_BUFFER_WATER_MARK 设置,该连接的等待发送的消息大于设置的值时,isWritable() 返回false,即该连接不能再发生消息了。

连接复用

Http 协议天生就是独占,因为协议里没有唯一的请求ID,即一个连接同一时候,只能承载一个请求,这样在高并发下,连接势必会成为瓶颈,连接复用能用少量的连接支持高并发,提高吞吐量

想在http 上做连接复用,有点事倍功半的意思,如果想达到事半功倍的效果,需要多方的调优才行。

要想复用,我们首先得明白后端web 容器是怎么管理连接的,我们一般都用tomcat,下面以tomcat的为例说几个关键点。

tomcat 维持连接支持重用,但会在下面两种情况下会关闭连接:

  • 空闲超时关闭,默认20秒
  • 重用次数达到限制时关闭 由maxKeepAliveRequests 参数控制,默认100

maxKeepAliveRequests 参数如果你设置-1,那就时长连接了。否则,一个连接只要发送了100次就会在响应头里设置Connection:close 告诉客户端,我要关闭连接了,这也是为啥你用了连接池,还是不断新建连接的请求,在压测时特别明显。

知道tomcat的这些特性后,我们就能让连接复用了比较简单了。也就是和rpc 协议的做法一样,在header 里添加一个唯一请求ID,服务端需要把该ID 写会给网关系统。

需要注意的是,不是这样就万事大吉了,我们通过分析tomcat nio的代码,发现tomcat的读请求是同步的,即一个连接上堆积了多个请求,tomcat nio 是必须一个接一个处理完,不能并发同时处理多个请求。因为tomcat 的nio 解析http 包是在tomcat 的socketprocess task 由Catalina-exec线程处理的。即tomcat 的catalina线程即要负责io读取和业务执行两件事情,除非业务另起了业务线程来异步处理,或者是Serlvet3.0 异步,并不是nio poller 线程。

由于tomcat是同步处理请求,这样势必导致接收的慢即接收缓冲区很容易写满,从而引发发送端堆积,因为接受端回告诉发送端你不能发了,最终导致连接不可用。

还有一个是连接复用也解决不了tcp 层的头Head of block 问题,即一个连接上先发的包由于丢包或者延迟没有到达,即使该连接上后面的其他请求包都到达了,tcp 层还是等那个延迟的包。这个在google最新的QUIC 协议里有解决这个问题。

接入端用Netty

有同学会问,我们都有了tomcat 这么好的容器来接受http请求,为啥要用netty来做,个人觉得用netty来做http 协议接入有如下好处:

  • Netty的高性能就不用说了,比如对象池,内存池,边缘触发模式,对epoll bug的处理等,

  • netty的堆外内存,能很大程度上减少gc的压力,因为堆外内存真正的数据大对像号称冰山对象bytebuffer是不受jvm管理的,而jvm管理的只是一个很小的DirectByteBuffer对象

  • 读和写分别减少一次copy,如果是tomcat,我们必须通过getInputStream()来获取http的body,而这是需要从tomcat内部的inputBuffer copy 出来的,需要注意的是tomcat 的底层inputBuffer 默认是堆内的,这样的话,tomcat 从OS缓冲区 copy 出来会多一次copy,即OS–>Direct Buffer–>tomcat socketbuffer,用netty后,而Netty是使用堆外内存,相对于tomcat可以减少1次或者2次copy(tomcat 使用堆内buffer),特别是在并发量大的情况下,tomcat 堆buffer 下GC 压力很大,用Netty后,同样压力,GC 比较平稳。

  • tomcat在应对大并发时会容易引起nginx的block,tomcat默认的连接数是10000,假如并发超过了10000,tomcat在accept完10000个后,不会去accept后面的连接(都已经完成tcp 三次握手),这些连接都在tcp的连接队列里面,而客户端完成连接后就就开始写数据,最终表现客户端超时,用netty后,就可以在连接数达到限制后,我们之间关闭该连接,不让客户端等待超时才关闭。

完全异步

网关系统设计必须是异步的,才能接入各种后端响应时间不同的应用,后端响应慢,不会阻塞请求的进入。

Tomcat 做容器

异步后,tomcat的线程返回时我们不能让response 响应客户端,这里需要servlet3.0的异步支持。啥时候响应,当然是我们收到后端服务的结果后,再主动写response 给客户端。

Netty 实现

netty实现http服务端,需要自己实现异步线程池,从接入端到发起请求的客户端都得益于netty的事件驱动机制,没有阻塞。

总体线程模型关系图如下:
在这里插入图片描述

业界大厂基本都是这个线程模型,开源界大佬Netflix 的zuul2 也是有原来的servlet3 异步机制改造位netty 做接入端和服务调用的客户端。zuul2 更激进的是
接入端和客户端共用同一个event loop pool,一个请求的处理和响应都是有同一个io worker 线程处理,节省了线程上下文切换的开销,但是万一那个工程师写了个阻塞的代码,比如网络调用等,那对线上是灾难,所以我们为规避这个风险,接收这点上下文切换的开销是值得得

转载自:https://www.jianshu.com/p/1346f7fb6442

注:更多netty相关文章请访问博主专栏: netty专栏

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值