超詳細Tomcatプロファイルの解読


1、tomcat Tomcatが完全な意味でのJave EEではないことを理解する(j 2 ee)サーバは、完全なJava EEエンタープライズアプリケーションプラットフォームのAPIを提供していないため、Tomcatはapacheオープンソースプロトコルに従い、現在のJava開発フレームワークのオープンソースコンポーネントStructs、Spring、Hibernateなどを完璧にサポートしているため、tomcatは多くの企業によって多くのJavaアプリケーションを配置し、いくつかのビジネスのJavaアプリケーションサーバに代わるものを実現するために使用されている.、Tomcatのディレクトリ構造tomcatを導入するには、tomcatのディレクトリ構造と各ディレクトリの役割を理解する必要があります.ここでtomcat 7を例にTomcatをインストールしますが、再度説明しないでください.
tomcatインストールディレクトリに入ります.
|-- bin |   |-- bootstrap.JAr tomcatの起動時に依存するクラスで、tomcatの起動時にUsing CLASSSPATH:このクラスがロードされていることがわかります|--catalina-tasks.xmlはtomcatがロードしたライブラリファイルを定義し、クラスファイル|--catalina.bat |   |-- catalina.sh tomcat単一インスタンスLinuxプラットフォームでの起動スクリプト|--commons-daemon-native.tar.gz jsvcツールは、tomcatのデーモンプロセス方式を実行することができ、インストール|--commons-daemonを個別にコンパイルする必要がある.JAr jsvcツールに依存するjavaクラス|--configtest.bat |   |-- configtest.sh tomcatプロファイル構文が正しいLinuxプラットフォームスクリプト|--cpappend.bat |   |-- daemon.sh tomcatはプロセス方式の実行時の、起動、停止スクリプト|--digest.bat |   |-- digest.sh |   |-- setclasspath.bat |   |-- setclasspath.sh |   |-- shutdown.bat |   |-- shutdown.sh tomcatサービスはLinuxプラットフォームの下でスクリプト|--startupを閉じます.bat |   |-- startup.sh tomcatサービスLinuxプラットフォームでスクリプト|--tomcat-juliを起動します.jar |   |-- tomcat-native.tar.gzはtomcatがapacheのaprを使用してライブラリを実行できるようにし、tomcatの性能を強化するにはインストール|--tool-wrapperを単独でコンパイルする必要がある.bat |   |-- tool-wrapper.sh |   |-- version.bat |   `-- version.sh tomcatおよびJVMのバージョン情報|--confはその名の通り、プロファイルディレクトリ|--catalina.policyはtomcatのファイルシステムにおけるディレクトリやファイルの読み取り、書き込み実行などの権限、およびいくつかのメモリ、sessionなどの管理権限|--catalinaを構成する.properties配置tomcatのclasspath等|--context.xml tomcatのデフォルトcontextコンテナ|--logging.propertiesはtomcatのログ出力方式|--serverを構成する.xml tomcatのメインプロファイル|--tomcat-users.xml tomcatのロール(ライセンスユーザー)プロファイル|`--web.xml tomcatのアプリケーションの配置記述子ファイル|--lib|--logsログファイルデフォルト格納ディレクトリ|--temp|`--safeToDelete.tmp|--webapps tomcatはアプリケーションのディレクトリをデフォルトで保存します.例えばapacheのデフォルトのウェブページの保存経路は/var/www/htmlのように|--docs tomcatドキュメント|--examples tomcatが持参した独立したウェブアプリケーションの例|--host-manager tomcatのホスト管理アプリケーション||--META-NFアプリケーション全体のエントリです.jarファイルを記述するための情報|`--context.xml現在のアプリケーションのcontextコンテナ構成はtomcat/conf/contextを上書きします.xmlにおける構成||WEB-INFは、現在のアプリケーションのプライベートリソースを格納するために使用する|||classesは、現在のアプリケーションに必要なclassファイルを格納するために使用される||||libは、現在のアプリケーションのロックに必要なjarファイルを格納するために使用される|webである.xml現在のアプリケーションのデプロイメント記述子ファイルでは、アプリケーションがロードするserverletクラスと、そのプログラムがどのようにデプロイメントされるかを定義します|--manager tomcatの管理アプリケーション|--ROOTはtomcatのアプリケーションのルートを指し、アプリケーションがROOTにデプロイメントされる場合は、直接http://ip:port`--ワークにアクセスして、JSPアプリケーションの導入時にコンパイルされたclassファイルを保存します.
3、tomcatのメインプロファイル(server.xml)の構造と意味を理解する下図に示すように、フロントエンド要求はtomcatによって直接受信されるか、フロントエンドのエージェントによってHTTP、またはAJPによってTomcatにエージェントされる.このとき要求はtomcatのconnectorによって受信され、異なるconnectorとEngineはserviceコンポーネントによって関連付けられ、1つのEngineで多くの仮想ホストが定義されている.ホストはHostコンテナによって定義され、各ホストは1つのホストを表し、それぞれのHostでは複数のContextを定義して、1つの仮想ホスト内の複数の独立したアプリケーションを定義することもできます.
4.単一インスタンスアプリケーション構成の一例
  : 
      :/web/www        :www.test1.com 
      :/web/bbs     URL:bbs.test1.com/bbs 
      :$CATALINA_HOME/wabapps   URL:manager.test.com          :172.23.136.* 

