圖解 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<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：將請求消息（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

第二道穿越的是 Web 應用，它由 ListenerFilterServlet 等組件構成，主要配置文件是：web.xml

第三道穿越的是 Spring 框架，它自己又分紅三層：表現層、領域層和數據源層，這些層也是由不一樣的配置文件來配置維護的，表現層是經過 mvc-servlet.xml，領域層是經過 applicationContext.xml，數據源層是經過對象關係映射框架 ORM（HibernateiBatisMyBatis等）的配置文件 sqlmap-mapping.xml、jdbc.properties 等來配置組裝的，具體對應關係能夠參照下圖：

老兵哥我介紹這部份內容的緣由是幫助你們創建一個概念，這整套系統是由外而內一層包一層構建出來的，而每一個層內部是像搭積木同樣由不一樣類型的組件構建出來的，而層與層之間、每層內部都是經過配置文件銜接的。若是你想要更加系統深刻地掌握整個應用架構，咱們能夠把上述這幾份配置文件做爲切入口或者線索。考慮到本文的主題是剖析 HTTP 請求的處理流程機制，咱們就再也不展開探討了。

6. HTTP 請求處理常見問題說明

在平常系統開發或維護當中，大部分問題都會跟 HTTP 請求處理相關。其中一部分是咱們對 HTTP 協議自己不熟悉，HTTP 協議是目前互聯網中各個系統集成的最主要的應用層協議，該協議設計很是優良，咱們能夠抽些時間深刻研究這套協議，固然若是有時間再附帶 TCP/IP 協議，尤爲是協議中控制服務質量的各類類型參數等。除此以外，還有大部分是不熟悉 HTTP 請求處理的全流程，不知道在什麼環節設置調試斷點，以及配置文件不按要求填寫等，這樣就容易讓本身陷入迷宮，耗費大量的時間精力找不到線索頭緒。

本文主要價值是幫助你們梳理出端到端的全流程框架，也就是咱們常說的全局視角或者上帝視角。有了這個框架以後，咱們能夠根據本身的須要按圖索驥找相關節點的資料來研究學習，不至於陷入細節找不到方向。固然，考慮到咱們每一個人的工做學習狀況不一樣，平時遇到的問題也不一樣，本文內容沒法覆蓋全部人遇到的問題，歡迎你們留言提問，也歡迎關注博客或公衆號「IT老兵哥」交流互動，我會盡力盡快解答你們提出的問題，謝謝！

本系列其餘文章索引以下：

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