Spring Cloud 升级之路 - 2020.0.x - 2. 使用 Undertow 做为咱们

> 本项目代码地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford

在咱们的项目中，咱们没有采用默认的 Tomcat 容器，而是使用了 UnderTow 做为咱们的容器。其实性能上的差别并无那么明显，可是使用 UnderTow 咱们能够利用直接内存做为网络传输的 buffer，减小业务的 GC，优化业务的表现。

**Undertow 的官网**：https://undertow.io/

可是，Undertow 有一些**使人担心**的地方：

1. NIO 框架采用的是 [XNIO](http://xnio.jboss.org/)，在官网 3.0  roadmap 声明中提到了将会在 3.0 版本开始，从 XNIO 迁移到 netty， 参考：[Undertow 3.0 Announcement](https://undertow.io/blog/2019/04/15/Undertow-3.html)。可是，目前已通过了快两年了，**3.0 仍是没有发布，而且 github 上 3.0 的分支已经一年多没有更新了**。目前，仍是在用 2.x 版本的 Undertow。不知道是 3.0 目前不必开发，仍是胎死腹中了呢？目前国内的环境对于 netty 使用更加普遍而且大部分人对于 netty 更加熟悉一些， XNIO 应用并非不少。不过，XNIO 的设计与 netty 大同小异。2. **官方文档的更新比较慢，可能会慢 1~2 个小版本**，致使 Spring Boot 粘合 Undertow 的时候，配置显得不会那么优雅。**参考官方文档的同时，最好仍是看一下源码，至少看一下配置类，才能搞懂到底是怎么设置的**。

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的思考](https://zhuanlan.zhihu.com/p/161939673)）。也能够经过文件映射内存直接分配，即 Java MMAP（具体能够参考个人一篇文章：[JDK核心JAVA源码解析（5） - JAVA File MMAP原理解析](https://zhuanlan.zhihu.com/p/258934554)）。因此，通常的 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 分析](https://juejin.cn/post/6925217498723778568)），可是简化了不少。**咱们只须要配置 buffer size ，并开启使用直接内存便可**。

       - Undertow `Listener`: 默认内置有 3 种 Listener ，分别是 HTTP/1.一、AJP 和 HTTP/2 分别对应的 Listener（HTTPS 经过对应的 HTTP Listner 开启 SSL 实现），负责全部请求的解析，将请求解析后包装成为 `HttpServerExchange` 并交给后续的 `Handler` 处理。

       - Undertow `Handler`: 经过 Handler 处理响应的业务，这样组成一个完整的 Web 服务器。

# Undertow 的一些默认配置

Undertow 的 Builder 设置了一些默认的参数，参考源码：

[`Undertow`](https://github.com/undertow-io/undertow/blob/2.2.7.Final/core/src/main/java/io/undertow/Undertow.java)

```
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`](https://github.com/undertow-io/undertow/blob/2.2.7.Final/core/src/main/java/io/undertow/server/DefaultByteBufferPool.java) 构造器：

```
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`](https://github.com/spring-projects/spring-boot/blob/2.4.x/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/web/ServerProperties.java) 这个类。目前 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`。