死磕Tomcat系列(1)——總體架構

死磕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將對象解析爲字節流發送給客戶端

往期關於Tomcat的文章

• 一次奇怪的StackOverflowError問題查找之旅
• 如何斷點調試Tomcat源碼

參考

• 深刻拆解Tomcat&Jetty