Spring Cloud 升級之路 – 2020.0.x – 2. 使用 Undertow 作為我們的 Web 服務容器

本項目代碼地址：//github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford

在我們的項目中，我們沒有採用默認的 Tomcat 容器，而是使用了 UnderTow 作為我們的容器。其實性能上的差異並沒有那麼明顯，但是使用 UnderTow 我們可以利用直接內存作為網絡傳輸的 buffer，減少業務的 GC，優化業務的表現。

Undertow 的官網：//undertow.io/

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

  1. 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 大同小異。
  2. 官方文檔的更新比較慢，可能會慢 1~2 個小版本，導致 Spring Boot 粘合 Undertow 的時候，配置顯得不會那麼優雅。參考官方文檔的同時，最好還是看一下源碼，至少看一下配置類，才能搞懂究竟是怎麼設置的。
  3. 仔細看 Undertow 的源碼，會發現有很多防禦性編程的設計或者功能性設計 Undertow 的作者想到了，但是就是沒實現，有很多沒有實現的半成品代碼。這也令人擔心 Underow 是否開發動力不足，哪一天會突然死掉？

使用 Undertow 要注意的問題：

  1. 需要開啟 NIO DirectBuffer 的特性，理解並配置好相關的參數。
  2. access.log 中要包括必要的一些時間，調用鏈等信息，並且默認配置下，有些只配置 access.log 參數還是顯示不出來我們想看的信息，官網對於 access.log 中的參數的一些細節並沒有詳細說明。

使用 Undertow 作為我們的 Web 服務容器

對於 Servlet 容器，依賴如下：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

對於 Weflux 容器，依賴如下：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

Undertow 基本結構

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 的 Builder 設置了一些默認的參數，參考源碼：

Undertow

private Builder() {
    ioThreads = Math.max(Runtime.getRuntime().availableProcessors(), 2);
    workerThreads = ioThreads * 8;
    long maxMemory = Runtime.getRuntime().maxMemory();
    //smaller than 64mb of ram we use 512b buffers
    if (maxMemory < 64 * 1024 * 1024) {
        //use 512b buffers
        directBuffers = false;
        bufferSize = 512;
    } else if (maxMemory < 128 * 1024 * 1024) {
        //use 1k buffers
        directBuffers = true;
        bufferSize = 1024;
    } else {
        //use 16k buffers for best performance
        //as 16k is generally the max amount of data that can be sent in a single write() call
        directBuffers = true;
        bufferSize = 1024 * 16 - 20; //the 20 is to allow some space for protocol headers, see UNDERTOW-1209
    }

}
  • ioThreads 大小為可用 CPU 數量 * 2，即 Undertow 的 XNIO 的讀線程個數為可用 CPU 數量，寫線程個數也為可用 CPU 數量。
  • workerThreads 大小為 ioThreads 數量 * 8.
  • 如果內存大小小於 64 MB，則不使用直接內存，bufferSize 為 512 位元組
  • 如果內存大小大於 64 MB 小於 128 MB，則使用直接內存，bufferSize 為 1024 位元組
  • 如果內存大小大於 128 MB，則使用直接內存，bufferSize 為 16 KB 減去 20 位元組，這 20 位元組用於協議頭。

Undertow Buffer Pool 配置

DefaultByteBufferPool 構造器：

public DefaultByteBufferPool(boolean direct, int bufferSize, int maximumPoolSize, int threadLocalCacheSize, int leakDecetionPercent) {
    this.direct = direct;
    this.bufferSize = bufferSize;
    this.maximumPoolSize = maximumPoolSize;
    this.threadLocalCacheSize = threadLocalCacheSize;
    this.leakDectionPercent = leakDecetionPercent;
    if(direct) {
        arrayBackedPool = new DefaultByteBufferPool(false, bufferSize, maximumPoolSize, 0, leakDecetionPercent);
    } else {
        arrayBackedPool = this;
    }
}

