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

4. HTTP 请求在 Spring 框架中的处理流程

在穿越了 Web 容器和Web 应用之后，HTTP 请求将被投送到 Spring 框架，我们继续剖析后续流程。Web 应用与 Spring MVC 的衔接是通过配置文件 mvc-servlet.xml 完成的，我们通过这份配置文件定义构成 Spring MVC 的各种核心组件和初始化配置，其中包括：控制器 Controller、视图解析器 ViewResolver、视图 View 等等。不同组件分别承担不同的功能，在介绍 Spring 框架处理 HTTP 请求流程之前，我们照例先了解一下这些核心组件。

4.1 Spring 框架核心组件简介

我们应用开发者在使用 Spring 时接触最多的就是各种注解，包括：@Component、@Controller、@Service、@Repository 等，这些都是 Spring 的核心组件。除此之外，我们还会使用 @RequestMapping、@RequestParam、@PathVariable、@RequestBody 等辅助性注解：

模型 Model：封装了业务数据，主要以 POJO 形式存在。
控制器 Controller：主要负责具体业务流程的调度控制，以及调用业务逻辑服务 Service。控制器 Controller 处理完 HTTP 请求之后返回 ModelAndView 对象给前置分发器 DispatcherServlet，ModelAndView 中包含了模型 Model 对象和视图 View 名称。
视图 View：负责渲染呈现模型 Model 数据，以及提供表单供用户录入各种业务数据。
视图解析器 ViewResolver：负责根据已知的视图名称获取一个特定视图 View 子类实例对象。
处理器映射 HandlerMapping：主要负责控制器 Controller 的注册和查找，由应用上下文 ApplicationContext 持有。具体实现上它拥有 HashMap 类型的成员属性 handlerMap，其中 key 是 HTTP 请求的 URI 信息，value 可以是一个字符串或者处理请求的 HandlerExecutionChain。如果是 String，则视为 Spring Bean 名称。
服务 Service：主要负责实现具体的业务逻辑。
数据存储对象 Repository：也称为数据访问对象 DAO（Data Access Object），不管采用什么开发框架，大部分应用都需要跟数据库交互，DAO 就是将访问数据库操作做了封装，隔离了 SQL 相关复杂度。

抵达 Spring MVC 的所有 HTTP 请求均由前置分发器 DispatcherServlet 统一分发，在将请求分发给特定的控制器 Controller 之前需要借助处理器映射 HandlerMapping 来定位，大概过程如下：

Web 容器监听主机特定端口，每当有请求抵达时，Web 容器最终将调用 Servlet 的 service 方法处理 HTTP 请求。在 Spring Web 应用中，接收 HTTP 请求的 Servlet 就是前置分发器 DispatcherServlet。
在前置分发器 DispatcherServlet 的 service 方法中判断 HTTP 请求类型，包括：GET、POST、PUT、PATCH 等等，然后再决定调用 doGet()、doPost()、doPut() 等方法。
在 doGet()、doPost()、doPut() 等方法中执行 processRequest() 方法，完成请求上下文的的初始化。
调用 doService() 方法，进一步执行 doDispatch() 方法。
在 doDispatch() 方法中获取 HTTP 请求的 mappedHandler 和 HandlerAdapter，然后再发起对业务控制器 Controller 的调用以及后续流程，等待处理结果再构建响应数据。

4.2 Spring 框架处理 HTTP 请求的流程

前置分发器 DispatcherServlet 接收到 HTTP 请求之后，将查找适当的控制器 Controller 来处理请求，它通过解析 HTTP 请求的 URL 获得 URI，再根据该 URI 从处理器映射 HandlerMapping 当中获得该请求对应的处理器 Handler 和处理器拦截器 HandlerInterceptor，最后以 HandlerExecutionChain 形式返回。
前置分发器 DispatcherServlet 根据获得的处理器 Handler 选择合适的适配器 HandlerAdapter。如果成功获得适配器 HandlerAdapter，在调用处理器 Handler 之前其拦截器的方法 preHandler() 优先执行。
方法 preHandler() 提取 HTTP 请求中的数据填充到处理器 Handler 的入参当中，然后开始调用处理器 Handler（即控制器 Controller）相关方法。
控制器 Controller 执行完成之后，向前置分发器 DispatcherServlet 返回一个模型与视图名对象 ModelAndView 。
前置分发器 DispatchServlet 根据模型与视图名对象 ModelAndView 选择适合的视图解析器 ViewResolver，前提该视图解析器必须已经注册至 Spring IOC 容器当中。
视图解析器 ViewResolver 将根据 ModelAndView 里面指定的视图名称获得特定的视图 View。
前置分发器 DispatchServlet 将模型数据填充进视图当中，然后将渲染结果返回给客户端。

