本系列程式碼地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford

在我們的專案中，我們沒有采用預設的 Tomcat 容器，而是使用了 UnderTow 作為我們的容器。其實效能上的差異並沒有那麼明顯，但是使用 UnderTow 我們可以利用直接記憶體作為網路傳輸的 buffer，減少業務的 GC，優化業務的表現。其實 Tomcat 也有使用直接記憶體作為網路傳輸的 buffer 的配置，即 Connector 使用 NIO 或者 NIO2，還有 APR 這種基於 JNI 的優化檔案與請求傳輸的方式，但是 tomcat 隨著不斷迭代與發展，功能越來越完善以及元件化的同時，架構也越來越複雜，這也帶來了程式碼設計與質量上的一些降低。對比 Tomcat Connector 那裡的原始碼與設計，我最終選擇了更為輕量設計的 Undertow。至於不選 Jetty 的原因和 Tomcat 類似，不選 reactor-netty 的主要原因是專案還是比較新並且不太成熟，並且基於非同步回撥，很多時候異常處理不全面，導致最後詭異的響應並且異常定位成本比較高。

Undertow 的官網：https://undertow.io/

  • 紅帽開源產品，目前是 WildFly（JBoss AS）的預設 Web 容器。
  • 在不需要非常複雜的配置情況下，可以展現出很高的效能以及穩定性。
  • 非常輕量，只需通過 API 即可快速搭建 Web 伺服器。
  • 底層基於 XNIO，和 Netty 設計類似，使用 NIO 作為網路互動的方式，並且使用直接記憶體作為網路傳輸的 buffer，減少業務的 GC。
  • 由於基於這種非同步框架，所以配置也是交由鏈式Handler配置和處理請求，可以最小化按需載入模組，無須載入多餘功能
  • 支援 Servlet 4.0 以及向下相容，支援 WebSocket

但是，Undertow 有一些令人擔憂的地方：

  1. 官網一股貧窮的氣息，背靠紅帽這個不太靠譜的爹
  2. NIO 框架採用的是 XNIO，在官網 3.0 roadmap 宣告中提到了將會在 3.0 版本開始，從 XNIO 遷移到 netty， 參考：Undertow 3.0 Announcement。但是，目前已經過了快兩年了，3.0 還是沒有釋出，並且 github 上 3.0 的分支已經一年多沒有更新了。目前，還是在用 2.x 版本的 Undertow。不知道是 3.0 目前沒必要開發，還是胎死腹中了呢？目前國內的環境對於 netty 使用更加廣泛並且大部分人對於 netty 更加熟悉一些， XNIO 應用並不是很多。不過，XNIO 的設計與 netty 大同小異。
  3. 官方文件的更新比較慢，可能會慢 1~2 個小版本，導致 Spring Boot 粘合 Undertow 的時候，配置顯得不會那麼優雅。參考官方文件的同時，最好還是看一下原始碼，至少看一下配置類，才能搞懂究竟是怎麼設定的。
  4. 仔細看 Undertow 的原始碼，會發現有很多防禦性程式設計的設計或者功能性設計 Undertow 的作者想到了，但是就是沒實現，有很多沒有實現的半成品程式碼。這也令人擔心 Underow 是否開發動力不足，哪一天會突然死掉？

不過，幸好有 spring-boot，在 spring-boot 專案中，切換容器的成本不大，修改依賴即可。同時要注意，不同 web 容器的配置。

Undertow 目前(2.x) 還是基於 Java XNIO，Java XNIO 是一個對於 JDK NIO 類的擴充套件，和 netty 的基本功能是一樣的，但是 netty 更像是對於 Java NIO 的封裝，Java XNIO 更像是擴充套件封裝。主要是 netty 中基本傳輸承載資料的並不是 Java NIO 中的 ByteBuffer，而是自己封裝的 ByteBuf，而 Java XNIO 各個介面設計還是基於 ByteBuffer 為傳輸處理單元。設計上也很相似，都是 Reactor 模型的設計。其結構如下所示：