其中：

  • direct：是否使用直接內存，我們需要設置為 true，來使用直接內存。
  • bufferSize：每次申請的 buffer 大小，我們主要要考慮這個大小
  • maximumPoolSize：buffer 池最大大小，一般不用修改
  • threadLocalCacheSize：線程本地 buffer 池大小，一般不用修改
  • leakDecetionPercent：內存泄漏檢查百分比，目前沒啥卵用

對於 bufferSize，最好和你系統的 TCP Socket Buffer 配置一樣。在我們的容器中，我們將微服務實例的容器內的 TCP Socket Buffer 的讀寫 buffer 大小成一模一樣的配置（因為微服務之間調用，發送的請求也是另一個微服務接受，所以調整所有微服務容器的讀寫 buffer 大小一致，來優化性能，默認是根據系統內存來自動計算出來的）。

查看 Linux 系統 TCP Socket Buffer 的大小：

  • /proc/sys/net/ipv4/tcp_rmem (對於讀取)
  • /proc/sys/net/ipv4/tcp_wmem (對於寫入)

在我們的容器中，分別是：

bash-4.2# cat /proc/sys/net/ipv4/tcp_rmem
4096    16384   4194304 
bash-4.2# cat /proc/sys/net/ipv4/tcp_wmem
4096    16384   4194304

從左到右三個值分別為：每個 TCP Socket 的讀 Buffer 與寫 Buffer 的大小的 最小值，默認值和最大值，單位是位元組。

我們設置我們 Undertow 的 buffer size 為 TCP Socket Buffer 的默認值，即 16 KB。Undertow 的 Builder 裏面，如果內存大於 128 MB，buffer size 為 16 KB 減去 20 位元組（為協議頭預留）。所以，我們使用默認的即可。

application.yml 配置：

server.undertow:
    # 是否分配的直接內存(NIO直接分配的堆外內存)，這裡開啟，所以java啟動參數需要配置下直接內存大小，減少不必要的GC
    # 在內存大於 128 MB 時，默認就是使用直接內存的
    directBuffers: true
    # 以下的配置會影響buffer,這些buffer會用於服務器連接的IO操作
    # 如果每次需要 ByteBuffer 的時候都去申請，對於堆內存的 ByteBuffer 需要走 JVM 內存分配流程（TLAB -> 堆），對於直接內存則需要走系統調用，這樣效率是很低下的。
    # 所以，一般都會引入內存池。在這裡就是 `BufferPool`。
    # 目前，UnderTow 中只有一種 `DefaultByteBufferPool`，其他的實現目前沒有用。
    # 這個 DefaultByteBufferPool 相對於 netty 的 ByteBufArena 來說，非常簡單，類似於 JVM TLAB 的機制
    # 對於 bufferSize，最好和你系統的 TCP Socket Buffer 配置一樣
    # `/proc/sys/net/ipv4/tcp_rmem` (對於讀取)
    # `/proc/sys/net/ipv4/tcp_wmem` (對於寫入)
    # 在內存大於 128 MB 時，bufferSize 為 16 KB 減去 20 位元組，這 20 位元組用於協議頭
    buffer-size: 16384 - 20

Undertow Worker 配置

Worker 配置其實就是 XNIO 的核心配置，主要需要配置的即 io 線程池以及 worker 線程池大小。

默認情況下，io 線程大小為可用 CPU 數量 * 2，即讀線程個數為可用 CPU 數量，寫線程個數也為可用 CPU 數量。worker 線程池大小為 io 線程大小 * 8.

微服務應用由於涉及的阻塞操作比較多，所以可以將 worker 線程池大小調大一些。我們的應用設置為 io 線程大小 * 32.

application.yml 配置：

server.undertow.threads:
    # 設置IO線程數, 它主要執行非阻塞的任務,它們會負責多個連接, 默認設置每個CPU核心一個讀線程和一個寫線程
    io: 16
    # 阻塞任務線程池, 當執行類似servlet請求阻塞IO操作, undertow會從這個線程池中取得線程
    # 它的值設置取決於系統線程執行任務的阻塞係數，默認值是IO線程數*8
    worker: 128

Spring Boot 中的 Undertow 配置

