共計 4723 個字符，預計需要花費 12 分鐘才能閱讀完成。

Web 服務器 Tomcat 的架構模塊有哪些，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

俗話說，站在巨人的肩膀上看世界，一般學習的時候也是先總覽一下整體，然后逐個部分個個擊破，最后形成思路，了解具體細節，Tomcat 的結構很復雜，但是  Tomcat 非常的模塊化，找到了 Tomcat 最核心的模塊，問題才可以游刃而解，了解了 Tomcat 的整體架構對以后深入了解 Tomcat 來說至關重要!

一、Tomcat 頂層架構

先上一張 Tomcat 的頂層總體結構圖(圖 A)，如下：

Tomcat 中最頂層的容器是 Server，代表著整個服務器，從上圖中可以看出，一個 Server 可以包含至少一個 Service，用于具體提供服務。

Service 主要包含兩個部分：Connector 和 Container。從上圖中可以看出 Tomcat 的心臟就是這兩個組件，他們的作用如下：

1、Connector 用于處理連接相關的事情，并提供 Socket 與 Request 和 Response 相關的轉化;

2、Container 用于封裝和管理 Servlet，以及具體處理 Request 請求;

一個 Tomcat 中只有一個 Server，一個 Server 可以包含多個 Service，一個 Service 只有一個 Container，但是可以有多個 Connectors，這是因為一個服務可以有多個連接，如同時提供 Http 和 Https 鏈接，也可以提供向相同協議不同端口的連接, 示意圖如下(Engine、Host、Context 下邊會說到)：

多個 Connector 和一個 Container 就形成了一個 Service，有了 Service 就可以對外提供服務了，但是 Service   還要一個生存的環境，必須要有人能夠給她生命、掌握其生死大權，那就非 Server 莫屬了! 所以整個 Tomcat 的生命周期由 Server 控制。

另外，上述的包含關系或者說是父子關系，都可以在 tomcat 的 conf 目錄下的 server.xml 配置文件中看出，下圖是刪除了注釋內容之后的一個完整的 server.xml 配置文件(Tomcat 版本為 8.0)

詳細的配置文件文件內容可以到 Tomcat 官網查看：http://tomcat.apache.org/tomcat-8.0-doc/index.html

上邊的配置文件，還可以通過下邊的一張結構圖更清楚的理解：

Server 標簽設置的端口號為 8005，shutdown=”SHUTDOWN” ，表示在 8005 端口監聽“SHUTDOWN”命令，如果接收到了就會關閉 Tomcat。一個 Server 有一個 Service，當然還可以進行配置，一個 Service 有多個，Service 左邊的內容都屬于 Container 的，Service 下邊是 Connector。

二、Tomcat 頂層架構小結：

(1)Tomcat 中只有一個 Server，一個 Server 可以有多個 Service，一個 Service 可以有多個 Connector 和一個 Container;

(2) Server 掌管著整個 Tomcat 的生死大權;

(4)Service 是對外提供服務的;

(5)Connector 用于接受請求并將請求封裝成 Request 和 Response 來具體處理;

(6)Container 用于封裝和管理 Servlet，以及具體處理 request 請求;

知道了整個 Tomcat 頂層的分層架構和各個組件之間的關系以及作用，對于絕大多數的開發人員來說 Server 和 Service 對我們來說確實很遠，而我們開發中絕大部分進行配置的內容是屬于 Connector 和 Container 的，所以接下來介紹一下 Connector 和 Container。

三、Connector 和 Container 的微妙關系

由上述內容我們大致可以知道一個請求發送到 Tomcat 之后，首先經過 Service 然后會交給我們的 Connector，Connector 用于接收請求并將接收的請求封裝為 Request 和 Response 來具體處理，Request 和 Response 封裝完之后再交由 Container 進行處理，Container 處理完請求之后再返回給 Connector，最后在由 Connector 通過 Socket 將處理的結果返回給客戶端，這樣整個請求的就處理完了!

Connector 最底層使用的是 Socket 來進行連接的，Request 和 Response 是按照 HTTP 協議來封裝的，所以 Connector 同時需要實現 TCP/IP 協議和 HTTP 協議!

Tomcat 既然處理請求，那么肯定需要先接收到這個請求，接收請求這個東西我們首先就需要看一下 Connector!

四、Connector 架構分析

Connector 用于接受請求并將請求封裝成 Request 和 Response，然后交給 Container 進行處理，Container 處理完之后在交給 Connector 返回給客戶端。

因此，我們可以把 Connector 分為四個方面進行理解：

(1)Connector 如何接受請求的?

(2)如何將請求封裝成 Request 和 Response 的?

(3)封裝完之后的 Request 和 Response 如何交給 Container 進行處理的?

(4)Container 處理完之后如何交給 Connector 并返回給客戶端的?

首先看一下 Connector 的結構圖(圖 B)，如下所示：

Connector 就是使用 ProtocolHandler 來處理請求的，不同的 ProtocolHandler 代表不同的連接類型，比如：Http11Protocol 使用的是普通 Socket 來連接的，Http11NioProtocol 使用的是 NioSocket 來連接的。

