以前,一個應用可以支持成千上萬并發的客戶端會的想法會被認為是荒謬。今天我們認為是理所當然的。事實上,開發者知道,總是會有這樣的需求-以較低的成本交付來換取更大的吞吐量和可用性。
我們不要低估最后一點的重要性。我們從漫長的學習痛苦的經驗,低級別的 API 不僅暴露了一個高水平的直接使用的復雜性,而且引入了過分依賴于這項技術所造成的短板。因此,面向對象的一個基本原則:通過抽象來隱藏背后的復雜性。
這一原則已見成效,框架的形式封裝解決方案成為了常見的編程任務,他們中有許多典型的分布式系統。現在大多數專業的 Java 開發人員都熟悉一個或多個這些框架(比如 Spring),并且許多已成為不可或缺的,使他們能夠滿足他們的技術要求以及他們的計劃。
## [](https://github.com/waylau/essential-netty-in-action/blob/master/GETTING%20STARTED/Introducing%20Netty.md#誰在用-netty)誰在用 Netty
Netty 是一個廣泛使用的 Java 網絡編程框架(Netty 在 2011 年獲得了Duke's Choice Award,見[https://www.java.net/dukeschoice/2011](https://www.java.net/dukeschoice/2011)。它的活躍和成長用戶社區包括大型公司像 Facebook 和 Instagram 以及流行 開源項目如 Infinispan, HornetQ, Vert.x, Apache Cassandra 和 Elasticsearch,都利用其強大的網絡抽象的核心代碼。
反過來,Netty 也從這些項目中獲益。隨著這些項目的作用,也提高其范圍和靈活性,比如實現的實現的協議 FTP, SMTP, HTTP, WebSocket 和 SPDY 以及其他二進制和基于文本的。
在初創公司中 Firebase 和 Urban Airship 在使用 Netty。前者 Firebase 是使用 long-lived HTTP 連接,后者是使用 各種推送通知。
當你使用 Twitter,你會使用 Finagle,這個是基于 Netty API 提供給內部系統通訊。Facebook 使用 Netty 來提供于 Nifty 類似的功能 Apache Thrift 服務。這些公司可擴展性和高性能的表現得益于 Netty 的貢獻。
這些例子的真實案例會在后面幾章講到。
2011 年 Netty 項目從 Red Hat 獨立開來從而讓廣泛的開發者社區貢獻者參與進來。Red Hat ,Twitter 繼續使用 Netty ,并且成為保持其最活躍的貢獻者之一。
下面展示了 Netty 技術和方法的特點
* 設計
* 針對多種傳輸類型的統一接口 - 阻塞和非阻塞
* 簡單但更強大的線程模型
* 真正的無連接的數據報套接字支持
* 鏈接邏輯支持復用
* 易用性
* 大量的 Javadoc 和 代碼實例
* 除了在 JDK 1.6 + 額外的限制。(一些特征是只支持在Java 1.7 +。可選的功能可能有額外的限制。)
* 性能
* 比核心 Java API 更好的吞吐量,較低的延時
* 資源消耗更少,這個得益于共享池和重用
* 減少內存拷貝
* 健壯性
* 消除由于慢,快,或重載連接產生的 OutOfMemoryError
* 消除經常發現在 NIO 在高速網絡中的應用中的不公平的讀/寫比
* 安全
* 完整的 SSL / TLS 和 StartTLS 的支持
* 運行在受限的環境例如 Applet 或 OSGI
* 社區
* 發布的更早和更頻繁
* 社區驅動
## [](https://github.com/waylau/essential-netty-in-action/blob/master/GETTING%20STARTED/Introducing%20Netty.md#異步和事件驅動)異步和事件驅動
所有的網絡應用程序需要被設計為可擴展性,可以被界定為“一個系統,網絡能力,或過程中能夠處理越來越多的工作方式或可擴大到容納增長的能力”(見 Bondi, André B. (2000). "Characteristics of scalability and their impact on performance")。我們已經說過,Netty 幫助您利用非阻塞 I/O 完成這一目標,通常稱為“異步 I/O”
我們將使用“異步”和其同源詞在這本書中大量的使用,所以這是介紹他們的一個很好的時候。異步,即非同步事件,當然是跟你日常生活的類似。例如,您可以發送電子郵件;可能得到或者得不到任何回應,或者當你發送一個您可能會收到一個消息。異步事件也可以有一個有序的關系。例如,你通常不會收到一個問題的答案直到提出一個問題,但是你并沒有阻止同時一些其他的東西。
在日常生活中異步就這樣發生了,所以我們不會經常想到。但讓計算機程序的工作方式,來實現我們提出了的特殊的問題,會有一點復雜。在本質上,一個系統是異步和“事件驅動”將會表現出一個特定的,對我們來說,有價值的 行為:*它可以響應在任何時間以任何順序發生的事件*。
這是我們要建立一種制度,正如我們將會看到,這是典范的 Netty 自底向上的支持。
- Introduction
- 開始
- Netty-異步和數據驅動
- Netty 介紹
- 構成部分
- 關于本書
- 第一個 Netty 應用
- 設置開發環境
- Netty 客戶端/服務端 總覽
- 寫一個 echo 服務器
- 寫一個 echo 客戶端
- 編譯和運行 Echo 服務器和客戶端
- 總結
- Netty 總覽
- Netty 快速入門
- Channel, Event 和 I/O
- 什么是 Bootstrapping 為什么要用
- ChannelHandler 和 ChannelPipeline
- 近距離觀察 ChannelHandler
- 總結
- 核心功能
- Transport(傳輸)
- 案例研究:Transport 的遷移
- Transport API
- 包含的 Transport
- Transport 使用情況
- 總結
- Buffer(緩沖)
- Buffer API
- ByteBuf - 字節數據的容器
- 字節級別的操作
- ByteBufHolder
- ByteBuf 分配
- 總結
- ChannelHandler 和 ChannelPipeline
- ChannelHandler 家族
- ChannelPipeline
- ChannelHandlerContext
- 總結
- Codec 框架
- 什么是 Codec
- Decoder(解碼器)
- Encoder(編碼器)
- 抽象 Codec(編解碼器)類
- 總結
- 提供了的 ChannelHandler 和 Codec
- 使用 SSL/TLS 加密 Netty 程序
- 構建 Netty HTTP/HTTPS 應用
- 空閑連接以及超時
- 解碼分隔符和基于長度的協議
- 編寫大型數據
- 序列化數據
- 總結
- Bootstrap 類型
- 引導客戶端和無連接協議
- 引導服務器
- 從 Channel 引導客戶端
- 在一個引導中添加多個 ChannelHandler
- 使用Netty 的 ChannelOption 和屬性
- 關閉之前已經引導的客戶端或服務器
- 總結
- 引導
- Bootstrap 類型
- 引導客戶端和無連接協議
- 引導服務器
- 從 Channel 引導客戶端
- 在一個引導中添加多個 ChannelHandler
- 使用Netty 的 ChannelOption 和屬性
- 關閉之前已經引導的客戶端或服務器
- 總結
- NETTY BY EXAMPLE
- 單元測試
- 總覽
- 測試 ChannelHandler
- 測試異常處理
- 總結
- WebSocket
- WebSocket 程序示例
- 添加 WebSocket 支持
- 測試程序
- 總結
- SPDY
- SPDY 背景
- 示例程序
- 實現
- 啟動 SpdyServer 并測試
- 總結
- 通過 UDP 廣播事件
- UDP 基礎
- UDP 廣播
- UDP 示例
- EventLog 的 POJO
- 寫廣播器
- 寫監視器
- 運行 LogEventBroadcaster 和 LogEventMonitor
- 總結
- 高級主題
- 實現自定義的編解碼器
- 編解碼器的范圍
- 實現 Memcached 編解碼器
- 了解 Memcached 二進制協議
- Netty 編碼器和解碼器
- 測試編解碼器
- EventLoop 和線程模型
- 線程模型的總覽
- EventLoop
- EventLoop
- I/O EventLoop/Thread 分配細節
- 總結
- 用例1:Droplr Firebase 和 Urban Airship
- 用例2:Facebook 和 Twitter