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<String, Object> 類型的成員屬性 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：將請求消息（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老兵哥 」，賦能程序人生！
本系列其他文章索引如下：