一、中間件技術在系統設計規劃方面的經驗總結
1.1、中間件應用架構的選擇
這種架構選擇的焦點就是業務邏輯到底是放在前臺應用中還是放在後臺中間件應用中。其實，引入中間件平臺的原因之一就是業務邏輯的集中管理，出現這種爭論的原因主要是開發商對這種業務邏輯集中的理解不深，在應用設計的過程中仍然沒有擺脫以前兩層結構的影響，再加上因爲業務邏輯集中會增加程序開發量，纔出現了這種情況。我們認爲，把業務邏輯集中在中間件服務器上不僅對於業務邏輯的集中管理有好處，而且對於系統的後期運行維護、軟件的升級管理都有着明顯的優勢。當然,在開發的工作量方面，業務邏輯集中時工作量大很多。
1.2、中間件服務分佈的設計和優化原則
在Tuxedo中，Server可以理解成爲Unix的一個進程，Service可以理解成爲應用進程Server中的一個函數。用戶可以任意劃分Server和Service：既可以把所有的Service放在一個單一的Server中，也可以採用“一個Service一個Server”的方式。Tuxedo對此沒有任何限制。
中間件應用的性能直接影響到營業前臺服務的穩定性和連續性，而影響中間件應用性能的因素除了硬件資源的保證、數據庫響應時間、中間件應用軟件本身的質量之外，中間件應用服務的分佈也起着至關重要的作用。我們有着這樣的一個例子，在前臺進入收費界面的時候，應用程序需要調用一個SERVICE名字叫A，A分佈在一個叫SA的server中，而SA中又包含着很多其他的在線統計的SERVICE B，結果造成了SA響應B調用的時候執行時間比較長，所有的SA都在執行SERVICE B ，前臺請求SERVICE A得不到響應，收費的界面怎麼都進不去，從而導致前臺收費業務中斷。這就是個典型的因爲服務分佈不當造成的系統故障。
我們在系統規劃設計過程中遵循的一個最基本原則就是儘量將“類似的Service”捆綁在一個Server之內。所謂“類似的Service”是指這些函數有相似的大小、執行時間、複雜度或者功能。我們來考慮一個極端的例子：假設一個Service A是完成非常簡單工作的，它的平均執行時間是100毫秒。另一個Service B進行數據庫的查詢，它的執行時間可能長達20秒。如果將這兩個Service捆綁在一起使用，就會出現非常嚴重的後果。大家知道，操作系統的基本調度單位是進程。在一個進程中的Service執行是串行的。Tuxedo把發往同一個Server的請求交易包放在同一個消息隊列中。當Service B在執行的時候，Service A的請求包必須在隊列裏面等待20秒以上纔可能被執行，雖然它的執行時間僅僅100毫秒。這顯然是不能容忍和應該避免的。
實際上，用戶在設計和開發應用程序的時候，並不能完全估計出每個Service的執行時間和頻度。所以對Server和Service的劃分優化是在應用程序開發完畢後進行調整的。調整的依據就是在系統運行的時候記錄每個Service的執行時間和頻度，然後根據這些數據來進行優化調整。下面就是我們在實際當中獲得經驗的一些系統總結。
1、 區分Service的不同類型：是業務操作還是簡單的數據訪問
在中間件應用中的Service可以進一步細分成負責完成業務操作和負責數據訪問的兩種類型。在設計的時候，最好把這兩種不同類型的Service區別出來。所謂完成業務操作的類型其實就是進行數據修改的操作，負責數據訪問的類型其實就是進行數據查詢的操作。但是在實際的系統運行過程中，凡是涉及到數據修改的操作過程中必然會有數據查詢的操作，這種類型的操作也應該規整到第1種類型中去。
2、 請求/響應類型的Service要和會話Service分開在不同的Server中
在Tuxedo中，一個Server要麼支持請求/響應類型類型的Service，要麼支持會話方式的Service。會話方式和請求/響應方式是兩種互斥的通訊方式。請求/響應方式效率比較高，是使用最頻繁的通訊類型。Tpcall/tpacall/tpforward都是這種類型的函數。會話方式適合大量的數據傳輸，但是它的代價是效率的下降。所以這兩種類型的Service要分開放在不同的Server裏面。
3、 執行時間相似的Service放在同一個Server裏面
在Tuxedo應用環境中，可能有成百上千的Service，這些Service的執行時間顯然是不同的。對於單線程的Server來說，雖然它可能有多個Service，但是這些Service的執行是串行的。如果某個Server擁有兩個Service，A和B。A的執行時間是100ms，B的執行時間是1000ms，也就是說執行一次B的時間可以執行十次A。那麼當B在執行的時候，可能會有十個A在隊列裏面等待。這種情況會急劇降低該Server處理Service的吞吐率。因此很自然的一個原則是把執行時間相似的Service放在同一個Server裏面。
4、 具有相同執行頻度的Service放在同一個Server裏面
在一個典型的Tuxedo應用系統中，並不是所有的Service的執行頻率都是相同的。可能一些Service被頻繁的執行，而另外一些Service只是偶爾才被執行幾次。把這些SERVICE分開可以避免偶爾調用的SERVICE堵塞頻繁調用的SERVICE。
5、 避免死鎖的情況發生
在Tuxedo中的死鎖情況有兩種，第一種是一個Server中的Service A去調用同在一個Server中的Service B。這種死鎖發生的原因是，對於單線程的Server來說，它其中的Service是串行執行的。Service A去調用Service B的時候，Service A還沒有執行完，它等待Service B的返回結果。 但是Service B不能執行，因爲該Server還處於執行Service A的狀態。最終導致Service A超時而出錯。
第二種情況是兩個Server中的Service互相調用。例如Server1和Server2，Server1中的Service A去調用Server2中的Service X。同時Server2中的Service Y去調用Server1中的Service B。這種情況發生的死鎖和第一種情況非常類似，都是因爲進程只能串行實行Service導致的。
這兩種死鎖情況在應用設計時特別要注意避免。第一種情況是比較容易察覺的，但是第二種情況就不大容易察覺。
1.3、中間件系統應用平臺FAILOVER方式的選擇在真實的生產運行環境中，運行平臺的failover是一個必須考慮的問題。Tuxedo平臺上的實現failover機制基本上有兩種，一種是利用tuxedo自己的failover機制配合前臺配兩個WSNADDR地址來實現failover。一種是利用雙機軟件來實現。
第一種方式是指使兩臺的中間件服務器處於MP工作模式下，在每一臺都啓動WSL進程，然後在中間件前臺配置兩個ip地址。通過自己實驗發現利用tuxedo自己的failover機制只有如下好處即不需要額外的操作系統和軟件的支持，但是其缺點確很多，主要缺點如下：
1、兩臺中間件平臺的MASTER切換必須要手工完成，無法自動完成。
2、前臺配置的兩個WSNADDR地址，如果第一個地址失敗，要重新連接到第二個地址需要很長的時間，並且在每次服務調用時都要等待同樣的時間。
通過雙機軟件來實現FAILOVER是指兩臺中間件服務器都配置在SHP模式下，然後利用雙機軟件的ip切換功能來實現failover。這種方法需要在各自的配置文件中加入另外一臺主機的WSL的信息，在另外一臺主機故障時，通過雙機軟件進行IP切換，再通過雙機切換腳本將這臺主機的備用WSL啓動即可。採用這種方式有以下優點
1、機器切換自動完成，不需要人工干預。
2、前臺業務不受影響，能保證業務開展的連續性。
缺點主要有
1、在正常情況下，每一臺主機的啓動中間件時，備用的WSL服務會啓動失敗，不過這不影響正常使用，備用的WSL只在另外一臺主機故障後才起作用。
2、需要額外的雙機配置和腳本配置工作。
經過這些比較，我們選定了採用雙機軟件的方案實現了中間件的failover機制。在以後的運行維護過程中起到了好的效果。
1.4、中間件與數據庫的連接方式的選擇在TUXEDO中間件應用中連接數據庫的方式有兩種，一種爲通過XA方式連接數據庫，另外一種是在應用程序中自己連接數據庫。
通過XA方式連接數據庫是指利用關係型數據庫的XA接口，在tuxedo的配置文件中的OPENINFO段中加入連接信息，然後在server程序的初始化代碼的中調用中tp_open（或xa_open），當SERVER啓動時進行數據庫連接。
通過應用程序直接連接數據庫，數據庫的連接操作不一定是在SERVER啓動時進行的。
這兩種方式的連接在BOSS系統中都會用到，其中的區別主要就在於如果業務操作的事務爲分佈式事務時，則必須要用XA方式。詳細比較如下：
1、通過XA連接的方式可以實現分佈式事務，即能夠保證事務在不同數據庫中的一致性。但是正是因爲如此，它對中間件系統和數據庫系統都有額外的開銷，有時候這種開銷甚至會影響系統的性能。
2、通過應用程序直連數據庫的方法不能夠實現分佈式事務，但是同時也因此減少了對系統的壓力。
綜上，選擇數據庫的連接方式對整個系統的性能影響也是至關重要的，我們有個原則，凡是在不涉及到分佈式事務的地方就不用XA連接。過多的依賴了XA接口，會給系統帶來了許多額外的負擔和壓力，也會造成許多額外的故障。
二、中間件技術在系統維護方面的經驗總結在中間件的日常維護中，我們瞭解了一些TUXEDO的基本知識，摸索了一套行之有效的故障排除方法，積累了一些常見故障的排除經驗，現在與大家介紹如下：
2.1、LICENSE數的問題tuxedo的license由文本文件lic.txt來控制，位於udataobj目錄下，分爲SDK/RTK兩種，兩種LICENSE不能合併使用。它控制的是併發用戶數並且有10%的冗餘，這裏的併發用戶數是指在某一時刻前臺程序已經發起tpinit還沒有作tpterm的連接數，所以在tuxedo中間件的使用中存在着長連接和短連接的問題。長連接是指tpinit後就開始一系列的服務調用，只在系統重啓或系統非常空閒的時候才做tpterm，而短連接是指每次服務調用前作tpinit，調用結束後立即作tpterm調用。因爲短連接下的服務調用需要額外的連接時間消耗，這對系統響應時間會有影響，而長連接又會佔用系統的併發用戶數。所以在系統設計時需要針對不同的應用情況做出不同的設計，比如針對接口類型的應用因爲服務調用比較頻繁，進行連接的時間就會佔比較大的比重，這時就需要使用長連接，而對於前臺應用類型的應用，連接過程的時間對於業務操作的時間來說是可以忽略的，這時就要用短連接來節約license資源。
2.2、客戶端連接的問題當客戶端無法連接中間件時，我們需要確認的是
1、 客戶端的WSNADDR是否設置或是否設置正確。
2、 系統配置文件中的MAXWSCLIENTS和MAXACCESS是否正確設置。
3、 WSL是否啓動，WSH的個數是否足夠。
4、 是否有防火牆，如果有防火牆存在，則需要在WSL的配置中作相應的地址映射和端口指定。
5、 操作系統是否有足夠的SCOKET資源使用。
解決了這些問題後，一般就可以解決客戶端連接不上的問題了。
在TUXEDO中，參數TMTRACE對故障的定位和排除很有作用，它是一個環境境變量。我們一般在系統監控的工作終端上將此參數設置爲on，在前臺報系統故障的時候，我們直接進入故障模塊將故障重現，然後在終端機器的c:/或者tuxedo的安裝目錄下打開一個ULOG文件，在此文件中會發現tpcall服務的失敗信息，根據這個信息查找對應的SERVER和SERVICE的對應表，很快就可以找到問題服務。採用這種方式，維護人員不需要了解程序的具體流程就可以定位錯誤解決故障。
在TUXEDO的服務端，有幾類文件需要關注，這些文件包括ULOG文件、XA接口的trc文件、數據庫連接故障的sqlnet.log、標準輸出文件stdout（也可以被應用程序自己定義）。在這些文件中包含着豐富的系統運行錯誤告警信息。ULOG記載關於中間件的啓停記錄和系統本身的一些配置運行告警信息。XA的trc文件記錄的是XA接口方面的一些的錯誤信息，關於分佈式事務的一些錯誤在這個文件中都有記錄。sqlnet.log記錄了應用程序和數據庫連接故障的信息，只要有當前日期時間的這個文件存在，應用和數據庫的連接就會存在問題。標準輸出文件stdout記錄了應用程序本身的運行信息。這些文件的跟蹤檢查對於及時主動的發現故障有着重要的意義。
2.3、事務控制的問題1、事務邊界的問題：在這裏我們要遵循誰發起發起事務，誰就結束的原則，這裏的誰主要是指中間件的前臺和後臺。我們知道在TUXEDO中事務的發起既可以在前臺程序中發起，也可以在後臺程序中發起。無論放在前臺還是放在後臺都有其優缺點。事務放在前臺增加了網絡傳輸的流量，當時可以保證異常情況下前後臺操作的一致性，事務放在後臺可以減少網絡流量，但是對於異常情況下前後臺操作的一致性很難保證。我們採用的是事務放在前臺程序中。但是無論放在前臺還是後臺，都要遵循誰發起，誰結束的原則。
2、XA接口使用的注意事項：首先是XA資源文件的配置，在oracle數據庫中一般用到的是libclntsh.a，我們可以先Make sample，提取其中用到的連接庫加入到RM文件中即可。其次在oracle8i之前要對XA進行授權，要在oracle的DBA用戶下執行grant select on dba_pending_transactions to public。
3、事務掛起的問題：在使用XA的情況下，我們經常會遇到這種情況，SERVER進程還在，可就是不做事。在相關的日誌文件中總是報“當前的進程已經在一個本地事務中了”的錯誤，這時只有重啓該SERVER，才能排除故障。其實這是一個事務控制的問題，它產生的根本原因是在開啓全局事務前，該SERVER執行了一個本地的事務並且沒有提交或回滾。在程序代碼上表現爲如下三種原因：
（1）、在調用該SERVER的某個帶DML語句的service前沒有加tpbegin。
（2）、在調用tpbegin後沒有判斷返回值。
（3）、tpbegin後的tpcall服務調用沒有判斷返回值，在全局事務超時後沒有能夠及時的退出後續的調用，導致下一個tpcall產生了一個本地事務。
此外，還會有一類比較特殊的問題，那就是TMS服務掛起的問題，利用tmadmin中的pq命令發現TMS的隊列中有很多請求存在，在這種情況下，一般只能等待其執行完成，情況嚴重時，則需要調整相應的數據庫參數，在ORACLE中該參數應該設爲max_commit_propagation_delay>=90000。
在實際的運行維護中，我們發現即使把數據庫參數調整了，有時還會有TMS掛起的故障發生。針對這件事情我們專門作了研究，TMS之所以掛起是因爲TMS在等待數據庫中DX獨佔鎖的釋放，這種獨佔鎖加鎖的對象一般都是ORACLE的系統對象，而這種獨佔鎖的產生一般是在全局事務中執行着DML語句，當這種DML語句執行比較慢時，就會引起TMS的鎖等待現象。此外，我們還發現，一般的查詢語句是不會產生鎖的（OPS的lm_lock鎖除外），但是如果將查詢放入一個全局事務中時，它就會產生一個共享的DX鎖，如果這個在全局事務中的查詢的調用是通過ORACLE的工具包DBMS_SQL來進行的話，那就會產生一個DX的排他鎖。基於這些結果，我們建議在程序的開發過程中要遵循能不用XA全局事務的情況下就不用，能將查詢放到事務之外的就不要放到事務之內，能不用ORACLE工具包進行開發的就不要用。我們也按照這個原則要求我們的開發商，取得了比較好的效果。
4、事務超時設置的問題
中間件應用系統的事務超時控制很重要，不設置超時時間對系統來說簡直就是一種災難。我們曾經就有過因爲超時時間的設置沒設和設置不當造成了嚴重的系統故障，最直接的故障就是系統報全局事務數不夠的錯誤，無法開啓新的事務，從而導致前臺業務的終止。TUXEDO的超時主要有三種，一個是在代碼中的tpbegin超時（值爲其參數）T1，他控制整個事務的完成時間，第二個爲XA連接的超時（配置文件中的open_info中的SesTm ）T2，他控制同一連接中對於分佈式事務鎖的等待超時時間，還有一個爲數據庫中等待數據庫對象非分佈式事務鎖釋放的超時時間（_dirstributed_lock_timeout）T3。這三個超時共同作用並且有如下的關係 T1
2.4、服務不能正常啓動的問題在實際的維護工作中，經常會出現服務不能正常啓動的現象。明明所有的服務都已經關閉了，tmboot就是起不來。這種原因一般是因爲系統的IPC資源沒有釋放。IPC資源是操作系統用來進行進程間通訊的系統資源，主要包括信號燈、共享內存、消息隊列。在UNIX操作系統下通過IPCS命令可以清楚的看到IPC資源的使用情況。當服務無法啓動的時觀察IPCS就會發現tuxedo運行環境的用戶下的ipc資源沒有被釋放，這時使用ipcrm命令清除相應的IPC資源，再啓動服務就可以了。
