Servlet 和 Servlet容器

2020 年 4 月 23 日
筆記
Java知識點

Servlet

很多同學可能跟我一樣始終沒有搞清楚到底什麼是 Servlet，什麼是 Servlet 容器。網上看了很多帖子，或許人家說的很清楚，但是自己的那個彎彎就是拐不過來。

想了很久說一下自己的理解。

Java web 開發中為啥要有 Servlet 呢？是否可以不要。

web開發的本質就一句話：客戶端和伺服器交換數據。於是你使用 Java 的 Socket 套接字進行編程，去處理客戶端來的 tcp 請求，經過編解碼處理讀取請求體，獲取請求行，然後找到請求行對應的處理邏輯步入伺服器的處理中，處理完畢把對應的結果返回給當前的 Socket 鏈接，響應完畢，關閉 Socket。

以上過程，你有沒有發現其實是兩個部分：

建立連接，傳輸數據，關閉連接，你肯定知道這些步驟不是你所開發的web服務去處理的，而是tomcat容器幫你做了這些事情。
拿到請求行之後去找對應的 url 路由，這一部分是誰做的呢？在如今 SpringBoot 橫行的時代，去配置化已經成為趨勢，編程越來越簡單導致的後果就是越來越難以理解事物最開始的樣子。還記得 SpringMVC工程中的 web.xml文件嗎？是否還記得在web.xml中有這麼一段配置呢：

<servlet>
	<servlet-name>SpringMVC</servlet-name>
	<servlet-class>org.springframework.web.servlet.DispatcherServlet
	</servlet-class>
	<init-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>classpath*:/spring/SpringMVC-servlet.xml</param-value>
	</init-param>
	<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
	<servlet-name>SpringMVC</servlet-name>
	<url-pattern>/</url-pattern>
</servlet-mapping>

Spring 的核心就是一個 Servlet,它攔截了所有的請求,將請求交給 DispatcherServlet 去處理。
我們再來問一遍，Servlet 到底是什麼，它就是一段處理 web 請求的邏輯，並不是很高深的東西。

再來看 Java 中的 Servlet，它只是一個介面：


package javax.servlet;

import java.io.IOException;


public interface Servlet {

   
    public void init(ServletConfig config) throws ServletException;

    public ServletConfig getServletConfig();

    public void service(ServletRequest req, ServletResponse res)
            throws ServletException, IOException;

    public String getServletInfo();

    public void destroy();
}

Servlet 介面規定請求從容器到達 web 服務端的規範，最重要的三個步驟是:

init()：初始化請求的時候要做什麼；
service()：拿到請求的時候要做什麼；
destory()：處理完請求銷毀的時候要做什麼。

所有實現 Servlet 的實現方都是在這個規範的基礎上進行開發。那麼 Servlet 中的數據是從哪裡來的呢？答案就是 Servlet 容器。容器才是真正與客戶端打交道的那一方。Servlet容器只有一個，而 Servlet 可以有多個。常見的Servlet容器Tomcat,它監聽了客戶端的請求埠,根據請求行資訊確定將請求交給哪個Servlet 處理，找到處理的Servlet之後，調用該Servlet的 service() 方法，處理完畢將對應的處理結果包裝成ServletResponse 對象返回給客戶端。

Servlet 容器

上面說過，Servlet 只是一個處理請求的應用程式，光有Servlet是無法運行起來的，需要有一個 main 方法去調用你的這段 Servlet 程式才行。所以這裡出現了Servlet 容器的概念。Servlet容器的主要作用是：

建立連接；
調用Servlet處理請求；
響應請求給客戶端；
釋放連接；

這上面的四步，如果是你來設計的話是否可以用一個模板方法搞定，1，3，4都是固定的步驟，不會因為請求不同而有很大的變化。2卻會因為對應的請求不同需要業務邏輯自己去實現不同的處理。所以這裡抽象出來了 Servlet，Servlet想怎麼玩就怎麼玩，這是你自己的事情。容器幫你做的是你不想做的臟活累活。

