《Netty系列之Netty可靠性分析》由会员分享，可在线阅读，更多相关《Netty系列之Netty可靠性分析（17页珍藏版）》请在金锄头文库上搜索。
1、BTNetty系列之Netty可靠性分析 作者 李林锋 发布于 2014年6月18日1. 背景1.1. 宕机的代价1.1.1. 电信行业毕马威国际(KPMG International)在对46个国家的74家运营商进行调查后发现，全球通信行业每年的收益流失约为400亿美元，占总收入的1%-3%。导致收益流失的因素有多种，主要原因就是计费BUG。1.1.2. 互联网行业美国太平洋时间8月16日下午3点50分到3点55分（北京时间8月17日6点50分到6点55分），谷歌遭遇了宕机。根据事后统计，短短的5分钟，谷歌损失了54.5万美元。也就是服务每中断一分钟，损失就达10.8万美元。2013年，从美
2、国东部时间8月19日下午2点45分开始，有用户率先发现了亚马逊网站出现宕机，大约在20多分钟后又恢复正常。此次宕机让亚马逊每分钟损失近6.7万美元，在宕机期间，消费者无法通过A、亚马逊移动端以及Amazon.ca等网站进行购物。1.2. 软件可靠性软件可靠性是指在给定时间内，特定环境下软件无错运行的概率。软件可靠性包含了以下三个要素：1) 规定的时间：软件可靠性只是体现在其运行阶段，所以将运行时间作为规定的时间的度量。运行时间包括软件系统运行后工作与挂起(开启但空闲)的累计时间。由于软件运行的环境与程序路径选取的随机性，软件的失效为随机事件，所以运行时间属于随机变量;2) 规定的环境条件:环境
3、条件指软件的运行环境。它涉及软件系统运行时所需的各种支持要素，如支持硬件、操作系统、其它支持软件、输入数据格式和范围以及操作规程等。不同的环境条件下软件的可靠性是不同的。具体地说，规定的环境条件主要是描述软件系统运行时计算机的配置情况以及对输入数据的要求，并假定其它一切因素都是理想的。有了明确规定的环境条件，还可以有效判断软件失效的责任在用户方还是提供方;3) 规定的功能:软件可靠性还与规定的任务和功能有关。由于要完成的任务不同，软件的运行剖面会有所区别，则调用的子模块就不同(即程序路径选择不同)，其可靠性也就可能不同。所以要准确度量软件系统的可靠性必须首先明确它的任务和功能。1.3. Net
4、ty的可靠性首先，我们要从Netty的主要用途来分析它的可靠性，Netty目前的主流用法有三种：1) 构建RPC调用的基础通信组件，提供跨节点的远程服务调用能力；2) NIO通信框架，用于跨节点的数据交换；3) 其它应用协议栈的基础通信组件，例如HTTP协议以及其它基于Netty开发的应用层协议栈。以阿里的分布式服务框架Dubbo为例，Netty是Dubbo RPC框架的核心。它的服务调用示例图如下：图1-1 Dubbo的节点角色说明图其中，服务提供者和服务调用者之间可以通过Dubbo协议进行RPC调用，消息的收发默认通过Netty完成。通过对Netty主流应用场景的分析，我们发现Netty面
5、临的可靠性问题大致分为三类：1) 传统的网络I/O故障，例如网络闪断、防火墙Hang住连接、网络超时等；2) NIO特有的故障，例如NIO类库特有的BUG、读写半包处理异常、Reactor线程跑飞等等；3) 编解码相关的异常。在大多数的业务应用场景中，一旦因为某些故障导致Netty不能正常工作，业务往往会陷入瘫痪。所以，从业务诉求来看，对Netty框架的可靠性要求是非常的高。作为当前业界最流行的一款NIO框架，Netty在不同行业和领域都得到了广泛的应用，它的高可靠性已经得到了成百上千的生产系统检验。Netty是如何支持系统高可靠性的？下面，我们就从几个不同维度出发一探究竟。2. Netty高
6、可靠性之道2.1. 网络通信类故障2.1.1. 客户端连接超时在传统的同步阻塞编程模式下，客户端Socket发起网络连接，往往需要指定连接超时时间，这样做的目的主要有两个：1) 在同步阻塞I/O模型中，连接操作是同步阻塞的，如果不设置超时时间，客户端I/O线程可能会被长时间阻塞，这会导致系统可用I/O线程数的减少；2) 业务层需要：大多数系统都会对业务流程执行时间有限制，例如WEB交互类的响应时间要小于3S。客户端设置连接超时时间是为了实现业务层的超时。JDK原生的Socket连接接口定义如下：图2-1 JDK Socket连接超时接口对于NIO的SocketChannel，在非阻塞模式下，它
7、会直接返回连接结果，如果没有连接成功，也没有发生IO异常，则需要将SocketChannel注册到Selector上监听连接结果。所以，异步连接的超时无法在API层面直接设置，而是需要通过定时器来主动监测。下面我们首先看下JDK NIO类库的SocketChannel连接接口定义：图2-2 JDK NIO 类库SocketChannel连接接口从上面的接口定义可以看出，NIO类库并没有现成的连接超时接口供用户直接使用，如果要在NIO编程中支持连接超时，往往需要NIO框架或者用户自己封装实现。下面我们看下Netty是如何支持连接超时的，首先，在创建NIO客户端的时候，可以配置连接超时参数：图2-
8、3 Netty客户端创建支持设置连接超时参数设置完连接超时之后，Netty在发起连接的时候，会根据超时时间创建ScheduledFuture挂载在Reactor线程上，用于定时监测是否发生连接超时，相关代码如下：图2-4 根据连接超时创建超时监测定时任务创建连接超时定时任务之后，会由NioEventLoop负责执行。如果已经连接超时，但是服务端仍然没有返回TCP握手应答，则关闭连接，代码如上图所示。如果在超时期限内处理完成连接操作，则取消连接超时定时任务，相关代码如下：图2-5 取消连接超时定时任务Netty的客户端连接超时参数与其它常用的TCP参数一起配置，使用起来非常方便，上层用户不用关心
9、底层的超时实现机制。这既满足了用户的个性化需求，又实现了故障的分层隔离。2.1.2. 通信对端强制关闭连接在客户端和服务端正常通信过程中，如果发生网络闪断、对方进程突然宕机或者其它非正常关闭链路事件时，TCP链路就会发生异常。由于TCP是全双工的，通信双方都需要关闭和释放Socket句柄才不会发生句柄的泄漏。在实际的NIO编程过程中，我们经常会发现由于句柄没有被及时关闭导致的功能和可靠性问题。究其原因总结如下：1) IO的读写等操作并非仅仅集中在Reactor线程内部，用户上层的一些定制行为可能会导致IO操作的外逸，例如业务自定义心跳机制。这些定制行为加大了统一异常处理的难度，IO操作越发散，
10、故障发生的概率就越大；2) 一些异常分支没有考虑到，由于外部环境诱因导致程序进入这些分支，就会引起故障。下面我们通过故障模拟，看Netty是如何处理对端链路强制关闭异常的。首先启动Netty服务端和客户端，TCP链路建立成功之后，双方维持该链路，查看链路状态，结果如下：图2-6 Netty服务端和客户端TCP链路状态正常强制关闭客户端，模拟客户端宕机，服务端控制台打印如下异常：图2-7 模拟TCP链路故障从堆栈信息可以判断，服务端已经监控到客户端强制关闭了连接，下面我们看下服务端是否已经释放了连接句柄，再次执行netstat命令，执行结果如下：图2-8 查看故障链路状态从执行结果可以看出，服务
11、端已经关闭了和客户端的TCP连接，句柄资源正常释放。由此可以得出结论，Netty底层已经自动对该故障进行了处理。下面我们一起看下Netty是如何感知到链路关闭异常并进行正确处理的，查看AbstractByteBuf的writeBytes方法，它负责将指定Channel的缓冲区数据写入到ByteBuf中，详细代码如下：图2-9 AbstractByteBuf的writeBytes方法在调用SocketChannel的read方法时发生了IOException，代码如下：图2-10 读取缓冲区数据发生IO异常为了保证IO异常被统一处理，该异常向上抛，由AbstractNioByteChannel进
12、行统一异常处理，代码如下：图2-11 链路异常退出异常处理为了能够对异常策略进行统一，也为了方便维护，防止处理不当导致的句柄泄漏等问题，句柄的关闭，统一调用AbstractChannel的close方法，代码如下：图2-12 统一的Socket句柄关闭接口2.1.3. 正常的连接关闭对于短连接协议，例如HTTP协议，通信双方数据交互完成之后，通常按照双方的约定由服务端关闭连接，客户端获得TCP连接关闭请求之后，关闭自身的Socket连接，双方正式断开连接。在实际的NIO编程过程中，经常存在一种误区：认为只要是对方关闭连接，就会发生IO异常，捕获IO异常之后再关闭连接即可。实际上，连接的合法关闭
13、不会发生IO异常，它是一种正常场景，如果遗漏了该场景的判断和处理就会导致连接句柄泄漏。下面我们一起模拟故障，看Netty是如何处理的。测试场景设计如下：改造下Netty客户端，双发链路建立成功之后，等待120S，客户端正常关闭链路。看服务端是否能够感知并释放句柄资源。首先启动Netty客户端和服务端,双方TCP链路连接正常：图2-13 TCP连接状态正常120S之后，客户端关闭连接，进程退出，为了能够看到整个处理过程，我们在服务端的Reactor线程处设置断点，先不做处理，此时链路状态如下：图2-14 TCP连接句柄等待释放从上图可以看出，此时服务端并没有关闭Socket连接，链路处于CLOS
14、E_WAIT状态，放开代码让服务端执行完，结果如下：图2-15 TCP连接句柄正常释放下面我们一起看下服务端是如何判断出客户端关闭连接的，当连接被对方合法关闭后，被关闭的SocketChannel会处于就绪状态，SocketChannel的read操作返回值为-1，说明连接已经被关闭，代码如下：图2-16 需要对读取的字节数进行判断如果SocketChannel被设置为非阻塞，则它的read操作可能返回三个值：1) 大于0，表示读取到了字节数；2) 等于0，没有读取到消息，可能TCP处于Keep-Alive状态，接收到的是TCP握手消息；3) -1，连接已经被对方合法关闭。通过调试，我们发现，
15、NIO类库的返回值确实为-1：图2-17 链路正常关闭，返回值为-1得知连接关闭之后，Netty将关闭操作位设置为true,关闭句柄，代码如下：图2-18 连接正常关闭，释放资源2.1.4. 故障定制在大多数场景下，当底层网络发生故障的时候，应该由底层的NIO框架负责释放资源，处理异常等。上层的业务应用不需要关心底层的处理细节。但是，在一些特殊的场景下，用户可能需要感知这些异常，并针对这些异常进行定制处理，例如：1) 客户端的断连重连机制；2) 消息的缓存重发；3) 接口日志中详细记录故障细节；4) 运维相关功能，例如告警、触发邮件/短信等Netty的处理策略是发生IO异常，底层的资源由它负责
16、释放，同时将异常堆栈信息以事件的形式通知给上层用户，由用户对异常进行定制。这种处理机制既保证了异常处理的安全性，也向上层提供了灵活的定制能力。具体接口定义以及默认实现如下：图2-19 故障定制接口用户可以覆盖该接口，进行个性化的异常定制。例如发起重连等。2.2. 链路的有效性检测当网络发生单通、连接被防火墙Hang住、长时间GC或者通信线程发生非预期异常时，会导致链路不可用且不易被及时发现。特别是异常发生在凌晨业务低谷期间，当早晨业务高峰期到来时，由于链路不可用会导致瞬间的大批量业务失败或者超时，这将对系统的可靠性产生重大的威胁。从技术层面看，要解决链路的可靠性问题，必须周期性的对链路进行有效性检测。目前最流行和通用的做法就是心跳检测。心跳检测机制分为三个层面：1) TCP层面的心跳检测，即TCP的Keep-Alive机制，它的作用域是整个TCP协议栈；2) 协议层的心跳检测，主要存在于长连接协议中。例如SMPP协议；3) 应用层的心跳检测，它主要由各业务产品通过约定方式定时给对方发送心跳消息实现。
