本项目代码地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford
在我们的项目中，我们没有采用默认的 Tomcat 容器，而是使用了 UnderTow 作为我们的容器。其实性能上的差异并没有那么明显，但是使用 UnderTow 我们可以利用直接内存作为网络传输的 buffer，减少业务的 GC，优化业务的表现。
Undertow 的官网：https://undertow.io/
但是，Undertow 有一些令人担忧的地方：
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 大同小异。
官方文档的更新比较慢，可能会慢 1~2 个小版本，导致 Spring Boot 粘合 Undertow 的时候，配置显得不会那么优雅。参考官方文档的同时，最好还是看一下源码，至少看一下配置类，才能搞懂究竟是怎么设置的。
仔细看 Undertow 的源码，会发现有很多防御性编程的设计或者功能性设计 Undertow 的作者想到了，但是就是没实现，有很多没有实现的半成品代码。这也令人担心 Underow 是否开发动力不足，哪一天会突然死掉？
使用 Undertow 要注意的问题：
需要开启 NIO DirectBuffer 的特性，理解并配置好相关的参数。
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 包含两个不同的线程池类型，分别是：