图解 Spring：HTTP 请求的处理流程与机制【3】

3. HTTP 请求在 Web 应用中的处理流程

在穿越了 Web 容器以后，HTTP 请求将被投送到 Web 应用，咱们继续以 Tomcat 为例剖析后续流程。Web 容器与 Web 应用的衔接是经过配置文件 web.xml 完成的。web.xml 是遵循 Java Servlet 标准规范的配置文件，咱们经过这份配置文件定义构成 Web 应用的各类核心组件和初始化配置，其中包括：过滤器 Filter、监听器 Listener、伺服器 Servlet 等等。不一样组件分别承担不一样的功能，在介绍 Web 应用处理 HTTP 请求流程以前，咱们照例先来了解一下这些核心组件。

3.1 Web 应用核心组件简介

3.1.1 过滤器 Filter

过滤器 Filter 负责对 HTTP 请求作预处理，接着将请求交给 Servlet 进行处理并生成响应，最后 Filter 再对响应进行后处理。从 HTTP 请求的处理过程来看，Filter 主要参与如下几个环节：

• 在 HttpServletRequest 到达 Servlet 以前，拦截客户的 HttpServletRequest。
• 根据须要检查 HttpServletRequest，也能够修改 HttpServletRequest 报文头和数据。
• 在 Servlet 生成的 HttpServletResponse 抵达客户端以前，拦截 HttpServletResponse。
• 根据须要检查 HttpServletResponse，也能够修改 HttpServletResponse 报文头和数据。

过滤器映射 filter-mapping，用于声明 Web 应用将会用到的过滤器，过滤器可被映射到一个 Servlet 或 URL 模式。若是将过滤器映射到一个 Servlet 上，那它就做用于特定 Servlet。若是将过滤器映射到一个 URL 模式，那么它将做用于任何资源，只要该资源的 URL 与 URL 模式匹配。若是对某个资源的请求匹配到多个 Filter，那么在处理 HTTP 请求过程当中，Tomcat 将按照过滤器映射 filter-mapping 在配置文件 web.xml 中的前后顺序来执行，在前面的先执行，在后面的后执行，多个过滤器 Filter 能够组成调用链。

URL 模式匹配有三种类型规则：

