圖解 Spring：HTTP 請求的處理流程與機制【4】

4. HTTP 請求在 Spring 框架中的處理流程

在穿越了 Web 容器和Web 應(yīng)用之后，HTTP 請求將被投送到 Spring 框架，我們繼續(xù)剖析后續(xù)流程。Web 應(yīng)用與 Spring MVC 的銜接是通過配置文件 mvc-servlet.xml 完成的，我們通過這份配置文件定義構(gòu)成 Spring MVC 的各種核心組件和初始化配置，其中包括：控制器 Controller、視圖解析器 ViewResolver、視圖 View 等等。不同組件分別承擔(dān)不同的功能，在介紹 Spring 框架處理 HTTP 請求流程之前，我們照例先了解一下這些核心組件。

4.1 Spring 框架核心組件簡介

我們應(yīng)用開發(fā)者在使用 Spring 時接觸最多的就是各種注解，包括：@Component、@Controller、@Service、@Repository 等，這些都是 Spring 的核心組件。除此之外，我們還會使用 @RequestMapping、@RequestParam、@PathVariable、@RequestBody 等輔助性注解：

• 模型 Model：封裝了業(yè)務(wù)數(shù)據(jù)，主要以 POJO 形式存在。
• 控制器 Controller：主要負(fù)責(zé)具體業(yè)務(wù)流程的調(diào)度控制，以及調(diào)用業(yè)務(wù)邏輯服務(wù) Service。?控制器 Controller 處理完 HTTP 請求之后返回 ModelAndView 對象給前置分發(fā)器 DispatcherServlet，ModelAndView 中包含了模型 Model 對象和視圖 View 名稱。
• 視圖 View：負(fù)責(zé)渲染呈現(xiàn)模型 Model 數(shù)據(jù)，以及提供表單供用戶錄入各種業(yè)務(wù)數(shù)據(jù)。
• 視圖解析器 ViewResolver：負(fù)責(zé)根據(jù)已知的視圖名稱獲取一個特定視圖 View 子類實例對象。
• 處理器映射 HandlerMapping：主要負(fù)責(zé)控制器 Controller 的注冊和查找，由應(yīng)用上下文 ApplicationContext 持有。具體實現(xiàn)上它擁有 HashMap<String, Object> 類型的成員屬性 handlerMap，其中 key 是 HTTP 請求的 URI 信息，value 可以是一個字符串或者處理請求的 HandlerExecutionChain。如果是 String，則視為 Spring Bean 名稱。
• 服務(wù) Service：主要負(fù)責(zé)實現(xiàn)具體的業(yè)務(wù)邏輯。

• 數(shù)據(jù)存儲對象 Repository：也稱為數(shù)據(jù)訪問對象 DAO（Data Access Object），不管采用什么開發(fā)框架，大部分應(yīng)用都需要跟數(shù)據(jù)庫交互，DAO 就是將訪問數(shù)據(jù)庫操作做了封裝，隔離了 SQL 相關(guān)復(fù)雜度。
  
  抵達 Spring MVC 的所有 HTTP 請求均由前置分發(fā)器 DispatcherServlet 統(tǒng)一分發(fā)，在將請求分發(fā)給特定的控制器 Controller 之前需要借助處理器映射 HandlerMapping 來定位，大概過程如下：

• Web 容器監(jiān)聽主機特定端口，每當(dāng)有請求抵達時，Web 容器最終將調(diào)用 Servlet 的 service 方法處理 HTTP 請求。在 Spring Web 應(yīng)用中，接收 HTTP 請求的 Servlet 就是前置分發(fā)器 DispatcherServlet。
• 在前置分發(fā)器 DispatcherServlet 的 service 方法中判斷 HTTP 請求類型，包括：GET、POST、PUT、PATCH 等等，然后再決定調(diào)用 doGet()、doPost()、doPut() 等方法。
• 在 doGet()、doPost()、doPut() 等方法中執(zhí)行 proce***equest() 方法，完成請求上下文的的初始化。
• 調(diào)用 doService() 方法，進一步執(zhí)行 doDispatch() 方法。
• 在 doDispatch() 方法中獲取 HTTP 請求的 mappedHandler 和 HandlerAdapter，然后再發(fā)起對業(yè)務(wù)控制器 Controller 的調(diào)用以及后續(xù)流程，等待處理結(jié)果再構(gòu)建響應(yīng)數(shù)據(jù)。

4.2 Spring 框架處理 HTTP 請求的流程

