TuxedoDesignPatternPAGEBEA(中國(guó))系統(tǒng)有限公司上海代表處第22頁(yè)共22頁(yè) BEA(中國(guó))系統(tǒng)有限公司上海辦事處二○○二年一月，上海

修訂日志日期版本作者描述2001-12-261.0王玉亭最初的第一版本2002-11.1王玉亭重新調(diào)整框架，充實(shí)內(nèi)容

目錄TOC\o"1-3"\h\z第一章. 導(dǎo)論 51.1企業(yè)應(yīng)用框架架構(gòu)的演變和發(fā)展 51.1.1聯(lián)機(jī)事務(wù)處理系統(tǒng)(OLTP)的特點(diǎn)和要求 51.1.2企業(yè)OLTP框架的演變歷史 51.2Tuxedo的歷史發(fā)展 5第二章. Tuxedo體系結(jié)構(gòu)和設(shè)計(jì)思想 82.1Tuxedo整體結(jié)構(gòu)和各個(gè)組成部分 82.1.1Tuxedo整體結(jié)構(gòu) 82.1.2Tuxedo服務(wù)器端 82.1.3Tuxedo客戶(hù)端 82.1.4Tuxedo的Domain 82.1.5Tuxedo的Q 82.1.6Tuxedo的安全 82.1.7Tuxedo的管理框架 82.2Tuxedo高可靠性的設(shè)計(jì)思想評(píng)述 8節(jié)點(diǎn)之間的監(jiān)控 9進(jìn)程的狀態(tài)檢查 10網(wǎng)絡(luò)連接 10Tuxedo對(duì)事務(wù)的控制 112.3Tuxedo高擴(kuò)展性的設(shè)計(jì)思想評(píng)述 112.4Tuxedo高性能的設(shè)計(jì)思想評(píng)述 11第三章. Tuxedo應(yīng)用的設(shè)計(jì)原則和經(jīng)驗(yàn) 12如何劃分Tuxedo的Server和Service? 12規(guī)則一：詳細(xì)注釋每個(gè)Service 13規(guī)則二：區(qū)分Service的不同類(lèi)型：Business和DataAccess 14使用XA時(shí)候需要考慮的問(wèn)題 14Tuxedo七種通訊方式的選擇 14Tuxedo超時(shí)機(jī)制 14內(nèi)核參數(shù)的調(diào)整 14如何在Tuxedo中使用各種開(kāi)發(fā)工具 15第四章. 基于Tuxedo設(shè)計(jì)企業(yè)關(guān)鍵業(yè)務(wù)應(yīng)用 16如何做到高性能 16如何做到高穩(wěn)定性 16如何做到高擴(kuò)展性 16第五章. Tuxedo應(yīng)用系統(tǒng)容量配置 17第六章. Tuxedo設(shè)計(jì)案例 18某銀行省級(jí)大集中案例 18設(shè)計(jì)目標(biāo) 18系統(tǒng)構(gòu)架 18應(yīng)用要點(diǎn) 18某電信省級(jí)計(jì)費(fèi)系統(tǒng)案例 18設(shè)計(jì)目標(biāo) 18系統(tǒng)構(gòu)架 18應(yīng)用要點(diǎn) 18某證券公司集中交易案例 18設(shè)計(jì)目標(biāo) 18系統(tǒng)構(gòu)架 18應(yīng)用要點(diǎn) 18結(jié)束語(yǔ) 19附錄.術(shù)語(yǔ)表 20導(dǎo)論作為構(gòu)建大規(guī)模的C/S應(yīng)用系統(tǒng)的體系結(jié)構(gòu)，三層構(gòu)架已經(jīng)得到實(shí)踐的檢驗(yàn)和人們的認(rèn)可，成為企業(yè)關(guān)鍵應(yīng)用的唯一可靠和成熟的選擇模式。Tuxedo作為三層架構(gòu)體系結(jié)構(gòu)中的關(guān)鍵部件－中間件，在各行各業(yè)發(fā)揮著越來(lái)越大的作用。在本文中，BEA(中國(guó))有限公司上海辦事處把在幫助客戶(hù)構(gòu)建三層架構(gòu)應(yīng)用中所積累的經(jīng)驗(yàn)進(jìn)行總結(jié)，供客戶(hù)在運(yùn)用Tuxedo構(gòu)建企業(yè)級(jí)關(guān)鍵大規(guī)模C/S應(yīng)用系統(tǒng)時(shí)參考。本文檔作為論述Tuxedo的高級(jí)資料，需要讀者初步掌握Tuxedo，有一定的使用經(jīng)驗(yàn)。1.1企業(yè)應(yīng)用框架架構(gòu)的演變和發(fā)展1.1.1聯(lián)機(jī)事務(wù)處理系統(tǒng)(OLTP)的特點(diǎn)和要求1.1.2企業(yè)OLTP框架的演變歷史1.2Tuxedo的歷史發(fā)展作為最開(kāi)放的交易中間件產(chǎn)品和事實(shí)上的中間件標(biāo)準(zhǔn)，Tuxedo的歷史是和開(kāi)放系統(tǒng)的化身Unix的歷史是緊密不可分的。1969年，貝爾實(shí)驗(yàn)室的工程師KenThompson最初創(chuàng)建Unix的時(shí)候，Unix實(shí)際上是一個(gè)單用戶(hù)的操作系統(tǒng)，就象MS-DOS一樣，只不過(guò)它比DOS要強(qiáng)壯的多。關(guān)于Unix的歷史，讀者可以從任何一本介紹Unix的書(shū)籍中獲得，這里我們不多重復(fù)。當(dāng)多任務(wù)的功能加入到Unix以后，最初的Unix內(nèi)核缺少一個(gè)非常重要的功能：如何在不同的進(jìn)程之間通訊。這個(gè)功能主要是通過(guò)原始的管道和磁盤(pán)文件等拙劣的方式來(lái)滿(mǎn)足的。為了改進(jìn)這個(gè)方面，Unix內(nèi)核作為擴(kuò)展的選項(xiàng)，加入了我們現(xiàn)在非常熟悉的“進(jìn)程間通訊”(Inter-ProcessCommunication，簡(jiǎn)稱(chēng)IPC)。IPC功能的引入完全是內(nèi)部需要的驅(qū)動(dòng)，而它的意義確實(shí)非常大的。當(dāng)初貝爾實(shí)驗(yàn)室開(kāi)發(fā)Unix的一個(gè)目的就是想在實(shí)際的項(xiàng)目中使用這個(gè)操作系統(tǒng)。當(dāng)IPC引入到Unix以后，貝爾實(shí)驗(yàn)室的工程師們很快地圍繞這個(gè)特性，建立了一套工具，并且把這套工具應(yīng)用在他們的實(shí)際項(xiàng)目中。這些工具就形成了后來(lái)的BEATuxedo的核心部分。Tuxedo的最初形態(tài)是一些幫助用戶(hù)構(gòu)建不同進(jìn)程間通訊的函數(shù)庫(kù)。這些工具在很多AT&T的著名的項(xiàng)目中得到了應(yīng)用和實(shí)踐的檢驗(yàn)，非?？煽?。與此同時(shí)，AT&T內(nèi)部開(kāi)始產(chǎn)生了為Unix開(kāi)發(fā)數(shù)據(jù)庫(kù)的興趣，因?yàn)楫?dāng)時(shí)沒(méi)有商業(yè)化的數(shù)據(jù)庫(kù)系統(tǒng)。這些興趣導(dǎo)致了AT&T的UNITS項(xiàng)目(UNITS是UNIXTransactionSystem的簡(jiǎn)稱(chēng))。這個(gè)項(xiàng)目產(chǎn)生了兩個(gè)不同的產(chǎn)品：DUX和TUX。DUX(DatabaseforUniX的簡(jiǎn)稱(chēng))為Unix實(shí)現(xiàn)了一個(gè)SQL數(shù)據(jù)庫(kù)的引擎，該引擎為外部獨(dú)立的事務(wù)管理器(TM:TransactionManager)留了一些管理接口。DUX后來(lái)變成了BEATuxedo的“/D”的部件。但是由于其它商業(yè)數(shù)據(jù)庫(kù)系統(tǒng)，例如Oracle、Sysbase、Informix的興起，這個(gè)部件逐漸被廢棄了。TUX(TransactionsforUniX)是負(fù)責(zé)保證事務(wù)完整性的引擎，這個(gè)引擎后來(lái)演變成Tuxedo的“/T”部件，這是BEATuxedo的核心部件。TUX也就成為了BEATuxedo的命名的來(lái)源。在傳統(tǒng)的數(shù)據(jù)庫(kù)管理系統(tǒng)產(chǎn)品（如Oracel、Informix、Sysbase等）中，事務(wù)的范圍局限在本地的一個(gè)進(jìn)程內(nèi)部。這是數(shù)據(jù)庫(kù)編程的一個(gè)基本假設(shè)，而且至今還是這個(gè)樣子。TUX和DUX是兩個(gè)獨(dú)立的產(chǎn)品，但是它們兩個(gè)可以配合使用，并且引入了一個(gè)重要的概念：分布式事務(wù)處理(DistributedTransaction)。在分布式事務(wù)處理中，事務(wù)的范圍突破了單個(gè)進(jìn)程的限制。每個(gè)進(jìn)程是一個(gè)大事務(wù)的臨時(shí)參與者而已。TUX使用底層的消息傳遞機(jī)制來(lái)為應(yīng)用開(kāi)發(fā)提供了一個(gè)穩(wěn)固的框架。在這個(gè)框架中，TUX負(fù)責(zé)管理和跟蹤應(yīng)用的數(shù)據(jù)流，使得分布式事務(wù)的管理和監(jiān)控對(duì)應(yīng)用程序是透明的。TUX和DUX配合使用，使得TUX的事務(wù)管理器TM能夠做兩件事情：第一，TM負(fù)責(zé)通知DUX的數(shù)據(jù)庫(kù)作為單個(gè)的參與者“參與”一個(gè)“全程”的事務(wù)；第二，TM在外部可以根據(jù)全局事務(wù)的狀態(tài)來(lái)控制單個(gè)參與者的提交或者回滾。TUX/DUX實(shí)際上提供了一個(gè)從應(yīng)用程序角度來(lái)看待數(shù)據(jù)庫(kù)的抽象的模型。當(dāng)商業(yè)數(shù)據(jù)庫(kù)系統(tǒng)開(kāi)始越來(lái)越流行的時(shí)候，TUX/DUX的接口被提交給國(guó)際標(biāo)準(zhǔn)組織X/OPEN，作為標(biāo)準(zhǔn)的TM和數(shù)據(jù)庫(kù)的集成的工業(yè)標(biāo)準(zhǔn)。經(jīng)過(guò)少量無(wú)關(guān)大局的修改以后，這個(gè)標(biāo)準(zhǔn)，就是大家熟悉的XA標(biāo)準(zhǔn)，被大多數(shù)數(shù)據(jù)庫(kù)系統(tǒng)支持，而且也得到了所有的“開(kāi)放系統(tǒng)事務(wù)管理器”的支持。這個(gè)最初發(fā)源于Tuxedo的標(biāo)準(zhǔn)成為所有交易中間件的標(biāo)準(zhǔn)，也是Tuxedo自豪的一個(gè)地方。與此同時(shí)，TUX為開(kāi)發(fā)和管理多任務(wù)的應(yīng)用系統(tǒng)提供了一個(gè)非常良好的框架。這個(gè)框架在很多AT&T的著名的大型項(xiàng)目中得到實(shí)踐的檢驗(yàn)和認(rèn)可。基于這個(gè)原因，除了它的分布式事務(wù)管理器的功能以外，BEATuxedo作為應(yīng)用系統(tǒng)開(kāi)發(fā)框架的價(jià)值也被迅速地認(rèn)可。隨著時(shí)間的流逝，越來(lái)越多的關(guān)鍵功能被加入到BEATuxedo中來(lái)，這些功能包括：基于LAN的服務(wù)器集群、不同的服務(wù)器可以參與全局事務(wù)、對(duì)大型機(jī)的支持、允許從遠(yuǎn)端的客戶(hù)端發(fā)起全局事務(wù)、安全管理、對(duì)各種通訊模式的支持等等。BEATuxedo越來(lái)越成為支持企業(yè)關(guān)鍵業(yè)務(wù)的多層應(yīng)用的核心部件。今天，經(jīng)過(guò)十幾年的發(fā)展和無(wú)數(shù)世界范圍內(nèi)的大型和超大型的應(yīng)用實(shí)踐的考驗(yàn)，BEATuxedo已經(jīng)成為高性能的、具有藝術(shù)般品質(zhì)的企業(yè)關(guān)鍵應(yīng)用的引擎。現(xiàn)在BEATuxedo已經(jīng)可以支持超過(guò)80種的Unix平臺(tái)，也支持Windows-NT/2000、Open-VMS等操作系統(tǒng)。Tuxedo是基于C寫(xiě)成的，但是它作為BEA公司的旗艦產(chǎn)品，緊跟著世界IT技術(shù)的發(fā)展潮流，已經(jīng)開(kāi)始支持Java、Web管理、CORBA等代表未來(lái)發(fā)展方向的技術(shù)。Tuxedo體系結(jié)構(gòu)和設(shè)計(jì)思想2.1Tuxedo整體結(jié)構(gòu)和各個(gè)組成部分2.1.1Tuxedo整體結(jié)構(gòu)2.1.2Tuxedo服務(wù)器端2.1.3Tuxedo客戶(hù)端2.1.4Tuxedo的Domain2.1.5Tuxedo的Q2.1.6Tuxedo的安全2.1.7Tuxedo的管理框架Tuxedo的基本管理框架是基于標(biāo)準(zhǔn)的SNMP協(xié)議。它是建立在MIB(ManagementInformationBase)基礎(chǔ)上的一種“管理者/代理”的模型上的。Tuxedo的MIB允許管理者在一個(gè)集中的配置信息庫(kù)中定義組成應(yīng)用系統(tǒng)的硬件、軟件和網(wǎng)絡(luò)連接等部件。這個(gè)配置信息庫(kù)的控制粒度非常細(xì)微，提供了對(duì)Tuxedo以及應(yīng)用的全面細(xì)致的控制。例如，應(yīng)用設(shè)計(jì)者可以指定哪些Server和Service跑在哪臺(tái)機(jī)器上；當(dāng)服務(wù)器出現(xiàn)故障的時(shí)候，系統(tǒng)如何遷移；每個(gè)應(yīng)用服務(wù)進(jìn)程的優(yōu)先級(jí)別、超時(shí)時(shí)間等等。2.2Tuxedo高可靠性的設(shè)計(jì)思想評(píng)述TUXEDO的運(yùn)行管理機(jī)制提供了對(duì)軟件錯(cuò)誤的自動(dòng)監(jiān)控和修復(fù)功能。每個(gè)物理的節(jié)點(diǎn)、網(wǎng)絡(luò)連接、應(yīng)用進(jìn)程、客戶(hù)端以及Tuxedo本身的管理進(jìn)程（包括DBBL、BBL、BRIDGE等）都被自動(dòng)監(jiān)控起來(lái)。而且當(dāng)出現(xiàn)錯(cuò)誤的時(shí)候，Tuxedo會(huì)自動(dòng)嘗試去修復(fù)這些錯(cuò)誤，不需要管理員的人工干預(yù)。Tuxedo的事件機(jī)制允許出現(xiàn)錯(cuò)誤的時(shí)候有相應(yīng)的事件被觸發(fā)，而這些被觸發(fā)的事件可以被應(yīng)用進(jìn)程所捕獲。這種機(jī)制進(jìn)一步提高了的Tuxedo的監(jiān)控能力。當(dāng)Tuxedo出現(xiàn)錯(cuò)誤的時(shí)候，相應(yīng)的信息被記錄在Tuxedo的日志文件(ULOG)里面，可以供事后分析使用。缺省的日志記錄是每臺(tái)物理機(jī)器每天產(chǎn)生一個(gè)對(duì)應(yīng)本機(jī)的日志文件。BEA的ManagerLogCentral可以統(tǒng)一管理這些分布式的日志文件。下圖表現(xiàn)了Tuxedo是如何自動(dòng)對(duì)各個(gè)部件進(jìn)行監(jiān)控和錯(cuò)誤恢復(fù)的。節(jié)點(diǎn)之間的監(jiān)控DBBL進(jìn)程定期向各個(gè)節(jié)點(diǎn)的BBL進(jìn)程發(fā)送詢(xún)問(wèn)消息包。各個(gè)節(jié)點(diǎn)的BBL收到該詢(xún)問(wèn)消息包以后，會(huì)向DBBL發(fā)送類(lèi)似“IAMOK”的消息。這種機(jī)制可以稱(chēng)作“軟件心跳線”，類(lèi)似硬件容錯(cuò)使用的硬件心跳線。如果DBBL在詢(xún)問(wèn)某個(gè)BBL的時(shí)候沒(méi)有得到該BBL的應(yīng)答，則master節(jié)點(diǎn)將嘗試去啟動(dòng)相應(yīng)服務(wù)器上的BBL進(jìn)程。如果該節(jié)點(diǎn)上的BBL不能被啟動(dòng)，則該節(jié)點(diǎn)被標(biāo)記為”partitioned”的狀態(tài)。當(dāng)負(fù)責(zé)節(jié)點(diǎn)之間通訊的BRIDGE進(jìn)程因?yàn)橥ㄓ嵆瑫r(shí)而導(dǎo)致DBBL收不到BBL的回應(yīng)的時(shí)候，也可能導(dǎo)致這種”partitioned”狀態(tài)的出現(xiàn)。由于DBBL無(wú)法確定節(jié)點(diǎn)分離的持續(xù)時(shí)間，所以被偵測(cè)到的處于partitioned狀態(tài)的節(jié)點(diǎn)并不是自動(dòng)從整個(gè)系統(tǒng)中脫離，Tuxedo會(huì)拋出一個(gè)系統(tǒng)事件表明這個(gè)事件的發(fā)生，并且會(huì)在日志文件里面做記錄。當(dāng)節(jié)點(diǎn)分離是暫時(shí)的，例如由于BRIDGE通訊流量超過(guò)負(fù)荷而導(dǎo)致的，則DBBL和BBL的這種心跳連接稍后重新嘗試，直到自動(dòng)恢復(fù)。這種情況往往發(fā)生在系統(tǒng)負(fù)荷太大（客戶(hù)端請(qǐng)求太頻繁），超過(guò)服務(wù)器的承載能力的情況下。系統(tǒng)管理員可以在事后通過(guò)查閱系統(tǒng)日志來(lái)察覺(jué)這種情況的發(fā)生。當(dāng)問(wèn)題非常嚴(yán)重，被分離的節(jié)點(diǎn)永久地和其它節(jié)點(diǎn)脫離以后，需要系統(tǒng)管理員通過(guò)管理命令(tmadmin中的pclean)將該分離節(jié)點(diǎn)從整個(gè)系統(tǒng)中脫離開(kāi)來(lái)，其余節(jié)點(diǎn)會(huì)依然組成一個(gè)獨(dú)立的系統(tǒng)，繼續(xù)運(yùn)轉(zhuǎn)。該分離節(jié)點(diǎn)上的服務(wù)不涉及到和其它節(jié)點(diǎn)通訊的時(shí)候可以繼續(xù)為客戶(hù)端提供服務(wù)。除了DBBL對(duì)BBL進(jìn)行檢查以外，BBL會(huì)監(jiān)控DBBL的狀態(tài)，必要時(shí)也嘗試去重新啟動(dòng)DBBL。但是當(dāng)DBBL無(wú)法啟動(dòng)的時(shí)候，就需要手工地將運(yùn)行DBBL的master節(jié)點(diǎn)遷移到備用節(jié)點(diǎn)上（通過(guò)tmadmin的migrate命令）進(jìn)程的狀態(tài)檢查BBL進(jìn)程會(huì)定期檢查運(yùn)行在本地節(jié)點(diǎn)的進(jìn)程（包括應(yīng)用進(jìn)程和其它Tuxedo系統(tǒng)進(jìn)程）。當(dāng)有錯(cuò)誤被檢測(cè)到以后，TUXEDO會(huì)將正在進(jìn)行的事務(wù)終止，必要的情況下根據(jù)配置重新啟動(dòng)應(yīng)用服務(wù)進(jìn)程。這個(gè)時(shí)候，正在被處理的交易請(qǐng)求可能丟失，但是交易請(qǐng)求方會(huì)得到通知，以便采取適當(dāng)?shù)男袆?dòng)（例如：重新發(fā)送這筆請(qǐng)求）。等待在消息隊(duì)列里面尚未被處理的交易請(qǐng)求包將在應(yīng)用進(jìn)程重新啟動(dòng)后繼續(xù)得到處理。當(dāng)應(yīng)用進(jìn)程被重新啟動(dòng)的時(shí)候，用戶(hù)可以指定讓Tuxedo啟動(dòng)用戶(hù)事先指定好的一個(gè)應(yīng)用進(jìn)程。這種機(jī)制為客戶(hù)提供了靈活的控制手段。BBL也對(duì)客戶(hù)端進(jìn)程進(jìn)行監(jiān)控。對(duì)于本地的客戶(hù)端進(jìn)程，BBL對(duì)其的監(jiān)控和對(duì)應(yīng)用服務(wù)進(jìn)程的監(jiān)控是一樣的。另外本地客戶(hù)端進(jìn)程有一個(gè)超時(shí)的概念，當(dāng)超時(shí)發(fā)生的時(shí)候，BBL也認(rèn)為客戶(hù)端進(jìn)程出現(xiàn)問(wèn)題，會(huì)斷開(kāi)客戶(hù)端和Tuxedo的連接。對(duì)于遠(yuǎn)端的客戶(hù)進(jìn)程管理，BBL只能監(jiān)控網(wǎng)絡(luò)連接。當(dāng)在一定時(shí)間中，遠(yuǎn)端客戶(hù)進(jìn)程的網(wǎng)絡(luò)連接處于不活動(dòng)狀態(tài)，則BBL會(huì)自動(dòng)斷開(kāi)網(wǎng)絡(luò)連接，需要遠(yuǎn)端的客戶(hù)進(jìn)程重新連接和登錄。網(wǎng)絡(luò)連接BRIDGE進(jìn)程是負(fù)責(zé)提供各個(gè)服務(wù)器節(jié)點(diǎn)之間的通訊的。根據(jù)用戶(hù)的配置，一個(gè)BRIDGE進(jìn)程可以維護(hù)多個(gè)網(wǎng)絡(luò)連接。這些網(wǎng)絡(luò)連接被賦予不同的優(yōu)先級(jí)別。BRIDGE對(duì)這些網(wǎng)絡(luò)連接的使用策略如下：BRIDGE優(yōu)先使用優(yōu)先級(jí)最高的網(wǎng)絡(luò)連接進(jìn)行通訊。當(dāng)優(yōu)先級(jí)最高的網(wǎng)絡(luò)連接發(fā)生故障的時(shí)候，BRIDGE會(huì)自動(dòng)選擇優(yōu)先級(jí)次之的網(wǎng)絡(luò)連接進(jìn)行通訊。同時(shí)BRIDGE進(jìn)程會(huì)定期檢測(cè)優(yōu)先級(jí)別最高的網(wǎng)絡(luò)進(jìn)程是否恢復(fù)。一旦恢復(fù)，則BRIDGE會(huì)重新使用優(yōu)先級(jí)別最高的網(wǎng)絡(luò)連接。如果正在使用的網(wǎng)絡(luò)連接由于傳輸流量過(guò)大而發(fā)生阻塞情況的話，BRIDGE會(huì)啟用優(yōu)先級(jí)相同的另外一條備份網(wǎng)絡(luò)連接進(jìn)行網(wǎng)絡(luò)傳輸，從而增大了網(wǎng)絡(luò)傳輸?shù)耐掏铝俊Ｔ诜?wù)器配置多個(gè)網(wǎng)卡的時(shí)候，可以利用BRIDGE的這些特性將不同的網(wǎng)絡(luò)連接配置在不同的網(wǎng)卡中進(jìn)行，這樣當(dāng)某個(gè)網(wǎng)卡出現(xiàn)物理故障的時(shí)候，不影響Tuxedo的運(yùn)行。如果想利用BRIDGE的多條網(wǎng)絡(luò)連接同時(shí)傳輸數(shù)據(jù)，增大網(wǎng)絡(luò)流量，可以將這多條網(wǎng)絡(luò)連接的優(yōu)先級(jí)設(shè)置成為相同。BRIDGE對(duì)網(wǎng)絡(luò)通訊的監(jiān)控是采用超時(shí)機(jī)制，當(dāng)BRIDGE檢測(cè)到超時(shí)發(fā)生的時(shí)候，它會(huì)嘗試著重新建立網(wǎng)絡(luò)連接。如果某個(gè)節(jié)點(diǎn)的全部網(wǎng)絡(luò)連接都無(wú)法和其它節(jié)點(diǎn)連接的時(shí)候，DBBL會(huì)將該節(jié)點(diǎn)標(biāo)記為partitioned狀態(tài)。其余節(jié)點(diǎn)會(huì)自動(dòng)組成一個(gè)完整的系統(tǒng)。分離的節(jié)點(diǎn)也可以繼續(xù)為客戶(hù)端提供服務(wù)。Tuxedo對(duì)事務(wù)的控制2.3Tuxedo高擴(kuò)展性的設(shè)計(jì)思想評(píng)述2.4Tuxedo高性能的設(shè)計(jì)思想評(píng)述Tuxedo應(yīng)用的設(shè)計(jì)原則和經(jīng)驗(yàn)Tuxedo為用戶(hù)開(kāi)發(fā)應(yīng)用程序提供了一個(gè)高性能、高穩(wěn)定性的框架。用戶(hù)可以在這個(gè)框架內(nèi)做任意想做的工作。但是為了提高整個(gè)系統(tǒng)的性能和穩(wěn)定性，也需要遵循一些基本原則。在本章中，我們把BEA公司在幫助客戶(hù)構(gòu)建系統(tǒng)時(shí)積累的經(jīng)驗(yàn)進(jìn)行總結(jié)，系統(tǒng)整理出來(lái)，供客戶(hù)設(shè)計(jì)應(yīng)用系統(tǒng)時(shí)候參考。負(fù)載均衡包括負(fù)載均衡的概念，如何設(shè)置負(fù)載均衡，LOAD/NETLOAD，隊(duì)列的優(yōu)先級(jí)，MSSQ的使用，SPINCOUNT,CMPLIMT，負(fù)載均衡的例子如何劃分Tuxedo的Server和Service?在Tuxedo中，Server可以理解成為Unix的一個(gè)進(jìn)程，Service可以理解成為應(yīng)用進(jìn)程Server中的一個(gè)函數(shù)。在Tuxedo7.1以后版本中增加了對(duì)線程的支持，Server可以理解成為線程，但是這無(wú)關(guān)大局，我們依然用上面的理解來(lái)討論下面的問(wèn)題。用戶(hù)可以任意劃分Server和Service：既可以把所有的Service放在一個(gè)單一的Server中，也可以采用“一個(gè)Service一個(gè)Server”的方式。Tuxedo對(duì)此沒(méi)有任何限制。如果一個(gè)Service可以理解成獨(dú)立的工作單元，每個(gè)Service負(fù)責(zé)一個(gè)獨(dú)立、完整的商業(yè)業(yè)務(wù)流程，那么我們可以討論一下關(guān)于如何劃分Server和Service來(lái)提高整個(gè)系統(tǒng)的性能和可管理性。一個(gè)最基本的原則就是盡量將“類(lèi)似的Service”捆綁在一個(gè)Server之內(nèi)。所謂“類(lèi)似的Service”是指這些函數(shù)有相同的大小、復(fù)雜度或者功能（例如：都是查詢(xún)數(shù)據(jù)庫(kù)或者都是進(jìn)行計(jì)算）。為什么要這樣呢，我們來(lái)考慮一個(gè)極端的例子：假設(shè)一個(gè)ServiceA是完成非常簡(jiǎn)單工作的，它的平均執(zhí)行時(shí)間是100毫秒。另一個(gè)ServiceB進(jìn)行數(shù)據(jù)庫(kù)的查詢(xún)，它的執(zhí)行時(shí)間可能長(zhǎng)達(dá)20秒。如果將這兩個(gè)Service捆綁在一起，會(huì)出現(xiàn)什么現(xiàn)象呢？大家知道，操作系統(tǒng)的基本調(diào)度單位是進(jìn)程（或者線程）。在一個(gè)進(jìn)程中的Service執(zhí)行是串行的。Tuxedo把發(fā)往同一個(gè)Server的請(qǐng)求交易包放在同一個(gè)消息隊(duì)列中。當(dāng)ServiceB在執(zhí)行的時(shí)候，ServiceA的請(qǐng)求包必須在隊(duì)列里面等待20秒以上才可能被執(zhí)行，雖然它的執(zhí)行時(shí)間僅僅100毫秒。這顯然是不能容忍和應(yīng)該避免的。實(shí)際上，用戶(hù)在設(shè)計(jì)和開(kāi)發(fā)應(yīng)用程序的時(shí)候，并不能完全估計(jì)出每個(gè)Service的執(zhí)行時(shí)間和頻度。所以對(duì)Server和Service的劃分是在應(yīng)用程序開(kāi)發(fā)完畢后進(jìn)行調(diào)整的。調(diào)整的依據(jù)就是在系統(tǒng)測(cè)試的時(shí)候記錄每個(gè)Service的執(zhí)行時(shí)間和頻度，然后根據(jù)這些數(shù)據(jù)來(lái)進(jìn)行優(yōu)化調(diào)整。好在Tuxedo對(duì)Server和Service的劃分非常簡(jiǎn)單靈活，這些工作做起來(lái)工作量并不是很大。下面就是我們對(duì)在實(shí)際當(dāng)中獲得的經(jīng)驗(yàn)的一些系統(tǒng)總結(jié)。規(guī)則一：詳細(xì)注釋每個(gè)Service這實(shí)際上是一個(gè)軟件工程方面的規(guī)則。Tuxedo基于的模型是三層體系結(jié)構(gòu)。將用戶(hù)界面的開(kāi)發(fā)和商業(yè)邏輯的開(kāi)發(fā)分離開(kāi)來(lái)了。在一個(gè)實(shí)際的項(xiàng)目中，一般需要兩方面的開(kāi)發(fā)人員，一部分開(kāi)發(fā)人員負(fù)責(zé)用戶(hù)界面的開(kāi)發(fā)工作，這些人員最熟練的技巧往往是HTML、Java、VisualC++、Delphi、C++Builder、PowerBuilder、VisualBasic等等。而另一部分開(kāi)發(fā)人員負(fù)責(zé)商業(yè)邏輯的開(kāi)發(fā)，這些人員最熟練的技巧往往是在Unix環(huán)境下的Oracle和C/C++。Tuxedo的Service是獨(dú)立完整的商業(yè)邏輯的入口函數(shù)，所有的Service在Tuxedo中具有相同的聲明結(jié)構(gòu)。另外，大型的商業(yè)項(xiàng)目的Service往往幾百個(gè)甚至上千個(gè)。為了整個(gè)項(xiàng)目的可管理性，應(yīng)該對(duì)每個(gè)Service的開(kāi)頭進(jìn)行注釋?zhuān)砻鬟@個(gè)Service的入口和出口參數(shù)是什么，主要執(zhí)行什么功能。一個(gè)推薦的方法是制作一個(gè)通用的Service模版，開(kāi)發(fā)人員創(chuàng)建一個(gè)新的Service的時(shí)候不需要從頭開(kāi)始。下面是一個(gè)可以供參考的Service模版：GeneralDescriptionVersionNumber:ApplicationName(s):ServiceName:ServiceRoutine:SourceFileName:BusinessorDataAccessService:ResourcesAccessed:QueryorUpdateService:Request/ResponseorConversational:RoutingField:ServicePriority:ServiceLoadFactor:MeanInputBufferSize:MeanreturnedbuffersizeMeanExecutionTime:90%ExecutionTimeMeanCallFrequencyXact/hour:PeakCallFrequencyXact/hour:Constraints:e.g.only10instancesofthisservicecanexistServicesCalledatBoot-Time:Services