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

3. HTTP 請求在 Web 應用中的處理流程

在穿越了 Web 容器之后，HTTP 請求將被投送到 Web 應用，我們繼續以 Tomcat 為例剖析后續流程。Web 容器與 Web 應用的銜接是通過配置文件 web.xml 完成的。web.xml 是遵循 Java Servlet 標準規范的配置文件，我們通過這份配置文件定義構成 Web 應用的各種核心組件和初始化配置，其中包括：過濾器 Filter、監聽器 Listener、伺服器 Servlet 等等。不同組件分別承擔不同的功能，在介紹 Web 應用處理 HTTP 請求流程之前，我們照例先來了解一下這些核心組件。

3.1 Web 應用核心組件簡介

3.1.1 過濾器 Filter

過濾器 Filter 負責對 HTTP 請求做預處理，接著將請求交給 Servlet 進行處理并生成響應，最后 Filter 再對響應進行后處理。從 HTTP 請求的處理過程來看，Filter 主要參與以下幾個環節：

• 在 HttpServletRequest 到達 Servlet 之前，攔截客戶的 HttpServletRequest。
• 根據需要檢查 HttpServletRequest，也可以修改 HttpServletRequest 報文頭和數據。
• 在 Servlet 生成的 HttpServletResponse 抵達客戶端之前，攔截 HttpServletResponse。
• 根據需要檢查 HttpServletResponse，也可以修改 HttpServletResponse 報文頭和數據。

過濾器映射 filter-mapping，用于聲明 Web 應用將會用到的過濾器，過濾器可被映射到一個 Servlet 或 URL 模式。如果將過濾器映射到一個 Servlet 上，那它就作用于特定 Servlet。如果將過濾器映射到一個 URL 模式，那么它將作用于任何資源，只要該資源的 URL 與 URL 模式匹配。如果對某個資源的請求匹配到多個 Filter，那么在處理 HTTP 請求過程中，Tomcat 將按照過濾器映射 filter-mapping 在配置文件 web.xml 中的先后順序來執行，在前面的先執行，在后面的后執行，多個過濾器 Filter 可以組成調用鏈。URL 模式匹配有三種類型規則：

