valve
lifecycle
我們可以從 server.xml 中就能夠看出 tomcat 各元件的層次結構，具體結構圖如下：
從某種意義來說，server也算是一種應用，那種應用呢？
它可以接收其他計算機，也即是客戶端發來的請求，它處理請求，然後將處理後的結果返回給請求的客戶端。通常情況下，我們通過使用socket監聽伺服器指定埠來實現該功能。
按照最簡單的僅僅是用作嵌入在應用系統中的乙個遠端請求處理方案，而且我們的系統訪問量很低，那麼我們可以設想下，server只需要兩個操作就是可以了：start()和stop()。乙個是啟動服務，乙個關閉服務。如下圖
但我們需要的是乙個應用伺服器的話，就不能這麼簡單了。
connector:負責請求的接收和響應
container:負責具體的請求處理
我們知道，應用伺服器只有server啟動和關閉是不行的。需要提**用服務的功能，就要有接收需求、處理需求、響應需求的功能如下圖。為什麼要將請求響應和處理分開不同的處理模組。主要原因如下：
單一職責原則；
請求協議（http/https/ajp等）有多種，而處理邏輯比較統一；
如上圖，但這樣也有問題，即server中包含多個connector和container，那麼來個請求後，connector怎麼知道這個請求交給哪個container來處理呢？我們也可以在中間建立個對映來解決，但不是最優的，因為後來會多出很多元件，這樣對映關係會越來越複雜。
那麼我們就引入乙個service元件，而這個元件，進行包裝和維護多個connector和container。而來自connector的請求只能由它所屬service維護的container處理。結構圖如下：
現在我們的應用服務可以啟動，可以接受請求並處理請求。而且，多個請求方式，對應乙個處理。那麼這個可以想到多個網域名稱服務了。
host 封裝了各個context資源的集合；
按照領域模型，這個典型的url訪問，可以解析出三層領域物件，他們之間互有隸屬關係。層層遞進，層層組合。那麼host的集合就是engine。每個模組各司其職，通過配置（server.xml）就可以很大限度的擴充套件tomcat。設計的很靈活。
如果說以上三個容器是物理模型的封裝，那麼engine可以作為一種邏輯的封裝。到此結構關係如下圖：
從tomcat的結構圖可以看出，是按照層次，分別封裝成乙個物件。
為什麼要這樣做呢？
這主要是為了方便統一管理。類似命名空間的概念，在不同層次的配置，其作用域不一樣。以tomcat自帶的列印request與response訊息的requestdumpervalve為例。這個valve的類路徑是：
org.apache.catalina.valves.requestdumpervalve如果這個valve配置在server.xml的context節點下，則其只列印出訪問這個應用的的request與response訊息。
如果這個valve配置在server.xml的host節點下，則其可以列印出訪問這個host下所有應用的request與response訊息。
name
="localhost"
= unpackwars
="true"
autodeploy
="true"
xmlvalidation
="false"
xmlnamespaceaware
="false"
>
classname
="org.apache.catalina.valves.requestdumpervalve"
/>
path
="/beijing"
docbase
="/usr/local/tomcat8/web/mingjing"
>
context
>
path
="/shanghai"
docbase
="/usr/local/tomcat8/web/mingjing"
>
context
>
host
>
tomcat中的元件都交給這個介面管理，但是具體元件的生命週期是由包含元件的父容器來管理的，tomcat中頂級容器管理著service的生命週期，service容器又是connector和container的父容器，所以這兩個元件的生命週期是由service管理的，container也有子容器，所以管理著這些子容器的生命週期。這樣，只要所有元件都實現了lifecycle介面，從頂層容器server開始，就可以控制所有容器的生命週期了。而這裡使用了觀察者模式，包括pipeline和valve的責任鏈模式，有一篇tomcat涉及的設計模式中有詳細講解。
多層架構簡述
使用多層架構進行系統開發是現今系統設計的流行趨勢。通過分解業務細節，將不同的功能 分散開來，更利於系統的設計和開發，同時為可能的變更提供了更小的單元。以下就是乙個典型的多層體系結構圖。首先我們以 訂單 order 為例，進行乙個簡單的業務分解。1.訂單自然包括訂單的內容 orderinfo 其中有諸...
多層架構簡述
分類 多層架構 2007 06 20 14 47 2247人閱讀收藏 舉報 資料庫ioc 架構設計 儲存session作業 使用多層架構進行系統開發是現今系統設計的流行趨勢。通過分解業務細節，將不同的功能 分散開來，更利於系統的設計和開發，同時為可能的變更提供了更小的單元。以下就是乙個典型的多層體系...
Openstack 架構簡述
概述 本文章相關的靈感 說明 來自於 首先放幾張圖，詳細的解釋了openstack的架構以及網路拓撲結構.架構 拓撲openstack架構詳解 整個openstack由控制節點，計算節點，網路節點，儲存節點四大部分組成 以下架構僅為本人理解，不盡完全，如有錯誤歡迎指出 控制節點架構 控制節點包括以下...