PAGE集團公司應用服務器中間件建設技術規(guī)范中國航天科工集團公司二〇一〇年九月PAGEI目錄TOC\o"1-5"\h\z\u1目的及范圍 12術語和定義 12.1J2EE 12.2負載均衡(LoadBalance) 12.3服務器集群 13人員崗位職責 14產品選型 24.1選用范圍 24.2基本原則與技術要求 25應用服務器中間件建設基本策略要求 25.1應用服務器中間件安裝與卸載要求 25.2應用服務器中間件配置要求 35.3應用系統(tǒng)部署要求 35.4應用服務器安全管理要求 35.4.1全局安全管理要求 35.4.2資源訪問安全管理要求 35.5應用服務器集群管理要求 46技術規(guī)范 46.1WebSphere應用服務器中間件技術規(guī)范 46.1.1應用服務器中間件安裝與卸載 4安裝準備 4應用服務器中間件安裝 7應用服務器中間件卸載 96.1.2應用系統(tǒng)部署 96.1.3性能調優(yōu) 106.1.4備份與恢復 126.2Jboss應用服務器中間件技術規(guī)范 136.2.1應用服務器中間件安裝與卸載 13安裝準備 13應用服務器中間件安裝與配置 13應用服務器中間件卸載 136.2.2應用系統(tǒng)部署 146.2.3性能調優(yōu) 146.2.4備份與恢復 167集群與負載均衡規(guī)范 167.1配置規(guī)劃基本規(guī)范 167.2集群配置內容 177.3WebSphere應用服務器集群配置規(guī)范 187.4Jboss應用服務器集群配置規(guī)范 198日常管理 208.1應用服務器性能數據監(jiān)控 208.2應用服務器升級和移植規(guī)范 208.3日志管理規(guī)范 229安全管理規(guī)范 22PAGE1目的及范圍本規(guī)范規(guī)定了中國航天科工集團公司應用服務器中間件建設的相關技術要求，重點對應用服務器管理員的日常管理活動進行規(guī)范，適用于集團公司所屬各單位應用服務器中間件建設工作，各個建設階段的過程可參照本約定執(zhí)行。術語和定義J2EE“Java2Platform,EnterpriseEdition”的縮寫，即Java2平臺企業(yè)版，是由SUN、BEA、IBM、Oracle等主要EBusiness平臺開發(fā)商合作定義的一組技術規(guī)范與指南，簡化并規(guī)范應用信息系統(tǒng)的開發(fā)與部署，提高應用可移植性、安全與再用價值，已成為工業(yè)標準。負載均衡(LoadBalance)負載均衡是由多臺服務器以對稱的方式組成一個服務器集合，每臺服務器都具有等價的地位，通過某種負載分擔技術，將外部發(fā)送來的請求均勻分配到對稱結構中的某一臺服務器上，而接收到請求的服務器可以獨立地回應客戶的請求，籍此提供快速獲取重要數據，解決大量并發(fā)訪問服務問題。服務器集群服務器集群是指將很多服務器集中起來一起進行同一種服務，在客戶端看來就象是只有一個服務器，群集化操作可以獲得很高的計算速度或減少單點故障數量，實現了群集化資源的高可用性。服務器集群分為水平集群和垂直集群兩種實現形式。垂直集群是指同一機器上部署多個服務器，充分利用硬件資源；而水平集群利用多臺機器資源，每臺機器部署相同的應用。人員崗位職責J2EE規(guī)范按照企業(yè)應用開發(fā)、部署等不同階段各類人員的不同任務分工，將各類人員分為J2EE產品提供商、工具提供商、應用程序組件開發(fā)者、應用程序組裝者、應用程序部署者和系統(tǒng)管理員等五類角色。本規(guī)范涉及的角色是應用程序部署者和系統(tǒng)管理員，負責配置和部署J2EE應用程序，在程序運行時管理計算機和網絡結構，并且監(jiān)控運行時環(huán)境，包括設置事務控制、安全屬性和指定數據庫連接等。其主要職責如下：應用服務器管理根據應用系統(tǒng)的應用范圍、發(fā)展趨勢、性能等因素，為應用系統(tǒng)規(guī)劃合適的硬件配置和合理的應用服務器中間件。規(guī)劃合理的集群配置，建立有效的負載均衡機制，提高應用系統(tǒng)的吞吐量和可用性。應用服務器中間件的安裝與卸載完成應用服務器中間件的安裝卸載，根據各類應用系統(tǒng)的需要，設置連接配置、目錄配置、Java引擎配置、會話跟蹤等全局配置參數。應用系統(tǒng)部署合理規(guī)劃各類應用系統(tǒng)部署環(huán)境，配合應用系統(tǒng)實施人員完成應用系統(tǒng)的部署工作。日常管理與性能調優(yōu)監(jiān)控應用服務器的各項性能指標，并能根據檢測結果和各項性能調優(yōu)的最佳實踐，對影響性能的相關參數進行調整，優(yōu)化應用服務器的性能。建立有效的備份與恢復機制，以便應對各種突發(fā)情況快速恢復應用系統(tǒng)。安全管理結合集團對應用系統(tǒng)安全的相關規(guī)定和應用服務器中間件提供的安全機制，制定合理的安全策略，提高應用服務器和應用系統(tǒng)的安全保護級別。產品選型選用范圍根據應用服務器中間件的市場占有率、性能和技術指標、可擴展性，是否具有外部工具的支持以及應用服務的可移植性等要求，規(guī)定應用服務器應該主要產品包括如WebSphere、WebLogic、IplanetApplicationServer、OracleIAS、金蝶Apusic、Jboss等，以及Web服務器如MicrosoftIIS、ApacheTomcat等。基本原則與技術要求集團公司各級單位應用服務器層建設應遵循如下原則要求：應用服務器層建設應遵循業(yè)界主流技術標準，以提供更寬泛的技術適應能力為原則開展中間件的選型工作，采用J2EE為主的技術體系產品，同時應兼顧在必要時能容納.Net技術體系產品。各級單位應統(tǒng)籌規(guī)劃本級單位內J2EE基礎應用服務器的軟件選型建設，將各類應用服務器軟件的種類限定在有限范圍內，包含商用和開源應用服務器在內應控制在2種以內，禁止超過3種。各級單位應在系統(tǒng)分析本級單位整體業(yè)務應用在功能訪問、性能、可靠性等方面的需求后，統(tǒng)籌規(guī)劃本級單位應用服務器層的軟硬件部署，應避免按單個業(yè)務應用進行應用服務器軟硬件部署。應用服務器中間件建設基本策略要求應用服務器中間件安裝與卸載要求安裝之前需要根據應用系統(tǒng)的需要，從內存、操作系統(tǒng)、Web服務器、Java開發(fā)組件（JDK）、JavaservletAPI、Web瀏覽器等方面的要求，結合集團技術架構的規(guī)定，選擇合適的應用服務器中間件，為應用服務器中間件的安裝規(guī)劃合理的服務器配置。文件備份。將所需要的重要文件及應用服務進行備份，防止在安裝過程中由于錯誤發(fā)生文件和應用服務丟失的情況。如果服務器上安裝過該類應用服務器中間件，新安裝前需要對原安裝進行完整卸載。對于部分保留安裝痕跡的應用服務器中間件，卸載過程包括軟件卸載、操作系統(tǒng)關鍵路徑和歷史數據清理等，不能僅刪除應用服務器中間件的相關安裝文件。應用服務器中間件配置要求根據應用服務器類型，安裝完成后需要對應用服務器管理頁面、連接池、JNDI、Java引擎、會話跟蹤、日志等全局參數進行設置。在應用服務器運行過程中，對活動會話、數據庫緩沖池使用情況、錯誤日志等數據進行收集和監(jiān)控，分析資源的實時使用情況，并根據監(jiān)控的數據，對應用服務器中間件相關參數進行調整，優(yōu)化應用服務器的性能。應用系統(tǒng)部署要求J2EE應用可以以企業(yè)應用包（EnterpriseApplicationArchive,簡稱為EAR）的形式或者是展開目錄格式的形式部署到應用服務器上。一個組件可以被打包在EJB包（JAR）文件中，也可以在Web應用包（WebApplicationArchive，簡稱為WAR）文件中，或者是資源適配器包（ResourceAdaptorArchive，簡稱為RAR）文件中。如果以展開格式的形式部署J2EE應用，則在此格式中只應包含Web應用組件。如果是以包的形式部署J2EE應用，則所有應用組件都應采用包的形式。應將一類應用盡量規(guī)劃到一個應用服務器。應用服務器安全管理要求全局安全管理要求檢查應用服務器默認的安全性配置是否符合要求。關閉不必要的訪問端口。關閉共享文件夾的普通用戶訪問權限。關閉不必要的服務。及時安裝應用服務器補丁。資源訪問安全管理要求在應用服務器配置過程中，需要對以下資源進行設置和保密，保證應用服務器安全，需要的配置包括：管理員帳戶名、密碼。登錄認證模式。根據需要配置CA登錄認證模式。操作系統(tǒng)用戶權限。為應用服務器所在的操作系統(tǒng)用戶配置合適的管理權限，防止一般用戶不經授權直接具有應用服務器管理權限。配置應用程序安全性。根據需要定義訪問控制列表（ACL）、配置應用服務器中的應用程序資源的訪問安全性。應用服務器集群管理要求根據應用的需要選擇集群形式，包括水平集群和垂直集群。集群服務應充分考慮所有可能出現的失效情況，包括HTTP服務器、Web容器、EJB容器、管理服務器和數據庫等。集群服務至少保證進程可用和數據可用。進程可用指如果一個節(jié)點上的進程出現了故障，在另一個節(jié)點上能夠恢復這個進程；數據可用是指不會因為節(jié)點故障影響它正在處理的數據。集群服務至少要為應用服務提供如下功能：簡單清晰地進行集群系統(tǒng)的拓撲管理。支持多種負載平衡算法。能夠完整地對組件狀態(tài)進行復制。在服務器出現故障時，透明地對客戶程序進行故障恢復。在不同網絡環(huán)境下支持多種通信方式。技術規(guī)范WebSphere應用服務器中間件技術規(guī)范應用服務器中間件安裝與卸載安裝準備WebSphere應用服務器中間件安裝前，需要從服務器硬件配置、操作系統(tǒng)版本、網絡配置、主機名、拓撲架構等方面規(guī)劃應用服務器安裝環(huán)境。主要內容如下：應用服務器硬件配置WebSphere應用服務器對硬件配置的要求主要體現在待部署平臺的硬件架構、CPU、內存和磁盤存儲空間上，通常最低內存要求在512M以上，根據硬件平臺、WebSphere應用服務器版本、組件的不同，要求的配置會略有區(qū)別。確認操作系統(tǒng)版本是否滿足要求使用WebSphere服務器支持的操作系統(tǒng)平臺，能確保應用服務器安裝、使用過程中環(huán)境的正常穩(wěn)定運行。如果操作系統(tǒng)平臺不是IBMWebSphere應用服務器官方支持的平臺，在WebSphere應用環(huán)境出現問題后則無法獲得WebSphere應用服務器的售后支持。確認網絡配置/主機名滿足要求主機名是WAS安裝節(jié)點的物理機器的網絡名，它必須解析到服務器上的物理網絡節(jié)點。主機名的值可以是全限定DNS主機名（例如：）、短主機名(例如：hosta)，或甚至是數字IP地址(例如：)，但必須是WAS所在服務器實際配置的主機名。建議在安裝WebSphere應用服務器之前配置主機名當WAS配置完畢投入使用之后，更改主機名的過程比較復雜，不推薦更改設定的主機名。如果采用全限定DNS主機名或短主機名，可以通過hostname命令來查看當前系統(tǒng)的主機名。如果沒有配置，則到hosts文件中添加相應的條目。選擇保持不變的主機名形式，作為WAS使用的主機名在創(chuàng)建WAS的概要文件（Profile）之前，需要根據實際情況，選擇三種形式的主機名（全限定DNS主機名、短主機名或數字IP地址)中保持不變的那種主機名形式，作為WAS使用的主機名。如果使用DHCP或者如果經常更改IP地址，建議在概要文件創(chuàng)建時使用全限定DNS主機名或短主機名。如果機器ip固定，而全限定DNS主機名或短主機名有可能更改，則在概要文件創(chuàng)建中使用數字ip。避免帶下劃線的主機名在unix/linux系統(tǒng)中經常會碰到帶下劃線的主機名，這在WAS安裝中會出現錯誤,不能正常安裝。而且不能通過單純修改主機映射的方式來修改主機名，所以在安裝操作系統(tǒng)的時候要注意避免。確認磁盤空間是否滿足要求需要從以下幾個方面來計算要預留的空間：WebSphere應用服務器自身代碼的占用空間。這個空間一般在1G左右，在不同的系統(tǒng)平臺上略有差異。應在WAS安裝目錄下預留此空間。WebSphere應用服務器在Linux下的默認安裝路徑是/opt/IBM/WebSphere/AppServer，在AIX下的默認安裝路徑是/usr/IBM/WebSphere/AppServer（后面我們把此路徑簡稱為WAS_HOME）。用戶可以在安裝WAS時修改此安裝路徑。概要文件所占的空間。WebSphere應用服務器創(chuàng)建的概要文件基本類型有3種，每個概要文件所占用的空間如下：應用程序服務器(ApplicationServer)：在WebSphere應用服務器安裝沒有選擇安裝樣本程序時，這一概要文件所占磁盤空間約為200M。DeploymentManager：30M。定制概要文件（Custom，即nodeagent）：10M。如果要安裝WEB服務器，則在WEB服務器所在服務器上要預留WEB服務器所占的磁盤空間。IBMHTTP服務器一般占用110M左右的空間。如果安裝WEB服務器，則在WEB服務器所在機器上通常也要安裝WebServerPlug-in組件，該組件所占磁盤空間約為200M。WebSphere應用服務器系統(tǒng)日志的占用空間。日志空間的估算要結合系統(tǒng)對日志的配置情況。WebSphere應用服務器的主要日志有SystemOut.log、SystemErr.log。可設置日志文件的大小和保存的歷史日志文件數量，從而可以估算出其需要的空間。如果有WEB服務器，需考慮WEB服務器的日志空間。如果客戶開啟了WEB服務器的訪問日志access.log（默認開啟），此日志增長的速度極快，要預留足夠的空間。備份文件需要的空間。WebSphere應用服務器提供了一個備份命令（backupConfig.bat/sh），用來備份應用服務器的配置及其上應用。建議在系統(tǒng)穩(wěn)定之后及時備份。對于一個典型生產系統(tǒng)，WebSphere應用服務器這個配置文件經常超過100M?？稍诎l(fā)出backupConfig命令時，使用-logfile參數指定該備份文件的存放位置。系統(tǒng)出錯時日志，例如JVM在發(fā)生OutOfMemory時，在大多數平臺上WebSphere應用服務器會默認寫javacore文件和heapdump文件，記錄錯誤出現時的JVMHeap、線程情況，以備錯誤診斷使用。雖然可以調整應用服務器參數使之不產生此類文件，但為了分析問題，通常需要從此類文件入手。這類文件通常都特別大，例如heapdump文件，可能達到幾百M。如果多次出現OutOfMemroy，對磁盤空間的占用很快。因此，必須考慮為此類文件預留磁盤空間。WAS安裝程序還需要在系統(tǒng)的臨時目錄（tmp）中有100M以上的空閑空間。用戶發(fā)布到WebSphere應用服務器上所有應用程序以及應用自身的應用日志的占用空間。這個大小與實際應用相關，而且不同應用可以差別很大。針對特定操作系統(tǒng)的調整WAS對特定的操作系統(tǒng)版本安裝的包、內核參數等有特殊要求。例如，對于RHELAS4，必須安裝compat-libstdc++-33-3.2.3-47.3.ppc.rpm包（這是保持C++運行時兼容性所必需的，供諸如GSKit的組件、Java2軟件開發(fā)包（SDK）以及Web服務器插件使用）以及其他一些包。對于Linux、Solaris、HP等系統(tǒng)，需要調整一些相應的內核參數。對于Linux/Unix系統(tǒng)，確認能啟動圖形界面在Linux/UNIX平臺的服務器安裝WAS，需要在服務器預先安裝Xmanager、X-Win32等支持XWindow的工具軟件，以支持啟動圖形界面。準備合適的安裝介質在unix/linux上是32位、64位的安裝的介質是不同的，在64位的系統(tǒng)上一樣可以按照32位的WAS。兩者的安裝方式是相同的，但是在后期管理中如果想要使用圖形方式來管理profile，在64位上是不支持的，在64位上的profile管理只能使用命令行。所以在安裝的時候需要注意版本的問題，應從訂購的WAS產品包（包括各個平臺、組件的多張CD）中根據安裝的WAS組件、操作系統(tǒng)版本、操作系統(tǒng)位數選擇需要的安裝介質。設計WebSphere環(huán)境的拓撲架構根據實際應用場景的不同，規(guī)劃WAS、Web服務器的網絡拓撲結構，如果需要配置集群環(huán)境，還需要考慮DeploymentManager、各個結點和集群成員的分布情況。拓撲結構圖中應該描述服務器的分布情況、集群的構成、每臺服務器實際安裝、配置的組件等信息。應用服務器中間件安裝安裝WAS的過程主要包括安裝WAS產品、為產品打補丁、創(chuàng)建概要文件等3個步驟。安裝過程如果服務器上曾經安裝過WAS產品，安裝WAS產品之前，需要停掉正在運行的WAS進程。避免HttpServer的沖突。安裝過程中需要注意原有環(huán)境中是不是已經有了HTTPServer并且已經安裝的Server是不是占用了80端口。安裝過程中應該將本地操作系統(tǒng)語言設置為中文。如果發(fā)現向導中語言顯示為亂碼，可以先把本地操作系統(tǒng)語言設置為英文，使用英文語言安裝WAS，這樣安裝完畢的WAS仍然具有中文支持。建議不要安裝樣本應用程序，以在開發(fā)環(huán)境和生產環(huán)境中都能獲得更高性能。通過省略樣本，可以將應用程序服務器啟動時間縮短60％并節(jié)省15％的磁盤空間；可以節(jié)省相當程度的進程占用量；并且可以節(jié)省WAS產品安裝以及每次創(chuàng)建應用服務器概要文件的時間。建議在打完補丁后再創(chuàng)建初始概要文件，以節(jié)省打補丁所需的時間。打補丁建議先在測試環(huán)境中安裝補丁，確認安裝的補丁不會對運行環(huán)境帶來負面影響，再將補丁安裝到生產環(huán)境中。經過了適當的測試后，主動地安裝預防補丁，將避免一些可能導致系統(tǒng)出故障的問題。WAS補丁的命名規(guī)范為：版本名-產品名-產品組件名-平臺名-補丁編號名.pak。對于同樣補丁編號的補丁，建議先裝WASSDK補丁，再裝WAS補丁。打補丁的具體步驟如下：把補丁文件拷貝到補丁工廠安裝目錄的maintenance目錄下。在補丁工廠的安裝目錄下，執(zhí)行./update.sh命令啟動補丁工廠。在“安裝目錄”中選擇將要打補丁的組件的安裝目錄。通常，對WAS組件，補丁會自動識別出安裝位置；對于IBMHttpServer（簡稱IHS）或者Plug-in這樣的組件，需要選擇正確的安裝位置。在maintenancepackageselection頁面中選擇想要打的補丁。創(chuàng)建概要文件概要文件是一組用于定義運行時環(huán)境的文件，每個概要文件都是一組完全隔離的運行時環(huán)境。創(chuàng)建概要文件應該注意如下事項：概要文件創(chuàng)建有兩種方式，圖形化創(chuàng)建向導和命令行方式。如果用命令行方式，必須注意命令和參數是大小寫敏感的。建議在一個cell(Cell指WAS多個實例組成的一個受管域)中使用同一種類型的主機名(全限定名稱、短名稱、數字IP地址)，不要混用多種名稱方式。應該根據需要選擇創(chuàng)建適用于開發(fā)環(huán)境或生產環(huán)境使用的應用服務器實例。在開發(fā)環(huán)境，應該選擇“使用開發(fā)模板”來創(chuàng)建服務器；在生產環(huán)境中，不要選擇“使用開發(fā)模板”。概要文件創(chuàng)建過程應該選擇“啟用管理安全性”，讓用戶在進行登陸管理控制臺、停止WAS實例等管理任務時需要輸入用戶名、密碼。應該根據需要修改概要文件所占的port，避免端口沖突。其他注意事項JDK的版本：在WAS中所帶的JDK是IBM的,不要用SUN或者其它公司的JDK去替換它。雖然它們的接口相同,但是底層實現并不同，效率也不同。所以安裝后在檢測某些java應用程序時候，要注意使用的JDK。安裝后要及時\o"備份"備份配置信息。WAS提供的backupConfig命令可以將配置信息方便地進行\(zhòng)o"備份"備份。升級時要注意UpdateInstaller工具的版本升級WAS需要使用UpdateInstaller這個工具，對于不同版本的WAS需要注意的是要用不同版本的UpdateInstaller，不同版本的UpdateInstaller互相之間不兼容。升級產品WAS的升級過程包含多個方面的升級，應該根據實際需要來進行的。特別是升級ApplicationServer本身并不包括相應的JDK的升級，而是分為兩個不同的升級包。應用服務器中間件卸載WebSphere禁止通過直接刪除WebSphere安裝目錄的方式卸載，否則將不能再次成功安裝WebSphere。在卸載WAS之前，必須先停止機器上的WAS進程。做好應用系統(tǒng)的程序備份。卸載WAS的主要步驟如下：用ps–ef|grepjava確保沒有was進程在運行。執(zhí)行WAS_HOME/uninstall/uninstall.sh命令卸載WAS。應用系統(tǒng)部署在WebSphere上部署應用系統(tǒng)的主要任務是配置應用所需要的環(huán)境和資源。環(huán)境配置的內容包括系統(tǒng)變量、虛擬主機、類路徑、安全性等，資源配置的內容包括JMS資源、數據源等。在應用系統(tǒng)部署過程中應該注意如下事項：應用打包部署在WebSphere應用服務器上的應用可以是打包的*.ear、*.war文件，也可以是未打包但符合J2EE規(guī)范要求的組件。在生產環(huán)境中，建議使用打包的*.ear、*.war文件，便于版本控制和管理。合理放置公用的UtilityJar包，避免Jar包沖突禁止在同一個類載入路徑下存在同一個類的多個版本，否則會在實際運行中帶來很多莫名其妙且難以診斷的問題。對于JDBC驅動這類通用等級較高的UtilityJar包，建議放置在<WAS_HOME>/lib/ext目錄下。對于多個應用共享的UtilityJar，建議放在sharedlibrary（共享庫）中。共享庫的使用能夠避免UtilityJar包多個版本的混亂，以及UtilityJar包的沖突。對于單個應用使用的UtilityJar，可與應用打包在一起，或放入sharedlibrary中。合理設置會話超時時間和會話級別應該針對不同的應用場景，為會話設置合理的超時時間和會話級別。WebSphere應用服務器的會話管理分為Applicationserver、Application、WebModule三個級別。部署在WebSphere應用服務器上的應用，默認的會話超時時間為30分鐘，默認的會話管理級別是ApplicationServer。通過應用編程接口實現J2EE應用的部署和管理當應用程序要運行在同一個WebSphere應用服務器上，而且其中涉及到的EJB組件、JNDI名修改和資源（引用）修改較多時，建議通過應用編程接口實現J2EE應用的部署和管理，避免通過手工完成部署。性能調優(yōu)部署在WAS上的J2EE應用程序，其性能是由多個因素決定的。例如網絡、數據庫、\o"內存"內存分配、WAS服務器的配置以及應用程序的設計。對于一個標準的J2EE應用，一個請求的完成需要經過多次轉發(fā)：網絡>Web服務器>Web容器>EJB容器>數據庫。而每一次轉發(fā)，都可能造成請求處理的瓶頸，使得應用程序整體性能下降。在生產環(huán)境中安裝完畢WebSphere，必須根據實際情況進行必要參數的調整，以便提高WAS性能、方便錯誤診斷。參數的調整需要綜合考慮運行環(huán)境的實際情況、實際的并發(fā)量和服務器的資源利用情況等因素，調優(yōu)的內容涉及操作系統(tǒng)、應用、應用服務器和數據庫等的綜合調整。對于WAS調優(yōu)的一個基本原則是：使得在隊列中等待的請求數量最小化。所以建議的配置方式是使得隊列成為一個“漏斗”，即越靠近客戶端的隊列，其容量越大，而后面的隊列，其容量要略小于或等于前面的隊列。按照這個原則，調優(yōu)的基本步驟如下：啟用servlet高速緩存建議在Web容器配置選項中啟用servlet高速緩存。設置WebServer的最大并發(fā)用戶數在文件conf/httpd.conf中配置WebServer的最大并發(fā)用戶數。在Unix系統(tǒng)中，對應的屬性是MaxClient；在Windows系統(tǒng)中，對應的屬性是ThreadsPerChild。配置線程池線程池使服務器的組件能重用線程以消除在運行時創(chuàng)建新線程的需要。應該根據觀察的性能情況和應用情況設置合適的最小進程數、最大進程數、線程不活動超時等選項。最小線程數指定池中允許的最小線程數（缺省值10）。最大線程數指定池中允許的最大線程數。該值一般設置為等于峰值壓力下應用在線用戶數大小。缺省值50，如果硬件資源允許，建議把線程池的最大值調到100。線程不活動超時指定在收回空閑線程之前應該等待毫秒數。為“0”的值表明不等待，而負值（小于0）意味著永遠等待。單位是毫秒，缺省值為3500。可增長的線程池指定線程數是否能增加至超過為線程池配置的最大線程數。有效值是允許線程分配超過最大線程大小或“未啟用”。缺省值是未啟用。設置對象請求代理（ORB）的線程池大?。涸诠芾砜刂婆_中點擊應用程序\o"服務器"服務器>server1>ORB服務>線程池，根據觀察的性能情況和應用情況輸入合適的最小、最大進程數。設置數據庫的連接池屬性連接池的大小影響著服務器資源的占用情況。若連接池過大，則會長期占用服務器可利用資源，JVM有限的資源都耗費在維護連接池、處理與數據庫連接上，造成WAS性能的下降。若連接池過小，則無法滿足現場環(huán)境應用高負載使用的壓力。默認大小為1到10。根據資源設置的隊列(Queue)原則，從Web容器線程池，到數據源連接池的參數設置，應該是從大到小的管道。假如Web容器線程池的最大值設置100，對于數據源連接池，設置的最大值建議不超過50，多數情況下調整為30。實際運行中可以修改此參數值，評估調整對性能造成的影響。Java虛擬機設置設置JVM堆參數控制JVM代碼可使用的堆大小。JVM堆的最大值默認是256M，在生產環(huán)境中通常要根據機器物理內存情況、應用運行特性來設置，且多數情況下都要把此參數調大。內存充足時，建議調整在500M到1024M之間。如果JVMHeapSize過大，可能會引起內存分頁，或者造成JVM垃圾回收時間過長，影響應用服務器性能。對于32位系統(tǒng)，建議JVMHeap的最大值不要超過1024M，對于64位系統(tǒng)，根據應用情況具體設置（可以通過使用verbose:gc參數，設置監(jiān)控垃圾收集分析GC性能調整）。啟用JIT編譯器指定是否禁用JVM代碼的JustinTime（JIT）編譯器選項。如果禁用JIT編譯器，吞吐量明顯減少。因此，出于性能原因，建議保持JIT啟用。ORB參數調用方式的性能調優(yōu)應用程序\o"服務器"服務器>server1>ORB服務>選中按引用傳遞。關閉動態(tài)加載開關企業(yè)應用程序>應用名稱>關閉啟動類重新裝入開關。關閉會話序列化應用程序\o"服務器"服務器>server1>會話管理>分布式環(huán)境設置>分布式會話選擇無即可。WAS進程日志參數WAS進程日志常用的有SystemOut.log和SystemErr.log。這兩份日志默認大小為1M，歷史日志文件數為1份。在生產環(huán)境中，這樣的設置通常不足以充分保存發(fā)生問題時的錯誤信息。我們可以通過修改日志默認大小、歷史日志文件數來保存更多的信息。不要把單份日志文件大小設置過大（例如，超過10M以上），否則可能影響WAS性能。建議把應用日志與WAS日志分離開。如果應用中大量以System.out.print或者System.err.print來保存應用狀態(tài)日志，也可能會影響服務器性能。Heapdump文件Heapdump文件對磁盤空間占用很快，建議設置IBM_HEAPDUMP參數把Heapdump文件存放到指定目錄下。Web服務器的訪問日志access.logIBMHttpServer的訪問日志access.log默認是打開的，其中記錄了經過Http服務器的請求信息。在高并發(fā)的系統(tǒng)中，這一日志增長非?？?，當日志過大時，可能占用過多磁盤空間或引起性能下降，如果不需要該日志，或者有其他技術手段保存用戶訪問信息，建議關閉該日志。性能監(jiān)控服務在不需要進行性能檢測或者有其他工具監(jiān)控應用服務器性能的情況下，建議停止WAS\o"服務器"服務器的性能監(jiān)控服務。優(yōu)化應用程序的設計除利用WAS\o"服務器"服務器參數的調整來優(yōu)化應用程序的性能外，應用程序的性能好壞很大部分是取決于應用的設計。一般說來，性能調優(yōu)大概可以提高10％－40％效率，而不合理的代碼設計卻會使得性能幾倍的下降。備份與恢復WebSphere應用服務器需要備份的內容主要包括服務器概要文件配置的備份和業(yè)務系統(tǒng)的備份。生產環(huán)境、概要文件配置過于復雜或經常更改時，建議定期備份概要文件。業(yè)務系統(tǒng)的備份需要注意版本問題?？梢酝ㄟ^集群實現備份，也可以由管理員人工備份。Jboss應用服務器中間件技術規(guī)范應用服務器中間件安裝與卸載安裝準備在生產環(huán)境建議安裝二進制發(fā)布版，在開發(fā)環(huán)境建議安裝源代碼發(fā)布版。必須根據實際的操作系統(tǒng)平臺選擇適合相應平臺的安裝程序。需要在機器上使用合適版本的JDK。建議至少使用JDK1.4以上的版本。正確設置環(huán)境變量JAVA_HOME。應用服務器中間件安裝與配置在Jboss的安裝過程中需要注意以下事項：安裝目錄的完整路徑（比如，Windows操作系統(tǒng)中的ProgramFiles目錄）上不能夠含有空格。規(guī)劃JBoss各項服務的端口，避免端口沖突。建議將JBoss安裝成系統(tǒng)服務。當目標機器啟動時，JBoss將作為服務或者后臺應用運行。建議刪除不需要使用的組件，減少服務器的啟動時間。根據需要選擇合適的服務器實例配置(all、default以及minimal)或定制服務器實例配置。建議按照如下方式定制服務器實例配置：拷貝最接近用戶需求的現有配置，然后修改其具體內容。比如，如果不需要使用消息服務，則只需要拷貝default目錄，并重新命名為myconfig，然后刪除jms子目錄。最后，啟動myconfig配置。建議將安全性域添加給JMX控制臺應用。通過JMX控制臺基本上能夠控制JBoss服務器的各個方面，因此應該將安全性域添加給該控制臺。建議在perties文件中刪除admin用戶或修改該用戶的密碼。為提高Jboss的安全性，建議關閉jmx-console、web-console以及status統(tǒng)計信息，刪除jboss主頁相關的目錄和文件。應用服務器中間件卸載在卸載Jboss之前，必須先停止機器上的相關進程。做好應用系統(tǒng)的程序備份。刪除安裝目錄下的相關文件。刪除相關的環(huán)境變量.應用系統(tǒng)部署Jboss支持熱部署，只需要將EAR文件拷貝到deploy目錄即可。如果應用已經部署，則可以通過覆蓋相關的包來再次部署它。如果需要卸載應用，只需要將相應的存檔從deploy目錄刪除即可，JBoss服務器始終不需要重啟。部署過程需要妥善解決包沖突和應用程序的版本問題。性能調優(yōu)通過適當的參數調整、關閉不必要的服務，可以提高JBoss服務器的服務性能。參數調整調整JVM的參數修改JVM配置參數可以在啟動腳本run.sh/run.cmd下實現。建議如下：建議JDK使用JDK1.5以上版本。JDK5在垃圾收集方面比1.4有顯著的改善。在x86硬件建議使用BeaJRockit虛擬機。建議使用64位的機器和支持64位的虛擬機來提供比通常2-4GB更大的堆。如果應用不需要32位地址（2-4GB）以上的堆空間，建議不要使用-d64（64位支持的選項）。使用64位地址，在完成相同任務的情況下需要更多的內存，而且不能夠為應用帶來任何好處。合理設置堆空間的大小。堆空間的大小影響代式垃圾的收集和掃描堆的時間。在堆空間較小的情況下，很難有效地進行性能調優(yōu)；但是過大的堆空間將會在垃圾收集時需要更長的時間來掃描堆空間。在-server選項中建議將TheadStackSize設置為-Xss128k或以上，可以使線程使用更少的內存作為棧，從而能夠創(chuàng)建更多的線程。但是在運行復雜的遞歸代碼時?？臻g的減少將可能導致棧溢出。通過負載測試（OpenSTA、JMeter等）來選擇合適的垃圾收集器。建議使用多余2個處理器的多處理器計算機，并采用并行和并發(fā)的垃圾收集選項來獲得最佳性能和更高的垃圾收集吞吐量。