• 精確匹配：如“/foo.htm”，那只會匹配“foo.htm”這個 URL。
• 路徑匹配：如“/foo/*”，那只會匹配以 foo 為前綴的 URL。
• 后綴匹配：如“*.htm”，那只會匹配所有以“.htm”為后綴的 URL。

<filter>
    <filter-name>encodingFilter</filter-name>
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>UTF-8</param-value>
    </init-param>
    <init-param>
        <param-name>forceEncoding</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>encodingFilter</filter-name>
    <url-pattern>/*</url-pattern>??
</filter-mapping>

3.1.2 監聽器 Listener

監聽器 Listener 主要用于監聽 Application、Session、Request 等對象的變化，每當這些對象發生變化就會回調用對應的監聽方法。例如：在?Servlet API?中有一個?ServletContextListener?接口，它能夠監聽?ServletContext?對象的生命周期，實際上就是監聽?Web?應用的生命周期。當 Servlet?容器啟動或終止Web?應用時，會觸發 ServletContextEvent?事件，該事件由 ServletContextListener?來處理。

<listener>
    <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>

3.1.3 伺服器 Servlet

伺服器 Servlet 負責處理客戶端訪問動態資源的 HTTP 請求，接口 javax.servlet.Servlet 定義了所有 Servlet 必須要實現的方法。

從 HTTP 請求的處理過程來看，伺服器 Servlet 主要參與以下幾個環節：

• 接收請求：客戶端請求會被封裝成 HttpServletRequest 對象，包含報文頭參數和報文體等信息。
• 處理請求：通常調用 Servlet 的方法 service、doPost 或 doGet 等方法處理請求，并進一步調用業務層相應邏輯對其進行處理等。
• 反饋響應：處理完請求后，可以轉發（forward）、重定向（redirect）到某個視圖頁面或者直接返回結果數據，轉發是 HttpServletRequest 的方法，重定向是 HttpServletResponse 的方法。

在老兵哥的讀書年代，Web 應用相對簡單，主要是各種信息管理系統。當時 Spring 尚未誕生，主流技術棧是 JSP/Servlet，老兵哥我開發 Web 應用時主要編寫繼承自 HttpServlet 子類，將各種業務邏輯功能分別交由不同的 HttpServlet 子類實現。HttpServlet 繼承自 GenericServlet，后者實現了接口 Servlet。隨著數字化和互聯網化的不斷推進，業務系統變得越來越復雜，HttpServlet 子類越寫越多，web.xml 配置文件越來越復雜，這導致系統的擴展維護越來越困難，手工作坊式的開發方法已經跟不上業務發展的步伐了。時勢造英雄，Spring 就是在這種背景下呼之而出的，它創造性地發明了控制反轉 IOC 和面向切面編程 AOP，極大地降低復雜度。如下面配置示例所示，整個 Web 應用只需要配置一個 Servlet 就可以了，它就是 Spring 的前置分發器 DispatcherServlet：

<servlet>
    <servlet-name>mvc</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:mvc-servlet.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>mvc</servlet-name>
    <url-pattern>/api</url-pattern>
</servlet-mapping>

3.2 Web 應用處理 HTTP 請求的流程

如下圖所示，Web 應用處理 HTTP 請求的流程主要是穿越監聽器 Listener 和過濾器鏈 Filters，最終抵達伺服器 Servlet 的過程：

原先我們將 Web 應用的復雜度直接暴露給了 Tomcat，現在 Spring 通過控制反轉 IOC 和面向切面編程 AOP 等新技術接管了 Web 應用的復雜度。如前面 Servlet 的配置示例，整個 Web 應用只需要配置 Spring 提供的前置分發器 DispatcherServlet，開發者無需再編寫和配置 HttpServlet 子類，所有業務邏輯功能將按照 Spring 的標準規范來開發，從原先的編寫 Listener\Filter\Servlet 改為編寫 Spring Component，包括：Controller、Service、Repository 等。

Tomcat 在接收到某個 Web 應用的 Http 請求之后，它會將所有請求都轉交給前置分發器 DispatcherServlet，再由 DispatcherServlet 將請求派發給具體業務邏輯進行處理。DispatcherServlet 就是從 HttpServlet 派生的子類，它的類圖關系如下所示：

3.3 Web 應用架構演進過程解析

Web 應用架構的演進過程就像創業孵化過程，最初創業團隊打造的產品很簡單，大家采用手工作坊模式來快速打造最小化可行產品，這時候團隊的組織架構也跟產品一樣扁平簡單。但隨著產品被越來越多的用戶使用，功能變得越來越復雜，接著必須引進新架構才能有效管理復雜度，同時團隊規模的擴展也需要與業務發展匹配的組織架構，這樣才能保證產品的不斷發展。Web 應用架構的演化過程跟 Tomcat 體系結構的形成過程類似，老兵哥會經常借助“俄羅斯套娃”這個模型來闡述架構，Web 容器和 Web 應用這兩層的架構原則是類似的，就像大娃娃套著小娃娃一樣。

Spring 的 IOC 容器跟 Tomcat 的 Servlet 容器類似，也是通過配置文件等方式來定義組件，然后在啟動過程中將這些定義好的組件初始化并添加到容器當中，后續使用時從容器查找獲取。早期 Web 應用主要由大量開發者編寫的 Filter\Listener\Servlet 等組件構成，這些核心組件的配置全部都通過 web.xml 配置文件來維護，那么 Web 應用和 Web 容器之間其實不是松耦合的，而引進 Spring 之后就變成只需要配置 DispatcherServlet 等少量組件了，達到了分層架構的要求，更加有利于開發復雜的 Web 應用。如果采用架構的專業術語來描述，這就是經典的分層架構模式，層與層之間松耦合，僅通過少量的接口銜接，每層內部高內聚。

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

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

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