从 Servlet 到云原生：一文讲透 Java Web 容器的核心技术体系

当你在 Spring Boot 中通过 @RestController 轻松编写 REST 接口时，可曾思考过：

• 为什么本地启动时会显示"Tomcat started on port 8080"？

• 这个隐藏在框架背后的 Tomcat 究竟承担了什么职责？

• 为什么生产环境有时需要将内嵌 Tomcat 替换为 Undertow？

本文将穿透框架迷雾，直击 Web 容器的技术本质。

一、技术演进史：从静态页面到动态容器

先让我们先来简单回顾一下 Web 技术的发展历史，可以帮助你理解 Web 容器的由来。

1.1 静态时代：Web Server 独揽大局

早期的 Web 应用主要用于浏览新闻等静态页面，HTTP 服务器（比如 Apache、Nginx）向浏览器返回静态 HTML，浏览器负责解析 HTML，将结果呈现给用户。静态页面的出现已经是时代的巨大进步了，但是他也有其局限性。

• 核心痛点：每新增动态内容需修改 HTML 文件

• 技术局限：CGI 存在进程级资源消耗问题（每个请求创建新进程）

1.2 动态革命：Servlet 容器崛起

随着互联网的发展，我们已经不满足于仅仅浏览静态页面，还希望通过一些交互操作，来获取动态结果，因此也就需要一些扩展机制能够让 HTTP 服务器调用服务端程序。

在这场动态探索中，Sun 公司推出了 Servlet 技术。你可以把 Servlet 简单理解为运行在服务端的 Java 小程序，但是 Servlet 没有 main 方法，不能独立运行，因此必须把它部署到 Servlet 容器中，由 Servlet 容器来实例化并调用 Servlet。

// 第一个Servlet实现示例public class HelloServlet extends HttpServlet {    @Override    protected void doGet(HttpServletRequest req, HttpServletResponse resp) {        resp.getWriter().write("Hello Web Container!");    }}

• 线程级复用：相比 CGI 节省 90%以上资源

• 生命周期管理：init()→service()→destroy()的标准化控制

1.3 容器融合架构

有了 Servlet 技术以及 Servlet 容器后，我们便能让静态的页面变成动态的网站，在这个结合过程中，“HTTP 服务器 + Servlet 容器”组成的应用，就是我们常用的部署应用的容器了，也就是我们所说的 Web 容器。

• 双引擎协作：Connector 处理网络 I/O，Engine 执行业务逻辑

二、Web 容器选型决策模型

2.1 技术选型决策树

2.2 主流容器能力矩阵

三、Web 容器技术深度解析

3.1 Web 容器涉及知识

别小看这个 Web 容器，他涉及的知识还真不少！

3.2 HTTP 服务器核心机制

• I/O 模型演进路线

• 关键参数调优

# Tomcat连接池配置示例
server.tomcat.max-threads=200server.tomcat.accept-count=100server.tomcat.connection-timeout=5000

3.3 Servlet 容器核心机制

• 请求处理管线

// FilterChain伪代码实现public void doFilter(Request req, Response res) {    if(index < filters.length) {        filters[index++].doFilter(req, res, this);    } else {        servlet.service(req, res);    }}

• 设计模式应用：责任链模式（FilterChain）、门面模式（HttpServletRequestWrapper）

四、云原生时代的容器变革

4.1 看似退化的进化

现代的 Java Web 开发中，我们已经极少直接使用 Web 容器了，更别说手写 Servlet。

Spring MVC 屏蔽了 Servlet API；Spring Boot 自动配置与内嵌 Tomcat 容器的框架革新，也是惊艳了一代人。

内嵌容器的创新也为部署带来了无限可能，云原生与容器(此容器指的是 Kubernetes 等管理的容器而非 Web 容器)编排也是受益者。

Spring Boot 内嵌容器看似回归"All in One"模式，实则通过：

• 依赖隔离（FatJar）

• 环境适配（自动配置）

• 资源约束（CGroup 感知）实现了更高层次的抽象封装。

4.2 现代架构演进

4.3 三大技术冲击

1. 轻量化革命：Quarkus 等 Native 编译技术使内存降低至 30MB 以下

2. Serverless 适配：冷启动时间优化至 300ms 级（参考 AWS Lambda Java 运行时）

3. Service Mesh 冲击：Istio 接管流量治理后，容器回归纯业务处理角色

五、总结：技术本质的三层认知

1. 规范层：Servlet/JSP 标准的实现质量决定容器基础能力

2. 运行时层：线程模型与 I/O 策略直接影响系统性能上限

3. 架构层：在云原生体系中的定位从"全能选手"转变为"专项运动员"

思考题：当 Service Mesh 接管了流量管理、Kubernetes 负责资源调度，Web 容器最终会演化为什么形态？