Netty in Action 翻译（第一章）

1. Netty与Java NIO APIs

本章包括

• Netty的体系结构
• 为什么我们需要非阻塞IO（NIO）
• 阻塞IO与非阻塞IO
• 基于JDK的NIO存在的问题与Netty的解决办法

本章虽然是Netty的介绍章节，但重点却是Java的NIO API，如果你是JVM网络方面的新手，本章是个不错的开始，同时对于经验丰富的Java开发人员，也是一个不错的复习机会。如果你对NIO与NIO2（AIO）比较熟悉了，在你本机运行Netty后，请自行跳过本章，从第二章开始深入到Netty的世界了。

     Netty是一个NIO的CS（client-server）模式框架，使用它可以快速容易的开发网络应用，如协议服务器与客户端。Netty为你开发网络应用提供了一个新的易上手的可扩展方案。它的实现基于对复杂操作的抽象，并提供给一个对业务逻辑处理与网络处理代码的解耦的易用API。由于Netty是为NIO而设计，故其所有的API都是异步的。

     通常，不管是基于Netty还是基于其他NIO API的网络应用都存在扩展性的问题。Netty的关键组成部分是它的异步性，这一章节主要讨论同步（阻塞blocking）与异步（非阻塞non-blocking）IO，以此来解释我们为何以及如何通过异步代码解决可扩展性的问题。

     对于以上这些网络中新的部分，本章将给出一个关于网络应用的一般性理解以及Netty如何提升网络应用的性能的，本章将解释如何使用基本的Java networking APIs构建应用程式，以及讨论它的优缺点，另外，本章也展示了Netty是如何解决Java的这些问题（如Epoll模型的BUG或内存泄露问题）的。

     在本章结尾处，你将会理解Netty是什么以及它能帮我们干什么，同时结合本书的其他章节你也将会再次对你工作中用到的Java的NIO以及异步程式获得足够深入的理解。

1. 为何选择Netty

用David Wheeler的话来说"计算机科学中的所有问题都可以在另一个级别间接求解（all problems in computer science can be solved by another level of indirection）"，作为一个NIO CS框架，Netty提供了一个类似的另一级别间接解决方案。Netty简化了TCP或UDP服务端的网络编程，但你依然可以通过较低级别的APIs访问，因为Netty提供了较高层次的抽象。

1. 不是所有的网络框架都相似

Netty，"快且容易"并不意味着以牺牲应用的可维护性或性能为代价。来自于协议的实现经验（如FTP、SMTP、HTTP、WebSocket，SPDY以及各种二进制与基于文本的传统协议）引导了Netty的创作者们对Netty的设计非常小心，这也为Netty成功的提供了在可用性、性能、稳定性、灵活性上的兼顾。

     比较著名的公司以及开源组织包括RedHat、Twitter、Infinispan、HornetQ、Vert.x、Finagle、Akka、Apache  Cassandra、Elasticsearch等在使用Netty并为之做贡献。也可以公平的说Netty的一些特性正是这些项目所需的。过去的几年里，Netty变得越来越广为人之，同时它也是在一些盛行的开源非开源项目中应用最广泛的JVM网络框架之一。事实上，Netty在2011年荣获了"the  Duke_s  Choice  Award"奖。

     同样在2011年，Netty的作者Trustin Lee离开了RedHat加入了Twitter。基于这一点，Netty项目变成了一个独立的、任何公司都在努力为其做贡献的项目。RedHat与Twitter都在用Netty，所以，这两家公司理所当然的成为了Netty的最大贡献者，个人使用并贡献与Netty的数量还在增长。Netty的用户群体很活跃，Netty项目本身也是充满活力的。

1. Netty丰富的功能集

如果你按照本书的各章节操作练习时，你将会学到和用到很多Netty的功能。在下图的高亮部分（一些Netty支持的传输协议）给出了一个Netty架构的简要概述。

Figure 1.1 Overview of the model, transports, and protocols

 

除了它宽泛的传输协议，Netty也提供了在不同领域的优势（见下表1.1）

Table 1.1 Netty gives developers a full set of tools.

Development Area	Netty Features
Design	Unified API for various transport types_blocking and non-blocking socket Flexible to use Simple but powerful thread-model True connectionless datagram socket support Chaining of logics to make reuse easy
Ease of Use	Well-documented Javadoc and plenty of examples provided  No additional dependencies except JDK 1.6 (or above). Some features are supported only in Java 1.7 and above. Other features may have other  dependencies, but these are optional
Performance	Better throughput; lower latency than core Java APIs Less resource consumption because of pooling and reuse Minimized unnecessary memory copy
Robustness	No more OutOfMemoryError due to fast, slow, or overloaded connection. No more unfair read/write ratio often found in a NIO application in high-speed networks
Security	Complete SSL/TLS and StartTLS support
	Runs in a restricted environment such as Applet or OSGI
Community	Release early, release often Active

 

除了上述列举出来的功能，Netty也附带解决了在Java NIO中已知的BUG或限制，因此，你无需在为此花费精力讨论。

    在你对Netty的功能有了一个概览后，是时候仔细研究下异步处理的机制了，NIO与Netty都是严重依赖异步编码的，如果不了解与此相关的选择方案，就很难超越它。在下一部分，我们会研究下为何我们需要异步API。

1. 异步的设计

所有的Netty API都是异步的，异步式处理实际并不是新的东西；虽然这个方案的提出已经有一段时间了，但是在这段时间里，IO始终都是一个瓶颈，异步式处理一天比一天变得更重要。但它是如何工作的呢，又有哪些不同的模式可用呢？

    异步式处理鼓励你去更加有效的利用你的资源，首先你去开始一项任务，当任务结束的时候再去唤醒它继续执行，在这项任务的执行期间，你无须一直等待，你可以去做其他的事情。

    这部分将解释在利用异步API工作的时候的两个最常用的方法，也将讨论着两种技术的不同。

1. 回调

回调是在异步处理中常用到的一项技术。回调就是传到方法B中一个方法A，在B执行完以后，执行A方法，你可能在javascript中认出了此种模式，没错，回调函数是这门语言的核心，下面的例子向我们展示了如何利用该项技术来获取数据。

Listing 1.1 Callback example

public interface Fetcher {

void fetchData(FetchCallback callback);

}

public interface FetchCallback {

void onData(Data data);

void onError(Throwable cause);s

}

public class Worker {

public void doWork() {

Fetcher fetcher = ...

fetcher.fetchData(new FetchCallback() {

@Override

public void onData(Data data) { #1

System.out.println("Data received: " + data);

}

@Override

public void onError(Throwable cause) { #2

System.err.println("An error accour: " + cause.getMessage());

}

});

...

}

}s

#1 Call if data is fetched without error

#2 Call if error is received during fetch

（未完）