如果使用JDK1.4，建議調整JDK的NewSize的缺省值為小于20%，設置為大于20%將非常危險，可能引起虛擬機錯亂地進行完整的垃圾收集（fullgarbagecollection）,并且不會休眠或釋放足夠的空閑內存。JDK5已經修正了這個Bug，而且在缺省值的設置上更加合理。數據庫連接池的配置建議將訪問數據庫的方式設置為使用數據庫“連接池”，避免使用“單連接”方式訪問數據庫。應該根據系統(tǒng)的并發(fā)數、數據庫的處理能力及數據庫并發(fā)連接數等確定合適的最大連接數。建議在數據源中指定最小連接數等于最大連接數。調整Tomcat的參數修改server.xml、web.xml文件中的相關參數。建議如下：設置maxThreads為一次性并發(fā)訪問最大預期值的25％以上。如預期的最大并發(fā)數為200，則maxThreads至少應該設置為50。監(jiān)控應用的正常負載，設置minSpareThreads的值恰好比正常負載多一點。監(jiān)控應用的峰值負載，設置maxSpareThreads的值恰好比峰值負載多一點。移除任何不需要的值和日志。生產環(huán)境中，建議在web.xml文件中里關閉development（開發(fā)）模式。調整RMI遠程調用的參數默認情況下,JBoss為每個RMI請求創(chuàng)建一個新線程。建議將RMI轉向被集中的池.調整日志的參數建議將日志跟蹤級別改變?yōu)镋RROR(或者WARN)。建議關閉將日志打印到控制臺選項。調整部署掃描器的參數如果將部署掃描的掃描間隔時間設置為5秒，將給服務器帶來一定負擔。在應用服務器上不需要頻繁部署新應用的情況下，建議將掃描間隔時間設置為較大值。關閉不必要的服務應該根據需要關閉不必要的服務，可以關閉的服務主要包括：mail-service服務(J2EE標準的JavaMail客戶端)緩存失效服務J2EE客戶端部署服務。集成HAR部署和Hibernate會話管理服務HypersonicJBossMQ(JMS服務器)HTTPInvokerXA數據源(分布式and/or可恢復的事務)

