大家好，我是小米，一个在代码里泡了九年的程序员。前几天去面试一家互联网公司，面试官笑眯眯地问我：“你了解 Tomcat 的 Container 架构吗？”
我心想，这问题挺常见的，属于那种“问不深就考概念、问深了就劝退”的经典类型。于是我开始讲——没想到，这一讲，就聊了快半个小时。
今天就把我当时的回答完整复盘给你听，保证听完后，你不再怕面试官问这个问题。
1.故事开头：Tomcat 是一座“服务城市”
我特别喜欢把 Tomcat 比作一座城市。
在这座“城市”里，有各种基础设施：
- Connector（连接器）：它就像城市的“交通入口”，负责接待外来的请求（HTTP 或 AJP）。
- Container（容器）：它是城市的“核心区域”，负责处理这些请求、执行 Servlet、返回结果。
可以这么说，Connector 接收请求，Container 处理请求。
而 Container 的内部，其实是一个层层嵌套、各司其职的“小宇宙”。
如果把它比作一座行政体系，那它大概长这样：
Engine（发动机） → Host（主机） → Context（上下文） → Wrapper（包装器）
听起来有点抽象？别急，我们慢慢拆。
2.Engine：一切请求的总管
Engine 是整个 Container 体系的顶层容器，就像一座城市的“市政府”。
当 Connector 把请求交给 Engine 时，Engine 要决定：
- 这个请求该交给哪台主机（Host）？
- 用哪个 Web 应用（Context）去处理？
- 最后哪个具体的 Servlet（Wrapper）来执行？
Tomcat 默认只有一个 Engine，名字叫 Catalina（这名字是不是很熟？Tomcat 的主类就叫这个）。
Engine 内部会注册多个 Host，比如：
- localhost
- myapp.company.com
- test.company.com
Engine 根据请求头里的 Host 值去匹配对应的 Host。
换句话说，Engine 是整个容器链的入口，负责路由请求到正确的主机。
3.Host：承载多个 Web 应用的主机
每个 Host 代表一台虚拟主机，也就是一个域名或主机名。
比如我们访问：
http://localhost:8080/demo
这里的 localhost 对应的就是一个 Host。
Host 的职责是：
- 管理多个 Web 应用（Context）
- 为每个应用分配独立的 ClassLoader（类加载空间）
- 隔离不同应用间的资源
每个 Host 下可以部署多个 Context，例如：
/demo /shop /blog
Host 的核心思想是“多租户”——不同项目可以共存而互不干扰。
4.Context：Web 应用的灵魂
如果说 Host 是一台服务器，那 Context 就是一款部署在服务器上的 Web 应用。
Context 是最重要的容器之一，它直接对应一个 Web 项目（比如 webapps/demo 目录）。
Context 的职责包括：
- 管理 Servlet、Filter、Listener 等组件；
- 负责加载 web.xml、初始化应用；
- 负责分发请求到具体的 Servlet。
举个例子，当我们访问 /demo/hello 时：
- Engine 根据主机名找到 Host；
- Host 根据 /demo 找到对应的 Context；
- Context 再去定位具体的 Servlet（Wrapper）。
可以看到，Context 是实际业务处理的舞台，所有业务逻辑、配置、过滤器、拦截器都在这一级展开。
5.Wrapper：Servlet 的“外衣”
Wrapper 是 Container 体系中最底层、最贴近业务的一层。
它包裹着具体的 Servlet，比如 HelloServlet 或 UserLoginServlet。
Wrapper 负责：
- 管理 Servlet 的生命周期（加载、初始化、销毁）；
- 处理线程安全；
- 调用真正的 service() 方法。
当请求一路从 Engine → Host → Context → Wrapper 传递下来时，最终在 Wrapper 层执行具体的 Servlet。
所以，Wrapper 是执行请求的最后一站。
6.四层容器的层级关系总结
我们用一个简单的结构来表示它：
图片
这四层是典型的“组合模式”（Composite Pattern），每一层都是 Container 的子类，都实现了 org.apache.catalina.Container 接口。
Tomcat 用这个设计实现了一个可扩展、可递归的容器层级体系——上层管理下层，下层专注具体逻辑。
7.Container 的核心接口设计
Tomcat 的 Container 架构其实高度面向接口设计，主要接口包括：
- Container：所有容器的顶层接口；
- Engine、Host、Context、Wrapper：四个具体子接口；
- Pipeline / Valve：责任链机制，用于在请求处理前后执行拦截逻辑；
- Lifecycle：生命周期管理接口。
当我们理解这些接口后，就能明白 Tomcat 的设计精髓：
它把请求的处理过程抽象成一个管道（Pipeline），让每个 Valve 都能插入处理逻辑。
这就像在高速公路上设置多个收费站、检查站，每个环节都能“拦一拦、看一看、做点事”。
8.Pipeline 与 Valve：Tomcat 的责任链魔法
在每个容器中，都有一个 Pipeline（管道），里面装着一连串的 Valve（阀门）。
请求进入时，会依次流过这些 Valve，每个 Valve 可以做：
- 日志记录
- 权限验证
- 过滤器处理
- 性能统计
- 最终调用下一级容器
比如在 Context 层的 Pipeline 中，常见的一个 Valve 是 StandardContextValve，它的作用是：
- 找到请求对应的 Wrapper；
- 调用 Wrapper 里的 Servlet。
而在 Engine 层、Host 层，也都有各自的 Valve，比如：
- ErrorReportValve：统一异常处理；
- AccessLogValve：记录访问日志。
这个机制让 Tomcat 非常灵活，你可以轻松在任意层插入自定义逻辑。
9.请求在 Container 中的流转之旅
让我们以一次完整的请求为例，看看它的旅程：
1）Connector 接收请求
- 监听 8080 端口；
- 解析 HTTP 协议；
- 生成 Request 和 Response 对象；
- 把它交给 Engine。
2）Engine 匹配 Host
- 根据请求头里的 Host 字段找到对应的虚拟主机。
3）Host 匹配 Context
- 根据 URI 前缀（如 /demo）找到对应的应用。
4）Context 匹配 Wrapper
- 根据 Servlet 映射规则找到目标 Servlet。
5）Wrapper 调用 Servlet
- 通过 Pipeline 调用 Servlet 的 service() 方法；
- 最终执行我们的业务逻辑；
- 返回响应。
整个流程，就像一场“层层转发的旅程”：
Connector → Engine → Host → Context → Wrapper → Servlet
图片
10.面试官可能追问的进阶问题
别以为讲完层级关系就结束了，面试官很可能接着问：
“那 Container 和 Connector 之间怎么通信？”
答：通过 Mapper 映射组件。
Mapper 根据请求 URL、主机名、路径来定位目标容器（Host → Context → Wrapper）。
Connector 解析完请求后，会调用 Engine.getPipeline().getFirst().invoke(request, response)，启动整个责任链。
“每层容器如何实现解耦？”
答：Tomcat 使用接口 + 事件驱动机制，每个容器都实现 Lifecycle 接口，可以独立启动、销毁、重新加载。这让热部署、应用隔离变得可行。
11.写在最后：Tomcat 的“优雅之处”
当年第一次看 Tomcat 源码，我差点被绕晕。
但当我真正理解 Container 的设计后，才发现它的优雅之处在于：
- 用组合模式实现层级容器；
- 用责任链实现灵活拦截；
- 用生命周期接口实现可插拔模块；
- 用映射机制实现精准路由。
这不是“写一堆类”的架构，而是一个能应对上亿次请求的分层系统。
所以，当面试官问你“Tomcat 的 Container 架构”时，千万别只背诵那四层。要讲出它们为什么这样设计、怎么协作、能带来什么好处。
12.彩蛋：一句话总结送给你
Connector 负责“接”，Container 负责“处”。
Container 体系分四层：Engine、Host、Context、Wrapper。
每层用 Pipeline + Valve 实现责任链，
这就是 Tomcat 的“容器心脏”。
