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

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

创新互联建站专业提供服务器托管服务，为用户提供五星数据中心、电信、双线接入解决方案，用户可自行在线购买服务器托管服务，并享受7*24小时金牌售后服务。

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。

    encodingFilter
    org.springframework.web.filter.CharacterEncodingFilter
    
        encoding
        UTF-8
    
    
        forceEncoding
        true
    


    encodingFilter
    /*  

3.1.2 监听器 Listener

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

    org.springframework.web.util.Log4jConfigListener

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：

    mvc
    org.springframework.web.servlet.DispatcherServlet
    
        contextConfigLocation
        classpath:mvc-servlet.xml
    
    1


    mvc
    /api

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】

文章名称：图解Spring：HTTP请求的处理流程与机制【3】
当前地址：http://kswjz.com/article/pisiph.html