其中 ProtocolHandler 由包含了三個部件：Endpoint、Processor、Adapter。

(1)Endpoint 用來處理底層 Socket 的網絡連接，Processor 用于將 Endpoint 接收到的 Socket 封裝成 Request，Adapter 用于將 Request 交給 Container 進行具體的處理。

(2)Endpoint 由于是處理底層的 Socket 網絡連接，因此 Endpoint 是用來實現 TCP/IP 協議的，而 Processor 用來實現 HTTP 協議的，Adapter 將請求適配到 Servlet 容器進行具體的處理。

(3)Endpoint 的抽象實現 AbstractEndpoint 里面定義的 Acceptor 和 AsyncTimeout 兩個內部類和一個 Handler 接口。Acceptor 用于監聽請求，AsyncTimeout 用于檢查異步 Request 的超時，Handler 用于處理接收到的 Socket，在內部調用 Processor 進行處理。

至此，我們應該很輕松的回答 (1)(2)(3) 的問題了，但是 (4) 還是不知道，那么我們就來看一下 Container 是如何進行處理的以及處理完之后是如何將處理完的結果返回給 Connector 的?

五、Container 架構分析

Container 用于封裝和管理 Servlet，以及具體處理 Request 請求，在 Connector 內部包含了 4 個子容器，結構圖如下(圖 C)：

4 個子容器的作用分別是：

(1)Engine：引擎，用來管理多個站點，一個 Service 最多只能有一個 Engine;

(2)Host：代表一個站點，也可以叫虛擬主機，通過配置 Host 就可以添加站點;

(3)Context：代表一個應用程序，對應著平時開發的一套程序，或者一個 WEB-INF 目錄以及下面的 web.xml 文件;

(4)Wrapper：每一 Wrapper 封裝著一個 Servlet;

下面找一個 Tomcat 的文件目錄對照一下，如下圖所示：

Context 和 Host 的區別是 Context 表示一個應用，我們的 Tomcat 中默認的配置下 webapps 下的每一個文件夾目錄都是一個 Context，其中 ROOT 目錄中存放著主應用，其他目錄存放著子應用，而整個 webapps 就是一個 Host 站點。

我們訪問應用 Context 的時候，如果是 ROOT 下的則直接使用域名就可以訪問，例如：www.aistudy.com, 如果是 Host(webapps)下的其他應用，則可以使用 www.aistudy.com/docs 進行訪問，當然默認指定的根應用 (ROOT) 是可以進行設定的，只不過 Host 站點下默認的主營用是 ROOT 目錄下的。

看到這里我們知道 Container 是什么，但是還是不知道 Container 是如何進行處理的以及處理完之后是如何將處理完的結果返回給 Connector 的? 別急! 下邊就開始探討一下 Container 是如何進行處理的!

六、Container 如何處理請求的

Container 處理請求是使用 Pipeline-Valve 管道來處理的!(Valve 是閥門之意)

Pipeline-Valve 是責任鏈模式，責任鏈模式是指在一個請求處理的過程中有很多處理者依次對請求進行處理，每個處理者負責做自己相應的處理，處理完之后將處理后的請求返回，再讓下一個處理著繼續處理。

但是!Pipeline-Valve 使用的責任鏈模式和普通的責任鏈模式有些不同! 區別主要有以下兩點：

(1)每個 Pipeline 都有特定的 Valve，而且是在管道的最后一個執行，這個 Valve 叫做 BaseValve，BaseValve 是不可刪除的;

(2)在上層容器的管道的 BaseValve 中會調用下層容器的管道。

我們知道 Container 包含四個子容器，而這四個子容器對應的 BaseValve 分別在：StandardEngineValve、StandardHostValve、StandardContextValve、StandardWrapperValve。

Pipeline 的處理流程圖如下(圖 D)：

(1)Connector 在接收到請求后會首先調用最頂層容器的 Pipeline 來處理，這里的最頂層容器的 Pipeline 就是 EnginePipeline(Engine 的管道);

(2)在 Engine 的管道中依次會執行 EngineValve1、EngineValve2 等等，最后會執行 StandardEngineValve，在 StandardEngineValve 中會調用 Host 管道，然后再依次執行 Host 的 HostValve1、HostValve2 等，最后在執行 StandardHostValve，然后再依次調用 Context 的管道和 Wrapper 的管道，最后執行到 StandardWrapperValve。

(3)當執行到 StandardWrapperValve 的時候，會在 StandardWrapperValve 中創建 FilterChain，并調用其 doFilter 方法來處理請求，這個 FilterChain 包含著我們配置的與請求相匹配的 Filter 和 Servlet，其 doFilter 方法會依次調用所有的 Filter 的 doFilter 方法和 Servlet 的 service 方法，這樣請求就得到了處理!

(4)當所有的 Pipeline-Valve 都執行完之后，并且處理完了具體的請求，這個時候就可以將返回的結果交給 Connector 了，Connector 在通過 Socket 的方式將結果返回給客戶端。

看完上述內容，你們掌握 Web 服務器 Tomcat 的架構模塊有哪些的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！