• 精确匹配：如“/foo.htm”，那只会匹配“foo.htm”这个 URL。
• 路径匹配：如“/foo/*”，那只会匹配以 foo 为前缀的 URL。
• 后缀匹配：如“*.htm”，那只会匹配全部以“.htm”为后缀的 URL。

 1 <filter>
 2     <filter-name>encodingFilter</filter-name>
 3     <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
 4     <init-param>
 5         <param-name>encoding</param-name>
 6         <param-value>UTF-8</param-value>
 7     </init-param>
 8     <init-param>
 9         <param-name>forceEncoding</param-name>
10         <param-value>true</param-value>
11     </init-param>
12 </filter>
13 <filter-mapping>
14     <filter-name>encodingFilter</filter-name>
15     <url-pattern>/*</url-pattern>  
16 </filter-mapping>

3.1.2 监听器 Listener

监听器 Listener 主要用于监听 Application、Session、Request 等对象的变化，每当这些对象发生变化就会回调用对应的监听方法。例如：在 Servlet API 中有一个 ServletContextListener 接口，它可以监听 ServletContext 对象的生命周期，实际上就是监听 Web 应用的生命周期。当 Servlet 容器启动或终止Web 应用时，会触发 ServletContextEvent 事件，该事件由 ServletContextListener 来处理。

1 <listener>
2     <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
3 </listener>

3.1.3 伺服器 Servlet

伺服器 Servlet 负责处理客户端访问动态资源的 HTTP 请求，接口 javax.servlet.Servlet 定义了全部 Servlet 必需要实现的方法。

方法名称	功能说明
destroy()	由 Servlet 容器调用，用于关闭中止 Servlet 提供的服务
getServletConfig()	获取 Servlet 初始化和启动时参数的配置信息对象 ServletConfig
getServletInfo()	获取 Servlet 的说明信息，包括：做者、版本和版权等等
init()	由 Servlet 容器调用，籍由配置 ServletConfig 完成 Servlet 初始化，启动对外服务
service()	由 Servlet 容器调用，让 Servlet 处理某个 HTTP 请求

从 HTTP 请求的处理过程来看，伺服器 Servlet 主要参与如下几个环节：

• 接收请求：客户端请求会被封装成 HttpServletRequest 对象，包含报文头参数和报文体等信息。
• 处理请求：一般调用 Servlet 的方法 service、doPost 或 doGet 等方法处理请求，并进一步调用业务层相应逻辑对其进行处理等。
• 反馈响应：处理完请求后，能够转发（forward）、重定向（redirect）到某个视图页面或者直接返回结果数据，转发是 HttpServletRequest 的方法，重定向是 HttpServletResponse 的方法。

在老兵哥的读书年代，Web 应用相对简单，主要是各类信息管理系统。当时 Spring 还没有诞生，主流技术栈是 JSP/Servlet，老兵哥我开发 Web 应用时主要编写继承自 HttpServlet 子类，将各类业务逻辑功能分别交由不一样的 HttpServlet 子类实现。HttpServlet 继承自 GenericServlet，后者实现了接口 Servlet。

随着数字化和互联网化的不断推动，业务系统变得愈来愈复杂，HttpServlet 子类越写越多，web.xml 配置文件愈来愈复杂，这致使系统的扩展维护愈来愈困难，手工做坊式的开发方法已经跟不上业务发展的步伐了。

时势造英雄，Spring 就是在这种背景下呼之而出的，它创造性地发明了控制反转 IOC 和面向切面编程 AOP，极大地下降复杂度。以下面配置示例所示，整个 Web 应用只须要配置一个 Servlet 就能够了，它就是 Spring 的前置分发器 DispatcherServlet：

 1 <servlet>
 2     <servlet-name>mvc</servlet-name>
 3     <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
 4     <init-param>
 5         <param-name>contextConfigLocation</param-name>
 6         <param-value>classpath:mvc-servlet.xml</param-value>
 7     </init-param>
 8     <load-on-startup>1</load-on-startup>
 9 </servlet>
10 <servlet-mapping>
11     <servlet-name>mvc</servlet-name>
12     <url-pattern>/api</url-pattern>
13 </servlet-mapping>

3.2 Web 应用处理 HTTP 请求的流程

以下图所示，Web 应用处理 HTTP 请求的流程主要是穿越监听器 Listener 和过滤器链 Filters，最终抵达伺服器 Servlet 的过程：

原先咱们将 Web 应用的复杂度直接暴露给了 Tomcat，如今 Spring 经过控制反转 IOC 和面向切面编程 AOP 等新技术接管了 Web 应用的复杂度。如前面 Servlet 的配置示例，整个 Web 应用只须要配置 Spring 提供的前置分发器 DispatcherServlet，开发者无需再编写和配置 HttpServlet 子类，全部业务逻辑功能将按照 Spring 的标准规范来开发，从原先的编写 Listener\Filter\Servlet 改成编写 Spring Component，包括：Controller、Service、Repository 等。

Tomcat 在接收到某个 Web 应用的 Http 请求以后，它会将全部请求都转交给前置分发器 DispatcherServlet，再由 DispatcherServlet 将请求派发给具体业务逻辑进行处理。DispatcherServlet 就是从 HttpServlet 派生的子类，它的类图关系以下所示：

3.3 Web 应用架构演进过程解析

Web 应用架构的演进过程就像创业孵化过程，最初创业团队打造的产品很简单，你们采用手工做坊模式来快速打造最小化可行产品，这时候团队的组织架构也跟产品同样扁平简单。但随着产品被愈来愈多的用户使用，功能变得愈来愈复杂，接着必须引进新架构才能有效管理复杂度，同时团队规模的扩展也须要与业务发展匹配的组织架构，这样才能保证产品的不断发展。

Web 应用架构的演化过程跟 Tomcat 体系结构的造成过程相似，老兵哥会常常借助“俄罗斯套娃”这个模型来阐述架构，Web 容器和 Web 应用这两层的架构原则是相似的，就像大娃娃套着小娃娃同样。

Spring 的 IOC 容器跟 Tomcat 的 Servlet 容器相似，也是经过配置文件等方式来定义组件，而后在启动过程当中将这些定义好的组件初始化并添加到容器当中，后续使用时从容器查找获取。早期 Web 应用主要由大量开发者编写的 Filter\Listener\Servlet 等组件构成，这些核心组件的配置所有都经过 web.xml 配置文件来维护，那么 Web 应用和 Web 容器之间其实不是松耦合的，而引进 Spring 以后就变成只须要配置 DispatcherServlet 等少许组件了，达到了分层架构的要求，更加有利于开发复杂的 Web 应用。若是采用架构的专业术语来描述，这就是经典的分层架构模式，层与层之间松耦合，仅经过少许的接口衔接，每层内部高内聚。

 

本文主要价值是帮助你们梳理出端到端的全流程框架，也就是咱们常说的全局视角或者上帝视角。有了这个框架以后，咱们能够根据本身的须要按图索骥找相关节点的资料来研究学习，不至于陷入细节找不到方向。固然，考虑到咱们每一个人的工做学习状况不一样，平时遇到的问题也不一样，本文内容没法覆盖全部人遇到的问题，欢迎你们留言提问，也欢迎关注个人微信公众号“IT老兵哥”交流互动，我会尽力尽快解答你们提出的问题，谢谢！

本系列其余文章索引以下：

• 图解 Spring：HTTP 请求的处理流程与机制【1】
• 图解 Spring：HTTP 请求的处理流程与机制【2】
• 图解 Spring：HTTP 请求的处理流程与机制【4】
• 图解 Spring：HTTP 请求的处理流程与机制【5】