SpringCloud升级之路2020.0.x版-12.UnderTow 简介与内部原理

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
简介: SpringCloud升级之路2020.0.x版-12.UnderTow 简介与内部原理

image.png


在我们的项目中,我们没有采用默认的 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 容器的配置。


image.png


Undertow 目前(2.x) 还是基于 Java XNIO,Java XNIO 是一个对于 JDK NIO 类的扩展,和 netty 的基本功能是一样的,但是 netty 更像是对于 Java NIO 的封装,Java XNIO 更像是扩展封装。主要是 netty 中基本传输承载数据的并不是 Java NIO 中的 ByteBuffer,而是自己封装的 ByteBuf,而 Java XNIO 各个接口设计还是基于 ByteBuffer 为传输处理单元。设计上也很相似,都是 Reactor 模型的设计。其结构如下所示:


微信图片_20220625162337.jpg


Java XNIO 主要包括如下几个概念:

  • Java NIO ByteBufferBuffer 是一个具有状态的数组,用来承载数据,可以追踪记录已经写入或者已经读取的内容。主要属性包括: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 服务器。


image.png


我们这一节详细介绍了 Undertow 的结构,并且说明了 Undertow 的优点以及让我们比较担心的地方,并且与其他的 Web 容器做了对比。下一节我们将会分析 Undertow 的详细配置。

相关文章
|
6月前
|
缓存 Java API
【云原生】Spring Cloud Gateway的底层原理与实践方法探究
【云原生】Spring Cloud Gateway的底层原理与实践方法探究
|
18天前
|
负载均衡 算法 Java
蚂蚁面试:Nacos、Sentinel了解吗?Springcloud 核心底层原理,你知道多少?
40岁老架构师尼恩分享了关于SpringCloud核心组件的底层原理,特别是针对蚂蚁集团面试中常见的面试题进行了详细解析。内容涵盖了Nacos注册中心的AP/CP模式、Distro和Raft分布式协议、Sentinel的高可用组件、负载均衡组件的实现原理等。尼恩强调了系统化学习的重要性,推荐了《尼恩Java面试宝典PDF》等资料,帮助读者更好地准备面试,提高技术实力,最终实现“offer自由”。更多技术资料和指导,可关注公众号【技术自由圈】获取。
蚂蚁面试:Nacos、Sentinel了解吗?Springcloud 核心底层原理,你知道多少?
|
4月前
|
设计模式 监控 Java
解析Spring Cloud中的断路器模式原理
解析Spring Cloud中的断路器模式原理
|
2月前
|
XML 监控 Java
Spring Cloud全解析:熔断之Hystrix简介
Hystrix 是由 Netflix 开源的延迟和容错库,用于提高分布式系统的弹性。它通过断路器模式、资源隔离、服务降级及限流等机制防止服务雪崩。Hystrix 基于命令模式,通过 `HystrixCommand` 封装对外部依赖的调用逻辑。断路器能在依赖服务故障时快速返回备选响应,避免长时间等待。此外,Hystrix 还提供了监控功能,能够实时监控运行指标和配置变化。依赖管理方面,可通过 `@EnableHystrix` 启用 Hystrix 支持,并配置全局或局部的降级策略。结合 Feign 可实现客户端的服务降级。
152 23
|
27天前
|
负载均衡 Java API
Spring Cloud原理详解
Spring Cloud原理详解
61 0
|
29天前
|
负载均衡 Java 网络架构
Spring Cloud原理详解
介绍了Spring Cloud的原理和核心组件,包括服务注册与发现、配置管理、负载均衡、断路器、智能路由、分布式消息传递、分布式追踪和服务熔断等,旨在帮助开发人员快速构建和管理微服务架构中的分布式系统。
48 0
|
5月前
|
存储 搜索推荐 Java
微服务SpringCloud ES分布式全文搜索引擎简介 下载安装及简单操作入门
微服务SpringCloud ES分布式全文搜索引擎简介 下载安装及简单操作入门
73 2
|
6月前
|
负载均衡 算法 Java
【SpringCloud】Eureka原理分析、搭建Eureka服务、服务注册、服务发现
【SpringCloud】Eureka原理分析、搭建Eureka服务、服务注册、服务发现
70 3
|
5月前
|
缓存 Java 微服务
Spring Cloud中@RefreshScope实现动态刷新的原理
Spring Cloud中@RefreshScope实现动态刷新的原理
|
6月前
|
Java 开发者 微服务
Spring Cloud原理详解
【5月更文挑战第4天】Spring Cloud是Spring生态系统中的微服务框架,包含配置管理、服务发现、断路器、API网关等工具,简化分布式系统开发。核心组件如Eureka(服务发现)、Config Server(配置中心)、Ribbon(负载均衡)、Hystrix(断路器)、Zuul(API网关)等。本文讨论了Spring Cloud的基本概念、核心组件、常见问题及解决策略,并提供代码示例,帮助开发者更好地理解和实践微服务架构。此外,还涵盖了服务通信方式、安全性、性能优化、自动化部署、服务网格和无服务器架构的融合等话题,揭示了微服务架构的未来趋势。
98 6