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

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

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

凭借整站使用H5页面制作的创新体验、定制设计、设计团队积累与透明式的服务过程,符合行业特点，专属顾问根据企业产品，消费群体属性，准确定位；设计师以目标客户为中心，以突出品牌官网特性为宗旨，定制专属网站建设设计方案。

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() 等方法中执行 proce***equest() 方法，完成请求上下文的的初始化。
• 调用 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：将请求消息（JSON\XML 等格式数据）转换成 Java 对象。
• 数据转换：对 HTTP 请求中的数据做类型转换，例如：将 String 转换成 Integer、Double 等。
• 数据格式化：对HTTP 请求中的特定数据做格式化，例如将字符串转换成格式化数字或格式化日期等。
• 数据验证：验证数据的有效性（长度、格式等），验证结果存储到 BindingResult 或 Error 当中。

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

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

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

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

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

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