JMX-Consoleweb-console控制臺/email監(jiān)控警報如果不需要部署EAR文件，從server/slim/conf/jboss-service.xml文件刪除或注釋相關XML片段。

如果不需要JMS對列，從server/slim/conf/jboss-service.xml文件刪除或注釋相關XML片段。

如果不需要CORBA/IIOP，從server/slim/conf/jboss-service.xml文件刪除或注釋相關XML片段。

如果不需要client-side事務管理，從server/slim/conf/jboss-service.xml文件刪除或注釋相關XML片段。如果不使用RMI類裝載器（在服務器上利用classes從客戶端裝載代碼），從server/slim/conf/jboss-service.xml文件刪除或注釋相關XML片段。如果不使用JBossSX（為EJBs或者Web層組件繼承的基于JAAS的安全），從server/slim/conf/jboss-service.xml文件刪除或注釋相關XML片段。如果不使用BeanShelldeployer，從server/slim/conf/jboss-service.xml文件刪除或注釋相關XML片段。如果不使用熱部署文件到server/slim/deploy文件夾，而從外部重啟JBoss,則從server/slim/conf/jboss-service.xml文件刪除或注釋相關XML片段。如果不使用集群，建議從"default"配置啟動，而不是使用"all"配置啟動。備份與恢復Jboss應用服務器需要備份的內容主要包括：配置文件server.xml、web.xml的備份。業(yè)務系統(tǒng)的備份。集群與負載均衡規(guī)范集群(Cluster)由一組應用服務器組成，它們作為一個整體向用戶提供一組網絡資源，每個服務器上部署同樣的應用程序。集群對用戶是透明的，用戶由單一入口訪問集群的資源，而不會意識到集群中的節(jié)點。從用戶應用的角度，集群是一個系統(tǒng)，而非多個計算機系統(tǒng)。通過集群可以實現可擴展性（服務更多客戶，提高吞吐量）、負載均衡（平衡負載資源，使資源得以有效利用）、高可用性（提供故障恢復和補償機制，在關鍵性業(yè)務中提供容錯功能）。配置規(guī)劃基本規(guī)范在規(guī)劃集群配置時，應該注意以下關于網絡環(huán)境與集群配置的限制。集群中服務器必須保證主機名正確。如果主機名采用數字IP地址，則主機必須使用靜態(tài)IP地址。動態(tài)IP地址分配不能用于集群環(huán)境。如果服務器位于防火墻后面，而客戶機位于防火墻前面，那么服務器必須有公共的靜態(tài)IP地址，只有這樣，客戶端才能訪問服務器。集群中的所有服務器必須位于同一個局域網，并且必須是IP廣播可到達的。集群中的所有服務器必須使用同類應用服務器中間件的相同版本。對于使用了JDBC連接的EJB，所有分發(fā)了某EJB的服務器必須具有相同的分發(fā)與持久化配置。也就是說所有服務器都應該有相同的JDBC配置。所有分發(fā)了servlet的主機必須維護一組具有相同ACL的servlets。如果客戶端應用直接使用JDBC連接池，則必須為每個應用服務器創(chuàng)建相同的連接池（并具有相同的ACL）。即集群所使用的連接池應該在所有的機器上創(chuàng)建。例如，一臺運行應用服務器中間件的NT服務器配置了連接MicrosoftSQLServer數據庫的連接池，那么一個包含非Windows機器（即不支持MicrosoftSQLServer連接的機器）的集群不能使用這個連接池。集群中的每個應用服務器在所有與服務、類文件以及外部資源（例如數據庫）相關的方面應該具有相同的配置。為保持同步，確保集群中的每個應用服務器的時區(qū)、時間一致，建議誤差控制在秒級。集群配置內容在完成集群配置后，應用服務器管理員需要根據應用的實際情況，完成主服務器、成員服務器的相關配置。應用服務器管理員根據各類應用服務器中間件軟件的特點，集群配置的主要任務包括：集群配置配置集群服務器?？梢耘渲玫膶傩园–lusterName,ClusterListenPort以及集群中的服務器名?？寺∫粋€集群?？寺〉姆掌髋c原服務器具有相同的屬性設置，包含同樣的服務器。需要對新集群的名字進行重新設置。監(jiān)控集群中的服務器。為集群分配服務器。刪除集群。服務器配置：配置單獨的服務器。需要配置的屬性包括名字，監(jiān)聽端口與IP地址?？寺∫粋€成員服務器?？寺〉姆掌鞅４媪嗽瓉矸掌鞯膶傩灾?，需要配置新服務器的名字。刪除成員服務器。查看服務器的日志、JNDI樹、執(zhí)行隊列、serversockets、服務器連接。使用管理控制臺的Server節(jié)點進行強制垃圾收集。監(jiān)控服務器的安全。安全信息包括無效登錄的統(tǒng)計信息，被鎖用戶的統(tǒng)計信息與開啟用戶的統(tǒng)計信息等。查看服務器的版本。分發(fā)EJB。監(jiān)控分發(fā)在某一服務器上的所有EJB。將web應用組件分發(fā)在某一服務器上。監(jiān)控某一服務器上的所有web應用組件。在服務器上分發(fā)啟動與終止類。分配web服務器。為服務器分配JDBC連接池。監(jiān)控某一服務器的JDBC連接池。為服務器分配JMS服務器、連接工廠以及消息收信方。分配郵件會話。WebSphere應用服務器集群配置規(guī)范應該從需求、成本、管理復雜性、故障恢復時間等因素綜合考慮集群配置方案。搭建集群的Websphere應用服務器必須選擇WebsphereApplicationServerNetworkDeployment版本,簡稱WASND版。建議避免在異構平臺上創(chuàng)建WAS集群，避免使用絕對路徑異構操作系統(tǒng)的目錄格式不同，產品的缺省安裝目錄也不同，建議避免在異構平臺上創(chuàng)建WAS集群。如果在異構平臺上創(chuàng)建WAS集群，在資源配置和應用部署中，應當避免使用絕對路徑，而采用通用的節(jié)點作用域WebSphere變量來替代，然后根據每個節(jié)點的實際情況來對該變量賦值。配置集群前應先對管理節(jié)點和被聯合節(jié)點的各類概要文件作備份。在備份概要時，進程會停止，在成功備份完成后，需要手工重啟進程。根據WAS組件種類的不同，FixPack的種類也有所不同，各組件FixPack的版本應該保持一致。FixPack和FeaturePack的安裝應該嚴格按照其發(fā)布的時間順序依次疊加安裝。集群中的機器應該能互相解析機器名。需要分別在Windows和Linux機器上修改hosts文件。建議更新集群中各臺主機的hosts文件（默認目錄為/etc/hosts），確保每臺機器均包含對方的hostname和對應的IP地址，以便主機間的相互訪問。如果系統(tǒng)在Linux或Unix上，請編輯/etc/hosts文件以將localhost注釋掉，并添加帶主機名稱的實際IP地址。如果在windows平臺配置集群，在配置過程中建議選中“將應用服務器進程作為windows服務運行”選項。在設計和開發(fā)運行于WAS集群環(huán)境的應用程序時需要從文件同步，會話管理和動態(tài)緩存等方面考慮集群對應用程序的影響。在集群中部署應用系統(tǒng)應該注意以下內容：建立數據源時要選擇作用域范圍為集群范圍；集群控制臺中，做了配置修改后要同步各個節(jié)點，建議在系統(tǒng)管理->控制臺首選項中勾選上選擇同步節(jié)點項，以保證每次更改會自動同步各個節(jié)點；Jboss應用服務器集群配置規(guī)范Jboss負載均衡架構由負載均衡器和N個集群節(jié)點組成。每個節(jié)點是一個JBoss服務器實例。負載均衡器是全局唯一的前置機，全部用戶請求都發(fā)到負載均衡器，由其轉發(fā)到各節(jié)點。當負載均衡器發(fā)現一個節(jié)點失效后，會將請求轉發(fā)到另一個節(jié)點上，從而保證服務得以延續(xù)。負載均衡方案Jboss的負載均衡目前有兩種方案，一是使用apache的mod_jk，二是使用Jboss自帶的負載均衡模塊。Jboss自帶的負載均衡器的缺點是負載能力相對不高，配置參數少。建議采用apache+mod_jk作為負載均衡器。負載均衡的粒度可以選擇針對每個request的均衡，或者是針對每個用戶的均衡。應該根據不同的應用需要選擇不同的負載均衡粒度。在無特殊要求的情況下，建議采用基于用戶的負載均衡。基于request的負載均衡該種方式下，負載均衡器根據各個集群節(jié)點的狀況，把每個httprequest進行分發(fā)。使用這樣的均衡策略，就必須在多個節(jié)點之間復制用戶的session，實時保持整個集群的用戶狀態(tài)同步，這種操作被稱為session復制(sessionreplication)。該方式的優(yōu)點是客戶不會被綁定都具體的集群節(jié)點，只要還有一個服務器節(jié)點存活，用戶狀態(tài)都不會丟失，集群都能夠繼續(xù)工作。缺點是集群節(jié)點之間通信頻繁，對響應速度有影響，多并發(fā)、高頻操作的情況下性能下降比較厲害。基于request的負載均衡有兩種session復制模式，同步與異步。使用同步的方式，jboss會把session復制的操作和對request的響應放到一個應用事務，session復制完成后才處理request。異步復制則發(fā)送session復制的消息后馬上處理request，session復制則會稍有延遲。但是在多框架的web頁面中，這樣的集群方式會有問題。由于frame在同一時間發(fā)出多個request，會造成一些混亂?；谟脩舻呢撦d均衡該種方式下，當用戶發(fā)出第一個request后，負載均衡器動態(tài)的把該用戶分配到某個節(jié)點，并記錄該節(jié)點的jvm路由，以后該用戶的所有request都會被綁定這個jvm路由，用戶只會與該server發(fā)生交互，這種策略被稱為粘性session(sessionsticky)。該方法的優(yōu)點是響應速度快，多個節(jié)點之間無須通信。缺點是某個集群節(jié)點死掉以后，它負責的所有用戶都會丟失session。合理設置負載加權集群節(jié)點的負載加權值越大，獲得負載的機會就越大，應該根據集群節(jié)點的硬件性能合理分配各節(jié)點的負載加權值。日常管理應用服務器性能數據監(jiān)控應用服務器管理員需要運用相關監(jiān)控工具對應用服務器性能及運行狀況等參數進行監(jiān)控，并記錄、分析相關數據，根據應用服務器特點進行相應的調整。為各類監(jiān)控參數設置合理的預警值，提高系統(tǒng)的可用性。主要監(jiān)控的數據有：服務器信息，如CPU使用狀態(tài)、內存使用狀態(tài)、啟動時間、無效登錄、堆的狀態(tài)、套接字的數量、服務器重啟次數等。性能數據，包括JVM內存堆使用狀況、請求對象與等待請求的實時數據等。集群的信息（例如集群中有多少服務器處于活動狀態(tài)）。服務器安全信息，如無效登錄的統(tǒng)計信息，被鎖用戶的統(tǒng)計信息與開啟用戶的統(tǒng)計信息。JMS對象的統(tǒng)計信息：JMS服務器、連接、會話、收信方、消息生產者、消息使用者以及服務器會話池。JTA的統(tǒng)計信息，如有關事務與所有回滾的統(tǒng)計信息。JDBC連接池信息，對Java數據庫連接（JDBC）子系統(tǒng)實行監(jiān)控，如JDBC連接池的初始容量、容量增量、JDBC多池的負載平衡等相關數據。連接服務器的相關數據，如連接時間、遠程地址、所發(fā)送的字節(jié)數與接收到的字節(jié)數。有關Web應用的統(tǒng)計數據，如最大池容量以及最長的執(zhí)行時間。服務器的各類日志文件。應用服務器升級和移植規(guī)范在應用服務器版本的升級過程中，系統(tǒng)管理員在保證應用穩(wěn)定運行的情況下通過合理的升級和移植策略降低系統(tǒng)宕機時間。WebSphere提供本地升級（In-placeupgrade）和版本移植(Version-to-Versionmigration)兩種形式的運行時升級支持，Jboss尚未提供完整的升級和移植策略。本規(guī)范主要對WebSphere的升級和移植進行規(guī)范。本地升級本地升級是通過更新已有的WAS安裝目錄下的文件來實現的，以單個的WAS安裝目錄為單位，每次本地升級操作會將某一個安裝目錄下所有的概要文件（Profile）、節(jié)點（Node）和服務器（Server）進行更新。已部署的應用程序可以在更新后的系統(tǒng)上繼續(xù)運行，無需進行任何更改或重新配置操作。版本移植版本移植以單個概要文件為操作單位，依次進行。移植工具將低版本WAS概要文件上的應用程序及配置信息備份到本機的一個臨時目錄，將其中的應用程序自動安裝到新版本的WAS概要文件上，并根據臨時目錄中已保存的配置信息對新版本概要（Profile）進行相應配置。移植完成后，原有的WAS系統(tǒng)可以被完全卸載也可以原封不動，但