conf/server.xml 
 
   
   
   
   
   
   
   
     
   
   
   
   
     
     
     
     
     
     
         
     
    # Realm  ,                  ,      UserDatabase     
       
       
        www.test.com 
         
         
         
         
         
         
         
       
       
       
         
         
         
         
       
     
   
 

conf/tomcat-users.xml 
 
 
   
   
   
   
 

 
以上の構成から、問題の1つが明らかになった.いずれかのアプリケーションの構成を変更したい場合は、tomcatを再起動する必要があります.そうすると、他の2つのアプリケーションの通常のサービスに影響を及ぼす可能性があります.したがって、上記の構成はオンラインで使用するのに適していないため、複数のインスタンスに構成する必要があります.各インスタンスは独立したアプリケーションを1つだけ走るので、アプリケーション間で相互に影響を受けません.しかし、80ポートは1つのHTTP/1.1 Connectorによってのみ傍受され、3つのtomcatインスタンスは少なくとも3つのHTTP/1.1 Connectorが必要であり、これにより、HTTP 80ポートの要求を受信し、ドメイン名ごとにtomcatインスタンスのAJP/1.3 Connectorによって要求を伝達するフロントエンドエージェントが必要になるという問題に直面します.フロントエンドのエージェントはapacheを選択し、このような考え方に基づいてtomcatの負荷均衡を実現することができ、apacheは受信したHTTPハイパーテキスト転送メッセージをバイナリフォーマットに再カプセル化し、AJP/1.3プロトコルを通じてバックエンドに伝達するtomcat処理を行い、効率的にも明らかな向上がある.
5、apacheと結合して多例tomcatクラスタapacheを構築する方法は主に3種類ある:mod_jk,ajp_proxy,http_Proxy(tomcatにhttpプロトコルエージェント)を使用しますが、現在最も使用されているのはmod_です.jk.mod_jkの出現は比較的に早く、技術はすでにかなり成熟しており、クラスタノードの健康検査機能を備え、大型のAJPパケットをサポートしている.
インストールapache,tomcatここでは詳しくは説明していませんが、[ここを突いてください]インストールtomcat-connectors tar zxvf tomcat-connectors-1.2.30-src.tar.gz cd tomcat-connectors/src ./configure --with-apxs=/usr/local/apache/bin/apxs make && make install
①httpd-jkを単独で確立する.conf
httpd-jkを単独で確立する.confファイルはmod_を構成するために使用されますjkの関連設定vim/usr/local/apache 2/conf/extra/http-jk.conf
LoadModule jk_module modules/mod_jk.so#構成apacheマウントmod_jk.soモジュールJkWorkersFile/usr/local/apache/conf/extra/workers.properties#worker関連作業属性定義を保存したプロファイルJkLogFile/usr/local/apache/logs/mod_を指定します.jk.log#定義mod_jkモジュールのログファイルJkLog Level info#定義mod_jkモジュールログのレコードレベル
②worker関連作業属性定義のプロファイルvim/usr/local/apache/conf/extra/workersを作成する.properties worker.list=Cluster1,stat worker.web2.port=8003 worker.web2.host=172.23.138.19 worker.web2.type=ajp13 worker.web2.lbfactor=1
worker.web3.port=8003 worker.web3.host=172.23.136.144 worker.web3.type=ajp13 worker.web3.lbfactor=1 worker.Cluster1.type=lb worker.Cluster1.balance_workers=web2,web3 worker.Cluster1.sticky_session = 1
worker.stat.type=status worker.list=Cluster2 worker.manager2.port=7003 worker.manager2.host=172.23.138.19 worker.manager2.type=ajp13 worker.manager2.lbfactor=1
worker.manager3.port=7003 worker.manager3.host=172.23.136.144 worker.manager3.type=ajp13 worker.manager3.lbfactor=1 worker.Cluster2.type=lb worker.Cluster2.balance_workers=manager2,manager3 worker.Cluster2.sticky_session = 1
③バックエンドtomcatマルチインスタンスの構成スクリプトを使用してtomcatインスタンスを迅速に配置し、新しいインスタンスのAJP/1.3 Connectorのリスニングポート、HTTP/1.1 Connectorのリスニングポート、およびServerコンテナのリスニングポートを変更します.スクリプトの内容は次のとおりです.
 