Spring Boot 中對於 Undertow 相關配置的抽象是 ServerProperties 這個類。目前 Undertow 涉及的所有配置以及說明如下（不包括 accesslog 相關的，accesslog 會在下一節詳細分析）：

server:
  undertow:
    # 以下的配置會影響buffer,這些buffer會用於服務器連接的IO操作
    # 如果每次需要 ByteBuffer 的時候都去申請，對於堆內存的 ByteBuffer 需要走 JVM 內存分配流程（TLAB -> 堆），對於直接內存則需要走系統調用，這樣效率是很低下的。
    # 所以，一般都會引入內存池。在這裡就是 `BufferPool`。
    # 目前，UnderTow 中只有一種 `DefaultByteBufferPool`，其他的實現目前沒有用。
    # 這個 DefaultByteBufferPool 相對於 netty 的 ByteBufArena 來說，非常簡單，類似於 JVM TLAB 的機制
    # 對於 bufferSize，最好和你系統的 TCP Socket Buffer 配置一樣
    # `/proc/sys/net/ipv4/tcp_rmem` (對於讀取)
    # `/proc/sys/net/ipv4/tcp_wmem` (對於寫入)
    # 在內存大於 128 MB 時，bufferSize 為 16 KB 減去 20 位元組，這 20 位元組用於協議頭
    buffer-size: 16364
    # 是否分配的直接內存(NIO直接分配的堆外內存)，這裡開啟，所以java啟動參數需要配置下直接內存大小，減少不必要的GC
    # 在內存大於 128 MB 時，默認就是使用直接內存的
    directBuffers: true
    threads:
      # 設置IO線程數, 它主要執行非阻塞的任務,它們會負責多個連接, 默認設置每個CPU核心一個讀線程和一個寫線程
      io: 4
      # 阻塞任務線程池, 當執行類似servlet請求阻塞IO操作, undertow會從這個線程池中取得線程
      # 它的值設置取決於系統線程執行任務的阻塞係數，默認值是IO線程數*8
      worker: 128
    # http post body 大小，默認為 -1B ，即不限制
    max-http-post-size: -1B
    # 是否在啟動時創建 filter，默認為 true，不用修改
    eager-filter-init: true
    # 限制路徑參數數量，默認為 1000
    max-parameters: 1000
    # 限制 http header 數量，默認為 200
    max-headers: 200
    # 限制 http header 中 cookies 的鍵值對數量，默認為 200
    max-cookies: 200
    # 是否允許 / 與 %2F 轉義。/ 是 URL 保留字,除非你的應用明確需要，否則不要開啟這個轉義，默認為 false
    allow-encoded-slash: false
    # 是否允許 URL 解碼，默認為 true，除了 %2F 其他的都會處理
    decode-url: true
    # url 字符編碼集，默認是 utf-8
    url-charset: utf-8
    # 響應的 http header 是否會加上 'Connection: keep-alive'，默認為 true
    always-set-keep-alive: true
    # 請求超時，默認是不超時，我們的微服務因為可能有長時間的定時任務，所以不做服務端超時，都用客戶端超時，所以我們保持這個默認配置
    no-request-timeout: -1
    # 是否在跳轉的時候保持 path，默認是關閉的，一般不用配置
    preserve-path-on-forward: false
    options:
      # spring boot 沒有抽象的 xnio 相關配置在這裡配置，對應 org.xnio.Options 類
      socket:
        SSL_ENABLED: false
      # spring boot 沒有抽象的 undertow 相關配置在這裡配置，對應 io.undertow.UndertowOptions 類
      server:
        ALLOW_UNKNOWN_PROTOCOLS: false

Spring Boot 並沒有將所有的 Undertow 與 XNIO 配置進行抽象，如果你想自定義一些相關配置，可以通過上面配置最後的 server.undertow.options 進行配置。server.undertow.options.socket 對應 XNIO 的相關配置，配置類是 org.xnio.Options;server.undertow.options.server 對應 Undertow 的相關配置，配置類是 io.undertow.UndertowOptions。

Tags:

VirMach 便宜 VPS

QNews

QNews