另外，既然叫做容器肯定是能裝多個Servlet，並且可以管理Servlet的聲明周期。這些功能應該是容器必備的。

上面提到了 web.xml 中的 DispatcherServlet，它是 Spring 中定義的一個 Servlet，實現了 Servlet 介面，本質也是一個 Servlet。只是它是 HttpServlet 的繼承者，主要處理 http 請求。所以 Spring 程式本質是就是一個 Servlet。SpringMVC 幫你做了本該你去實現的邏輯，你看不到並不代表它不是。

好啦，以上通俗的語言解釋了什麼是 Servlet，什麼是 Servlet 容器，以及 Servlet 和 Servlet 容器之間的關係。

Tomcat

Tomcat是啥呢？本質上是一個 Servlet 容器，實現了對 Java Servlet 規範的支援。同時 Tomcat 也提供了處理HTTP請求的能力，所以也可以作為一個Web伺服器。了解到Tomcat有 Web伺服器和 Servlet容器的功能，那麼 Tomcat總體是如何設計的呢？我們來看一張簡圖：

Java web 應用如果部署到 Tomcat 中，一個Tomcat就表示一個服務。一個 Server 伺服器可以包含多個 Service 服務，Tomcat 默認的 Service 服務是 Catalina，而一個 Service 服務可以包含多個連接器，因為 Tomcat 支援多種網路協議，包括 HTTP/1.1、HTTP/2、AJP 等等，一個 Service 服務還會包括一個容器，容器外部會有一層 Engine 引擎所包裹，負責與處理連接器的請求與響應，連接器與容器之間通過 ServletRequest 和 ServletResponse 對象進行交流。

Tomcat容器的設計提現在一個核心文件中：server.xml。這個文件充分展示了Tomcat的高度抽象設計：

<Server port="8005" shutdown="SHUTDOWN">
    <Service name="Catalina">
        <Connector port="8080" protocol="HTTP/1.1"
                   connectionTimeout="20000"
                   redirectPort="8443"/>
      	<Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/>
				<Engine name="Catalina" defaultHost="localhost">
          	<Host name="localhost" appBase="webapps"
                    	unpackWARs="true" autoDeploy="true">
          
          
            </Host>
        </Engine>
    </Service>
</Server>

其中：

Server 組件是管理 tomcat 實例的組件，可以監聽一個埠，從此埠上可以遠程向該實例發送 shutdown 關閉命令。
Service 組件是一個邏輯組件，用於綁定 connector 和 container，有了 service 表示可以向外提供服務，就像是一般的 daemon 類服務的 service。可以認為一個 service 就啟動一個JVM，更嚴格地說，一個 engine 組件才對應一個 JVM （定義負載均衡時，jvmRoute 就定義在 Engine 組件上用來標識這個 JVM ），只不過 connector 也工作在 JVM 中。

小故事：

是否關注到 Service name = Catalina，實際上 Tomcat 的前身就是 Catalina，這是一個島的名字，而

Catalina 只是一個 Servlet 容器，為Servlet和 JavaServer Pages（JSP）實現了Sun Microsystems的規範。

Tomcat 的作者詹姆斯·鄧肯·戴維森，Sun Microsystems 的軟體架構師在後來 Sun Microsystems 向 Apache Software Foundation 捐贈該項目中發揮了重要作用。當時他認為許多開源項目都有與 O’Reilly 相關的書籍，封面上有動物，所以他想以動物命名。後來這位老哥想到了貓🐈。他認為這隻動物代表著某種可以自己生存的東西，當2003年 O’Reilly 發行帶有雪豹的 Tomcat 書籍時，他希望看到動物封面的願望終於實現了。
Connector 組件是監聽組件，它有四個作用：
1. 開啟監聽套接字，監聽外界請求，並和客戶端建立 TCP 連接；
2. 使用 protocolHandler 解析請求中的協議和埠等資訊，如 http 協議、AJP 協議；
3. 根據解析到的資訊，使用 processer 將分析後的請求轉發給綁定的 Engine；
4. 接收響應數據並返回給客戶端。
上面的 server.xml 配置我們能看到有兩個 Connector。
```
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443"/>
```
這個 Connector 表示通過 8080 埠使用 HTTP/1.1版本的協議來訪問 Tomcat。