#!/bin/bash 
# when:2013-01-21 
# who: [email protected] 

Java_Home=/usr/java/jdk1.7.0_10 
Tomcat_Home=/usr/local/tomcat_7 
Tomcat_User=tomcat 
New_instance=/usr/local/new 
 
if [ ! -d $New_instance ];then 
        mkdir -p $New_instance 
else 
        echo "The parh alreadly exists..." 
        exit 
fi 
 
id $Tomcat_User 2&> /dev/null & useradd -r $Tomcat_User 
 
cp -r $Tomcat_Home/conf $New_instance 
mkdir -p $New_instance/{logs,temp,webapps/ROOT,work} 
 
cat > $New_instance/tomcat.sh <
#!/bin/sh 
 
JAVA_HOME=`echo $Java_Home` 
JAVA_OPTS="-Xms64m -Xmx128m" 
CATALINA_HOME=`echo $Tomcat_Home` 
CATALINA_BASE=`echo $New_instance` 
export JAVA_HOME JAVA_OPTS CATALINA_HOME CATALINA_BASE 
 
su `echo $Tomcat_User` \$CATALINA_HOME/bin/catalina.sh \$1 
EOF 
 
cat > $New_instance/webapps/ROOT/index.jsp <
 
This is a new tomcat instance! 
 
Now time is:  
 
 
EOF 
 
chown $Tomcat_User:$Tomcat_User -R $New_instance 
バックエンドのtomcatノード1台あたりの構成状況は次のとおりです.
www.test.comの例:
manager.test.comの例:
新しいインスタンスのtomcatを使用します.shは各インスタンスを起動する
 
④マルチドメイン名のロードバランシングvim/usr/local/apache/conf/extra/http-vhostsを構成する.conf  
NameVirtualHost *:80     ServerName www.test.com     JkMount/* Cluster1     ServerName manager.test.com     JkMount/* Cluster2     JkMount/status stat
 
このマルチドメイン名マルチインスタンスに基づくtomcat負荷等化クラスタの構築が完了したらapacheを起動し、現在の構造に基づいて永続セッションマネージャ(PersistentManager)と組み合わせてセッション持続効果を実現することができます.