在填充处理器 Handler 入参的过程中，Spring 还会根据配置做些预处理工作：

HttpMessageConveter：将请求消息（JSONXML 等格式数据）转换成 Java 对象。
数据转换：对 HTTP 请求中的数据做类型转换，例如：将 String 转换成 Integer、Double 等。
数据格式化：对HTTP 请求中的特定数据做格式化，例如将字符串转换成格式化数字或格式化日期等。
数据验证：验证数据的有效性（长度、格式等），验证结果存储到 BindingResult 或 Error 当中。

4.3 不同应用架构下 HTTP 请求处理流程的区别

Spring Web 应用架构经历了多个阶段的发展，最初主流的前端视图技术就是 JSP，在此基础上又演化出了三剑客框架 SSH（StrutsSpringHibernate），但这时候前后端其实还是耦合在一起的，不管是 JSP 还是 SSH，在前面 Spring 框架处理 HTTP 请求的流程中，必须要依赖视图解析器 ViewResolver 和视图 View。

从 Spring 诞生到现在已经15年多了，它关联的后端技术演化其实没有前端那么快，主要原因就是前端需求越来越丰富多样，前端视图层的开发工作量和复杂度不断增加。在这样的背景之下，越来越多的前端工程化解决方案涌现，其中最有成效的就是前后端分离，从 AngularJSBackbone.js 到现在 ReactVue 等。在这种前后端分离架构下，前端就全部由静态资源（HTMLJavascriptCSS）等构成，可以独立部署在 Web 服务器当中，这样 Spring 框架就不需要再处理视图相关的内容，控制器 Controller 不再返回 ModelAndView，只需要反馈模型数据了。

5. HTTP 请求处理相关配置文件说明

HTTP 请求穿越的整个空间是分层的，包括：Web 容器、Web 应用、Spring 框架等，它们每层都是通过配置文件配置初始化的，这是一种松耦合的架构设计。现在我们来梳理一下这些配置文件，HTTP 请求最先穿越的就是 Web 容器，它的代表产品 Tomcat 的配置文件是：server.xml

老兵哥我介绍这部分内容的原因是帮助大家建立一个概念，这整套系统是由外而内一层包一层构建出来的，而每个层内部是像搭积木一样由不同类型的组件构建出来的，而层与层之间、每层内部都是通过配置文件衔接的。如果你想要更加系统深入地掌握整个应用架构，我们可以把上述这几份配置文件作为切入口或者线索。考虑到本文的主题是剖析 HTTP 请求的处理流程机制，我们就不再展开探讨了。

6. HTTP 请求处理常见问题说明

在日常系统开发或维护当中，大部分问题都会跟 HTTP 请求处理相关。其中一部分是我们对 HTTP 协议本身不熟悉，HTTP 协议是目前互联网中各个系统集成的最主要的应用层协议，该协议设计非常优良，我们可以抽些时间深入研究这套协议，当然如果有时间再附带 TCP/IP 协议，尤其是协议中控制服务质量的各种类型参数等。除此之外，还有大部分是不熟悉 HTTP 请求处理的全流程，不知道在什么环节设置调试断点，以及配置文件不按要求填写等，这样就容易让自己陷入迷宫，耗费大量的时间精力找不到线索头绪。

本文主要价值是帮助大家梳理出端到端的全流程框架，也就是我们常说的全局视角或者上帝视角。有了这个框架之后，我们可以根据自己的需要按图索骥找相关节点的资料来研究学习，不至于陷入细节找不到方向。当然，考虑到我们每个人的工作学习情况不同，平时遇到的问题也不同，本文内容无法覆盖所有人遇到的问题，欢迎大家留言提问，也欢迎关注博客或公众号“IT老兵哥”交流互动，我会尽力尽快解答大家提出的问题，谢谢！

本系列其他文章索引如下：