Java XNIO 主要包括如下幾個概念：

  • Java NIO ByteBuffer：Buffer 是一個具有狀態的陣列，用來承載資料，可以追蹤記錄已經寫入或者已經讀取的內容。主要屬性包括：capacity(Buffer 的容量)，position(下一個要讀取或者寫入的位置下標)，limit(當前可以寫入或者讀取的極限位置)。程式必須通過將資料放入 Buffer，才能從 Channel 讀取或者寫入資料。ByteBuffer是更加特殊的 Buffer，它可以以直接記憶體分配，這樣 JVM 可以直接利用這個 Bytebuffer 進行 IO 操作，省了一步複製（具體可以參考我的一篇文章：Java 堆外記憶體、零拷貝、直接記憶體以及針對於NIO中的FileChannel的思考）。也可以通過檔案對映記憶體直接分配，即 Java MMAP（具體可以參考我的一篇文章：JDK核心JAVA原始碼解析（5） - JAVA File MMAP原理解析）。所以，一般的 IO 操作都是通過 ByteBuffer 進行的。
  • Java NIO Channel：Channel 是 Java 中對於開啟和某一外部實體（例如硬體裝置，檔案，網路連線 socket 或者可以執行 IO 操作的某些元件）連線的抽象。Channel 主要是 IO 事件源，所有寫入或者讀取的資料都必須經過 Channel。對於 NIO 的 Channel，會通過 Selector 來通知事件的就緒（例如讀就緒和寫就緒），之後通過 Buffer 進行讀取或者寫入。
  • XNIO Worker: Worker 是 Java XNIO 框架中的基本網路處理單元，一個 Worker 包含兩個不同的執行緒池型別，分別是：
    • IO 執行緒池，主要呼叫Selector.start()處理對應事件的各種回撥，原則上不能處理任何阻塞的任務，因為這樣會導致其他連線無法處理。IO 執行緒池包括兩種執行緒（在 XNIO 框架中，通過設定 WORKER_IO_THREADS 來設定這個執行緒池大小，預設是一個 CPU 一個 IO 執行緒）：

      • 讀執行緒：處理讀事件的回撥
      • 寫執行緒：處理寫事件的回撥
    • Worker 執行緒池，處理阻塞的任務，在 Web 伺服器的設計中，一般將呼叫 servlet 任務放到這個執行緒池執行（在 XNIO 框架中，通過設定 WORKER_TASK_CORE_THREADS 來設定這個執行緒池大小）
  • XNIO ChannelListener：ChannelListener 是用來監聽處理 Channel 事件的抽象，包括：channel readable, channel writable, channel opened, channel closed, channel bound, channel unbound

Undertow 是基於 XNIO 的 Web 服務容器。在 XNIO 的基礎上，增加：

  • Undertow BufferPool: 如果每次需要 ByteBuffer 的時候都去申請，對於堆記憶體的 ByteBuffer 需要走 JVM 記憶體分配流程（TLAB -> 堆），對於直接記憶體則需要走系統呼叫，這樣效率是很低下的。所以，一般都會引入記憶體池。在這裡就是 BufferPool。目前，UnderTow 中只有一種 DefaultByteBufferPool，其他的實現目前沒有用。這個 DefaultByteBufferPool 相對於 netty 的 ByteBufArena 來說，非常簡單，類似於 JVM TLAB 的機制（可以參考我的另一系列：全網最硬核 JVM TLAB 分析），但是簡化了很多。我們只需要配置 buffer size ，並開啟使用直接記憶體即可。
  • Undertow Listener: 預設內建有 3 種 Listener ，分別是 HTTP/1.1、AJP 和 HTTP/2 分別對應的 Listener（HTTPS 通過對應的 HTTP Listner 開啟 SSL 實現），負責所有請求的解析，將請求解析後包裝成為 HttpServerExchange 並交給後續的 Handler 處理。
  • Undertow Handler: 通過 Handler 處理響應的業務，這樣組成一個完整的 Web 伺服器。

我們這一節詳細介紹了 Undertow 的結構，並且說明了 Undertow 的優點以及讓我們比較擔心的地方，並且與其他的 Web 容器做了對比。下一節我們將會分析 Undertow 的詳細配置。

微信搜尋“我的程式設計喵”關注公眾號，每日一刷，輕鬆提升技術，斬獲各種offer：