• 前置分發(fā)器 DispatcherServlet 接收到 HTTP 請求之后，將查找適當(dāng)?shù)目刂破?Controller 來處理請求，它通過解析 HTTP 請求的 URL 獲得 URI，再根據(jù)該 URI 從處理器映射 HandlerMapping 當(dāng)中獲得該請求對應(yīng)的處理器 Handler 和處理器攔截器 HandlerInterceptor，最后以 HandlerExecutionChain 形式返回。
• 前置分發(fā)器 DispatcherServlet 根據(jù)獲得的處理器 Handler 選擇合適的適配器 HandlerAdapter。如果成功獲得適配器 HandlerAdapter，在調(diào)用處理器 Handler 之前其攔截器的方法 preHandler() 優(yōu)先執(zhí)行。
• 方法 preHandler() 提取 HTTP 請求中的數(shù)據(jù)填充到處理器 Handler 的入?yún)?dāng)中，然后開始調(diào)用處理器 Handler（即控制器 Controller）相關(guān)方法。
• 控制器 Controller 執(zhí)行完成之后，向前置分發(fā)器 DispatcherServlet?返回一個模型與視圖名對象 ModelAndView 。
• 前置分發(fā)器 DispatchServlet 根據(jù)模型與視圖名對象 ModelAndView 選擇適合的視圖解析器 ViewResolver，前提該視圖解析器必須已經(jīng)注冊至 Spring IOC 容器當(dāng)中。
• 視圖解析器 ViewResolver 將根據(jù) ModelAndView 里面指定的視圖名稱獲得特定的視圖 View。
• 前置分發(fā)器 DispatchServlet 將模型數(shù)據(jù)填充進視圖當(dāng)中，然后將渲染結(jié)果返回給客戶端。

在填充處理器 Handler 入?yún)⒌倪^程中，Spring 還會根據(jù)配置做些預(yù)處理工作：

• HttpMessageConveter：將請求消息（JSON\XML 等格式數(shù)據(jù)）轉(zhuǎn)換成 Java 對象。
• 數(shù)據(jù)轉(zhuǎn)換：對 HTTP 請求中的數(shù)據(jù)做類型轉(zhuǎn)換，例如：將 String 轉(zhuǎn)換成 Integer、Double 等。
• 數(shù)據(jù)格式化：對HTTP 請求中的特定數(shù)據(jù)做格式化，例如將字符串轉(zhuǎn)換成格式化數(shù)字或格式化日期等。
• 數(shù)據(jù)驗證：驗證數(shù)據(jù)的有效性（長度、格式等），驗證結(jié)果存儲到 BindingResult 或 Error 當(dāng)中。

4.3 不同應(yīng)用架構(gòu)下 HTTP 請求處理流程的區(qū)別

Spring Web 應(yīng)用架構(gòu)經(jīng)歷了多個階段的發(fā)展，最初主流的前端視圖技術(shù)就是 JSP，在此基礎(chǔ)上又演化出了三劍客框架 SSH（Struts\Spring\Hibernate），但這時候前后端其實還是耦合在一起的，不管是 JSP 還是 SSH，在前面 Spring 框架處理 HTTP 請求的流程中，必須要依賴視圖解析器 ViewResolver 和視圖 View。

從 Spring 誕生到現(xiàn)在已經(jīng)15年多了，它關(guān)聯(lián)的后端技術(shù)演化其實沒有前端那么快，主要原因就是前端需求越來越豐富多樣，前端視圖層的開發(fā)工作量和復(fù)雜度不斷增加。在這樣的背景之下，越來越多的前端工程化解決方案涌現(xiàn)，其中最有成效的就是前后端分離，從 AngularJS\Backbone.js 到現(xiàn)在 React\Vue 等。在這種前后端分離架構(gòu)下，前端就全部由靜態(tài)資源（HTML\Javascript\CSS）等構(gòu)成，可以獨立部署在 Web 服務(wù)器當(dāng)中，這樣 Spring 框架就不需要再處理視圖相關(guān)的內(nèi)容，控制器 Controller 不再返回 ModelAndView，只需要反饋模型數(shù)據(jù)了。

本文主要價值是幫助大家梳理出端到端的全流程框架，也就是我們常說的全局視角或者上帝視角。有了這個框架之后，我們可以根據(jù)自己的需要按圖索驥找相關(guān)節(jié)點的資料來研究學(xué)習(xí)，不至于陷入細(xì)節(jié)找不到方向。當(dāng)然，考慮到我們每個人的工作學(xué)習(xí)情況不同，平時遇到的問題也不同，本文內(nèi)容無法覆蓋所有人遇到的問題，歡迎大家留言提問，也歡迎關(guān)注我的博客或公號“IT老兵哥”交流互動，我會盡力盡快解答大家提出的問題，謝謝！

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

• 圖解 Spring：HTTP 請求的處理流程與機制【1】
• 圖解 Spring：HTTP 請求的處理流程與機制【2】
• 圖解 Spring：HTTP 請求的處理流程與機制【3】
• 圖解 Spring：HTTP 請求的處理流程與機制【5】