使用Netty，我们到底在开发些什么？

流量可能还会通过外层的路由持续进入，造成无效请求。我的通常做法是首先在外层路由进行一次本地实例的摘除，把流量截断，然后再进行netty本身的优雅关闭。这种设计非常简单，即使没有重试机制也会运行的很好，前提是在路由层需要提前暴露相关接口。

异常处理功能

netty由于其异步化的开发方式，以及其事件机制，在异常处理方面就显得异常重要。为了保证连接的高可靠性，许多异常需要静悄悄的忽略，或者在用户态没有感知。

netty的异常会通过pipeline进行传播，所以在任何一层进行处理都是可行的，但编程习惯上，习惯性抛到最外层集中处理。

为了最大限度的区别异常信息，通常会定义大量的异常类，不同的错误会抛出不同的异常。发生异常后，可以根据不同的类型选择断线重连(比如一些二进制协议的编解码紊乱问题)，或者调度到其他节点。

功能限制

指令模式

网络应用就该干网络应用的事，任何通讯都是昂贵的。在《Linux之《荒岛余生》(五)网络篇》中，我们谈到百万连接的服务器，广播一个1kb消息，就需要1000M的带宽，所以并不是什么都可以放在网络应用里的。

一个大型网络应用的合理的思路就是值发送相关指令。客户端在收到指令以后，通过其他方式，比如http，进行大型文件到获取。很多IM的设计思路就是如此。

指令模式还会让通讯系统的扩展性和稳定性得到保证。增加指令可以是配置式的，立即生效，服务端不需要编码重启。

稳定性保证

网络应用的流量一般都是非常大的，并不适合全量日志的开启。应用应该只关注主要事件的日志，关注异常情况下的处理流程，日志要打印有度。

网络应用也不适合调用其他缓慢的api，或者任何阻塞I/O的接口。一些实时的事件，也不应该通过调用接口吐出数据，可以走高速mq等其他异步通道。

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!