Netty系列之Netty可靠性分析.pdfVIP

BT Netty 列之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年，从美国东部时间8月19日下午2点45分开始，有用户率先发现了亚马逊网站出现宕机，大约在20多分钟后 又恢复正常。此次宕机让亚马逊每分钟损失近6.7万美元，在宕机期间，消费者无法通过A、亚马逊移动 端以及Amazon.ca等网站进行购物。 1.2. 软件可靠性 软件可靠性是指在给定时间内，特定环境下软件无错运行的概率。软件可靠性包含了以下三个要素： 1) 规定的时间：软件可靠性只是体现在其运行阶段，所以将运行时间作为规定的时间的度量。运行时间包括软件 系统运行后工 与挂起(开启但空闲)的累计时间。由于软件运行的环境与程序路径选取的随机性，软件的失效为 随机事件，所以运行时间属于随机变量; 2) 规定的环境条件:环境条件指软件的运行环境。它涉及软件系统运行时所需的 种支持要素，如支持硬件、操 系统、其它支持软件、输入数据格式和范围以及操 规程等。不同的环境条件下软件的可靠性是不同的。具体 地说，规定的环境条件主要是描述软件系统运行时计算机的配置情况以及对输入数据的要求，并假定其它一切因 素都是理想的。有了明确规定的环境条件，还可以有效判断软件失效的责任在用户方还是提供方; 3) 规定的功能:软件可靠性还与规定的任务和功能有关。由于要完成的任务不同，软件的运行剖面会有所区别， 则调用的子模块就不同(即程序路径选择不同)，其可靠性也就可能不同。所以要准确度量软件系统的可靠性必须 首先明确它的任务和功能。 1.3. Netty的可靠性 首先，我们要从Netty的主要用途来分析它的可靠性，Netty 目前的主流用法有三种： 1) 构建RPC调用的基础通信组件，提供跨节点的远程服务调用能力； 2) NIO通信框架，用于跨节点的数据交换； 3) 其它应用协议栈的基础通信组件，例如HTTP协议以及其它基于Netty开发的应用层协议栈。 以阿里的分布式服务框架Dubbo为例，Netty是Dubbo RPC框架的核心。它的服务调用示例图如下： 图1-1 Dubbo的节点角色说明图 其 ，服务提供者和服务调用者 间可以通过Dubbo协议进行RPC调用，消息的收发默认通过Netty完成。 通过对Netty主流应用场景的分析，我们发现Netty面临的可靠性问题大致分为三类： 1) 传统的网络I/O故障，例如网络闪断、防火墙Hang住连接、网络超时等； 2) NIO特有的故障，例如NIO类库特有的BUG、读写半包处理异常、Reactor线程跑飞等等； 3) 编解码相关的异常。 在大多数的业务应用场景 ，一旦因为某些故障导致Netty不能正常工作，业务往往会陷入瘫痪。所以，从业务诉 求来看，对Netty框架的可靠性要求是非常的高。作为当前业界最流行的一款NIO框架，Netty在不同行业和领域都 得到了广泛的应用，它的高可靠性已经得到了成百上千的生产系统检验。 Netty是如何支持系统高可靠性的？下面，我们就从几个不同维度出发一探究竟。 2. Netty高可靠性之道 2.1. 网络通信类故障 2.1.1. 客户端连接超时 在传统的同步阻塞编程模式下，客户端Socket发起网络连接，往往需要指定连接超时时间，这样做的目的主要有 两个： 1) 在同步阻塞I/O模型 ，连接操作是同步阻塞的，如果不设置超时时间，客户端I/O线程可能会被长时间阻塞， 这会导致系统可用I/O线程数的减少； 2) 业务层需要：大多数系统都会对业务流程执行时间有限制，例如WEB交互类的响应时间要小于3S。客户端设置 连接超时时间是为了实现业务层的超时。 JDK原生的Socket连接接口定义如下： 图2-1 JDK Socket连接超时接口 对于NIO的SocketChannel，在非阻塞模式下，它会直接返回连接结果，如果没有连接成功，也没有发生IO异常， 则需要将SocketChannel注册到Selector上监听连接结果。所以，异步连接的超时无法在API层面直接