死磕Tomcat系列(1)——整體架構
在許多的高階開發的崗位中都會或多或少有要求面試人員要研究過一些常用中介軟體原始碼。這是因為一切的祕密都是藏在原始碼中，閱讀原始碼能夠讓我們對框架或者中介軟體的理解更加深刻，而我們也能夠在原始碼的研究中獲得其中一些優秀的設計方式。而我們的中介軟體和原始碼那麼多，我們該從何入手呢？其實大部分的中介軟體或者框架都有一些共性的部分，例如網路程式設計、多執行緒、反射和類載入等技術。所以深入研究透了一兩個中間價的話，那麼再回過頭來看其他的中介軟體，那麼就會很容易理解它裡面所用的技術以及原理。而作為一個老牌的WEB端框架Tomcat，無論是其整體的架構設計，還是其內在的一些技術靈活應用，都值得我們一看。
在學習框架的時候，我一般都是對這個框架有一個整體的認識。知道它整體是如何執行的，然後再深入其中某部分進行研究，這樣會事半功倍。
整體架構
我們想要了解一個框架，首先要了解它是幹什麼的，Tomcat我們都知道，是用於處理連線過來的Socket請求的。那麼Tomcat就會有兩個功能：
- 對外處理連線，將收到的位元組流轉化為自己想要的Request和Response物件
- 對內處理Servlet，將對應的Request請求分發到相應的Servlet中
那麼我們整體的骨架就出來了，Tomcat其實就分為兩大部分，一部分是聯結器(Connnector)處理對外連線和容器(Container)管理對內的Servelet。大體的關係圖如下
最外層的大框就是代表一個Tomcat服務，一個Tomcat服務可以對應多個Service。每個Service都有聯結器和容器。這些對應的關係我們也可以開啟在Tomcat目錄配置檔案中server.xml中看出來。
<Server port="8006" shutdown="SHUTDOWN">
<Service name="Catalina">
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<Connector port="8010" protocol="AJP/1.3" redirectPort="8443" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps"
</Host>
</Engine>
</Service>
</Server>
複製程式碼這裡我將其中配置檔案中刪除了一些內容精簡了一下，這裡我們可以看到聯結器其實就是Connector，一個Service中可以有多個聯結器，容器其實對應的就是Engine。
Tomcat的整體架構簡單來說就是這樣的對應關係。接下來我們簡單的介紹聯結器的整體架構和容器的整體架構。
聯結器
我們可以看到上圖中聯結器傳給容器的是ServletRequest物件，而容器傳給聯結器的是ServletResponse物件，這些在網路傳輸過程中是肯定不行的，因為網路傳輸中傳送的位元組流。所以聯結器的功能需求我們大概能總結出來以下幾點。
- Socket連線
- 讀取請求網路中的位元組流
- 根據相應的協議(Http/AJP)解析位元組流，生成統一的
Tomcat Requestt物件 - 將
Tomcat Reques傳給容器 - 容器返回
Tomcat Response物件 - 將
Tomcat Response物件轉換為位元組流 - 將位元組流返回給客戶端
其實上面的細分都能總結為以下的三點
- 網路通訊
- 應用層協議的解析
- Tomcat的
Request/Response與ServletRequest/ServletResponse物件的轉化
而在Tomcat中它也用了三個類來實現上面的三個功能，分別對應如下
- EndPoint
- Processor
- Adapter
用圖表示他們的關係的話就是這樣
容器
容器，顧名思義就是裝東西的器具，那麼這個Tomcat容器是裝什麼的呢？其實主要的就是裝了Servlet的。那麼容器是如何設計的呢？Tomcat的容器設計其實是用了組合設計模式（不瞭解組合設計模式的可以看我之前的文章不學無數——組合模式）。其實從Server.xml中我們也能看到其關係了。
<Engine name="Catalina" defaultHost="localhost">
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
</Host>
</Engine>
複製程式碼在這裡面我們只能看到容器中的兩個模組，一個是頂層模組Engine，另一個是Host，其實還有兩個模組，一個是Context對應的是我們webapp裡面的每個應用資料夾，每個資料夾就是對應一個Context，還有一個模組Wrapper對應的是我們Context中的所有servlet，Wrapper管理了訪問關係與具體的Servlet的對應。圖表示就是下面這樣。
Tomcat中容器所有模組都實現了Container介面，而組合模式的意義就是使得使用者對於單個物件和組合物件的使用具有一致性，即無論新增多少個Context其使用就是為了找到其下面的Servlet，而無論新增多少個Host也是為了找個下面的Servlet。而在容器中設計了這麼多的模組，一個請求過來Tomcat如何找到對應的Servlet進行處理呢？
請求如何定位
我們就舉個最簡單的例子，我們本機應用上啟動了一個Tomcat，webapp下有我們部署的一個應用buxuewushu。我們在瀏覽器上輸入http://localhost:8080/buxuewushu/add.do是如何找到對應Servlet進行處理呢？
在我們啟動Tomcat的時候，聯結器就會進行初始化監聽所配置的埠號，這裡我們配置的是8080埠對應的協議是HTTP。
- 請求傳送到本機的8080埠，被在那裡監聽的HTTP/1.1的聯結器Connector獲得
- 聯結器Connector將位元組流轉換為容器所需要的
ServletRequest物件給同級Service下的容器模組Engine進行處理 - Engine獲得地址
http://localhost:8080/buxuewushu/add。匹配他下面的Host主機 - 匹配到名為localhost的Host（就算此時請求為具體的ip，沒有配置相應的Host，也會交給名為localhost的Host進行處理，因為他是預設的主機）
- Host匹配到路徑為
/buxuewushu的Context，即在webapp下面找到相應的資料夾 - Context匹配到URL規則為*.do的servlet，對應為某個Servlet類
- 呼叫其
doGet或者doPost方法 - Servlet執行完以後將物件返回給Context
- Context返回給Host
- Host返回給Engine
- Engine返回給聯結器Connector
- 聯結器Connector將物件解析為位元組流傳送給客戶端