我們知道 80 埠是為 HTTP(HyperText Transport Protocol) 即超文本傳輸協議開放的，主要用於萬維網傳輸資訊的協議。而我們一般在 Tomcat 中監聽的是一個非 80 埠。那為啥不直接在 Tomcat 中寫上 80 埠，即所有 HTTP 請求都可以收到。這是因為在生產環境中，一般不會直接暴露原始服務給外網，一方面是安全性，另一方面是負載均衡處理和靜態資源處理。所以會在原始服務上加一層代理，代理來監聽 80 埠，再將服務暴露埠的請求轉發給對應服務。

第二個 Connector：
```
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/>
```
這個 Connector 監聽 8009 埠的 AJP 協議連接。AJP 協議負責和其他的 HTTP 伺服器(如 Apache )建立連接；在把 Tomcat 與其他 HTTP 伺服器集成時，就需要用到這個連接器。之所以使用 Tomcat 和其他伺服器集成，是因為 Tomcat 可以用作 Servlet/JSP 容器，但是對靜態資源的處理速度較慢，不如 Apache 和 IIS 等 HTTP 伺服器。因此常常將 Tomcat 與 Apache 等集成，前者作 Servlet 容器，後者處理靜態資源，而 AJP 協議便負責 Tomcat 和 Apache 的連接。

Container 表示一類組件，在配置文件(server.xml)中沒有體現出來。它包含4個容器類組件：Engine容器、Host容器、Context容器和 wrapper容器。

Engine 容器用於從 Connector 組件處接收已建立的 TCP 連接，還用於接收客戶端發送的 HTTP 請求並分析請求，然後按照分析的結果將相關參數傳遞給匹配出的虛擬主機。Engine 還用於指定默認的虛擬主機。

Host 容器定義虛擬主機，對應了伺服器中一個網路名實體（如」www.baidu.com」，或IP地址」23.0.32.1」）。為了使用戶可以通過域名連接 Tomcat 伺服器，這個域名應該在域名伺服器已經註冊過。

比如上例中的配置：

<Host name="localhost" appBase="webapps"
                    	unpackWARs="true" autoDeploy="true">

name=localhost 表示當前對應的請求是本機，這是因為已經配置了Nginx代理的原因，如果沒有配置代理，那麼這裡就必須是真實的IP 或者域名。注意後面的 appBase，appBase表示當前 web資源所在的目錄。

Context 容器主要是根據 path 和 docBase 獲取一些資訊，將結果交給其內的 wrapper 組件進行處理（它提供wrapper運行的環境，所以它叫上下文context）。一般來說，都採用默認的標準 wrapper 類，因此在 Context 容器中幾乎不會出現 wrapper 組件。

wrapper 容器對應 Servlet 的處理過程。它開啟 Servlet 的生命周期，根據 Context 給出的資訊以及解析 web.xml 中的映射關係，負責裝載相關的類，初始化 servlet 對象 init()、執行 servlet 程式碼 service() 以及服務結束時 servlet 對象的銷毀 destory()。

根據上面描述的 tomcat 組件體系結構，處理請求的大致過程其實很容易推導出來：

Client(request)-->Connector-->Engine-->Host-->Context-->Wrapper(response data)-->Connector(response header)-->Client

可以看到宏觀上 Tomcat 設計的真是非常精妙，層疊式的容器設計呈現出一種美感。Connector 和 Container 兩大組件涵蓋主要功能，這種複合組件化的設計思想我們是否可以應用在業務系統中呢。右面有空繼續分析 Tomcat 中各個模組的設計。

Tags: Java知識點